Kubernetes Startup Probes Nedir?

Başka bir yazımda readiness ve liveness probeları arasındaki farkı anlatmıştım. Probe ailesinin artık yeni bir üyesi var.

Elimizde bir java uygulaması var diyelim. Bir sürü yere bağlanıyor, db, kafka, redis, cassandra, rabbit, mongo vs ve bazen her seferinde yapmadığı db migration kısımlarını içeriyor. Siz sırf ara sıra çalışan bu migration işlemlerinden ötürü, probeların init delay secondslarını bu istinayı kapsasın diye ya genelde gereğinden fazla vermek zorunda kalıyorsunuz ve çoğu zaman boşa bekliyor ya da bu istisnai durumda pod sürekli fail alıp restart oluyor.

Tabi akla ilk gelen, açıkcası benimde uzun bir süre kullandığım failureThreshold * periodSeconds yöntemini uygulamak oluyor. Spesifik problemimizi çözsede, startup harici herhangi bir sıkıntıyla karşılaştığında da k8s aksiyon alabilmesi için bu uzun süreyi beklemesi gerekiyor.

Startup Probes

Ailenin yeni üyesi işte bizi bu dertten kurtarmak için var. Eğer startup probe tanımlarsanız, hata alırsa başka probelar çalışmaz ve aynı liveness probeda olduğu gibi hata aldıkça pod restart eder.

Eski uygulamalar, java daha doğrusu spring boot 🙂 uygulamaları için veli nimet.

Ne zaman ve nasıl kullanmalı

Eğer container initialDelaySeconds + failThreshold × periodSeconds normal değerinden daha uzun sürelerde kalkıyorsa kullanmak gerekir aksi halde liveness probe işinizi görecektir.

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

failureThreshold * periodSeconds = 300 saniye vermiş olduk. Eğer ki 301 saniye olursa probe bişeylerin doğru gitmediğini anlayacak ve podumuzu restart edicektir. Biz de böylelikle uzun bir timeout almayı bekleyen zombi poddan çok geç olmadan kurtulmuş olacağız.

Period seconds, failureThreshold zaten diğer problerdan alışkın olduğumuz kavramlar. Burda en dikkat edilmesi gereken nokta bence sürenin doğru ayarlanması. Tamamıyle size kalmış, uygulama uygulama süreler değişebilir.

failureThreshold * periodSeconds = 300 saniye vermiş olduk. Eğer ki 301 saniye olursa probe bişeylerin doğru gitmediğini anlayacak ve podumuzu restart edicektir. Biz de böylelikle uzun bir timeout almayı bekleyen zombi poddan çok geç olmadan kurtulmuş olacağız.