Kubernetes'te kesintisiz sürüm güncelleme: rolling update uygulaması

Rolling update nedir ve neden varsayılan stratejidir?

Kubernetes'te bir Deployment'ın pod şablonunu değiştirdiğinizde, örneğin yeni bir imaj etiketi yazdığınızda, Deployment yeni bir ReplicaSet oluşturur ve eski pod'ları bir anda silmek yerine kademeli olarak yenisiyle değiştirir. Bu kademeli geçişe rolling update (yuvarlanan güncelleme) denir. Strateji alanı belirtilmezse Deployment bu yöntemi kullanır.

Amaç, güncelleme sırasında uygulamanın bir bölümünün her zaman hizmet vermesidir. Yeni pod hazır olmadan eskisi kapatılmaz; trafik, hazır olan pod'lara akar. Dolayısıyla doğru kurulduğunda kullanıcı sürüm değiştiğini fark etmez. Alternatif strateji Recreate'tir: önce tüm eski pod'ları durdurur, sonra yenilerini başlatır. Kısa bir kesinti pahasına, aynı anda eski ve yeni sürümün çalışmasını istemediğiniz durumlarda kullanılır.

Önemli bir ayrım: rolling update yalnızca pod şablonu değiştiğinde tetiklenir. Replika sayısını değiştirmek bir güncelleme sayılmaz, yalnızca ölçeklemedir.

Güncellemeyi tetiklemek ve izlemek

Güncellemeyi başlatmanın yolları bellidir. En yaygını manifestteki imaj etiketini değiştirip kubectl apply çalıştırmaktır; bu yöntem değişikliği sürüm kontrolünde tutar. Hızlı bir deneme için doğrudan komut da kullanılabilir:

kubectl set image deployment/uygulamam kapsayici=kayit.ornek.com/uygulamam:yeni-etiket

Güncellemenin seyrini şu komutla izlersiniz:

kubectl rollout status deployment/uygulamam

Bu komut, yeni sürüm tamamen yayılana ya da süreç takılana kadar bekler. CI/CD hattında rollout status komutu çoğu zaman dağıtımın başarılı sayılması için bir kapı olarak kullanılır. Geçmişi görmek için kubectl rollout history, ayrıntıları görmek için kubectl describe deployment komutu işe yarar. Aynı anda eski ve yeni ReplicaSet'leri görmek için kubectl get rs komutunu çalıştırın: eskisi küçülürken yenisi büyür.

Etiket olarak latest yerine mutlaka sabit ve izlenebilir bir etiket kullanın. Aynı etiketle farklı imaj yayımlamak, Deployment'ın bir değişiklik algılamamasına ya da hangi sürümün çalıştığının belirsizleşmesine yol açar.

maxSurge ve maxUnavailable: geçişin hızını ve riskini ayarlamak

Rolling update'in davranışını iki alan belirler:

• maxSurge: Güncelleme sırasında hedef replika sayısının üzerine en fazla kaç ek pod oluşturulabileceğini söyler. Büyük değer, daha hızlı geçiş ve geçici ekstra kaynak ihtiyacı demektir.
• maxUnavailable: Güncelleme sırasında en fazla kaç pod'un kullanılamaz olabileceğini söyler. Büyük değer hızlı ama kapasite düşüren geçiş sağlar.

İki alan da mutlak sayı ya da yüzde olarak yazılabilir. Varsayılan değerleri ve ayrıntılı davranışı Deployment belgesinden kontrol edin.

Aşağıdaki yapılandırma, kapasitenin düşmesini istemeyen ve geçici fazladan pod'a izin veren bir uygulama içindir:

apiVersion: apps/v1 kind: Deployment metadata: name: uygulamam spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: <sıfır> maxSurge: <geçici ek pod sayısı> minReadySeconds: <saniye> progressDeadlineSeconds: <saniye>

maxUnavailable alanını sıfıra çekmek, yeni pod hazır olmadan hiçbir eski pod'un kapatılmamasını sağlar. Bunun karşılığında maxSurge'ün sıfırdan büyük olması gerekir; aksi halde güncelleme ilerleyemez. Kaynağı kısıtlı bir kümede ek pod'a yer olup olmadığını da hesaba katın, yoksa yeni pod Pending'de kalır.

Güvenli güncellemenin dayanağı: readiness probe ve süre ayarları

Rolling update'in akıllı gibi görünen davranışı, tamamen pod'un hazır olduğunun doğru bildirilmesine dayanır. Kubernetes, bir pod'un hazır olup olmadığını readiness probe sonucuna göre anlar. Probe tanımlı değilse konteyner başladığı anda hazır sayılır; uygulama henüz bağlantı kabul etmese bile eski pod kapatılır ve kullanıcı hata görür. Bu yüzden rolling update öncesinde uygulamanın gerçekten istek karşılayabildiğini yoklayan bir readiness probe şarttır.

