Kubernetes’da liveness, readiness va startup proba: sozlash

Qisqa javob

Kubernetes’da uchta proba bor va har biri o‘z harakatini boshqaradi:

Probalarsiz Kubernetes faqat jarayon ishlayotganini biladi. Deadlock’dagi server yoki keshini hali qizdirayotgan ilova trafik olishda davom etadi.

Tekshirishning uch usuli

HTTP — veb-servislar uchun eng ko‘p ishlatiladigan variant. 200 dan 399 gacha bo‘lgan har qanday status muvaffaqiyat hisoblanadi.

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5
  failureThreshold: 3

TCP — faqat port ulanishlarni qabul qilishini tekshiradi. Ma’lumotlar bazalari, brokerlar va HTTP bo‘lmagan servislar uchun mos.

livenessProbe:
  tcpSocket:
    port: 5432
  periodSeconds: 10

Exec — konteyner ichida buyruq bajaradi; 0 chiqish kodi «sog‘lom» degani.

livenessProbe:
  exec:
    command: ["sh", "-c", "test -f /tmp/healthy"]
  periodSeconds: 10

Standart gRPC health protokolini qo‘llaydigan servislar uchun gRPC probalari ham bor. Exec proba har tekshiruvda jarayon ishga tushiradi, shuning uchun buyruq yengil bo‘lishi kerak.

To‘liq va oqilona sozlama

containers:
  - name: api
    image: registry.example.com/api:2.1.0
    ports:
      - containerPort: 8080
    startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      periodSeconds: 5
      failureThreshold: 30
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      periodSeconds: 10
      timeoutSeconds: 2
      failureThreshold: 3
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      periodSeconds: 5
      timeoutSeconds: 2
      failureThreshold: 2

Bu yerda startup proba ishga tushish uchun 30 × 5 = 150 soniyagacha vaqt beradi. U muvaffaqiyatli o‘tgach, ishni liveness va readiness davom ettiradi.

Har bir endpoint nimani tekshirishi kerak

• /healthz (liveness): faqat jarayonning o‘zini. U umuman javob beryaptimi, asosiy sikl tirikmi. Hech qanday tashqi chaqiruvlar yo‘q.
• /ready (readiness): bu nusxa foydali ish qila oladimi: qizdirilgan, to‘xtatilish jarayonida emas, muhim lokal resurslar mavjud. Agar pod bog‘liqliksiz haqiqatan foydasiz bo‘lsa, uni shu yerda tekshirish mumkin, ammo barcha podlar birdaniga o‘tmay qolsa nima bo‘lishini o‘ylab ko‘ring.
• Startup: ko‘pincha liveness bilan bir xil endpoint, faqat urinishlar zaxirasi kattaroq.

Kechikish va chegaralarni sozlash

Asosiy maydonlar:

• periodSeconds — qanchalik tez-tez tekshirish.
• timeoutSeconds — javobni qancha kutish. Standart qiymat kichik, sekin endpoint yuklama ostida o‘tmay qola boshlaydi.
• failureThreshold — harakatdan oldin ketma-ket nechta muvaffaqiyatsizlik.
• successThreshold — tiklanish uchun ketma-ket nechta muvaffaqiyat (liveness va startup uchun faqat 1).
• initialDelaySeconds — birinchi tekshiruvdan oldingi pauza. Startup proba bo‘lsa, odatda kerak emas.

Taxminiy reaksiya vaqti — periodSeconds × failureThreshold. Liveness’ni sabrli qiling (qayta ishga tushirish qimmat), readiness’ni esa tezkor (trafikni olib tashlash arzon va qaytariladigan).

Ko‘p uchraydigan xatolar

• Liveness’da ma’lumotlar bazasini tekshirish. Baza qisqa uzilganda barcha podlar probadan o‘tmaydi va bir vaqtda qayta ishga tushadi. Bu bazani tuzatmaydi, u tiklanganda esa yuklamani oshiradi.
• Liveness va readiness uchun bitta endpoint va bir xil chegaralar. «Trafik yuborma» va «meni qayta ishga tushir» o‘rtasidagi farq yo‘qoladi.
• Startup proba o‘rniga juda katta initialDelaySeconds. U faqat birinchi startni emas, har bir qayta ishga tushishni sekinlashtiradi.
• Juda qattiq timeout’lar: band, lekin sog‘lom pod eng yuqori yuklamada o‘ldiriladi va qolganlarga yuklama ortadi.
• Og‘ir health-handler’lar, ular ko‘p servislarni so‘raydi yoki ko‘p xotira ajratadi.
• Readiness umuman yo‘q: rolling update paytida yangi podlar tayyor bo‘lmasdan trafik oladi.