Merhaba arkadaşlar bu yazımda bir önceki yazım olan Durum Yönetimi konusu içerisinde bahsedilen API nesnelerinin ve bazı durumların alıştırmalarını yapacağız.

Container’ların durumunu anlamak ve yönetmek Kubernetes’in temel görevidir. Laboratuvarımızda önce container grublarını yönetmek için API nesnelerini inceleyeceğiz. Kubernetes’ler olgunlaşıp geliştikçe ekstra ek bazı nesnelerde bunun beraberinde geldi. İlk hedefimiz Deployment içerisinde de bulunan ReplicaSet’ler olacatır. Bir Deployment ReplicaSet’i sizin için yönetecektir. Ardından DeamonSets adlı başka bir nesne ile birlikte çalışarak container’ın yeni eklenen node’da çalışmasını sağlayacağız.

ReplicaSet’ler ile Çalışalım

ReplicaSet, desteklenen versiyonlara göre farklılık gösteren yeni nesil bir Replication Controller’dır. Artık ReplicaSet kullanmanın nedeni pod yazılımını güncellemeye gerek yoksa veya düzenleme gerekmiyorsa bu tipik işlemlerde yanıt veriyor olmasıdır. Şimdi uygulamamıza geçelim.

Mevcut olduğumuz ReplicaSet’leri listeleyelim.

$ kubectl get rs
No resources found.

Basit bir ReplicaSet için YAML dosyası oluşturalım. Burda eski bir nginx sürümü kullanacağız ve ardından bu sürümü güncelleyeceğiz.

$ vim basitrs.yaml
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
   name: basitrs
spec:
   replicas: 2
   template:
      metadata:
         labels:
            system: ReplicaDeneme
      spec:
         containers:
         - name: nginx
           image: nginx:1.9.1
           ports:
           - containerPort: 80

$ kubectl create -f basitrs.yaml
replicaset.extensions/basitrs created

$ kubectl describe rs basitrs
Name:         basitrs
Namespace:    default
Selector:     system=ReplicaDeneme
Labels:       system=ReplicaDeneme
Annotations:  <none>
Replicas:     2 current / 2 desired
Pods Status:  2 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  system=ReplicaDeneme
  Containers:
   nginx:
    Image:        nginx:1.9.1
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>

Oluşturduğumuz YAML dosyasından bir ReplicaSet oluşturduk ve açıklamalarını inceledik. ReplicaSet ile oluşturulan pod’ları görüntüleyelim. Oluşturulan YAML dosyasında 2 adet pod istedik.

$ kubectl get pods
NAME            READY   STATUS    RESTARTS   AGE
basitrs-r7nqv   1/1     Running   0          107s
basitrs-r8nkt   1/1     Running   0          107s

Şimdi ReplicaSet’i silelim ve bakalım pod’larda durum nasıl olacak.

$ kubectl delete rs basitrs --cascade=false
replicaset.extensions "basitrs" deleted

$ kubectl get pods
NAME            READY   STATUS    RESTARTS   AGE
basitrs-r7nqv   1/1     Running   0          18m
basitrs-r8nkt   1/1     Running   0          18m

Fark ettiğiniz üzere ReplicaSet silindi fakat oluşturduğu pod’lara birşey olmadı (cascade parametresi sayesinde). Şimdi tekrardan ReplicaSet’i oluşturalım. Selector alanını değiştirmediğimiz sürece oluşturulan ReplicaSet yine aynı pod’lardan sorumlu olmaya devam edecektir.

$ kubectl create -f basitrs.yaml
replicaset.extensions/basitrs created

$ kubectl get pods
NAME            READY   STATUS    RESTARTS   AGE
basitrs-r7nqv   1/1     Running   0          20m
basitrs-r8nkt   1/1     Running   0          20m

$ kubectl edit po basitrs-r7nqv
....
  labels:
    system: AyriPod => bu alanı değiştirdik
  name: basitrs-r7nqv
....

ReplicaSet tarafından oluşturulan pod’un label parametresi altında bulunan system özniteliğini değiştirdiğimiz zaman bu pod’u artık ReplicaSet yönetmez. Çünkü kendi oluşturduğu pod’ların bu etiketine bakarak kontrol sağlar ve yönetir. Burda yönetmekten kastımız replica sayısını koruyarak pod oluşturup silmek.

$ kubectl get po -L system
NAME            READY   STATUS    RESTARTS   AGE     SYSTEM
basitrs-r7nqv   1/1     Running   0          24m     AyriPod
basitrs-r8nkt   1/1     Running   0          24m     ReplicaDeneme
basitrs-w8l6m   1/1     Running   0          2m11s   ReplicaDeneme

