Kubernetes Rolling Update ve Blue-Green Deployment Nedir?

Kubernetes Rolling Update ve Blue-Green Deployment, yazılım uygulamalarının güncellenmesi ve dağıtımı için kullanılan iki farklı stratejidir. Her ikisi de sistemlerin kesintisiz ve güvenli bir şekilde güncellenmesini sağlamak için tasarlanmıştır.

Kubernetes üzerinde çalışan uygulamalarınızı güncellemek istediğinizde kullanabileceğiniz belirli deployment stratejileri vardır. Her bir stratejinin kendine özgü avantaj ve dezavantajları mevcuttur. Bu nedenle hangi stratejiyi seçeneğinizi belirlemeden önce bu stratejilerin ne olduklarına bakalım.

1. Kubernetes Deployment Stratejileri

Kubernetes deployment stratejilerinin ne olduğunu, neden gerekli olduğunu ve hangisini tercih etmeniz gerektiğini incelemek için ReplicationController veya ReplicaSet ile yönettiğiniz pod'larınızın olduğunu varsayalım.

RC veya RS ile yönettiğiniz mevcut pod'larınızı güncelleyebilmek için üç stratejimiz bulunuyor. Bunlar;

• Önce mevcut tüm podları silmek ve ardından yenilerini başlatmak
• Önce yeni pod'ları başlatmak ve ardından tüm eski pod'ları silmek [Blue-Green Deployment]
• Sırayla yeni pod'ları başlatırken eş zamanlı eski pod'ları silmek [Rolling Update]

Şimdi herbir stratejiyi sırasıyla detaylı olarak inceleyelim.

1.1. Önce mevcut tüm podları silmek ve ardından yenilerini başlatmak

ReplicationController yazımızda anlattığımız gibi bir RC'nin template'ini güncellediğimizde yeni oluşturulan pod'lar bu yeni template ile oluşturulur.

Kubernetes Replication Controller Nedir?

Replication Controller, pod’ları sürekli izleyerek belirlenen sayıda pod’un çalışır olduğunu garantiler.

Kerteriz BlogIsmet BALAT

Eğer uygulamamızı güncelleyeceksek, bu özelliği kullanarak RC'nin template'ini güncelleyebilir ve ardından tüm pod'ları silerek yeni pod'ların güncel ve yeni template ile oluşturulmasını sağlayabiliriz.

1.2. [Blue-Green Deployment] - Önce yeni pod'ları başlatmak ve ardından tüm eski pod'ları silmek

Eğer uygulamanızda downtime görmek istemiyorsanız önce yeni pod'ları başlatmalı ve ardından Service'i bu yeni pod'lara bir anda yönlendirmeliyiz. Bu stratejiye Blue-Green Deployment adı verilir.

Blue-Green Deployment, yeni bir uygulama sürümünün mevcut sürümle aynı ortamda yan yana çalıştığı bir dağıtım stratejisidir. Bu yaklaşım, yeni bir sürümü etkinleştirmeden önce kullanıcılara ve testlere açık olan ayrı bir ortam kullanır.

İşlem genellikle şu adımları izler:

• Mevcut ortam "Blue" olarak adlandırılır ve kullanıcı trafiğini karşılar.
• Yeni bir sürüm, yeni pod-selector değerleriyle oluşturulur ve test edilir, bu sürüm "Green" olarak adlandırılır ve ayrı bir ortamda çalışır.
• Green ortamı başarılı bir şekilde test edildikten ve onaylandıktan sonra, trafik Blue'dan Green'e yönlendirilir.
• Tüm trafik Green ortamına geçtikten ve Blue ortamında hiçbir kullanıcı kalmadıktan sonra Blue ortamı kapatılır.

Bu işleyişi gerçekleştirebilmek için Green ortamı hazır olduktan sonra Service'in selector değerini kubectl set selector komutuyla veya manifest update ile Green ortamında kullandığınız yeni selector değeriyle değiştirmeniz gerekir. Ardından Service gelen trafiği bu yeni selector'un olduğu pod'lara yönlendirecektir.

