Canlılık/Hazırlık örnekleri

2) Tasarım ilkeleri

1. Ayrı bir semantik.

Hazırlık: Taleplere hizmet vermek için harici yetenek (kritik bağımlılıkları dikkate alır).
Canlılık: Sürecin "tedavi edilemez" durumunun tespit edilebilirliği.
2. Başarısız hızlı, ama yanlış hızlı değil. Kısa patlamaların gereksiz yeniden başlatmalara yol açmaması için zaman aşımlarını/eşik değerini 'failureThreshold'olarak ayarlayın.
3. Örneklerde ağır operasyon yok. Kontrol hızlı olmalı (≤100 -200 ms) ve yan etkileri olmamalıdır.
4. Zarif bir bozulma. Bağımlılıkların kısmen bulunmaması durumunda - Hazır olma = Tamam, güvenli bir geri dönüş varsa (önbellek/kabalaşma).
5. Deterministik I/O Durumlar sadece mevcut duruma bağlıdır, "rastgele" harici testlere bağlı değildir.

3) SAĞLIK-uç noktalarının semantiği

3. 1 HTTP yaklaşımı (önerilir)

'GET/healthz/liveness' - 200 işlem "canlı'ise (olay döngüsü dönüyor, GC sıkışmış değil, bekçi" kalp "atıyor).
'GET/healthz/readiness' - Örnek kritik sınıf trafiği için hazırsa 200. Denetimler: bağlantı havuzu, yerel önbellekler, iş mantığı çekirdeği kullanılabilirliği.
'GET/healthz/startup' - 200 başlatıldıktan sonra (geçişler/önbellek ısınma/yükleme modelleri).

• Dış veritabanlarına/API'lere canlılık içinde gidemezsiniz - bu, bağımlılık olayları sırasında "intiharlara" yol açacaktır.
• Hazırlıkta, kritik bağımlılıkları kontrol edebilirsiniz, ancak zaman aşımları ve bozulma ile: geçerli bir geri dönüş varsa, onu düşürmeyin.

3. 2 gRPC Sağlık Kontrolü

'GRPC' standardını kullanın. sağlık. v1. Sağlık/Check 'with service-scoped states (' SERVING ',' NOT _ SERVING '). Kubernetes için - grpc probları (veya http proxy).

3. 3 Dahili tetikleyiciler

Watchdog "soft" stop: SIGTERM seti ile Readiness = FAIL - 'terminationGracePeriodSeconds' için bekleyin - bitiş, çalışma kuyrukları.

4) Zamanlamalar ve eşikler (ayarlama)

• 'initialDelaySeconds', 'periodSeconds', 'timeoutSeconds', 'successThreshold', 'failureThreshold'.

• hazırlık: 'period = 5s, timeout = 0. 2–0. 5s, başarısızlık = 2 '
• liveness: 'period = 10 s, timeout = 0. 2–0. 5s, başarısızlık = 3 '

• başlangıç: 'periyot = 5s, başarısızlık = 60' (~ 5 dakikaya kadar)
• Başlangıç başarısından sonra harekete geçirilen hazırlık/canlılık

• Hazırlık, işleme hazırlığını yansıtır (bir komisyoncuya bağlantı, DLQ bozulması olup olmadığı),
• canlılık - iç kalp atışı döngüsü.

Arızalarda geri dönüş: Uygulamada, bağımlılıklara yeniden bağlanmak için üstel geri dönüşü kullanın, aksi takdirde hazır olma "görüldü" olacaktır.

5) Konfigürasyonlar (parçalar)

5. 1 Kubernetes, HTTP probları

yaml livenessProbe:
httpGet: { path: /healthz/liveness, port: 8080 }
periodSeconds: 10 timeoutSeconds: 1 failureThreshold: 3

readinessProbe:
httpGet: { path: /healthz/readiness, port: 8080 }
periodSeconds: 5 timeoutSeconds: 1 failureThreshold: 2

startupProbe:
httpGet: { path: /healthz/startup, port: 8080 }
periodSeconds: 5 failureThreshold: 60

