Liveness/Readiness namunalari

2) Dizayn prinsiplari

1. Semantikalarni ajrating.

Readiness: so’rovlarga tashqi xizmat ko’rsatish qobiliyati (tanqidiy bog’liqliklarni hisobga oladi).
Liveness: jarayonning «davolab bo’lmaydigan» holati detekti.
2. Fail-fast, lekin «false-fast» emas. Vaqtni/chegarani’failureThreshold’deb oʻzgartiring, shunda qisqa portlashlar ortiqcha restartlarga olib kelmaydi.
3. Namunalarda og’ir operatsiyalar bo’lmaydi. Tekshirish tez (100-200 ms ≤) va nojo’ya ta’sirlarsiz bo’lishi kerak.
4. Nafis degradatsiya. Bog’liqlik qisman mavjud bo’lmaganda - xavfsiz follbek (kesh/kesh) mavjud bo’lsa, Readiness = OK.
5. Deterministic I/O. Statuslar «tasodifiy» tashqi testlarga emas, balki faqat joriy holatga bogʻliq.

3) HEALTH-endpointlar semantikasi

3. 1 HTTP yondashuvi (tavsiya etiladi)

’GET/healthz/liveness’ → 200 agar jarayon «tirik» bo’lsa (event-loop aylanadi, GC tiqilib qolmaydi, watchdog «yurak» uradi).
’GET/healthz/readiness’ → 200 agar nusxa kritik sinf trafigiga tayyor bo’lsa. Tekshirish: ulanish puli, mahalliy keshlar, biznes-mantiq yadrosining mavjudligi.
’GET/healthz/startup’ → 200 ishga tushirilgandan keyin (migratsiya/keshni isitish/modellarni yuklash).

• Liveness tashqi DB/APIga borish mumkin emas - bu giyohvandlik hodisalari paytida «o’z joniga qasd qilish» ga olib keladi.
• Readiness-da siz tanqidiy qaramlikni tekshirishingiz mumkin, ammo taymaut va degradatsiya bilan: agar valid follbek bo’lsa, uni yo’q qiling.

3. 2 gRPC Health Checking

’grpc’ standartidan foydalaning. health. v1. Health/Check’s service-scoped holatlari (’SERVING’,’NOT _ SERVING’). Kubernetes uchun - grpc-namunalar (yoki http-proksi).

3. 3 Ichki triggerlar

SIGTERMda Readiness = FAIL → kutib turish’terminationGracePeriodSeconds’→ navbatlarni ishlab chiqish bilan tugash.

4) Tayminglar va ostonalar (tuning)

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

• readiness: `period=5s, timeout=0. 2–0. 5s, failure=2`
• liveness: `period=10s, timeout=0. 2–0. 5s, failure=3`

• startup:’period = 5s, failure = 60’(~ 5 daqiqagacha)
• readiness/liveness startup muvaffaqiyatidan keyin faollashadi

• readiness qayta ishlashga tayyorligini aks ettiradi (brokerga ulanish, DLQ degradatsiyasi bor-yo’qligini),
• liveness - ichki heartbeat loop.

Backoff muvaffaqiyatsiz tugadi: ilovada eksponensial backoffdan foydalaning, aks holda readiness «teshadi».

5) Konfiguratsiyalar (parchalar)

5. 1 Kubernetes, HTTP namunalari

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-sinov

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

5. 3 Graceful shutdown

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

’/healthz/drain’servisi ichida Readiness = FAIL (stop-accepting) tarjima qiladi, faol soʻrovlarni yakunlash uchun vaqt beradi.

6) Qaramlik va degradatsiya

Tanqidiy (ularsiz xizmat ko’rsatish mumkin emas): ’/login’uchun avtorizatsiya ma’lumotlari, ’/pay’uchun to’lov shlyuzi. Readiness’da’timeoutSeconds’namunasining 80% ≤ vaqtni tekshirish mumkin.
Tanqidiy bo’lmagan: analitika, email, yuk ortilgan taqdirda kesh qatlami. Ularni readiness tizimiga kiritmang; follbekdan foydalaning.
Feature-flags: Qisman tanazzulga uchraganda, Readiness = OK ni saqlab qolish orqali bogʻliqlikni oʻchiring.

7) Navbatlar va fon ishlovchilari

• Readiness = OK, agar brokerga obuna/konnekt oʻrnatilgan boʻlsa va uni qayta ishlash uchun resurs mavjud boʻlsa.
• DLQ/lag → Readiness to’lib ketganda OK qolishi mumkin (agar qabul qilsak va qo’ysak), lekin SLI «yangilik/lag» yonadi - ma’lumotlarga ko’ra alert.
• Liveness: poll-sikl/heartbeat, dedlok detektorini boshqaring.

Idempotentlik: liveness restartlaridan keyin tiklanishni tezlashtiradi.

8) Sidecar/mesh/ingress

• ’readinessGate’ (K8s) ni sidecar maqomini hisobga olish uchun kiriting,
• Namunalar mTLS toʻsiqlariga tushmasligiga ishonch hosil qiling (yoki istisnolar qoʻshing).
• Ingress/Envoy/Nginx: ’/healthz/’ ni lokal ravishda proksatsiya qiling, ichki qismlarni «tashqariga chiqarmang».

