Kubernetes Deployment Stratejisi Bölüm 2: Rolling Update

Kubernetes, uygulama dağıtımını ve güncellemelerini yönetmek için gelişmiş stratejiler sunar. Bu yazı dizisinin ikinci bölümünde, “Rolling Update” adlı bir Deployment stratejisini inceleyeceğiz.

Neden Rolling Update Stratejisi?

  • Yüksek Kullanılabilirlik: Rolling Update, uygulamanın güncellenirken kesintisiz olarak çalışmasını sağlar. Yeni sürümü sırayla dağıtarak kullanılabilirliği artırır.
  • Hızlı Geri Dönüş: Eğer yeni bir güncelleme sorunlara yol açarsa, geri dönmek kolaydır. Bir önceki sürüme sıkıntısız bir şekilde geçebilirsiniz.
  • Otomasyon ve İzleme: Kubernetes, Rolling Update stratejisini otomatikleştirmenize ve işleminizi izlemenize yardımcı olur.

Rolling Update Adımları

  1. Yeni Bir Docker Image Oluşturun: Güncel sürümünüzü içeren yeni bir Docker görüntüsü oluşturun.
  2. Deployment Yapılandırması: Deployment YAML dosyanızda güncel sürüme işaret eden yeni görüntüyü ekleyin.
  3. Deployment’i Güncelleyin: kubectl apply -f deployment.yaml komutunu kullanarak güncellemeyi başlatın.
  4. Rolling Update Gözlemi: kubectl get pods komutunu kullanarak güncellemenin nasıl ilerlediğini izleyin. Her bir pod sırayla güncellenecektir.

Şimdi sırasıyla Rolling Update adımlarını uygulayalım.

rollingUpdate-deployment-v1.yaml adında bir yaml oluşturun.
nano rollingUpdate-deployment-v1.yaml
Aşağıdaki yaml içeriğini oluşturduğunuz yaml file’a yapıştırın.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sercan
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: sercan
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 50%    
  template:
    metadata:
      labels:
        app: sercan
    spec:
      containers:
      - image: gcr.io/google-samples/hello-app:1.0
        imagePullPolicy: Always
        name: sercan
        ports:
        - containerPort: 8080


Kubernetes Deployment’larında maxSurge ve maxUnavailable parametreleri, güncelleme sırasında aynı anda kaç yeni podun başlayabileceğini ve kaç podun aynı anda kullanılamayacağını belirlemek için kullanılır. Bu parametreler, güncellemenin kontrol edilmesi ve hatalı güncellemelerin geri alınması gibi işlemlerde önemlidir.

maxSurge: Bu parametre, mevcut replica sayısına göre belirli bir yüzde veya tam sayı değeri temsil eder. Örneğin, maxSurge değeri %25 ise ve toplam replica sayınız 4 ise, güncelleme sırasında en fazla bir ekstra pod başlatılabilir demektir. Bu, yeni sürümün aynı anda yavaşça dağıtılmasına yardımcı olur.

maxUnavailable: Bu parametre, mevcut replica sayısına göre belirli bir yüzde veya tam sayı değeri temsil eder. Örneğin, maxUnavailable değeri %50 ise ve toplam replica sayınız 4 ise, güncelleme sırasında en fazla 2 pod aynı anda kullanılamaz olabilir demektir. Yani, en fazla yarısı devre dışı bırakılabilir.

yaml file’ı Ctrl+X ile kaydedip çıkın ardından, apply edin.
kubectl apply -f rollingUpdate-deployment-v1.yaml

Deployment’ı kontrol etmek için Pod ve ReplicaSet’leri izleyin.
watch kubectl get pods
watch kubectl get rs

Görüldüğü üzere Podlar ve ReplicaSet sorunsuz olarak çalışmakta.

İlk yaml’da gcr.io/google-samples/hello-app:1.0 image’ını deploy etmiştik.
Şimdi Rolling Update yöntemi ile gcr.io/google-samples/hello-app:2.0 image’ını deploy edeceğiz.

rollingUpdate-deployment-v2.yaml adında bir yaml oluşturun.
nano rollingUpdate-deployment-v2.yaml

kind: Deployment
metadata:
  name: sercan
  namespace: default
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 25%
  selector:
    matchLabels:
      app: sercan
  template:
    metadata:
      labels:
        app: sercan
    spec:
      containers:
        - name: sercan
          image: gcr.io/google-samples/hello-app:2.0
          imagePullPolicy: Always
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
            successThreshold: 1

readinessProbe, bir Kubernetes Pod’unun hizmete hazır olup olmadığını kontrol etmek için kullanılan bir mekanizmadır. Aşağıda readinessProbe içindeki her bir özelliğin anlamını kısaca açıklayayım:

  • httpGet: Bir HTTP isteği gönderilir. Bu, belirli bir HTTP yoluna ve bir port numarasına yönlendirilir. Pod’un hizmet verdiğini doğrulamak için bu isteğe cevap vermesi beklenir.
  • path: httpGet ile yapılan isteğin hedef URL’sini belirtir. Bu, Pod’un sağlıklı olduğunu doğrulamak için kontrol edilen hedef sayfayı temsil eder.
  • port: Hangi port numarasının kullanılacağını belirtir. httpGet isteği, belirtilen port numarasına yönlendirilir.
  • initialDelaySeconds: Pod başlatıldıktan sonra ne kadar süre sonra ilk kez readinessProbe‘un çalıştırılacağını belirtir. Bu, Pod’un hizmete hazır olana kadar beklenmesini sağlar. Bu, hizmet başlatma süresini hesaba katmanıza yardımcı olur.
  • periodSeconds: readinessProbe‘un yeniden ne kadar süre arayla çalıştırılacağını belirtir. Yani, bu saniye cinsinden bir süredir ve Pod’un sürekli olarak hizmette olup olmadığını kontrol etmek için kullanılır.
  • successThreshold: Kaç ardışık başarılı (successThreshold) readinessProbe sonucunun gerektiğini belirtir. Örneğin, successThreshold değeri 1 ise, tek bir başarılı sonucun ardından Pod hizmete hazır olarak kabul edilir.

Şimdi yeni versiyonlu image’ı deploy edin.
kubectl apply -f rollingUpdate-deployment-v2.yaml

Ardından Pod ve ReplicaSet’leri izleyin.
Öncelikle yeni image build edilir. İlk deployment(v1) hala çalışmaya devam eder.

Yeni image deploy edildikten sonra  9t4k2 ve c5qp5 adındaki eski pod’lar terminate edilir ve deployment sorunsuz gerçekleşir.

Kubernetes’in “Rolling Update” stratejisini inceledik ve uygulamalarınızı güncellerken nelere dikkat etmeniz gerektiğini öğrendik. Rolling Update, uygulamanızın yüksek kullanılabilirliğini ve kesintisiz hizmet sunmasını sağlayan güçlü bir stratejidir.