29 Mart 2019 Cuma

Kubernetes Notlarım

KUBERNETES (K8S)


Container orkestrasyon sisteminin bir örneğidir. Google çıkışlıdır.
Şu anda cloud native computing federation tarafından geliştirilmekte ve yönetilmektedir.
200’den fazla organizasyon projeye contribute etmektedir.
Böyle bir mimariniz olduğunu düşünün. Microservislerden biri down olduğunda bunu elle restrat
edebilirsiniz. Peki ya saat 3’de bu sorun yaşansa ve kızgın müşterileriniz varsa :)
Google bu containerlardan aynı anda 2 milyar kadarını çalıştırmakta.
Siz sisteminizde 5-6 tane container çalıştırsanız bile bir container orchestration system’e ihtiyaç
duyarsınız.




Docker ile built-n gelen Swarm’da aynı işi yapar. Öğrenmesi daha kolaydır.
Ama kubernates daha zengin özelliklere sahiptir ve cloud ortamlarında platform bağımsız bir
abstraction sağlar.
Yani kubernates ayarlarınızı taşıyarak kolaylıkla platformlar arasında geçiş yapabilirsiniz.
Sonuç olarak zaman içinde değişir mi bilinmez ama kubernates çok daha populer ve yaygındır.


Kubernates’i localde test etmek için minikube uygulaması kurmamız gerekiyor.
Bu biraz karmaşık olabilir.
Minikube production ortamındaki kubernatesi emule eder.
Minkube için ilk şart bilgisayarınızın biosdan virtualization’u enabled olmalıdır.
Eğer Windows 10 pro kullanıyorsanız bilgisayarınızdaki hyper-v yeterli olacak ve sanal bir switch
tanımlamanız gerekecek. Diğer işletim sistemlerinde oracle virtualbox kuranız yeterli olacaktır.


Şimdi kubernates’e komutlarla yöneten cli kubectl ve kubernates’i emule eden minikube’u kurabiliriz.
kubectl bir binary dosya indirip bilgisayarımıza kuruyoruz.
(Daha detaylı bilgi için VPP kubernates kursuna bakılabilir)


PODS
Pod kubernates’de herbir container’ı wrap eden yapı olarak düşünülebilir.
Genelde container pod ilişkisi one to one’dır.
Aynı zamanda many to one  ilişikisi de mümkündür.
Many to one ilişikisi bir microservice’le çok yakın ilişkili iş yapan diğer microservice aynı podda
bulunabilir.
Containerlar bu senaryoda tek başlarına çalışmaları anlam ifade etmez, beraber çalışmaları gerekir.
(microservice’i loglamak gibi)
Ama unutmamak gerekirse genel yapı one to one şeklindedir.
Pod’lar kubernatisin en temel deployment birimleridir. Dik alnaı, CPU kullanımları vs gibi bilgileri
Kubernates Podlardan alabilir.


Pod yaratmak için hello world örneği:
Şimdi bir örnek uygulayalım.
Minikube’un durumuna bakalım
Evet çalışıyor.
Şimdi bir yaml dosyası oluşturalım




Dosyanın bulunduğu dizinde :




kubectl get all kubernates clusterın durumu hakkıda bilgi verir.


kubectl apply -f first-pod.yml pod’u ayağa kaldırır.


Ayağa kaldırdığımız bu pod’un çalıştığını görmek için browsera girdiğimizde bir duvarla karşılaşırız.






Pod’lar sadece cluster içinden ulaşılabilecek şekilde tasarlanmışlardır.
Bu engeli birazdan nasıl aşacağımızı göreceğiz.











Pod hakkında detaylı bi,lgi almak için :


kubectl describe pod [podName] kullanırız.
Örnek sonuç aşağıdaki gibidir.


Events bölümü pod ayağa kalkarken neler olduğu hakkında bilgi verir.


Pod üzerinde ayrıca exec ile komutlar çalıştırabiliriz. Root dizininde ls çalıştıralım :




kubectl exec -it webapp sh -> pod’un shellini açacaktır.


Açtığımız shell’de aşağıdaki komutu çalıştırırsak response alırız.




Podlar doğası itibariyle kısa ömürlüdürler.
Kubernates uzun ömürlü olarak servisleri tasarlamıştır.


Servisler ip adresine sahiptir ve podlara bağlanırlar.