9) Xavfsizlik va maxfiylik

Health-endpointlar konfiguralar, kutubxona versiyalari, xato satrlarini ochib bermasligi kerak - faqat «OK/FAIL» + sababning minimal kodi.
Tashqaridan kirish imkoniyatini cheklang (NetworkPolicy/ACL). Jamoatchilik uchun faqat tafsilotlarsiz liveness-ping bering.
Health-tekshirish daftarlari - DEBUG darajasida, trottling bilan.

10) Kuzatuv va SLO

’health _ readiness {status}’,’health _ liveness {status}’metrlarini eksport qiling.
Readiness-flaplarni SLO bilan bogʻlang (endpointlardan yoʻqolish → 5xx/connection reset).

• «Tez-tez restartlar bo’yicha liveness> N/soat» - dedloklar/oqishlar alomati.
• «Flap Readiness> X/15 min» - bog’liqlik/tarmoq muammolari alomati.
• Deployga bogʻlanish (’service. version`).

11) Test sinovlari

Unit/Contract: endpointlar ’/healthz/’ har bir bogʻlanish oʻchirilganda toʻgʻri holatlarni qaytaradi.
Chaos: DB/kesh/brokerni o’chirib qo’yish: Readiness to’g’ridan-to’g’ri modelga muvofiq tushishi yoki follbekni yoqishi kerak. Liveness - agar jarayon «tirik» bo’lsa, tetiklanmaydi.
Load/Soak: og’irlik ostida health-endpointlar tez qolishi kerak (kontenshn tashlamang).
Canary: trafikni oshirishdan oldin Readiness barqarorligini tekshiring.

12) Tez-tez xatolar va ulardan qanday qochish mumkin

Liveness/tashqi APIlarni tekshiradi. Natija - hodisalarda cheksiz restartlar. Yechim: hayotni «jarayon hayoti» bilan cheklash.
Og’ir sinovlar. Noto’g "ri rad etishga olib keladi. Yechim: oson tekshirish + alohida background-health monitorlari.
Startup Probe yoʻq. Sekin startlar hayotni «o’ldiradi». Yechim: keng oynali startup qoʻshish.
graceful shutdown mavjud emas. Kamyob 5xx deployda Yechim: preStop + balansdan chiqarish.
Flap bo’ronlari. Juda tajovuzkor chegaralar. Yechim:’failureThreshold’ni ko’tarish,’timeoutSeconds’ni ko’paytirish, backoff qo’shish.
Hamma narsa uchun bir xil endpointlar. Semantiklarni aralashtirish. Yechim: alohida’liveness/readiness/startup’.

13) Realizatsiya qilishning mini-patternlari

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) Chek-varaqlar

Sotishdan oldin

• Endpointlar liveness/readiness/startup bo’lingan, ularning semantikasi tasvirlangan.
• Liveness tashqi qaramliklarga ta’sir qilmaydi; Readiness faqat tanqidiy taymaut va follbek bilan tekshiradi.
• ’initialDelay/period/timeout/failureThreshold’xizmat profiliga moslangan.
• graceful shutdown yoqilgan:’preStop’+ balansdan chiqarish.
• Sog’liq metrikasi/loglari ulangan; qayta tiklash/flap uchun alertlar.
• Giyohvandlikni rad etish va sekin boshlash testlari o’tkazildi.

Foydalanish

• Readiness restartlari va flaplari bo’yicha haftalik hisobot.
• Hodisalardan keyin ostonalarni tyuning; relizlar bilan aloqa.
• Doimiy bogʻliqlik oʻchirish testlari.
• Bog’liqlikning tanqidiyligini o’zgartirishda semantiklarning dolzarbligi.

15) FAQ

V: Hamma narsani bitta sinov bilan yopish mumkinmi?
O: Nomaqbul. ’Startup’,’readiness’,’liveness’bo’ling - bu noto’g’ri ishlashni kamaytiradi va RCAni tezlashtiradi.

S: Keshni readiness’da tekshirish kerakmi?
O: Agar keshsiz to’g’ri (sekin bo’lsa ham) rejim mavjud bo’lsa, readiness’dan voz kechmang, shunchaki degradatsiyani yoqing.

S: Liveness bo’yicha tez-tez restartlarda nima qilish kerak?
O: Avvaliga dedlok/oqishni chiqarib tashlang; keyin ostonalarni yumshating va dasturga watchdog qo’shing.

V: Ko’p ijarani qanday hisobga olish mumkin?
O: Readiness har qanday ijara-trafikka xizmat ko’rsatish qobiliyatini aks ettirishi kerak. Ma’lum bir ijarachining shaxsiy muammolari uchun - readiness’ni o’zgartirmang, balki alohida SLI/alertlar bilan signal bering.

• «Kuzatilganlik: loglar, metriklar, trastirovkalar»
• «Taqsimlangan trassalar»
• «SLO/SLA va metrika»
• «Vebxuklarni yetkazib berish kafolatlari»
• «In Transit shifrlash»
• «Sirlar menejmenti»