Birkaç süre alanı güvenliği artırır: • minReadySeconds: Yeni pod'un, hazır olduktan sonra belirli bir süre çökmeden kalmasını bekler. Hazır olup hemen çöken pod'ların sürümü yaymasını engeller. • progressDeadlineSeconds: Güncelleme bu süre içinde ilerlemezse Deployment, durumunda ilerleme zaman aşımına uğradığını bildirir. kubectl rollout status bu durumda hata verir; süreci sizin geri almanız gerekir, Deployment otomatik geri dönmez. • terminationGracePeriodSeconds ve preStop kancası: Kapanan pod'un devam eden istekleri tamamlayabilmesi için zaman tanır. Uygulama SIGTERM sinyalini işleyip yeni bağlantı almayı bırakmalıdır.

Readiness probe yalnızca trafiğe hazır olup olmadığını bildirir; liveness probe konteynerin yeniden başlatılıp başlatılmayacağını, startup probe ise yavaş açılan uygulamalarda diğer probe'ların ne zaman devreye gireceğini belirler.

Takılan güncellemeyi geri almak ve sorun gidermek

Güncelleme beklediğiniz gibi gitmediğinde ilk iş geri almaktır:

kubectl rollout undo deployment/uygulamam

Bu komut bir önceki revizyona döner. Belirli bir revizyona dönmek için rollout history çıktısındaki revizyon numarası kullanılır. Deployment eski ReplicaSet'leri sınırlı sayıda saklar; revisionHistoryLimit alanı bu sayıyı belirler. Çok düşük tutarsanız geri dönecek bir şey kalmayabilir.

Geri aldıktan sonra nedeni araştırın. Yaygın senaryolar şunlardır: • ImagePullBackOff: İmaj adı ya da etiketi yanlış, kayıt defterine erişim yetkisi yok. Yeni pod'lar hiç başlamadığı için eski pod'lar kapanmaz ve hizmet etkilenmez. • CrashLoopBackOff: Yeni sürüm başlangıçta çöküyor. kubectl logs ile önceki konteyner çıktısına bakın. • Pending: Kümede ek pod'a kaynak yok. maxSurge ya da kaynak isteklerini gözden geçirin. • Readiness hiç geçmiyor: Probe yolu ya da portu yanlış; uygulama ayakta ama kontrol başarısız.

Duraklatma da işe yarar: kubectl rollout pause güncellemeyi bırakır, böylece birden çok değişikliği tek seferde uygulayabilirsiniz; kubectl rollout resume ile devam edersiniz. Kontrollü bir canary denemesi için daha ileri araçlar ve ayrı Deployment'lar gerekir; rolling update bunu doğrudan sunmaz.

Kesintisiz güncelleme kontrol listesi

Yayına çıkmadan önce şu soruları gözden geçirin:

• Readiness probe uygulamanın gerçekten hazır olduğunu mu yokluyor?
• Uygulama SIGTERM sinyalini alınca devam eden istekleri tamamlayıp kapanıyor mu?
• Aynı anda eski ve yeni sürüm çalışabilir mi? Veritabanı şeması ve API sözleşmesi geriye uyumlu mu? Rolling update'te eski ve yeni sürüm bir süre beraber çalışır.
• Kaynak istekleri ve kümenin boş kapasitesi geçici ek pod'lara yetiyor mu?
• Kesinti bütçesi (PodDisruptionBudget) tanımlı mı? Düğüm bakımı ile aynı zamana denk gelen güncellemeler kapasiteyi beklenenden fazla düşürebilir.
• Geri alma yolu denendi mi? rollout undo komutunun çalıştığını bir test ortamında görmek, gerçek olayda zaman kazandırır.
• Sabit imaj etiketi kullanılıyor mu?

Bu kontrol listesi, çoğu "güncellemede kesinti yaşadık" hikâyesinin kökenini ortaya çıkarır: genelde sorun Kubernetes'te değil, uygulamanın hazır olma ve kapanma davranışındadır.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Rolling update, Deployment ve iş yükü yönetimi bilgisinin üzerine oturur. Mindset kataloğundaki "Kubernetes ile Orkestrasyon" programı, "İş Yükü Kaynakları", "Ölçekleme ve Kaynak Yönetimi" ve "Güvenilirlik ve Sorun Giderme" modülleriyle bu temeli verir. Dağıtım süreçlerinden sorumlu geliştiriciler, DevOps mühendisleri ve platform ekipleri, güncelleme stratejisini bu modüllerdeki kavramlarla birlikte ele alabilir. Kurumsal ekipler için sürüm yayınlama pratiğinin ortak bir dilde oturtulması açısından uygundur.