Kubernetes (k8s) Deployment Stratejileri

Bir önceki yazımda kubernetes mimarisini ve terminolojisini aktarmaya çalıştım. Bu yazımda ise kubernetes üzerine deployment stratejilerinden bahsediyor olacağım. (if you want to read this article in English, click here)

Artık continuous delivery’nin ve çevikliğin ön planda olduğu, şirketlerin agile dönüşümlerine önem verdiği bir dönemdeyiz. Hemen hemen tüm teknoloji şirketleri delivery sürelerini düşürmek, gün içinde hızlı bir şekilde ve birden fazla kez productiona paketler atmayı hedefler haline geldi.

Günümüz popülaritesini yakalarken; uygulamadaki değişimin sistem ve son kullanıcıyı olumsuz etkilememesi adına deployment seçeneklerinin çok iyi değerlendirilip karar verilmesi gerekmektedir.

Kullanım durumlarına bağlı olarak kullanabileceğimiz bu stratejileri sizlere aşağıda görselleriyle aktarıyor olacağım.

1- Recreate

Türkçe’ye çevirdiğimizde adından da anlaşılacağı gibi yeniden oluşumdur. Yani; uygulamamızın çalıştığı podların tamamen kapanıp, yeni versiyonla podların ayağa kalktığını düşünebilirsiniz.

Uygulama; podların kapanıp yeniden oluşması süresinde tamamen erişime kapalı(down durumda) olacağını altını çizerek sölemek isterim. Uygulamamız warm-up aşamasında da trafiği üzerine almayacaktır. 7 gün 24 saat kullanılabilir olması beklenen siteler için asla önerilmez. (iş arama platformları, e-ticaret siteleri vb) Yaml dosyamıza ufak bir dokunuşla bu stratejiyi kullanabiliriz.

apiVersion: apps/v1
kind: Deployment
metadata:
   namespace: your namespace
spec:
   replicas: 1
   strategy:
      type: Recreate

Şekil ve grafiksel olarak aşağıdaki görsellerle daha rahat anlayacağınızı düşünüyorum.

2- Rolling Update (Ramped Slow-Rollout) Deployment

Uygulamamızın çalıştığı podları artımlı bir şekilde kapatır ve yeni poda taşır. Hiç bir kesinti olmaz. Eski podun kapatılması sırasında pod üzerindeki sessionlar sonlanana kadar podu öldürmez. Böylece geçiş basit ve son kullanıcı hata almadan yeni versiyona geçiş tamamlanır. Stratejiyi belirlerken “maxSurge” tanımlarız. Bu adım adım kaç tane podun kapatılıp kaç tane yenisi açılacağının sayısını verir. “maxUnavailable” ise deployment sırasında kaç tane podun servis dışı olabileceğini tanımlar.

apiVersion: apps/v1
kind: Deployment
metadata:
   namespace: your namespace
spec:
   replicas: 5
   strategy:
      type: RollingUpdate
      rollingUpdate:
         maxSurge: 1
         maxUnavailable: 0

Yin şekil ve grafiksel olarak aşağıdaki görsellerle daha rahat anlayacağınızı düşünüyorum.

Geri kalan deployment stratejilerini yine görseller ile diğer yazılarımda paylaşıyor olacağım. Tek bir yazıda overload yaşatmak istemedim :)

Stay tuned! :)