Kubernetes Deployment Stratejileri 1

Recreate & Rolling Update

Merhabalar,

Bu yazımda kubernetes de kullanılan deployment stratejileri inceliycez.

Ilk olarak recreate ile başlayalım. Peki recreate deployment nedir veya biz nasıl kullanabiliriz ? Recreate deployment;

• Recreate kullandığımızda deployment replicası sayınsındaki tüm podları kapattıktan sonra yeni image ile ilgili podları ayağa kaldırır. Tabiki de geçen sürede downtime kaçınılmazdır. Downtime süresi sizin eski application kapatma süresi ve yeni versyionun sağlıklı bir şekilde ayağa kalkmasındaki geçen süre olacaktır.
• Recreate deployment stratejisi kullanıyorsunuz uygulamanız eski ve yeni versiyon ile çalışmaz.
• Recreate genellde v1'den v2 versiyonlarına geçişte kullanılır.
• Versiyon geçişinde sorun yaşanır ise rollback sıkıntı yaşabilirsiniz.

Şimdi örnek manifest’imize bakalım. Ilk olarak deployment manifest’imize bakalım.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: recreate-dep-test
  namespace: default
  labels:
    app: recreate-dep-test
spec:
  selector:
    matchLabels:
      app: recreate-dep-test
  replicas: 10
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: recreate-dep-test
    spec:
      containers:
      - name: recreate-dep-test
        image: denizturkmen/app1
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
          limits:
            cpu: 100m
            memory: 100Mi
        ports:
        - containerPort:  80
          name: recreate-test

Şimdide services yaml manifest’imize bakalım.

apiVersion: v1
kind: Service
metadata:
  name: recreate-dep-test
  namespace: default
spec:
  selector:
    app: recreate-dep-test
  type: NodePort
  ports:
  - name: recreate-dep-test
    protocol: TCP
    port: 80
    targetPort: 5000 
    nodePort: 32568

kubectl apply -f .

Yukarıda komut ile deployment ve services apply ediyoruz.

ve

Görüldüğü gibi replica sayısını 10 olarak belirtik ve 10 adet pod running state şuan. Deployment içerisindeki image çıktısına bakmak için; terminalden curl yada tarayıcıdan ilgili ip ve port ile gidebilirsiniz. Uygulama örneğini minikube cluster’ımızda yaptığımız için;

minikube service list

Ekranda Load Balancer 1 çıktısını göreceksiniz.

Amacımız recreate deployment strategy anlattığımız image çıktısı çok önemli değil ama siz burada Load Balancer 1 çıktısını version-1 ve Load Balancer 2 çıktısınıda versiyon-2 olarak düşünebilirsiniz.

Şimdide image denizturkmen/app2 yapıp deployment re-trigger edelim ve replicaset ve çıktıyı takip edelim.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: recreate-dep-test
  namespace: default
  labels:
    app: recreate-dep-test
spec:
  selector:
    matchLabels:
      app: recreate-dep-test
  replicas: 10
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: recreate-dep-test
    spec:
      containers:
      - name: recreate-dep-test
        image: denizturkmen/app2
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
          limits:
            cpu: 100m
            memory: 100Mi
        ports:
        - containerPort:  80
          name: recreate-test

kubectl apply -f recreate-dep-test.yaml 

Yukarıdaki şekilde görüldüğü gibi tüm podları terminate state çekiyor ve daha sonrasında yeni image ile ayağa kaldırcak tabikide geçen sürede podlar içindeki application cevap alamıycaz. Yeni image ile ayağa kaldığında ise trafik tekrar podlara yönlendirilecek.

Note: Burada kastettiğimiz downtime ise, versiyon-1 den versiyon-2 image geçerkenki replica sayısındaki tüm podların healty ve running state geçme süresidir. Eğer herhangi bir nedenden dolayı pod running state geçemez ise pod’un içindeki application çalışmaz.

İkinci bir dezavantajı ise roolback süresinin böyle durumlarda uzun ve meşaketli olmasıdır.

Ekranda görüldüğü çıktı olarak Load Balancer 2 çıktısını görebildik. Böylece recreate deployment tamamlamış olduk.

Şimdide rollingUpdate deployment nedir veya biz nasıl kullanabiliriz ?

Rolling deployment;

