Kubernetes Deployment Strategies
kubernetes deployment stratejilerinden bahseceğim.
her production kubernetes kullanıcısı için belirlemesi gereken bir konudur bu.
5 ana başlıkta inceleyeceğiz;
- Rolling Update
- Recreate
- Blue/Green
- A/B testing
- Canary
yapılan günlük deploymentların bu şekilde farklılandırılmasında ki etkenler şunlardır,
- yeni versiyon geçişinde down-time ı azaltılması,
- yeni versiyonla ilgili testlerin yapılabilmesi ve sorunlar için hızlı fixler alınması,
- müşterilerin yeni versiyona daha hızlı ulaşması
gibi maddeler belirleyebiliriz.
Rolling Update (Ramped)
kubernetes için default deployment stratejisidir, basit bir şekilde ifade edersek; yeni versiyon bir pod create edillir eğer bu Pod içindeki application düzgün çalışıp Running state e geçiyorsa eski version Podlardan biri terminate edilir böylece tek tek bütün podlar yeni versiyona geçer.
spec altında strategy adımında yazarız.
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0farklı olarak yüzde olarak verilip mesela aynı anda sayının 4 e 1 i kadar pod create edilip terminate edilir.
spec:
replicas: 6
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%kolay bir şekilde uygulanması yanında bazı dezavatajları olabiliyor, mesela trafiği yönetemiyorsunuz bir trafik eski versiyona biri yeni versiyona düşüyor. ve sorunlu bir deployment olduysa rollback biraz uzun sürüyor tek tek ayağa kaldırdığı için eğer Pod sayınız fazlaysa eski versiyona da geçmeniz uzun sürer.
Recreate
ya hep ya hiç gibi düşünebilirsiniz. bütün var olan versiyonlardaki pod u kapatıp yenisini açar. hızlı bir geçiş oluşturur fakat downtime kaçınılmaz. yeni podlar ayağa kalkana kadar trafik gönderilmeyecek.
spec:
replicas: 2
strategy:
type: Recreate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1Blue/Green (red/black)
blue deployment sizin production ortamınızdaki çalışan aktif deployment olsun. yeni versiyon çıktığınızda bunu green deployment olarak çalıştırırsınız böylece ortamınızda hem blue hem green iki tane deployment üzerinde çalışan podlarınız olur. green üstünde gerekli testleri yaptıktan sonra herşey olması gerektiği gibi ise trafiği blue dan alıp green e çevirirz böylece yeni istekler green podlara yönelir.
en hızlı deployment stratejisi diyebiliriz çünkü sadece trafiği çevireceğiz Pod ların ayağa kalkmasını beklemeyeceğiz zaten hazır olduklarını biliyoruz. ayrıca çok hızlı bir şekilde rollback yapabiliriz blue podlar zaten hala ortamımızda bulunuyor.
dezavantaj olarak hem blue hem de green aynı anda var olacağı için 2 kat resource tüketiriz ayrıca her green deployment anında testlerin tamamlanması gerekiyor. bunun dışında bütün çalışan trafiği bir anda çevirdiğiniz anda green deployment ın kaldırabilmesi gerekiyor, bu şekilde riskler olsa da çok yararlı bir stratejidir.
A/B Testing
Blue/Green deploymenta benzese de aslında aynı değildir.
genellikle yüksek bir versiyon geçişi değil de userlardan geri dönüşlü bir test için özellikle UI larda kullanılan deployment çeşididir. yeni bir feature testi yapılıyor olabilir ya da geo bazlı bir değişiklik çıkılmıştır testi yapılıyor olabilir. burada amaç bazı userları bir versiona bazılarını diğer versiyonda çalıştırmadır. böylece gelecek feedback e göre hangi versiyonla ilerlenecek karar verilebilir.
farklı bir sürü versiyonu paralelde aynı anda çalıştırabilmesi bu strateji için çok güzel özellik. fakat tüm bu trafik yönlendirilmeleri ve yeni versiyonlarda oluşacak kaynak kullanımı maliyetli olacaktır. burda troubleshoot ederken ayrıca farklı versiyonlardaki sorunlara farklı farklı bakmak gerekecek biraz yorucu olabilir.
Canary
Mantıkta blue/green e benziyor ama burada yeni versiyona komple trafik çevrilmiyor var olan versiyondan diğer versiyona trafik belli bir ölçüde gönderiliyor. çoğu user eski versiyona gitsede birazı yeni versiyona gidiyor böylece testçiler yeni versiyon üzerindeki testlerini yaparken aynı anda yeni versiyonu kullanan kullanıcılardan da feedback gelecek böylece hem blue/green hem de a/b testing i aynı anda yapmış olacağız.
Burada dezavantaj iyi bir traffic management gerekiyor, bu yapıyı kurmak için linkerd ya da istio gibi toollar da gerekebilir. maliyetli fakat en garantili versiyon geçişi bana göre canary release.
SONUÇ:
ortamınızın ve yaptığınız applicationların kritkliğine göre bir deployment stratejisi belirlemeniz gerekiyor. eğer sıkıntısız bir geçişim olsun son kullanıcı ile kontrollü geçelim derseniz canary uygun. ama son kullanıcıya bağlı kalmadan testleri ben yaparım uygunluğu belirlerim şeklinde düşünüyorsanız blue/green sizin için en faydalı olan olacaktır. resouce kullanımına önem veriyorsanız testleri lokalde yaparım diyorsanız RollingUpdate sizde göre.
umarım faydalı olmuştur, bir sonraki yazımda görüşmek üzere.
h.a.s.
source :