Podlar’da key value şeklinde değerler tutarız. Bu şekilde servisler podara bağlanabilir.
Buradaki örnekde app:webapp şeklinde tutmuşuz..



















Servis tanımı örneği (yaml):




Burada name önemlidir çünkü iki servis bu isimlerle birbiriyle konuşuyor olacaklar.
Eğer bir yazılım mimarıysanız bu isimlendirme önemlidir ve anlamlı olmalıdır.


type: ClusterIp olarak seçersek, servis sadece cluster içinden erişilebilir.




type NodePort seçilirse servisin dışarıya açılmasını sağlarız.
Bunu yaptığımızda ports kısmında nodePort’un kaç olacağını tanımlamamız gerekir.
Kubernates bu noktada nodePortun sadece 30000’den yukarı olmasına izin verir.
Production ortamında type:loadBalancer kullanacağımızdan dışarı açılan portu istediğimiz değeri
verebiliriz.


Sonuç olarak service yaml dosyamız :




burada app:webapp containerdaki label alaının key valuesu
name fleetman ile başlayan isim
ports’daki name tanımlayıcı(bilgi verici ali’de yazabilirdik)
port containerın çıkış portu
nodePort deşarı açılan portumuz


kubectl apply -f webapp-service.yaml yaptığımızda servisimizi ayağa kaldırmış oluyoruz.
Artık minkube ip adresinden aldığımız ip’nin 30080 portundan uygulamamızı browserda
gösterbiliriz.










Label’in bir özelliğide sıfır downtime ile farklı release podları servisimizde dışarıya çıkarabilriz.


Podlarda olduğu gibi servislerinde detaylarını


kubectl describe svc[serviceName] ile görebiliriz.









Get all herşeyi getirirken;
Podları listeleme :




Buraya kadar podlarla ilgili çok konuştuk ve podlarla ilgili direkt işlemlerde bulunduk.
Production ortamında durum böyle değildir. Podlar kısa yaşam döngüsü olan varlıklardır.
Bu kısa yaşama podların çok kaynak tüketmesi (CPU gibi) neden olabilir.
Kubernates podları sürekli denetler ve ölmelerini sağlıyabilirler.
Eğer buraya kadar olan bölümdeki gibi yaml dosyassını komut vererek podlar oluştursaydık yaşam
döngüsünü biz yönetmek zorunda olacaktık.


DIPNOT :Podları elle
şeklinde silebiliriz.






REPLICASET


Pod’lar herhangi bir neden silindiğinde aynı podun replicası yerini alınması istendiği için


Podlar ReplicaSet’ler içinde tanımlanır. Buradaki örnekte Replicas değeri 1 verilmiş.
Artık Pod çökerse yenisi yartılacak. Biz bu değeri artırıp replica podları artırabiliriz.


Replicaset için yeni bir yaml dosyası açmıyoruz. Var olan pods yaml’da podsları replica içine alıyoruz.
Aşağıdaki örnekte bu şekilde yaptık fakat queue’u herhangi bir replicaset içine almadık.




Podlar template’in altında ve replica değeri 2 olarak verildi.


Podları, servisleri, replika setleri, tek bir yaml dosasına --- ile ayırarak yazabilirsiniz.
Veya ayrı dosylar halinde tutabilirsiniz. Bu tamamen size kalmış.


DIPNOT:


Tüm podları siler.


Replicaet hakkında bilgi almak istersek:


kubectl describe rs [replicaSetName] şeklinde de kullanabiliriz.


Geldik kritik noktaya.


Eğer replikaSet içerisindeki pod’u silersek, yeni bir pod otomatik olarak ayağa kaldırılacaktır.




Eğer replicaSetimiz birden fazlaysa downtime hiç olmaz.


Replica sayısı mimari bir karardır. Mesela bir frontend webapp’ınız varsa 24 saat her dk ayakta
kalmasını istersiniz ve 1 den büyük seçersiniz.














DEPLOYMENTS
Şimdi sıra geldi Deployments’a. Kubernates çoğu zaman replicaSet yerine Deployments  yapısını
,önermektedir.


Deployments replicaset üzerinde bir layerdir.
Replicasetleri direkt olarak kullanmaktansa deploymentsi kullancağız.
Bu sayede podlarımız V1’den V2’ye zero downtime’da geçiş yapabileceğiz.














V1


V2




2 instanceli V2 30 sn içierisinde geçiş yapılacak.