Bu noktada ReplicaSet’i bu sefer cascade parametresi vermeden silelim ve değişimi gözlemleyelim.

$ kubectl get pod -L system
NAME            READY   STATUS        RESTARTS   AGE    SYSTEM
basitrs-r7nqv   1/1     Running       0          26m    AyriPod
basitrs-r8nkt   0/1     Terminating   0          26m    ReplicaDeneme
basitrs-w8l6m   0/1     Terminating   0          4m4s   ReplicaDeneme

Gördüğünüz gibi ReplicaSet’in sorumlu olduğu pod’lar silinmeye başladı.

ReplicaSet üzerinde anlatacaklarımız temel anlamda bu kadar diyebilirim. Şimdi ortamımızı temiz bırakmak adına diğer pod’larıda kaldıralım.

$ kubectl delete po -l system=AyriPod
pod "basitrs-r7nqv" deleted

DaemonSets ile Çalışma

DaemonSet bir Deployment gibi izleme döngüsü sağlayan bir nesnedir. DamonSet bir node bir cluster’a eklendiğinde, o node’da bir pod oluşturulacağını garanti eder. Bir Deployment yalnızca genel olarak bir pod sayısı yaratır, bir kaç tanesi tek bir node’da olabilir. DaemonSet kullanmak uygulamaların her düğümde olduğundan emin olmanız gerektiği zaman yararlı olur. Bir node bir cluster’dan kaldırılırsa DaemonSet pod’ların çöp olmasını sağlar.

DaemonSet kullanımına bir YAML dosyası oluşturarak başlarız. Bu durumda kind: DaemonSet olarak ayarlanır. Kullanım kolaylığı olması adına yukarıda oluşturduğumuz basitrs.yaml dosyası üzerinde düzenlemeler yapacağız.

$ cp basitrs.yaml basitds.yaml

$ vim basitds.yaml
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
   name: basitds
spec:
   template:
      metadata:
         labels:
            system: DaemonSetDeneme
      spec:
         containers:
         - name: nginx
           image: nginx:1.9.1
           ports:
           - containerPort: 80

Düzenlediğimiz YAML dosyasını oluşturalım.

$ kubectl create -f basitds.yaml
daemonset.extensions/basitds created

$ kubectl get ds
NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
basitds   2         2         2       2            2           <none>          3m29s

$ kubectl get pods
NAME            READY   STATUS    RESTARTS   AGE
basitds-8p6t5   1/1     Running   0          2m45s
basitds-d6wxp   1/1     Running   0          3m40s

Burada dikakt etmemiz gereken nokta, kaç tane node’umuz varsa o node’lar içerisinde birer tane pod oluşturduğudur. Eğer yeni bir node eklerse yine o node içerisinde bir pod konuşlandırılacaktır. Eğer bir node silinirse o node ile birlikte içerisindeki pod da silinecektir.

Rolling Güncellemeleri ve Rollback

Mikroservislerin avantajlarından biri istemciye yanıt vermeye devam ederken container’ı değiştirme ve yükseltme yeteneğidir. Bir container silindiğinde yükselten OnDelete ayarını ve sonra RollingUpdate ayarını kullanacağız.

DaemonSet başlığı altında oluşturduğumuz YAML dosyası içerisinde Strategy anahtar kelimesini arayalım ve updateStrategy ayarını görerek başlayalım.

$ kubectl get ds basitds -o yaml | grep -A 1 Strategy
  updateStrategy:
    type: OnDelete

DaemonSet örneğinde yer alan nginx’in daha yeni bir sürümünü kullanmak için DaemonSet’i güncelleyelim.

$ kubectl set image ds basitds nginx=nginx:1.12.1-alpine
daemonset.extensions/basitds image updated

$ kubectl get pods
NAME            READY   STATUS    RESTARTS   AGE
basitds-8p6t5   1/1     Running   0          18m
basitds-d6wxp   1/1     Running   0          19m

$ kubectl describe pods basitds-8p6t5 | grep Image:
Image:          nginx:1.9.1

Güncelleme işleminden sonra DaemonSet tarafından oluşturulan pod’un nginx sürümüne baktığımız zaman bir değişiklik göremedik. Şimdi pod’u silelim ve dağıtılmasını bekleyelim.

$ kubectl delete po basitds-8p6t5
pod "basitds-8p6t5" deleted

$ kubectl get po
NAME            READY   STATUS    RESTARTS   AGE
basitds-d6wxp   1/1     Running   0          24m
basitds-k46m4   1/1     Running   0          5s