Kubernetes Service Nedir?

Kubernetes Service, bir Pod grubuna sabit bir adresten erişmek için kullanılan bir Kubernetes nesnesidir.

Kerteriz BlogIsmet BALAT

Bu yöntem, kullanıcılar için kesintisiz bir deneyim sağlar. Eğer bir sorun ortaya çıkarsa, hızla önceki sürüme geri dönülebilir. Blue-Green Deployment, güncelleme sürecinde riskleri en aza indirmek ve hızlı bir geri dönüş yapmak için kullanışlı bir stratejidir.

Avantajları:

• Yeni sürümün tamamen test edilmesi ve onaylanması sağlanır.
• Kullanıcılar kesintisiz bir deneyim yaşarlar.
• Geri dönüş yapmak hızlı ve kolaydır.

Dezavantajları:

• İkinci bir ortamın oluşturulması ve bakımı gerektirir.
• İki ortam arasında geçiş sırasında ekstra yapılandırma veya veri senkronizasyonu gerekebilir.
• Yüksek maliyetli olabilir. Çünkü aynı anda daha fazla pod çalışacağı için kaynak tüketimi artacaktır.

1.3. [Rolling Update] - Sırayla yeni pod'ları başlatırken eş zamanlı eski pod'ları silmek

Tüm yeni pod'ları bir kerede aktif edip eski pod'ları silmek yerine, pod'ları adım adım değiştiren bir sıralı güncelleme işlemi de gerçekleştirebilirsiniz. Bunu, önceki ReplicationController'ı yavaşça scale-in ederken ve yenisini scale-out yaparak elde edebilirsiniz. Bu durumda, Service'in pod selector değeri aynı kalacak ve hem eski hem de yeni pod'ları içerecektir. Böylece istekleri her iki pod grubuna yönlendirecektir.

Rolling Update, bir uygulamanın mevcut bir sürümünü yeni bir sürümle değiştirirken, sistemdeki kullanılabilirliği ve devamlılığı korumak için adımlı bir yaklaşım kullanır. Bu strateji, uygulamayı adım adım güncelleyerek hizmet kesintisi olmaksızın yeni sürüme geçişi sağlar.

İşlem genellikle şu adımları izler:

• Eski sürümden bir pod kaldırılır ve yerine yeni sürümden bir pod oluşturulur.
• Eski sürüm kalmayana kadar bu işlem devam eder.
• Eski sürümden pod kalmadığında eski sürümün RC veya RS'si kaldırılır.

Rolling Update, uygulamaların sürekli çalışmasını ve yüksek kullanılabilirliğini sağlamak için önemlidir. Bir sorun ortaya çıkarsa, geri dönüş yapmak ve önceki sürüme geçmek oldukça kolaydır.

Avantajları:

• Uygulama sürekli çalışır ve yüksek kullanılabilirlik sağlanır.
• Güncelleme sürecinde kullanıcılar etkilenmez.
• Sorunlar ortaya çıktığında geri dönüş yapmak kolaydır.
• Kaynak tüketimi aynı kalacağı için daha az maaliyetlidir.

Dezavantajları:

• Uygulama güncellenirken bazı hatalar veya uyumsuzluklar ortaya çıkabilir.
• Eski ve yeni sürüm arasındaki uyumluluğu kontrol etmek önemlidir.
• Güncelleme süreci daha uzun sürebilir.

2. Kubectl ile Otomatik Rolling Update

Kubernetes deployment stratejilerini yukarıdaki başlıklarda öğrendik. Tüm bu stratejileri her ne kadar mümkün olsa da elle yapmak oldukça zahmetli ve hataya açıktır. Bu nedenle kubectl aracı bize rolling update için bu işlemleri otomatik yapacak bir komut sunuyor.