Versiyonlar arası geçiş yapılırken status görüntülemek için:




Geçiş yapmak için pods.yaml’daki versiyonu (image’ı) güncellememiz ve apply etmemiz yeterlidir.
Bahsettiğimiz gibi eski versiyon yaml’da belirlenen minReadySeconds kadar koşmaya devam edecek
ve daha sonra yeni versiyona geçiş yapacaktır.


History ile yaptığımız geçişlerin revisionlarını görebiliriz. Yaml değiştirmeden bir önceki versiyona
dönebiliriz.




Burada revision 2’ye dönmüşüz ve döndüğümüz bu revision artık 4 olmuş.


Ayrıca parametresi ile istediğimiz revision’a dönebiliriz.


Revizyonlar arası geçiş sadece acil durumlarda yapılmalıdır. Eğer versiyon değişikliği yapılmak
isteniyorsa bu yaml dosyası değişitirilip apply edilerek yapımalıdır. Eğer komutla revizyon değişikliği
yapılmışsa yaml update edilmelidir.


DİPNOT: Eğer yaml’da yanlış bir image adı girilirse eski replicaset çalışmaya devam edecek ve geçiş
olmayacaktır.


NETWORKING - DISCOVERY


Docker kursunda gördüğümüz üzere bir containerın bir servis kapsaması idealdi.


Dolayısyla uygulama ve db’yi ayrı containerlara koyduk.


Gelelim kubernates kısmına:


Eğer bu containerları aynı pod içersine koyarsak uygulamamızdan db ‘ye localhostla erişebiliriz.




Fakat bu da iyi bir yöntem değildir. Pod fail olduğunda hangi container fail olduğunu anlayamayız.

Makbul olanı aşağıdaki gibi servisleri ayırmaktır.




Bu şekilde servisler birbirlerini cluster içinde ip adresleriyle görebilirler. Kubernates’de ip adresleri
dinamik olarak değiştiğinden Kubernates DNS ile bu hizmeti kolaylaştırmıştır.




Bu dns servis kubernates tarafından otomatik olarak oluşturulur ve yönetilir. Herhangi bir konfigrasyona
ihtiyaç duymaz.



kubectl get all dediğimizde bu dns service’i görmeyiz. İşte bu noktada namespace devreye
girer.




Podlar için bir namespace belirtilmezse default namespace’e atanırlar. Javadaki package yazpısı gibi
düşünebiliriz.


kubectl get all dediğinizde namespace belirtmezseniz sadece default namesapacedeli kaynakları
görüntülersiniz.


size namespaceleri listeler.

kube-system namespace’indeli podları listelemek istersek :


kube-dns podu buradadır.


kube-system namspacedeki Tüm resourceları listelersek:




kube-dns servisinin burada olduğunu göreceğiz.

describe gibi komutlarla çalışıyorsanız ve bir resource’a erişmeye çalışıyorsanız default namespace’de
değilse napespace’i parametre olarak vermelisiniz.




webapp uygulamanızın terminaline bağlandığınızda




resolv.conf altında dns serverın otomatik olarak atandığını görürsünğüz.
Bu şekilde database servisine nslookup yaptığınızda bu dns server üzerinden ip adresini alabilirsiniz.
(winpity eklentidir, linux ve windows terminalinde kullanmaya gerek yoktur)

DIPNOT:
database aslında full quailfied domain name - database.default.svc.cluster.local olarak service
discovery’e register olmuştur.




resove.conf’da default namespace için fqdn otamatik olarak eklenir ama aradığınız servis default
namespace’de değilse (örneğin mynamespace) ozaman lookup’ını bu namespace’e göre
yapmalısınız.

LOG TRACE
kubectl logs [padName]


DELETE ALL RESOURCES


yaml dosyalarının olduğu dizine gelinir ve


kubecetl delete -f .


Sadece bir yaml dosyasındaki resourceları silmek için :


kubectl delete -f [yamlName.yaml]


PERSISTENCE


Eğer mongodb gibi bir db kullanıyorsak ve bunu bir podda çalıştırıyorsak. Pod öldüğünde tüm dataları
kaybederiz. Kaybolmaması için persistence ayarlarını yapıp bilgisayarımızda bir file’a yazmamız
gerekmekte.


Bu işlemi local’inizde ve cloudda yapmak farklılık gösterir


Local için :


