Graceful Shutdown — Deploy Sırasında Kaç İstek Düşer?
Önce şunu oku: Actuator ve Gözlemlenebilirlik — Sağlık, Metrik, İz
30 saniyede özet
Yeni sürüme geçerken eski sunucu kapanır. Kapanış sırasında hem yarım kalan isteklerin bitmesini beklemek hem de yeni isteklerin o sunucuya gelmesini durdurmak gerekir; ikisi aynı anda olmaz.
Her yeni sürümde, ödeme sayfasında birkaç kullanıcı hata alıyor. Graceful shutdown açık, readiness probe doğru. Hatalar deploy’un tam ilk saniyelerinde toplanıyor.
-
Bayt: Her yeni sürümde birkaç kullanıcı ödeme sayfasında hata alıyor!
-
Sen: Graceful shutdown açık değil mi?
-
Bayt: Açık! Readiness de doğru. Hatalar yalnızca deploy'un ilk saniyelerinde.
-
Bayt: Kapanırken aynı anda iki şey başlıyor. Hangisi önce bitiyor?
Kapanırken iki yarış
Pod silinince Kubernetes iki şeyi aynı anda başlatır: pod’u Service endpoint’lerinden çıkarmak ve container’a SIGTERMSürece 'kapan' diyen işletim sistemi sinyali. Süreç temizlik yapabilir; Kubernetes grace süresi dolunca yakalanamayan SIGKILL gönderir.Sözlükte gör → göndermek. Load balancer’ın haberi birkaç saniye gecikebilir.
İkinci yarış süreyle: terminationGracePeriodSeconds (varsayılan 30) dolunca Kubernetes yakalanamayan SIGKILL gönderir.
Kafam karıştı, daha basit anlat
Dükkânı kapatırken iki şey aynı anda olur: kapıya “kapalı” tabelası asılır ve kasiyere “toparlan” denir. Tabelayı görmeyen müşteri bir süre daha gelmeye devam eder.
Graceful shutdown açık olmasına rağmen her rolling deploy'da birkaç istek 502 alıyor. En olası neden hangisi?
Graceful shutdown neyi korur?
graceful shutdownKapanırken yeni istek almayı kesip işlenenlerin bitmesini belirli bir süre beklemek. Spring Boot 3.4'ten beri varsayılan; süreyi timeout-per-shutdown-phase belirler.Sözlükte gör →, SIGTERM geldiğinde yeni bağlantı almayı keser ve işlenen isteklerin bitmesini bekler. Bekleme süresini spring.lifecycle.timeout-per-shutdown-phase (varsayılan 30 sn) belirler.
Graceful shutdown açık, preStop yok. SIGTERM t=0'da geldi, load balancer t=3'e kadar istek göndermeye devam ediyor. t=1'de gelen istek ne olur? Cevabı göster
Reddedilir. Graceful shutdown işlenen istekleri korur, gelmekte olanları değil. Kapı kilitli; tabela henüz çevrilmedi.
Adım adım oku
- SIGTERM gelince uygulama yeni istek almayı bırakır, içeride yarım kalan istekleri bitirir: kapı kilitlenir, müşteriler alışverişini tamamlar.
- Load balancer'ın bu pod'u listeden çıkarması ise birkaç saniye sürer: tabela hâlâ açık yazıyor.
- O arada gelen istek kilitli kapıya çarpar ve hata alır.
- preStop'ta kısa bir bekleme, önce tabelanın dönmesini sağlar; kapı ancak sonra kilitlenir.
Çözüm bir preStop hookKubernetes'in SIGTERM'den önce container içinde çalıştırdığı komut. Kısa bir sleep, load balancer'ın pod'u listeden çıkarmasına zaman tanır.Sözlükte gör →: sleep 10, SIGTERM’i yönlendirme güncellenene kadar geciktirir. preStop süresi grace süresinin içindedir, üstüne eklenmez.
Kafam karıştı, daha basit anlat
Graceful shutdown, kasadaki müşterilerin işini bitirip sonra kapatmaktır. Ama kapı kilitlendikten sonra gelen müşteri yine içeri giremez.
server.shutdown=graceful açıkken uygulama SIGTERM aldı. Web sunucusu ne yapar?
preStop'ta sleep 10 var, terminationGracePeriodSeconds varsayılan (30), Boot'un timeout-per-shutdown-phase'i varsayılan (30 sn). SIGTERM geldiğinde 25 saniye sürecek bir istek işleniyor. Ne olur?
Graceful shutdown sırasında readiness probe'u ne döner ve neden önemlidir?
Kendin gör
Deploy sırasında kaç istek düşer?
Tohum 23039Oynat ya da adımla.
Şu an ne oldu?
Yeni sürüm geliyor, bu pod gidiyor
Kubernetes pod'u endpoint listesinden çıkarmaya ve SIGTERM göndermeye aynı anda başlar. Hangisi önce biter?
Görevler0/3
Graceful shutdown açıkken yine de istek kaybetaçık
İpucu
SIGTERM ne zaman geliyor?
Kubernetes'e SIGKILL gönderttiraçık
İpucu
Uzun iş, preStop, varsayılan süreler.
Uzun rapor varken sıfır hatayla kapataçık
İpucu
preStop ve daha uzun süreler.
Olay günlüğü (0)
Henüz olay yok. Oynat veya adımla.
- Varsayılanla oynat. Graceful açık, ama t=1 ve t=2’deki istekler reddedildi.
- preStop’u aç. Sıfır hata.
- İstekleri “40 sn süren rapor” yap. t=30’da SIGKILL.
- Süreleri uzat. Rapor bitti, sıfır hata.
- server.shutdown’ı “immediate” yap. Rapor anında kesildi.
Her ayarı, kapanışta neyi koruduğuna göre ayır.
Tuzaklar
Sinyal shell’de kaybolur. sh start.sh içinde java -jar çalışıyorsa SIGTERM shell’e gider, Java’ya ulaşmaz. exec java ... yaz ya da Java’yı doğrudan ENTRYPOINT yap.
Arka plan işleri beklenmez. Graceful shutdown web isteklerini bekler; @Async kuyruğu için spring.task.execution.shutdown.await-termination ayrıca açılmalı.
Uzun işler HTTP isteğinde. Grace süresini dakikalarca uzatmak her deploy’u uzatır ve çöken pod’u korumaz. Uzun işi bir iş kuyruğuna taşı.
Kafam karıştı, daha basit anlat
Kapatma haberi Java’ya ulaşmalı. Arada bir kabuk betiği varsa haber orada kaybolur ve uygulama toparlanmaya fırsat bulamadan kapanır.
Pod her kapanışta tam 30 saniye bekliyor ve sonra SIGKILL ile ölüyor; uygulama log'unda hiçbir kapanış satırı yok. Hatalı satır hangisi?
@Async ile gönderilen e-postaların bir kısmı her deploy'da kayboluyor. Graceful shutdown açık. Neden?
Aşağıdaki örnek bir bankanın internet bankacılığı API’sinden; müşteri transferin ortasındayken deploy yapılabilmeli. Sıfır hatalı deploy için gereken parçalar bir arada: uygulama ayarları, sinyali JVM’e ulaştıran imaj, preStop ve süreleri tutarlı bir Kubernetes manifesti, ve HTTP isteğinden çıkarılmış uzun bir iş.
Derinleş · Internet bankacılığında kesintisiz deploy: uçtan uca 6 dosya · ~126 satır · ilk okumada atlayabilirsin
Kendini sına
Pod silinince Kubernetes endpoint'ten çıkarmayı ve SIGTERM'i aynı anda başlatır.
Bir uç nokta büyük bir CSV'yi 3 dakikada üretip indiriyor. Deploy'larda bu indirmeler yarıda kesiliyor. En sağlam çözüm hangisi?
Aklında kalacak üç şey
- 1 Sunucuyu listeden çıkarmak ile kapatma sinyali aynı anda başlar. preStop'taki kısa bir bekleme, yönlendirme güncellenmeden kapanışın başlamasını engeller.
- 2 Graceful shutdown yeni istek almayı keser ve yarım kalanları belli bir süre bekler; Spring Boot 3.4'ten beri varsayılan olarak açıktır.
- 3 preStop ile en uzun iş, verilen kapanış süresine sığmalıdır. Sığmazsa Kubernetes işlemi zorla öldürür ve hiçbir temizlik yapılamaz.
5 kart sonraki derste seni bekliyor