5. 2 Kubernetes, gRPC örneği

yaml readinessProbe:
grpc:
port: 9090 service: my. app. Service periodSeconds: 5 timeoutSeconds: 1

5. 3 Zarif kapatma

yaml terminationGracePeriodSeconds: 30 lifecycle:
preStop:
exec:
command: ["/bin/sh","-c","curl -s localhost:8080/healthz/drain && sleep 5"]

Hizmetin içindeki'/healthz/drain ', Readiness = FAIL (stop-accepting) çevirisini yapar, aktif istekleri tamamlamak için zaman verir.

6) Bağımlılıklar ve bozulma

Kritik (bunlar olmadan hizmet verilemez):'/login 'için yetkilendirme veritabanı,'/pay' için ödeme ağ geçidi. 'TimeoutSeconds' örneklerinin % ≤80'ü zaman aşımına hazır olarak kontrol edilebilir.
Kritik olmayan: analitik, e-posta, bir yük varsa önbellek katmanı. Onları hazırlığa dahil etmeyin; Follbeck kullan.
Özellik bayrakları: Kısmen bozulmuşsa, Readiness = OK değerini korurken bağımlı özellikleri devre dışı bırakın.

7) Kuyruklar ve arka plan işleyicileri

• Hazırlık = Komisyoncuya bir abonelik/bağlantı kurulmuşsa ve işlenecek bir kaynak varsa Tamam.
• Ne zaman DLQ/lag taşması - Hazırlık Tamam kalabilir (kabul eder ve eklersek), ancak SLI "tazelik/gecikme" yanar - verilere göre uyarı.
• Canlılık: anket döngüsü/kalp atışı, deathdetector kontrol.

Idempotence: Yeniden başlayan canlılıktan iyileşmeyi hızlandırır.

8) Sidecar/mesh/giriş

• Yan araç durumunu hesaba katmak için 'readinessGate' (K8s) etkinleştirme,
• Örneklerin mTLS bariyerlerine düşmediğinden emin olun (veya istisnalar ekleyin).
• Giriş/Elçi/Nginx: Prox'/healthz/' yerel olarak, iç parçaları "ortaya çıkarmayın".

9) Güvenlik ve gizlilik

Sağlık uç noktaları yapılandırmaları, kütüphane sürümlerini, hata dizelerini ifşa etmemelidir - yalnızca "OK/FAIL" + minimum neden kodu.
Dış erişimi kısıtlayın (NetworkPolicy/ACL). Halk için - ayrıntılar olmadan sadece canlılık-ping yapalım.
Sağlık kontrollerinin günlükleri - DEBUG düzeyinde, kısma ile.

10) Gözlemlenebilirlik ve SLO

Dışa aktarma metrikleri: 'health _ readiness {status}', 'health _ liveness {status}', örnek işlem süresi.
Hazır bulunabilirlik SLO'ları ile birlikte Hazır Bulunuşluk bayraklarını ilişkilendirin (uç noktalardan düşülebilir - 5xx/bağlantı sıfırlama).

• "Sık sık canlılık> N/saat ile yeniden başlar" - deadlock/sızıntı belirtisi.
• "Flap Hazırlığı> X/15 dakika" - bağımlılık/ağ sorunlarının bir belirtisi.
• Deploy ('hizmeti ile korelasyon. versiyon ').

11) Test etme

Birim/Sözleşme: Her bağımlılık devre dışı bırakıldığında endpoints'/healthz/' iade doğru durumları.
Kaos: Veritabanı/önbellek/komisyoncu devre dışı bırakma: Hazırlık, modele göre kesinlikle follback'i düşürmeli veya etkinleştirmelidir. Canlılık - süreç "canlı'ise tetiklemez.
Load/Soak: Yük altında, sağlık uç noktaları hızlı kalmalıdır (içeriği zorlamayın).
Kanarya: Trafiği artırmadan önce Hazırlık durumunu kontrol edin.

12) Sık yapılan hatalar ve bunlardan nasıl kaçınılacağı