Bağlayacapımız nokta local için minikube’ün çalıştığı sanal makinada(minikube linux) olacaktır.




Burada mongodb deployments’da volumeMounts containers içerisindeki mongo storage path’ini
gösterirken, volumes alında “hostPath” altında local minkube sanal makinamızdaki local path’i gösterir.
Bu şekilde localimize bağlamış oluyoruz.


hostpath’i hard code olarak bağlamak yerine pointer görevini gören persistentVolumeClaim kullanmak
burada akıllıca. Çünkü bu pointer’a bağlı PersistentVolume zamanla değişebilir(özellikle farklı cloudlar
arası taşıma işleminde). Bunu tek bir noktadan yönetmiş olup, podlarda değişiklik yapmamaıza gerek
kalmaz.
persistence volumleri listelemek için :




perisistence volume claimleri listelemek için :




Cloud için :


CLOUD DEPLOYMENTS
Her bir EC2 amazon instance’ına node diyoruz. Microservicelerimiz bu nodlar arasında paylaştırıyoruz.
(pods) Replicasetlerimizde birden fazla instance olacağını düşünürsek bazı podlardan farklı nodlarda
bulunabilir. Bir adet master node’umz var ve bu nodeları kontrol edip yönetiyor. Eğer nodumuzun teki
çözkerse içindeki podlar diğer nodeların birinde oluşturuluyor ve çalışmaya başlıyor.




Şimdi daha detaylı inceleyelim…
ebs amazonun sunmuş olduğu storage servisi. Mongodb gibi resourcelarımızı bu volumelere
bağlayabiliyoruz.


AWS hesabınızı açtıktan sonra hesabınıza kubernetes kurmanız gerekiyor.


Bu işi otomatikleştirmek için kubermetesin kops (kubernetes operations) uygulamasını kullanacağız.




DIPNOT: kops’u aynı zamanda development makinanıza yükleyerek aws’deki node’ları
yöneteblilrisiniz.


İlk önce aws ec2’de bir instance oluşturuyoruz


Sonra cops’u makinamiza yüklüyoruz


curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s
https://api.github.com/repos/kubernetes/kops/releases/latest |
grep tag_name | cut -d '"' -f 4)/kops-linux-amd64
chmod +x kops-linux-amd64
sudo mv kops-linux-amd64 /usr/local/bin/kops


Daha sonra kubectl’i yüklüyoruz


  1. Download the latest release with the command:
  2. curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
  3. To download a specific version, replace the $(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt) portion of the command with the specific version.
  4. For example, to download version v1.13.0 on Linux, type:
  5. curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.13.0/bin/linux/amd64/kubectl
  6. Make the kubectl binary executable.
  7. chmod +x ./kubectl
  8. Move the binary in to your PATH.
  9. sudo mv ./kubectl /usr/local/bin/kubectl


Services altındali IAM(Identity and access management)’e gelip


kops adında yeni bir grup oluşturuyoruz


next deyip




rolleri tanımlıyoruz.


Daha sonra user tanımlıyoruz.


Grup’u tanımladığımız yerde kops user tanımlıyoruz. Access type programatic access seçiyoruz.


daha sonra add grup deyip kops grubuna ekliyoruz.


Burada bir access key ve password tanımlanacak. Bunu bir yere not edip kimseyle paylaşmıyoruz:


Daha sonra konsoldan aws configure deyip
key ve apsswordu giriyoruz
uygun regionu seçiyoruz


daha sonra


dediğimizde userları görebiliyoruz. aws configure ettik


export AWS_ACCESS_KEY_ID=$(aws configure get aws_access_key_id)
export AWS_SECRET_ACCESS_KEY=$(aws configure get aws_secret_access_key)
diyoruz.


Şimdi kops’un kullanması için s3’de bir bölüm açıyoruruz. (Services altında s3)


[ec2-user@ip-172-31-39-81 ~]$ export NAME=fleetman.k8s.local
[ec2-user@ip-172-31-39-81 ~]$ export KOPS_STATE_STORE=s3://turkninja-state-store


yapıyoruz




Herbir node’u farklı zone’lara koyarak birisi çöktüğünde diğerinden devam edebilme şansını
yakalarız. zone’ları görmek için listeleyeylim