$ kubectl describe po basitds-k46m4 | grep Image:
Image:          nginx:1.12.1-alpine

Şimdi güncelleştirme geçmişimizi görelim, kaç tane güncelleme yapmışız ve nelermiş.

$ kubectl rollout history ds basitds
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

$ kubectl rollout history ds basitds --revision=1
Pod Template:
  Labels:       system=DaemonSetDeneme
  Containers:
   nginx:
    Image:      nginx:1.9.1
    Port:       80/TCP
    Host Port:  0/TCP
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>

$ kubectl rollout history ds basitds --revision=2
Pod Template:
  Labels:       system=DaemonSetDeneme
  Containers:
   nginx:
    Image:      nginx:1.12.1-alpine
    Port:       80/TCP
    Host Port:  0/TCP
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>

Şimdi bu güncelleme geçmişlerini kullanarak geri dönme işlemi gerçekleştirelim ve bunu teyit edelim.

$ kubectl rollout undo ds basitds --to-revision=1
daemonset.extensions/basitds rolled back

$ kubectl describe po basitds-k46m4 | grep Image:
Image:          nginx:1.12.1-alpine

$ kubectl delete po basitds-k46m4
pod "basitds-k46m4" deleted

$ kubectl get po
NAME            READY   STATUS    RESTARTS   AGE
basitds-d6wxp   1/1     Running   0          30m
basitds-rln5q   1/1     Running   0          8s

$ kubectl describe po basitds-rln5q | grep Image:
Image:          nginx:1.9.1

Gördüğünüz gibi ilk haline geri döndük ve pod’u sildik tekrardan 1.9.1 versiyonunda pod oluşturdu. Bu yaptığımız model OnDelete modeliydi diyebiliriz. Şimdi RollingUpdate modelini deneyelim.

$ kubectl get ds basitds -o yaml > rollupdate.yaml
$ vim rollupdate.yaml
....
 labels:
    system: DaemonSetDeneme
  name: rollupdate
....
 updateStrategy:
    type: RollingUpdate
....

$ kubectl create -f rollupdate.yaml
daemonset.extensions/rollupdate created

$ kubectl get po
NAME               READY   STATUS    RESTARTS   AGE
basitds-d6wxp      1/1     Running   0          37m
basitds-rln5q      1/1     Running   0          6m25s
rollupdate-26sd4   1/1     Running   0          7s
rollupdate-m5ms8   1/1     Running   0          7s

$ kubectl describe po rollupdate-26sd4 | grep Image:
Image:          nginx:1.9.1

$ kubectl edit ds rollupdate
....
spec:
      containers:
      - image: nginx:1.12.1-alpine
....
daemonset.extensions/rollupdate edited

$ kubectl get po
NAME               READY   STATUS    RESTARTS   AGE
basitds-d6wxp      1/1     Running   0          38m
basitds-rln5q      1/1     Running   0          7m45s
rollupdate-68jvw   1/1     Running   0          19s
rollupdate-v87gx   1/1     Running   0          12s

$ kubectl describe po rollupdate-68jvw | grep Image:
Image:          nginx:1.12.1-alpine

Gördüğünüz gibi bu işlemle beraber DaemonSet’i düzenleme moduna geçtiğimizde image sürümünü değiştirdik ve önceden oluşturulmuş olan 2 image’da silindi ve yerine yeni versiyona sahip iki pod otomatik olarak oluştu.

Şimdi bu işlemlerin geçmişini inceleyelim.

$ kubectl rollout status ds rollupdate
daemon set "rollupdate" successfully rolled out

$ kubectl rollout history ds rollupdate
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

$ kubectl rollout history ds ds-two --revision=2
Pod Template:
  Labels:       system=DaemonSetDeneme
  Containers:
   nginx:
    Image:      nginx:1.12.1-alpine
    Port:       80/TCP
    Host Port:  0/TCP
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>

Burada bölmeler güncelleştirme gerçekleştirmesi için otomatik olarak silinirken OnDelete modunda bizim el ile silmemizden sonra güncelleşme gerçekleşmektedir.

Laboratuvar ortamımız burada sonlanmıştır. Bir sonraki Kubernetes Eğitim Serisi yazımızda servisleri göreceğiz. Görüşmek üzere !

Umarım bu yazı sizin için bilgilendirici olmuştur. Yazıyla ilgili bir sorunuz, görüşünüz veya isteğiniz varsa alt kısımda bulunan yorumlardan veya mail adresimden iletişime geçebilirsiniz. Bu yazının başkaları içinde bilgilendirici olduğunu düşünüyorsanız sosyal olun ve sosyal medyada paylaşın! Okuduğunuz için teşekkürler !!!