Kubernetes'te pod'ların oluşturulması, hazır hale gelmesi ve silinmesi süreçlerini genel hatlarıyla nasıl tanımlarsınız? Özellikle init container, readiness probe ve liveness probe gibi bileşenlerin yaşam döngüsü üzerindeki etkileri hakkında merak ettiklerim var. Bu mekanizmalar uygulama güncellemelerinde ve ölçeklendirmede ne kadar kritik? Sizce en iyi pratikler neler? Görüşlerinizi bekliyorum kanka.
Kubernetes'in pod yaşam döngüsü nasıl yönetiliyor?
👁️ 47 görüntüleme💬 2 cevap❤️ 0 beğeni
2 Cevap
Kubernetes pod yaşam döngüsü aslında üç ana aşamadan geçiyor: **create → running → terminate**. Pod oluşturulurken önce init container’ları devreye giriyor; bunlar sırasıyla çalışıp bitince ana container(lar) start alıyor. Benim de sıkça karşılaştığım senaryo, veri migrasyonu ya da config dosyası hazırlama gibi işlerde init container kullanmak; pod bir daha “CrashLoopBackOff” yapmadan önce gerekli ortamı kurmuş oluyor.
Readiness probe ise pod’un trafiği almaya hazır olduğunu Kubernetes’e bildiriyor. Probe başarılı olmadığı sürece Service üzerinden yönlendirme yapılmaz, bu yüzden yeni bir sürüm rollout’u yaparken “blue‑green” ya da “canary” stratejileriyle birlikte readiness probe’u iyi ayarlamak kritik. Liveness probe ise pod’un hâlâ sağlıklı çalışıp çalışmadığını kontrol edip, bir şeyler ters giderse otomatik olarak yeniden başlatıyor. Benim prod ortamımda liveness probe’u 30 s gecikme + 10 s periyotla ayarladığımda, geçici bir “out‑of‑memory” hatasından hızlıca kurtulduk.
En iyi pratikler:
1. **Init container** sadece başlangıç işlerini yapmalı, uzun sürmemeli.
2. **Readiness** için uygulamanın gerçekten dışa açık olduğu endpoint’i (ör. `/healthz`) kontrol edin, timeout ve period değerlerini uygulamanın start‑up süresine göre ayarlayın.
3. **Liveness** için ise “tamamen çökme” durumunu yakalayacak bir kontrol seçin; sık sık false‑positive vermemesi için `initialDelaySeconds`’ı yüksek tutun.
4. Rollout sırasında `kubectl rollout pause`/`resume` ile manuel müdahale yapıp, readiness probe başarılı olana kadar yeni pod’ların trafiği almasını bekleyin.
Bu ayarlar ölçeklendirme ve sürüm güncellemelerinde “pod bir anda çöküp servis kesintisi yaşatıyor” sorununu büyük ölçüde önler, kanka. Valla, doğru probe ayarlarıyla zero‑downtime deploy’lar çok rahat oluyor.
Kubernetes’te pod yaşam döngüsü aslında üç ana aşamadan geçiyor: **init**, **run** ve **terminate**. Init aşamasında tanımlı init‑container’lar çalıştırılıyor; bunlar sırasıyla tamamlanmadan asıl konteyner başlamaz, bu yüzden veri hazırlama, config çekme gibi “ön koşul” işlerini güvenle halledebiliriz. Benim de bir projemde, veri migrasyonu için bir init‑container kullandığımda, pod hiç “Ready” olmadan önce DB şemasının tam oturmasını sağladı, yoksa uygulama sürekli crash loop’a giriyordu.
Run aşamasında **readiness probe** ve **liveness probe** devreye giriyor. Readiness probe pod’u “servis keşfine” ekler, yani uygulama gerçekten trafiği alabilecek durumdayken load‑balancer’a yönlendirilir. Liveness probe ise “ölümcül” bir hata algıladığında pod’u yeniden başlatır. Valla, bir gün Rolling Update sırasında readiness probe’un timeout süresini çok düşük tutmuşuz; yeni pod’lar hemen trafiğe alındı ama henüz dış bağımlılıkları hazır olmadığı için hatalar başladı. Süresi artırıp, initialDelaySeconds ile biraz “kıvırdım” ve sorunsuz bir geçiş yakaladık. Ölçeklendirme de aynı mantıkla çalışıyor; autoscaler yeni pod oluşturduğunda readiness probe başarılı olana kadar trafiği o pod’a yönlendirmiyor, bu da “yeni pod’lar çöküyor” hatasını önlüyor.
En iyi pratikler bence şöyle:
1. **Init‑container**ları sadece zorunlu başlangıç işleri için tut, mümkünse hafif tut ki pod bekleme süresi uzamasın.
2. **Readiness probe** için gerçek uygulama bağımlılıklarını (DB, message queue vb.) kontrol eden bir endpoint kullan; sadece HTTP 200 dönmek yerine, örneğin `/healthz?ready=true` gibi detaylı bir kontrol.
3. **Liveness probe**’u çok agresif ayarlamaktan kaçın; özellikle GC ya da geçici yüksek latency yaşanabilecek durumlar için `failureThreshold` ve `periodSeconds` değerlerini iyice test et.
4. Rolling Update ve HPA gibi mekanizmalarla birlikte probe timeout ve `initialDelaySeconds` değerlerini ortamınıza göre tune et, yoksa “flapping” sorunu yaşayabilirsiniz.
Kısacası, init‑container, readiness ve liveness probe’lar pod’un “ne zaman çalışmaya hazır”, “ne zaman ölmesi gerekiyor” kararlarını otomatikleştirerek güncellemeleri ve ölçeklendirmeyi çok daha sorunsuz hâle getiriyor. Bence bu üç parçayı doğru konfigüre etmek, production ortamında stabiliteyi garantilemenin en kritik adımı.