Liveness veritabanlarını/harici API'leri kontrol eder. Sonuç, olaylar için sonsuz yeniden başlatmadır. Çözüm: canlılığı "yaşamı işlemek'ile sınırlamak.
Örneklerde ağır kontroller. Yanlış başarısızlıklara yol açar. Çözüm: ışık kontrolleri + bireysel arka plan-sağlık monitörleri.
Başlangıç sondası yok. Yavaş başlangıçlar canlılık tarafından "öldürülür". Çözüm: geniş bir pencere ile başlangıç ekleyin.
Zarif kapatma yok. Deplasta nadir 5xx. Çözüm: preStop + dengesizlik.
Kanat çırpma fırtınaları. Çok agresif eşikler. Çözüm: 'failureThreshold' yükseltin, 'timeoutSeconds' artırın, geri dönüş ekleyin.
Her şey için aynı son noktalar. Semantiği karıştırıyorum. Çözüm: bireysel 'canlılık/hazırlık/başlangıç'.

13) Mini Uygulama Desenleri

python
@app. get("/healthz/liveness")
def liveness():
return 200

@app. get("/healthz/readiness")
def readiness():
ok_core = core_is_ready () # local pools/caches/initialization ok_db = db. ping (timeout = 50 _ ms) # only if the DB is critical return 200 if (ok_core and ok_db) else 503

@app. get("/healthz/startup")
def startup():
return 200 if INIT_DONE else 503

@app. post("/healthz/drain")
def drain():
set_readiness(False); return 200

go
// use google. golang. org/grpc/health/grpc_health_v1 healthServer. SetServingStatus("my. app. Service", SERVING) // or NOT_SERVING

yaml spec:
readinessGates:
- conditionType: "proxy. istio. io/ready"

14) Kontrol listeleri

Satmadan önce

• Canlılık/hazırlık/başlangıç uç noktaları ayrılır, anlambilimleri tanımlanır.
• Canlılık dış bağımlılıklara dokunmaz; Hazırlık sadece zaman aşımları ve follbeck ile kritik testler.
• Servis profili için 'initialDelay/period/timeout/failureThreshold' yapılandırıldı.
• zarif kapatma etkin: 'PreStop' + dengesizlik.
• Sağlık metrikleri/günlükleri bağlanır; yeniden başlatır/flap için uyarılar.
• Bağımlılık hatası ve yavaş başlangıç testleri geçti.

Operasyon

• Yeniden başlatmalar ve hazırlık bayrakları hakkında haftalık rapor.
• Olaylardan sonra eşiklerin ayarlanması; Bültenlerle bağlantı.
• Bağımlılıkları devre dışı bırakmanın düzenli kaos testleri.
• Bağımlılık kritikliği değiştiğinde semantiğin alaka düzeyi.

15) SSS

S: Her şeyi tek bir arıza ile kapatmak mümkün mü?
A: İstenmeyen. Ayrı 'başlangıç', 'hazırlık', 'canlılık' - bu yanlış pozitifleri azaltır ve RCA'yı hızlandırır.

S: Önbelleği hazır olarak kontrol ediyor muyum?
C: Önbellek olmadan doğru (daha yavaş olsa da) bir mod varsa, hazır olma durumunu düşürmeyin, sadece bozulmayı açın.

S: Canlılık için sık sık yeniden başlatmalarla ne yapmalı?
C: Önce bir dektor/sızıntı dışlayın; Ardından eşikleri gevşetin ve uygulamaya bir bekçi köpeği ekleyin.

S: Çoklu kiracılığı nasıl hesaba katıyoruz?
C: Hazırlık, herhangi bir kiralık trafiğe hizmet etme yeteneğini yansıtmalıdır. Belirli bir kiracının özel sorunları için - hazırlığı değiştirmeyin, ancak ayrı SLI/uyarılarla sinyal verin.

• "Gözlemlenebilirlik: günlükler, metrikler, izler"
• "Dağıtılmış İzler"
• "SLO/SLA ve Metrikler"
• "Webhook teslimat garantisi"
• "Transit Şifrelemede"
• "Gizli yönetim"