Kubernetes (K8s) Deployment Stratejileri
Bu yazıda sektörde sıklıkla kullandığımız deployment stratejilerini inceleyeceğiz. Makalede stratejilerin nasıl kullanılacağından daha çok genel bir bilgi vermek amaç edinilmiştir. Bir yazılım geliştirici olarak uygulamaya yeni özellikler kazandırmak, bugları temizlemek ve bakım yapmaktan sorumluyuz. Fakat tek sorumluluğumuz bu değil, bunun yanında uygulamanın müşterilere nasıl ulaştırılacağı da sorumluluklarımız arasında. Elimizdeki case’e göre doğru deployment stratejileri belirlemek müşteri memnuniyeti ve hata yönetimi açısından kritik önem taşımaktadır. Deployment stratejilerine geçmeden önce birkaç temel kavramı açıklamakla başlayalım. Bu kavramlar makalenin konusu olmadığından yüzeysel değinilecektir, detaylar için araştırma yapmanızı öneririm.
Kubernetes Nedir?
Kubernetes aslen Yunanca kökenli bir kelimedir ve dümenci/pilot anlamına gelmektir. Kaynaklarda çoğunlukla K8S olarak da kullanılır. Kubernetes bir yazılımın dağıtımını, ölçeklendirmeyi ve yönetimini otomatikleştirmek için kullanılır. Dockerize olmuş image’ları stratejik bir biçimde müşteriye sunar.
Pod Nedir?
Container’ların çalışma alanı diyebiliriz. Bir pod içerisinde birden fazla container çalıştırılabilir. Kubernetes’te deployment için temel bir atomik birimdir.
Kubernetes’te pod, paylaşılan depolama alanı ve ağa sahip bir veya birden fazla containerdan oluşan bir gruptur.
ReplicaSet Nedir?
Bir poddan kaç adet olacağını belirler. İstediğimiz bir pod’u kesintisiz scale etmemiz veya azaltmamıza olanak tanır.
Deployment Statejileri
Kubernetes deployment stratejileri bir uygulamanın farklı sürümlerinin nasıl oluşturulacağının, yükseltilip veya düşürüleceğini tanımlar. Geleneksel yazılım ortamında, uygulamalara yapılan dağıtımlar veya yükseltmeler kesinti süresine veya hizmetin aksamasına neden olur. Kubernetes, kesinti süresini önlememize veya en aza indirmemize olanak tanıyan bazı deployment stratejileri sunarak bunlara karşı önlem almamızı sağlar.
Bir deployment stratejisi uygulamanın yaşam döngüsünü ve bir uygulamadaki güncellemelerin nasıl uygulanması gerektiğini tanımlar. Genelde bir YAML dosyası üstünde configure edilir.
1 — Rolling Deployment
Kubernetes’in varsayılan deployment stratejisidir. Podların mevcut sürümünü yeni bir sürümle günceller, podları kesinti olmadan tek tek günceller.
Rolling Update, yeni podları tek seferde aktif etmek yerine podları adım adım değiştirir. Sıralı bir güncelleme olarak düşünebilirsiniz. Sistemdeki kullanılabilirliği ve devamlılığı korumak için adımlı bir yaklaşım kullanır. Sistemde bir kesintiye sebep olmaz.Rolling update aşamasında bir hata ortaya çıkarsa eski sürüme geri dönüş yapmak kolaydır.
Rolling update’de görünen avantajlarına rağmen dikkat edilmesi gereken bazı hususlar vardır. Adım adım eski sürüme sahip podları öldürüp, yeni sürüme sahip podları deploy ederken iki farklı sürümün production ortamında müşteriye ulaşacağının bilincinde olmak gerekir. Yeni sürümde çıkılan bir feature, eski bir sürümde olmayacağından sorunlar ortaya çıkabilir ve consistency gibi problemler olabilir.
Bir fintech şirketinde çalıştığınızı düşünelim; bu şirkette bir feature geliştirdiniz ve rolling-update ile deployment yapılıyor. Ahmet kullanıcısı telefonundan attığı istek ile eski sürüme gidiyor ve yeni feature ile artık eski yapı kullanılmayı bırakılacak. Tam deployment sırasında ise Cem yeni sürüme istek atıp, feature bağlamında happy path’i deneyimliyor. Bu durumda Ahmet için olumsuz bir deneyim sunabilir, DB üzerinde problemler yaşanabilir veya consistency bozulabilir. Bu gibi caseler detaylandırılabilir. Proje için deployment stratejisi seçerken bu gibi durumlara dikkat edilmelidir. Multi-version destekleyen bir proje üstünde çalışıyorsanız bu gibi durumları tolere edebilirsiniz.
2 — Recreate Deployment
Recrate deployment tüm eski sürüme sahip podları kapatan ve yeni sürüme sahip podlarla değiştiren bir deployment modelidir. Tüm eski podların kapatılıp, yeni sürüme sahip podların oluşması sırasında bu deployment stratejisi downtime’a sebep olabilir.
Eğer proje multi-version bir yapıyı desteklemiyorsa recrate deployment stratejisi tercih edilebilir.
3 — Ramped Slow Rollout Deployment
Ramped slow rollout, eski sürüme sahip podları kaldırırken yeni kopyalar oluşturarak podları kademeli olarak günceller. Her seferinde kullanıma sunulacak çoğaltma sayısı seçilebilir. Ayrıca hiçbir pod’un kullanılmaz hale geldiğinden emin olmak gerekir.
Bu strateji ile rolling update arasındaki temel fark, yeni sürüme sahip kopyaların kullanıma sunulma hızını kotnrol etmektir. Örneğin; güncelleme riskini azaltmak için herhangi bir zamanda yalnızca 2, 3 veya 1 olarak belirleyeceğinz podun güncellenmesi gerektiği tanımlanabilir.
4 —Blue-Green Deployment
Kubernetes içerisinde bu strateji için bir deployment’in iki sürümünü tutarsınız. Çalışan mevcut sürüm için Blue, yeni sürüm için Green. İkisi arasındaki trafiği yönetmek için Kubernetes hizmetleri kullanılır.
- Başlangıçta tüm trafiği Blue, yani eski sürüme yönlendirir.
- Cluster içerisinde Blue sürümün yanında, Green sürüm de deploy edilir.
- Green, yani yeni sürüm hazır olduğunda ve test edildiğinde trafiği Green sürüme yönlendirilir.
- Herhangi bir problem ortaya çıkarsa tekrardan Blue sürüme geçilir.
Artıları:
- Blue-Green deployment avantajlarından birisi basit, hızlı, iyi anlaşılmış ve uygulamasının kolay olmasıdır. Olası durumlarda geriye almak da basittir. Diğer dağıtım stratejilerine göre riskli değildir.
Eksileri
- Maliyet, blue-green deployment için bir dezavantajdır. Bir üretim ortamını çoğaltmak, özellikle microserisler ile çalışırken karmaşık ve pahalı olabilir.
- Trafikte geçiş yapıldığında işlem gören istekler kaybolabilir, müşteri tarafında sorunlar yaratabilir ve geniş çaplı olumsuz iş etkileri olabilir.
5- Canary Deployment
Canary deployment genellikle bir uygulamanın backend tarafındaki bazı yeni özellikleri test etmek için kullanılır. Bir uygulamanın iki veya daha fazla hizmeti, sürümü paralel olarak dağıtılır; bunlardan biri mevcut sürümü çalıştırırken diğeri yeni özellikler içerir. Kullanıcılar kademi olarak yeni sürüme geçirilerek, yeni sürümün kullanıcılara dağıtılması sağlanır. Herhangi bir hata görülmezse, tüm kullanıcılara dağıtılır.
Artıları
- Canary deployment, şirketlerin production ortamında gerçek kullanıcılar ve senaryolara ile test yapmasına olanak tanır. İki production ortamı gerektirmediği için blue-green deployment stratejisinden daha ucuzdur. Geri dönüş senaryosu hızlı ve güvenlidir.
Eksileri
- Canary deployment’in dezavantajları, production ortamında test etme ve gerekli uygulamaları içerir. Testler zaman alabilir, production ortamında test senaryolarını uygulamak zor olabilir.
6- Shadow Deployment
Shadow deployment, uygulamanın yeni sürümünün mevcut sürüm ile birlikte fakat son kullanıcıları etkilemeden trafikte yer edindiği bir yaklaşımdır. Bu deployment stratejisi ekiplerin sistemin gerçek yük ve veriler ile, gerçek zamanlı test etmesine olanak tanır.
7- A/B Testing
A/B Testleri deployment bağlamından ayrı olarak, business unitlerinin karar vermede kullanacağı dataları da oluşturur. Büyük ölçekli şirketler A/B testlerini finanse edebilecek güce sahip olduğundan uygulamaya getirilecek yeni bir özellik için A/B testleri uygulamayı tercih edebilir. Örneğin; kadın kullanıcılara farklı, erkek kullanıcılara farklı arayüz kullandırtmanın etkilerini araştırabilir. Müşterileri belirli havuzlara ayırıp, bir kısmına kırmızı renkte buton gösterip diğer kısmına turuncu renkte buton gösterebilir. Bu butonlara tıklanma oranlarından gelecekteki stabil sürümde hangisinin tercih edileceği kararlaştırılabilir.
A/B Testing kullanıcıların katılımı, hata oranları veya diğer KPI’lar açısından hangisinin daha iyi perfomans gösterdiğini görmek için bir uygulama özelliğini iki veya daha fazla sürümünü aynı anda bir kullanıcı kümesine sunar.
