Modern DevOps dünyasında, son kullanıcıları rahatsız etmeden yazılım güncellemelerini yayınlama yeteneği sadece bir kolaylık değil, bir gerekliliktir. Endüstri standardı konteyner orkestrasyon platformu Kubernetes, riski azaltmak ve yüksek kullanılabilirliği sağlamak için tasarlanmış sofistike bir dağıtım stratejileri yelpazesi sunar. Orta ve ileri düzey geliştiriciler için bu stratejilerin nüanslarını anlamak, dayanıklı altyapı oluşturmak açısından kritiktir. Bu yazıda en yaygın Kubernetes dağıtım desenlerini, teknik uygulamalarını ve her birinin ne zaman kullanılacağını inceleyeceğiz.
Varsayılan: Rolling Güncellemeler
RollingUpdate stratejisi, Kubernetes'teki varsayılan davranıştır. Eski pod'ları yenisileriyle kademeli olarak değiştirerek çalışır. Denetleyici, eski örnekleri sonlandırmadan önce en azından belirtilen sayıda pod'un kullanılabilir olduğundan (minReadySeconds) emin olur. Bu yaklaşım, hız ile kullanılabilirlik arasında denge kurduğu için standart dağıtımlar için mükemmeldir.
Aşağıdaki Deployment manifest parçasına bakın. strategy.type değerini RollingUpdate olarak ayarlayıp maxSurge ve maxUnavailable değerlerini yapılandırarak güncelleme hızını kontrol edebilirsiniz:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels:
app: web-app
template:
spec:
containers:
- name: web
image: my-app:1.1
Bu örnekte, maxUnavailable: 0 güncelleme sırasında hiçbir isteğin düşürülmediğini garanti ederken, maxSurge: 1 geçici olarak bir ekstra pod'un oluşturulmasına izin verir. Bu, yeni sürümün hemen ve tam ölçekte benimsenmesinin kabul edilebildiği stateless (durumsuz) uygulamalar için idealdir.
Gelişmiş Kontrol: Canary Dağıtımları
Rolling güncellemeler güvenilir olsa da, genellikle yeni sürümü hemen kullanıcıların %100'üne tanıtmayı içerir. Bir Canary Dağıtımı, tam bir yayılım yapmadan önce hataları veya performans sorunlarını izlemek için trafiğin küçük bir yüzdesini yeni sürüme yönlendirmenize olanak tanır. Bu strateji, kötü bir yayılımın etkisini (blast radius) önemli ölçüde azaltır.
Kubernetes'te canary dağıtımları uygulamak genellikle, aynı hizmet etiketini paylaşan ancak farklı replika sayılarına sahip iki ayrı dağıtım oluşturmayı gerektirir. Trafik şekillendirme genellikle bir Ingress denetleyicisi (Nginx veya Traefik gibi) veya Istio gibi bir hizmet ağı (service mesh) tarafından yönetilir. Ancak temel bir uygulama şu şekilde görünebilir:
# Canary Dağıtımı (Kullanıcıların %20'si)
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app-canary
spec:
replicas: 1
template:
spec:
containers:
- name: web
image: my-app:1.2
# Stabil Dağıtım (Kullanıcıların %80'i)
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app-stable
spec:
replicas: 4
template:
spec:
containers:
- name: web
image: my-app:1.1
Gerçek bir trafik bölme işlemi gerçekleştirmek için, ağırlıklı uç noktaları olan bir Service kullanabilir veya gelen isteklerin %20'sini canary hizmetine ve %80'ini stabil hizmete yönlendirmek için Ingress kurallarınızı yapılandırabilirsiniz.
Kesintisiz Geçiş: Blue-Green Dağıtımları
Bir Blue-Green dağıtımında, iki aynı üretim ortamını korursunuz: Blue (şu anda canlı trafiği sunan) ve Green (yeni sürümün dağıtıldığı). Green ortamı tüm sağlık kontrollerini geçtiğinde, yük dengeleyiciyi Green'e yönlendirirsiniz. Bu, anında geri alma (rollback) yeteneği sağlar; Green başarısız olursa, trafiği tekrar Blue'a yönlendirmeniz yeterlidir.
Kubernetes'te Blue-Green'in zorluğu, iki kaynak setini (Services, Deployments, Persistent Volumes) yönetmektir. Özellikle uygulama durumu iki ortam arasında kolayca senkronize edilemiyorsa dikkatli planlama gerektirir. Bu strateji, karmaşık veritabanı geçişlerine sahip veya durumu aynı anda paylaşmanın zor olduğu paylaşılan durumlara sahip uygulamalar için en uygunudur.
Doğru Stratejiyi Seçmek
Doğru stratejinin seçimi, belirli kısıtlamınıza bağlıdır. Dağıtım hızının öncelikli olduğu basit, stateless mikro hizmetler için Rolling Güncellemeleri kullanın. Yeni özellikleri kullanıcıların bir alt kümesiyle doğrulamak veya kaynak tüketimini yakından izlemek istediğinizde Canary Dağıtımları tercih edin. Son olarak, anında geri almanın vazgeçilmez olduğu ve altyapı maliyetlerinin daha az önemli olduğu kritik güncellemeler için Blue-Green stratejisini saklayın.
Sonuç
Kubernetes, uygulama yaşam döngülerini yönetmek için güçlü araçlar sağlar ancak platform kendisi tek bir teslimat yöntemini zorlamaz. Rolling, Canary ve Blue-Green stratejileri arasındaki ödünleşimleri anlamak, DevOps mühendislerinin uygulamalarının güvenilirlik gereksinimleriyle uyumlu dağıtım pipeline'ları tasarlamasına olanak tanır. GitOps ve otomatik CI/CD pipeline'larına doğru ilerlerken, bu stratejileri entegre etmek altyapınızın sağlam, ölçeklenebilir ve modern yazılım geliştirme hızını yönetebilecek durumda kalmasını sağlar.