StatefulSet — Kubernetes’da barqaror identity, tartibli lifecycle va persistent storage talab qiladigan podlar to‘plamini boshqaruvchi workload controller. Deployment’dagi podlar odatda o‘zaro almashtiriladigan bo‘lsa, StatefulSet podlari db-0, db-1 kabi doimiy ordinal nomga ega. U database, consensus a’zosi yoki shard identifikatoriga bog‘liq tizimlarda ishlatiladi.
Barqaror identity
StatefulSet nomi va ordinal podning network identity’sini belgilaydi. Headless Service orqali har pod db-0.service, db-1.service kabi alohida DNS nom olishi mumkin. Pod qayta yaratilsa yangi IP oladi, ammo logical nom saqlanadi.
Ordinal application konfiguratsiyasida node ID yoki shard roliga bog‘lanishi mumkin. Biroq faqat nom mavjudligi distributed database membership’ini to‘g‘ri qilmaydi; applicationning join, leave, quorum va data rebalance jarayoni baribir zarur.
Persistent volume
volumeClaimTemplates har replica uchun alohida PersistentVolumeClaim yaratadi. db-0 qayta yaratilganda o‘z claim’iga qayta ulanadi; db-1 bilan disk almashmaydi. StatefulSet o‘chirilganda volume odatda avtomatik yo‘q qilinmaydi, chunki data tasodifiy o‘chishdan himoyalanadi.
| Xususiyat | StatefulSet xatti-harakati |
|---|---|
| Pod nomi | Barqaror ordinal |
| Start tartibi | Default holatda 0 dan yuqoriga |
| Stop tartibi | Yuqori ordinaldan pastga |
| Storage | Har podga alohida claim |
| Network nomi | Headless Service bilan barqaror |
Volume availability zone’ga bog‘langan bo‘lsa pod faqat shu zone’dagi node’ga schedule qilinishi mumkin. Node failure’dan keyin attachment ajralishi va yangi node’ga ulanishi vaqt oladi.
Tartibli boshqaruv
Default OrderedReady siyosatida keyingi pod avvalgisi Ready bo‘lgach boshlanadi. Bu bootstrap tartibi talab qiladigan tizimga mos, ammo bitta pod tayyor bo‘lmasa rolloutni to‘xtatadi. Parallel podlarni bir vaqtda boshqaradi; application bunga tayyor bo‘lishi kerak.
Scale-down eng katta ordinaldan boshlanadi. Pod sonini kamaytirish database’dan a’zoni xavfsiz chiqarish, replica ko‘chirish yoki shardni bo‘shatishni avtomatik bajarmaydi. Operator yoki lifecycle automation bu biznesga xos amallarni bajaradi.
Rolling update
RollingUpdate odatda yuqori ordinaldan boshlab podlarni yangilaydi va har birining Ready bo‘lishini kutadi. Partition qiymati ma’lum ordinaldan past podlarni eski versionda qoldirib canary yoki bosqichli rollout qilishga imkon beradi.
Readiness faqat port ochilganini emas, node clusterga qo‘shilgan va so‘rovga tayyorligini bildirishi kerak. Shu bilan birga readiness barcha replica bilan to‘liq sinxron bo‘lishni kutsa bootstrap deadlock yuz berishi mumkin. Probe semantics application protokoliga mos yoziladi.
StatefulSet va database HA
Uch replica yaratish ma’lumot avtomatik ko‘payadi degani emas. Replication database engine yoki alohida operator tomonidan sozlanadi. StatefulSet faqat pod, identity va volume lifecycle’ini taqdim etadi. Backup, point-in-time recovery va consistency alohida boshqariladi.
Pod anti-affinity va topology spread replica’larni turli node yoki zonaga joylashtiradi. Quorum tizimida replica soni, failure domain va network latency birga rejalashtiriladi. Ikki zonaga teng tarqatish partition paytida qaysi tomon quorum olishini murakkablashtirishi mumkin.
Nosozlik va tiklash
Pod stuck terminating bo‘lsa uni majburan o‘chirishdan oldin eski instance haqiqatan ishlamayotgani tekshiriladi. Aks holda bir xil identity bilan ikki node storage yoki clusterga kirib split-brain yaratishi mumkin. Volume detach, fencing va application lease muhim.
Disaster recovery’da faqat YAML manifest yetarli emas. Persistent data backupi, encryption key, storage class va external DNS/secret qayta tiklanadi. Restore yangi StatefulSet identity’lari va database membership’i bilan muvofiqlashtiriladi.
Bog‘liq tushunchalar
Kubernetes, Pod, PersistentVolumeClaim, Headless Service, Replication, Quorum, Operator pattern