[ec2-user@ip-172-31-39-81 ~]$ aws ec2 describe-availability-zones --region eu-central-1
{
   "AvailabilityZones": [
       {
           "State": "available",
           "ZoneName": "eu-central-1a",
           "Messages": [],
           "RegionName": "eu-central-1"
       },
       {
           "State": "available",
           "ZoneName": "eu-central-1b",
           "Messages": [],
           "RegionName": "eu-central-1"
       },
       {
           "State": "available",
           "ZoneName": "eu-central-1c",
           "Messages": [],
           "RegionName": "eu-central-1"
       }
   ]
}


kops create cluster --zones eu-central-1a,eu-central-1b,eu-central-1c ${NAME}


daha sonra ssh keygeneration yapıyoruz




ssh-keygen -b 2048 -t rsa -f ~/.ssh/id_rsa




kops create secret --name ${NAME} sshpublickey admin -i ~/.ssh/id_rsa.pub






















kops edit ig nodes --name ${NAME}






[ec2-user@ip-172-31-39-81 ~]$ kops get ig --name ${NAME}
NAME                    ROLE MACHINETYPE MIN     MAX ZONES
master-eu-central-1a    Master m3.medium 1       1 eu-central-1a
nodes                   Node t2.medium 3       5 eu-central-1a,eu-central-1b,eu-central-1c




dediğimizde nodelar oluşacak. (dikkat! nodelar paralı instancelar)


[ec2-user@ip-172-31-39-81 ~]$ kops update cluster ${NAME} --yes
I0114 19:33:52.441756   32452 apply_cluster.go:542] Gossip DNS: skipping DNS validation
I0114 19:33:52.690686   32452 executor.go:103] Tasks: 0 done / 81 total; 30 can run
I0114 19:33:53.098804   32452 vfs_castore.go:736] Issuing new certificate: "ca"
I0114 19:33:53.590600   32452 vfs_castore.go:736] Issuing new certificate: "apiserver-aggregator-ca"
I0114 19:33:53.763248   32452 executor.go:103] Tasks: 30 done / 81 total; 26 can run
I0114 19:33:53.998770   32452 vfs_castore.go:736] Issuing new certificate: "kops"
I0114 19:33:54.334726   32452 vfs_castore.go:736] Issuing new certificate: "kubecfg"
I0114 19:33:55.286197   32452 vfs_castore.go:736] Issuing new certificate: "kubelet"
I0114 19:33:55.291909   32452 vfs_castore.go:736] Issuing new certificate: "kube-scheduler"
I0114 19:33:55.416023   32452 vfs_castore.go:736] Issuing new certificate: "apiserver-aggregator"
I0114 19:33:55.510762   32452 vfs_castore.go:736] Issuing new certificate: "kubelet-api"
I0114 19:33:55.912137   32452 vfs_castore.go:736] Issuing new certificate: "kube-proxy"
I0114 19:33:56.002766   32452 vfs_castore.go:736] Issuing new certificate: "kube-controller-manager"
I0114 19:33:56.033260   32452 vfs_castore.go:736] Issuing new certificate: "apiserver-proxy-client"
I0114 19:33:56.344550   32452 executor.go:103] Tasks: 56 done / 81 total; 21 can run
I0114 19:33:56.579713   32452 launchconfiguration.go:380] waiting for IAM instance profile "nodes.fleetman.k8s.local" to be ready
I0114 19:33:56.616227   32452 launchconfiguration.go:380] waiting for IAM instance profile "masters.fleetman.k8s.local" to be ready
I0114 19:34:06.961240   32452 executor.go:103] Tasks: 77 done / 81 total; 3 can run
I0114 19:34:07.275706   32452 vfs_castore.go:736] Issuing new certificate: "master"
I0114 19:34:08.003876   32452 executor.go:103] Tasks: 80 done / 81 total; 1 can run
W0114 19:34:08.100642   32452 executor.go:130] error running task "LoadBalancerAttachment/api-master-eu-central-1a" (9m59s remaining to succeed): error attaching autoscaling group to ELB: ValidationError: Provided Load Balancers may not be valid. Please ensure they exist and try again.
       status code: 400, request id: 5c2fb636-1833-11e9-8376-638d23791b67
