Kubernetes'te Pod'ların yaşam döngüsü nasıl yönetilir?

30 Haz 05:37

Geçen yıl bir müşterinin üretim ortamında Kubernetes kümesini yönetirken, bir deployment’in Pod’larının sürekli **"CrashLoopBackOff"** durumunda sıkıştığını gördüm. Her yeniden başlatmadan sonra pod loglarına baktığımda, uygulamanın kendi başlatma süresiyle health check’lerin çatıştığını fark ettim — uygulama henüz ayağa kalkmamışken Kubernetes’in **liveness probe**’u "başarısız" olarak işaretliyordu. Sorun şuydu: **başlangıç gecikmesi (initialDelaySeconds)** 30 saniyeydi, ama uygulama 45 saniyede hazır oluyordu. Küçük bir değişiklikle `initialDelaySeconds: 45` ve `timeoutSeconds: 5` ayarlarını yaptık, ardından pod’lar stabilize oldu. Bir başka sorun da **kaynak kısıtlamaları** yüzünden self-healing mekanizmasının devreye girememesiydi. Node’larda CPU throttle’ları oluşunca, pod’ların restart’ları aslında durumu daha da kötüleştiriyordu. Burada yaptığımız şey, **LimitRange** ve **ResourceQuota** objelerini kullanarak namespace bazında CPU/memory limitlerini düzgün ayarlamak oldu. Özellikle `requests` ve `limits` arasındaki dengesizliği düzeltince, Kubernetes’in **Horizontal Pod Autoscaler (HPA)** düzgün çalışmaya başladı ve pod’lar gerektiğinde ölçeklendi. Sonunda, en kritik nokta **readiness ve liveness probe’ların doğru tanımlanması**. Ben genellikle her zaman **TCP readiness** ve **HTTP liveness** kombinasyonunu kullanıyorum — uygulama göze çarpıcı şekilde yanıt vermiyorsa restart edilsin, ama sadece belli endpointler hazır değilse trafik almasın. Bu sayede self-healing daha akıllıca çalışıyor. Arka planda gördüğüm en büyük iyileşme, **k8s audit log’larını izleyerek probe ayarlarının zamanla nasıl değişmesi gerektiğini öğrenmek** oldu. Özellikle trafiğin yoğun olduğu dönemlerde probe sürelerini dinamik olarak ayarlamak için küçük bir **sidecar ile probe ayarlarını geri besleme** sistemi kurduk — bunu da deneyimden öğrenilen bir "hack" olarak paylaşabilirim.