• Öncelikle kubernetes default deployment strategy’sidir.
• RoolingUpdate applicationızdaki eski image ile yeni image yer değiştir. Bunu yaparkende eski image herhangi bir kesinti yaşatmaz. Tabikide bu downtime yaşamak için readiness probe kullanmalısınız.

Note: Eğer horizontal pod autoscaling yapısını ilerleyen zamanda kullancaksanız maxSurge ve MaxUnavailable yüzdesel olarak vermelisiniz.

• maxSurge: Deployment’daki pod replicasının maksimum olarak yeni versiyona geçişteki maksimum pod sayısını belirtiriz. Yenisi sizin 10 replicalık bir pod’unuz var ve maxSurge 2 diyelim. Toplamda eski image ile yeni image geçişteki toplam pod sayısı 12 olabilir.
• MaxUnavailable: Eski image’dan yeni image geçerkende eski image dan bu kdar termiante et ve yeni image’dan da bu kadar pod ayağa kaldır demektir.

Dezavantajlarına bakacak olursak;

• Yavaş olmasıdır deployment’ın.
• Deployment herhangi bir sorun çıkar ise önceki versiyona dönmenin kolay bir yolu yoktur.
• Trafiği yönetmekte sorun yaşayabilirsiniz. Çünkü biriler eski birileri de yeni image gidebilir.

Deployment manifest’imize bakalım.

apiVersion: apps/v1
kind: Deployment
metadata:
  name:  roolingupdate-dep
  namespace: default
  labels:
    app:  roolingupdate
spec:
  selector:
    matchLabels:
      app: roolingupdate
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 50%
  template:
    metadata:
      labels:
        app:  roolingupdate
    spec:
      containers:
      - name:  roolingupdate
        image:  denizturkmen/app1
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
          limits:
            cpu: 100m
            memory: 100Mi
        readinessProbe:
          httpGet:
            path: /
            port: 5000
          initialDelaySeconds: 5
          timeoutSeconds: 2
          successThreshold: 1
          failureThreshold: 3
          periodSeconds: 10
        ports:
        - containerPort:  80
          name:  roolingupdate
      restartPolicy: Always

Services manifest’imize bakalım.

apiVersion: v1
kind: Service
metadata:
  name: roolingupdate-test
  namespace: default
spec:
  selector:
    app: roolingupdate
  type: NodePort
  ports:
  - name: roolingupdate-dep-test
    protocol: TCP
    port: 80
    targetPort: 5000 
    nodePort: 32425

Aşağıdaki komut ile deployment ve services objelerimizi cluster’ımıza apply edelim.

kubectl apply -f .

Deployment cluster’ımıza deploy ettikten sonra replicaset ve pod replikalarını bakabilirsiniz.

Şimdide image değiştirip tekrar deployment yapalım.

• image: denizturkmen/app2

apiVersion: apps/v1
kind: Deployment
metadata:
  name:  roolingupdate-dep
  namespace: default
  labels:
    app:  roolingupdate
spec:
  selector:
    matchLabels:
      app: roolingupdate
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 50%
  template:
    metadata:
      labels:
        app:  roolingupdate
    spec:
      containers:
      - name:  roolingupdate
        image:  denizturkmen/app2
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
          limits:
            cpu: 100m
            memory: 100Mi
        readinessProbe:
          httpGet:
            path: /
            port: 5000
          initialDelaySeconds: 5
          timeoutSeconds: 2
          successThreshold: 1
          failureThreshold: 3
          periodSeconds: 10
        ports:
        - containerPort:  80
          name:  roolingupdate
      restartPolicy: Always

kubectl apply -f rollingupdate-dep.yaml

Komutu ile deployment yapaşlım ve replicaset ve pod’ların durumuna bakalım aynı zamanda trafiğin eski ile yeni image gittiğini görmek için deployment tamamlana kadar sayfayı tarayıcıdan reflesh yada curl komutu ile bakabilirsiniz.

Görüldüğü gibi sayfayı refleshlediğimde trafiğin bir eski image bir de yeni image gittiğini görebilirsiniz.

Bu yazımızın da sonuna gelmiş bulunmaktayız. Araştırmalarım ve sektörde karşılaştığım senaryolar üzerine yazılarımı yazmaya devam edeceğim. Umarım faydalı bir yazı olmuştur. Yazımı okuduğunuz için teşekkürler.

Deniz Türkmen

Deniz Türkmen — Turkey | Professional Profile | LinkedIn

denizturkmen — Overview

Referanslar;