I0114 19:34:08.100709   32452 executor.go:145] No progress made, sleeping before retrying 1 failed task(s)
I0114 19:34:18.100984   32452 executor.go:103] Tasks: 80 done / 81 total; 1 can run
W0114 19:34:18.211696   32452 executor.go:130] error running task "LoadBalancerAttachment/api-master-eu-central-1a" (9m49s remaining to succeed): error attaching autoscaling group to ELB: ValidationError: Provided Load Balancers may not be valid. Please ensure they exist and try again.
       status code: 400, request id: 6234b247-1833-11e9-81a8-91745d3b1336
I0114 19:34:18.211759   32452 executor.go:145] No progress made, sleeping before retrying 1 failed task(s)
I0114 19:34:28.212107   32452 executor.go:103] Tasks: 80 done / 81 total; 1 can run
I0114 19:34:28.525792   32452 executor.go:103] Tasks: 81 done / 81 total; 0 can run
I0114 19:34:28.617288   32452 update_cluster.go:290] Exporting kubecfg for cluster
kops has set your kubectl context to fleetman.k8s.local


Cluster is starting.  It should be ready in a few minutes.


Suggestions:
* validate cluster: kops validate cluster
* list nodes: kubectl get nodes --show-labels
* ssh to the master: ssh -i ~/.ssh/id_rsa admin@api.fleetman.k8s.local
* the admin user is specific to Debian. If not using Debian please use the appropriate user based
on your OS.
* read about installing addons at: https://github.com/kubernetes/kops/blob/master/docs/addons.md.


nodelaarımız oluştu.


[ec2-user@ip-172-31-39-81 ~]$ kops validate cluster
Using cluster from kubectl context: fleetman.k8s.local


Validating cluster fleetman.k8s.local


INSTANCE GROUPS
NAME                    ROLE MACHINETYPE MIN     MAX SUBNETS
master-eu-central-1a    Master m3.medium 1       1 eu-central-1a
nodes                   Node t2.medium 3       5 eu-central-1a,eu-central-1b,eu-central-1c


NODE STATUS
NAME                                            ROLE READY
ip-172-20-100-151.eu-central-1.compute.internal node    True
ip-172-20-49-94.eu-central-1.compute.internal   node True
ip-172-20-61-91.eu-central-1.compute.internal   master True
ip-172-20-83-130.eu-central-1.compute.internal  node True


Your cluster fleetman.k8s.local is ready
[ec2-user@ip-172-31-39-81 ~]$


cluster’ımız artık hazır.


Ayrıca otomatik olarak load balancer’da oluşturuldu. Eğer master node çökerse yeni master node
oluşturulacak ve load balancer bu yeni master node a istekleri yönlendirecek.


Ayrıca eğer nodelardan biri terminate olursa min 3 dediğimizden yenisi ayağa otomatik olarak kaldırılır.


NODE’larımız hazır artık deploy işlemine geçelim :)


………


LOGS


kubectl logs [podName]  ile gün boyu tüm podlarımızı loglarını takip edemeyiz. Bu localde çözüm
olabilir ama prod ortamında genel bir çözüm değildir. Bir podda sorun mu var, ne kadar trafik alıyoruz
gibi soruları cevaplamak için ve logların history’sini tutmak için genel bir loglama yapısına ihtiyaç
duyarız.


Bu işlem için ELK stack kullanırız.


L harfi logstash temisl eder ama biz fluentD kullanacağız.(Benzer iş yapıyor ve daha populer)




Fluentd container’larda oluşan logları pull eder. Containerlar bu durumdan habersizdir ve
herhangi bir dependency’e ihtiyaç duymazlar.




Ve yakaladığımız bu kayıtları bir yere yazmamız gerekmekte. Burada bir arama moturu olan
elasticsearch’ü kullanıyoruz.




Ve query ve virtualization için kibanayı kulanırız.




Bu işlemler için her bir single node’da fluentd container’ın olması gerektiği görülmekte.


Peki elasticsearch ve kibanayı nerede kuracağız? Bunun cevabı ise tamamen mimarı bir seçimdir.
Misal elasticsearch servisini awsnin sağladığı elasticsearch servisinden alabilirsiniz. Bu şekilde
cluster dığında sağlam bir servis almış olursunuz.


Kibana bir web uygulaması olduğundan nereye istersek kurabiliriz. Hatta ayrı bir ec2 instance
açıp orayada kurabiliriz.


Biz elasticsearchi nodelarda çalıştırıp replicasetini 2 olarak ayarlayacağız.


Kibanayıda single nodeda çalıştıracağız.