Kubectl ile rolling update işlemini otomatik olarak yapmak için kubectl rolling-update komutunu kullanabiliriz. İşleyişin nasıl olacağını anlamak için örnek bir senaryo üzerinden incelemeye başlayalım.

Öncelikle uygulamamızın v1 versiyonunu yönetecek bir ReplicationController ve bu pod'lara trafiği yönlendirecek Service nesnemizi oluşturalım.

apiVersion: v1
kind: ReplicationController
metadata:
  name: kubia-v1
spec:
 replicas: 3
 template:
   metadata:
     name: kubia
     labels:
       app: kubia
   spec:
     containers:
     - image: kubia:v1
       name: nodejs
---
apiVersion: v1
kind: Service
metadata:
  name: kubia
spec:
  type: LoadBalancer
  selector:
    app: kubia
  ports:
  - port: 80
    targetPort: 8080

Şu anda mevcut durumumuz bir Service, bir ReplicationController ve üç adet pod'dan oluşuyor.

kubia-v1 ReplicationController'un template'inde yer alan kubia:v1 image versiyonu kubia:v2 olarak güncellemek için aşağıdaki komutu çalıştırıyoruz.

kubectl rolling-update kubia-v1 kubia-v2 --image=kubia:v2

Böylece kubia-v2 isimli ReplicationController oluşturularak rolling update işlemi başlatılacaktır.

Rolling update işlemi başlatıldığında kubia-v1 ve kubia-v2ReplicationController'ların pod-selector'una ve mevcut pod'lara random değerli bir deployment label daha eklenir.

Böylece Service'in kullandığı selector label aynı kalıp trafik akışı kesilmezken her ReplicationController kendi pod'larını rahatça yönetebilir hale gelmiş olur.

Tüm bu işlemler gerçekleşirken terminalinizde yapılan işlemleri de takip edebilirsiniz.

...
Scaling kubia-v2 up to 2
Scaling kubia-v1 down to 1
Scaling kubia-v2 up to 3
Scaling kubia-v1 down to 0
Update succeeded. Deleting kubia-v1
replicationcontroller "kubia-v1" rolling updated to "kubia-v2"

Tüm deployment başarıyla tamamlandığında kubia-v1 ReplicationController silinir ve ortamda sadece yeni versiyona sahip pod'larla kubia-v2 ReplicationController kalır.

2.1. Kubectl Rolling Update Dikkat Edilmesi Gerekenler

kubectl rolling-update komutu ile rolling update başlattığınızda terminalinize akan çıktılardan farkettiğiniz üzere işlemleri manual yapmak yerine kubectl sizin yerinize aynı stratejiyi uyguluyor. Fakat tıpkı sizin manual yaptığınızda olduğu gibi kubectl aracı da anlık terminal üzerinden Kubernetes API Server ile iletişime geçerek aynı adımları gerçekleştiriyor. Bu durumda eğer bir network, terminal veya farklı herhangi problem nedeniyle kubectl aracının API Server ile bağlantısı kesilirse deployment yarıda kalacaktır.

Herhangi bir problem sebebiyle kubectl rolling update deployment işlemlerini tamamlayamazsa güncelleme o anki haliyle kalacak ve devam edemeyecektir. Belki böyle bir durumda iki RC ve farklı versiyonlara ait birden fazla pod meydanda kalacak ve sizin manual müdahalenize ihtiyaç duyacaktır.

Sizin yerinize kubectl'in işlemleri manual yani imperative yöntemle yapması yukarıdaki sebepler yüzünden doğru olmayacağından bu komutu kullanmanızı önermiyoruz. Bunun yerine bir sonraki Kubernetes Deployment yazısını incelemenizi ve kullanmanızı şiddetle tavsiye ederiz.

Sıradaki yazı ile eğitim serisine devam edebilirsiniz.

Kubernetes Deployment Nedir?

Kubernetes Deployment, uygulamaların dağıtımını, güncellemesini ve ölçeklendirmesini yönetmek için kullanılan bir objedir.

Kerteriz BlogIsmet BALAT