Kubernetes Deployment Stratejileri 3

Blue / Green

Merhabalar,

Bu yazımda kubernetes de kullanılan deployment stratejilerinden blue-green deployment inceliycez. ilk olarak blue-green deployment nedir buna bakalım.

Blue-Green deployment temel olarak downtime’ı azaltmak amacıyla 2 farlı deployment’ın mevcut ortamda çalışmasını sağlanır ve ilgili service objesi ile rafik yönlendirerek downtime olmadan trafiği yönlendirmek için kullanılır. İlgili versiyonların kullanıma hazır hale getirmenin hızlı bir yoludur. Aynı zamanda bir problemle karşılaşıldığında hızlıca diğer versiyona geri döndürülür.

• Eski versiyon blue ile yeni versiyon green ile temsil edilir ve hem blue hem de green deployment aynı ortam da çalışır ve service objesindeki label-selector değiştirilerek trafic green deployment’ına yönlendirilir.
• Blue green deployment avantaji; Eski ve yeni sürümler arasında çakışma(overlap) olmaması ve dolayısıyla uyumluluk( compataible) sorunlarının önlenmesidir.

Minikube cluster’ımızda blue/green deployment stratejimizi yönetecez. Eğer minikube local’inizde yüklü değil ise diğer yazımdan okuyarak kurulum gerçekleştirebilirsiniz.

Minikube ile Kubernetes Kurulumu

Minikube cluster’ını başlatmak için;

minikube start --cpus 4 --memory 8192

Şimdide uygulama örneğimizi yapalım. İlk olarak blue deployment objemize bakalım.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-1
  namespace: default
  labels:
    app: web-app
spec:
  selector:
    matchLabels:
      app: web-app
      strategies: blue
  replicas: 1
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: web-app
        strategies: blue
    spec:
      containers:
      - name: web-app
        image: denizturkmen/rollingupdatev1:latest
        imagePullPolicy: IfNotPresent
        resources:
          requests:
            cpu: 100m
            memory: 1024Mi
          limits:
            cpu: 1000m
            memory: 2048Mi
        livenessProbe:
          tcpSocket:
            port: 80
          initialDelaySeconds: 5
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          timeoutSeconds: 2
          successThreshold: 1
          failureThreshold: 3
          periodSeconds: 10
        ports:
        - containerPort: 80
          name: web-app
      restartPolicy: Always

kubectl apply -f blue-dey.yaml

Yukarıdaki komut ile deployment yapalım. Şimdide service objemize bakalım.

apiVersion: v1
kind: Service
metadata:
  name: web-svc
  namespace: default
spec:
  selector:
    app: web-app
    strategies: blue
  type: NodePort
  ports:
  - name: web-svc
    protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 32565

kubectl apply -f blue-green-svc.yaml

Yukarıdaki komut ile service objemizi cluster’ımıza deploy yapalım.

Note: Burada en önemli olan noktalara değinecek olursak.

• Bildiğimiz üzere bir deployment objesi ve bu deployment oluşturduğu pod ilgili service yönlendirmek için label-selector yararlanırız. Bizim örneğimizde görüldüğü üzere; deployment labels:

labels:
    app: web-app

Fakat ilgili pod’a gidecek label-selector’imiz ise

template:
    metadata:
      labels:
        app: web-app
        strategies: blue

Görüldüğü gibi burada iki tane label tanımlanmış. Eğer service objemizdeki manifest’ime bakacak olursak yukarıda orada aynı abel selector’in olduğunu görürüz.

Buradan çıkartcağımız sonuç ise browserdan bir istek attığımızda bu deployment içindeki çalışan image aslında bizim pod’umuz oluyor. İstek önce service objesine gelecek oradan da bu service manifest’in label selector’ine göre pod’a trafiği yönlendirecektir.

Şimdide pod’umuza ilgili service objesi yönlenmiş mi bnu kontrol edelim. Minikube cluster’ında örneğimizi yaptıımız için;

minikube service list

Tarayıcıdan ilgili port’a gittiğimizde;

Görüldüğü gibi servis’imiz pod’a trafiği yönlendirdi ve pod’un içindeki image application cevap döndü. Şimdide green deployment objemizde bakalım.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-2
  namespace: default
  labels:
    app: web-app
spec:
  selector:
    matchLabels:
      app: web-app
      strategies: green
  replicas: 1
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: web-app
        strategies: green
    spec:
      containers:
      - name: web-app
        image: denizturkmen/rollingupdatev2:latest
        imagePullPolicy: IfNotPresent
        resources:
          requests:
            cpu: 100m
            memory: 1024Mi
          limits:
            cpu: 1000m
            memory: 2048Mi
        livenessProbe:
          tcpSocket:
            port: 80
          initialDelaySeconds: 5
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          timeoutSeconds: 2
          successThreshold: 1
          failureThreshold: 3
          periodSeconds: 10
        ports:
        - containerPort: 80
          name: web-app
      restartPolicy: Always

kubectl apply -f green-dep.yaml

Yukarıdaki komut ile green manifest’imizin deployment’ını yapalım ve kubectl get pods,svc ile de hem pod hem de service objelermize bakalım.

Şimdi son olarak baktığımızda cluster’ımızdaki deployment ve service objelerimize baktığımızda;

• iki tane deployment ve bir tane service objemiz mevcut.

Not: Bizim örneğimizde şuan ilgili servisimiz blue deployment manifest’imizin içindeki pod’a trafiği yönlendiriyor.

Not: Burada dikkat etmemiz gereken bir noktada deployment objemizdeki label-selector’lerdir;

• Blue deployment label-selector

labels:
        app: web-app
        strategies: blue

• Green deployment label-selector

labels:
        app: web-app
        strategies: green

• Service ilgili pod’a yönlenecek label-selector ise;

spec:
  selector:
    app: web-app
    strategies: blue

Yukaradaki label-selector görüldüğü üzere şuan trafic blue deployment gidiyor.

Şimdide yazımızın konusu olan blue/green deployment’ını nasıl gerçekleştireceğimiz bakalım. Bunu iki farklı yol ile yapabiliriz. İlgili service manifest’imizdeki label-selector’u strategies: green olarak güncelleyip tekrar manifest’i deploy yapabiliriz. Ya da var olan service objemizi editleyebiliriz.

Not: Önerilen yöntem her zaman declarative tabanlı gitmektir yani ilgili obje içindeki değişikler yapılıp tekrar deploy etmektir.

Biz ikinci yöntem ile ilerliycez. Bundan;

kubectl edit svc service_name

Selector’i strategies: green olarak değiştirip çıkalım ve tekrar minikube service list ile baktığımızda;

Browser’dan ilgili port’a gittiğimizde;

Yukarıdaki çıktıda görüldüğü gibi artık service objemiz içindeki label-selector var olan green-deployment’ımıza trafiği yönlendirmiştir.

Görüldüğü gibi blue-green deployment stratejisi bu kadar basit. İlgili trafiği label-selector ile ilgili pod’a yönlendirme yapıyoruz. İstediğimiz zaman service objemiz içindeki selector’ü değiştirerek trafiği ilgili pod’a yönlendirme yapabiliriz.

Not: Label-Selector ile ilgili trafiği pod’a yönlendirme yaptğımız downtime=0 olduğunuda gördük.

Önemli: Label-Selector’ün kubernetes objelerindeki kullanımın ne kadar önemli olduğunu öğrenmiş olduğumuzu umuyorum :)

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;