Technical Tutorials

Konteyner orkestrasyon dünyasında Kubernetes, uygulama yaşam döngülerini yönetmek için varsayılan standart haline gelmiştir. Ancak bir uygulamayı sadece konteynerleştirmek ilk adımdır. Gerçek meydan okuma, güncellemeleri kullanıcı deneyimini kesintiye uğratmadan güvenli ve verimli bir şekilde sunmaktır. Orta ve ileri düzey geliştiriciler için Kubernetes dağıtım stratejilerinin nüanslarını anlamak sadece iyi bir beceri değil; dayanıklı ve yüksek erişilebilirliğe sahip sistemler oluşturmak için kritik bir gerekliliktir.

Bu yazıda, Kubernetes'te mevcut olan en yaygın dağıtım stratejileri ele alınmakta; bunların artıları ve eksileri, uygulama detayları ve ideal kullanım durumları analiz edilmektedir.

Varsayılan: Rolling Güncellemeleri

RollingUpdate stratejisi, Kubernetes'in varsayılan dağıtım yöntemidir. Pod'ları kademeli olarak değiştirir ve çalışan örnek sayısının belirtilen bir minimumun altına düşmemesini sağlar. Bu yaklaşım, kesinti süresini ve kaynak kullanımını en aza indirerek çoğu standart web uygulaması için uygundur.

Kubernetes, varsayılan olarak güncelleme süreci sırasında pod'ların en fazla %25'inin erişilemez olmasına izin verir. Bu davranışı ince ayar yapmak için maxSurge (istenen sayının üzerindeki pod'lar) ve maxUnavailable yapılandırılabilir. Örneğin, kapasitenizin en az %50'sinin her zaman erişilebilir olmasını sağlarken, yeni sürümleri hızlıca yaymak için agresif bir şekilde ölçeklendirme yapmak isteyebilirsiniz.

Sıfır Durdurma Dağıtımları: Blue-Green ve Canary

Rolling Güncellemeleri sağlam olsa da, granüler trafik kontrolü sunmaz. %1 hata oranının bile kabul edilemez olduğu kritik hizmetler için Blue-Green ve Canary dağıtımları daha üstün seçeneklerdir.

Blue-Green Dağıtımları

Blue-Green stratejisinde, iki özdeş üretim ortamı tutarsınız. Herhangi bir anda yalnızca biri canlıdır (örneğin Blue). Yeni bir sürüm dağıttığınızda, bu sürüm boşta kalan ortama (Green) gider. Doğrulandıktan sonra, hizmetin uç noktalarını Blue'dan Green'e geçirirsiniz.

Kubernetes'te yerleşik bir "Blue-Green" kaynağı bulunmamakla birlikte, bu genellikle iki ayrı Deployment kullanarak ve Service içindeki selector etiketlerini değiştirerek gerçekleştirilir. Bu, anında ve atomik bir geçiş sağlar ancak iki katı hesaplama kaynağı gerektirir.

Canary Dağıtımları

Canary dağıtımları daha gelişmiş bir yapıdadır. Trafikin küçük bir yüzdesini yeni sürüme yönlendirirken, geri kalanının eski sürümde çalışmaya devam etmesini sağlar. Bu sayede, tam bir yayınlama işlemine geçmeden önce hata oranları ve gecikme süreleri gibi metrikleri izleyebilirsiniz.

Canary dağıtımlarını uygulamak genellikle harici bir servis mesh'i (Istio veya Linkerd gibi) veya ağırlıklı trafik bölme yeteneğine sahip gelişmiş bir ingress kontrolcüsü (Nginx veya Traefik gibi) gerektirir. İşte bir Nginx Ingress'un ağırlıklı yönlendirmeyi nasıl yönetebileceğine dair kavramsal bir örnek:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: canary-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10" # Yeni sürüme %10 trafik
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp-canary # Yeni sürüme işaret eder
            port:
              number: 80

Doğru Stratejinin Seçimi

Bir strateji seçimi birkaç faktöre bağlıdır:

Karmaşıklık: Rolling güncellemeleri yerleşiktir ve minimum yapılandırma gerektirir. Canary ise ek araçlar gerektirir.
Risk Toleransı: Geri alımları hızlıca gerçekleştirebiliyorsanız Rolling Güncellemeler yeterlidir. Gerçek trafikle test etmeniz gerekiyorsa Canary kullanın.
Kaynak Kısıtlamaları: Blue-Green, 2 katı kaynak gerektirir. Rolling güncellemeleri kaynakları verimli bir şekilde paylaşır.

Sonuç

Kubernetes dağıtımlarında her şeye uygun tek bir çözüm yoktur. Rutin mikroservis güncellemeleri için varsayılan Rolling Update stratejisi genellikle yeterli ve verimlidir. Ancak yüksek riskli yayınlar için Blue-Green veya Canary stratejilerine yatırım yapmak, azaltılan risk ve artan güven açısından kendini amorti eder. DevOps uygulamalarınızı olgunlaştırdıkça, bu dağıtım stratejilerini tamamlamak için otomatik sağlık kontrollerini ve geri alma tetikleyicilerini hattınıza entegre etmeyi düşünün.

Bu tekniklerin ustalaşmak, uygulamanızın erişilebilirliğini artırmakla kalmayacak; aynı zamanda geliştirme iş akışınızı da akıcı hale getirerek ekibinizin özellikleri daha hızlı ve daha güvenli bir şekilde yayınlamasına olanak tanır.