Peki bu kadar karıişık işmeli ve ayarları nasıl yapacağız. Bunu çok dert etmemize gerek yok çünkü
kubernetesin official sayfasında addsonlar mevcut.




Burada VPP kursunda bu dosyalar düzenlenerek isteğimiz yapı için yaml dosyası oluşturuldu ve bize
verildi.


Bu yaml faile’larda dikkat edilmesi gereken noktalardan biri ReplicaSet ve Deployments yapısı
benzeri bir fluend için oluşturulmuş bir DaemonSet mevcut. Bu yapı herbir container’ın clusterda her
bir nodda çalışacağı anlamına geliyor.
Aynı şekilde statefulSet replicaSet’in bir çişitidir ve her bir poda random isim vermez ve verilen isime
0-1-2 .. gibi indexler verip oluşturur.




Elasticsearch için vloume claimEde bu dosyaların içinde oluşturulmuştur.


Bu daha önce mongo db için oluşturduğumuz cloud-ssd ie eşleştirildi.


Kibana servisinide loadbalancer tyopeında dışarıya açıyoruz.




Bu dosyalrı tam anlamıyla anlammıza gerek yok. Genel olarak yapısını anlamamız gerekli. Her proje
için benzer bir yapı kullanılıyor ve kubernetes bunu bize sağlıyor.



Şimdi sırayla bu dosyaları çalıştıryooruz.






dosyalardaki resourceları farklı namaspacelerde(kube-system) yarattığımız için kubectl get all ile
resourceları göremiyeceğiz.






kibana için loadbalancer oluşturuldu artık erişebiliriz.




kubectl describe svc kibana-logging -n kube-system ile de bu dns adresine ulaşabiliriz.




Kibana’ya ilginiz varsa ayrı olarak araştırabilirsiniz.



MONITORING CLUSTER


Node’lar sağlıklımı, CPU Ram kullanımı ne seviyede, yeterince node var mı gibi soruları izlemeye
yarar.


Aslında instance’ınızı tıkladığınızada(Burada AWS, diğer cloud providerlarda olabilir), montioring
sekmesinde chartları görebilirsiniz.




Ayrıca ücretli olarak daha detaylı monitoring hizmetleri alabilirsiniz.


Ama biz kendi monitoring sistemini kuracağız.


Bu iş için kubernetesin desteklediği açık kaynak phrometeus2u kullanacağız.


Ön yüz olarakda Grafana’yı kullancağız.


Bu iki uygulamayı kurmak biraz zor olabilir, bu yüzden cluster’ımıza  helm package manager’ı
kullanacağız.


Helm kubernates işin package manager’dır. (yum apt-get brew benzetmesi yanlış olmaz herhalde)
Burada package’den kastımız pod koleksiyonu, servis koleksiyonu gibi resource koleksiyonları olabilir.
(Örnek olarak projenize mysql servisi eklemek)


Önce Helm2i kuruyoruz




Helmi başlatmak için helm init yapıyoruz.






tiller’ı şimdi görebiliyoruz.


Helm version dediğimizde çalıştığını görüyoruz










tiller’a farklı kubernetes namespacelaerinde çalışması için privillages’lar vermemiz gerekiyor:.








Kurulumu kaldırmak için :


Elimizden geldiğince Helm değil kendi yaml larımız kullanıp resource yaratmaya çalışmalıyız.


Monitoring elle kurması zor olduğundan ve artı bir özellik olduğundan helm ile kurulum yapayı tercih
ettik.






Ama biz Helm ile CoreOs projesini tercih edeceğiz

















Ama biz esas olarak ön yüz için grafanayı kullanacağız loadbalancerı geri kaldıryoruz.ç Çünkü
phormeateus ön yüz açısından çok zengin değil.














ALERTING




Grfananın arayüzünde servislerinizin eya podşarınızın iyi durumda olmadığını gösteren alertler
olabilirler.




monitoring namespaceinde alertmanager’ın yüklü olduğunu görüyoruz.


Bu arayüze kubernatesin proxy’sini kullarak eriştik.


dead man switch alarımı default olarak vardır ve kalıcıdır. tüm istemi bu aarmı kullanrak test
edeceğiz. Phormetteasun çalıştığını bu alarmın var olup olmadığına bakaraak anlayabiliriz.


Şimdi diğer alarmlara bakalım.


Tüm alarmları text dosyasına, emaile veya slack chanalle yazabiliriz.














0 yorum: