Technical Tutorials

Konteynerleştirilmiş uygulamaların modern manzarasında, yüksek erişilebilirlik ve sorunsuz güncellemeler vazgeçilmezdir. Kubernetes, orkestrasyon için de facto standart haline gelmiştir, ancak gücü sadece konteynerleri yönetmesinde değil, yaşam döngüsü geçişlerini nasıl yönettiğimizde yatar. Orta düzeyden ileri düzey geliştiriciler için, dağıtım stratejilerinin nüanslarını anlamak; trafik artışları ve kod yayınları sırasında sistem kararlılığını korumak açısından kritiktir. Bu yazı, üretim Kubernetes ortamında iş yüklerini dağıtmak için en etkili stratejileri incelemektedir.

Temel: Rolling Güncellemeleri

Kubernetes'te varsayılan ve en yaygın kullanılan strateji Rolling Update'dir (Kademeli Güncelleme). Adından da anlaşılacağı üzere, Kubernetes eski pod'ları yeni olanlarla kademeli olarak değiştirir. Bu strateji, mevcut sürümün tüm örneklerini aynı anda sonlandırmayarak uygulamanızın güncelleme süreci boyunca erişilebilir kalmasını sağlar.

Kubernetes, bu davranışı kontrol etmek için iki temel parametre sağlar: maxSurge ve maxUnavailable. maxSurge, istenen durumun üzerinde oluşturulabilecek maksimum pod sayısını tanımlarken, maxUnavailable güncelleme sırasında erişilemez olabilecek maksimum pod sayısını belirtir. Bu değerleri ayarlayarak, güncelleme hızını kümenizdeki kaynak tüketimi ve kararlılıkla dengeleyebilirsiniz.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v1.2

Yukarıdaki örnekte, maxUnavailable: 0 ayarlanması, yeni pod'lar tamamen hazır olana kadar hiçbir pod'un kaldırılmamasını garanti ederek sıfır kesinti sağlar. Ancak, bu durum geçici olarak artan pod sayısını işlemek için yeterli küme kaynakları gerektirir.

Gelişmiş Stratejiler: Blue/Green ve Canary

Rolling güncellemeler sağlam olsa da, trafik seviyesinde anında geri alma (rollback) yetenekleri sunmazlar. Yeni sürümde bir hata bulunursa, rolling güncellemesinin geri dönmesini beklemeniz gerekir ki bu da zaman alabilir. İşte tam da burada Blue/Green ve Canary dağıtımları devreye girer.

Blue/Green Dağıtımı

Blue/Green yaklaşımı, mevcut kararlı sürümü çalıştıran bir ortam (Blue) ve yeni sürümü çalıştıran başka bir ortam (Green) olmak üzere iki özdeş ortamı korumayı içerir. Green ortamı tamamen test edilip hazır olana kadar trafik Blue ortamına yönlendirilir. Doğrulandıktan sonra, hizmet seçicisi (service selector) Green pod'larına işaret edecek şekilde değiştirilir. Avantajı anında geri almaktır; sorunlar ortaya çıkarsa, hizmet seçicisini tekrar Blue'a geri çevirmek anında gerçekleşir.

Uygulama, iki ayrı Deployment kaynağını yönetmeyi ve Service seçicisini güncellemeyi gerektirir; bu süreç Argo Rollouts veya Flux gibi araçlar kullanılarak otomatikleştirilebilir.

Canary Dağıtımı

Bir Canary dağıtımı daha kademeli bir yaklaşımdır. Tüm trafiği değiştirmek yerine, yeni sürümü kullanıcıların küçük bir alt kümesine (örneğin, trafiğin %5'ine) yayımlarsınız. Hata oranları ve gecikme süresi gibi metrikleri izlersiniz. Metrikler sağlıklı görünüyorsa, yeni sürümün trafiğin %100'ünü işleyene kadar yeni sürüme yönlendirilen trafik yüzdesini kademeli olarak artırırız.

# Hipotetik bir araç kullanılarak yapılan bir Canary yapılandırma örneği
# Bu kavramsaldır, çünkü yerel K8s trafik bölme için Services/Ingress kullanır
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: {duration: 2m}
      - setWeight: 50
      - pause: {duration: 5m}

Canary dağıtımları, minimum kullanıcı etkisiyle sorunları tespit etmenize izin verdiği için riski en aza indirmek için idealdir. Ancak, bölünmüş trafiği etkili bir şekilde analiz etmek için gelişmiş trafik yönetimi ve izleme araçları gerektirirler.

Sonuç

Doğru dağıtım stratejisinin seçilmesi, kuruluşunuzun risk toleransına, altyapı yeteneklerine ve yayın sıklığına bağlıdır. Birçok ekip için iyi ayarlanmış bir Rolling Update yeterlidir. Ancak, yüksek riskli yayınlar için Blue/Green veya Canary stratejilerini benimsemek; uygulamanıza olan güveni korumak için gereken güvenlik ağını ve gözlemlenebilirliği sağlar. Bu kalıpları ustalıkla kullanarak, Kubernetes altyapınızı basit bir konteyner çalışma zamanından, güvenilirlikten ödün vermeden çevik geliştirme döngülerini destekleyebilen, dayanıklı ve üretim seviyesinde bir platforma dönüştürürsünüz.