Rolling deployment — xizmat instancelarini eski versiyadan yangisiga kichik guruhlar bilan ketma-ket almashtirish strategiyasidir. Bir qism yangilanayotganda qolganlari trafikni qabul qiladi, shu sabab to‘liq rejalashtirilgan downtime talab qilinmasligi mumkin. Jarayon availability va mixed-version moslikka tayanadi.
Replacement parametrlari
Max unavailable bir vaqtda nechta kerakli replica ishlamasligini, max surge esa desired countdan ortiq nechta yangi replica yaratilishini belgilaydi. Masalan, surge 1 bo‘lsa avval bitta yangi instance yaratiladi, sog‘lom bo‘lgach bitta eski instance to‘xtatiladi.
Capacity surge uchun yetarli bo‘lmasa yangi instance pending qoladi. Unavailable katta bo‘lsa rollout tez, ammo xizmat sig‘imi kamayadi. Parametrlar replica soni, request yuklamasi va failure tolerancega mos tanlanadi.
Health va progress
Yangi instance startup, readiness va minimal healthy time shartlarini bajaradi. Readiness fail bo‘lsa trafik olmaydi va keyingi guruh yangilanmaydi. Progress deadline jarayon cheksiz kutib qolishini to‘xtatadi.
Health endpoint dependencyga ortiqcha sezgir bo‘lsa kichik tashqi uzilish barcha yangi podni rad etadi. Juda yuzaki bo‘lsa xato application trafik oladi. Synthetic business check va metric analysis qo‘shimcha signal beradi.
Ikki versiya parallel holati
Rollout davomida eski va yangi instance bir xil request, database, cache va queue bilan ishlaydi. API va message contract backward-compatible bo‘ladi. Yangi cache serializationini eski code o‘qiy olmasa request qaysi instancega tushishiga qarab xato paydo bo‘ladi.
Database expand–contract migration bilan yangilanadi. Destructive schema o‘zgarishi barcha eski instance tugamaguncha bajarilmaydi. Background job versiyasi ham hisobga olinadi; faqat web podlarni ko‘rish yetarli emas.
Trafikni tugatish
Eski instance load balancerdan chiqarilgach yangi request olmaydi, lekin faol requestlarni grace periodda yakunlaydi. PreStop va signal handling cleanupni bajaradi. Queue worker yangi task olishni to‘xtatib, joriy taskni checkpoint yoki tugatish orqali topshiradi.
Long-lived connectionlar deploymentni cho‘zadi. Client reconnect va retryga tayyor bo‘ladi. Termination timeout tugagach majburiy kill bo‘lsa yarim side effectni idempotency yoki transaction himoya qiladi.
Failure va rollback
Yangi guruh metriclari buzilsa rollout pause qilinadi. Automatic rollback oldingi specificationni tiklaydi, ammo yangi instance yozgan data va migrationni bekor qilmaydi. Root cause aniqlanmaguncha retry loop yangi podlarni qayta-qayta yaratmasligi kerak.
Rolling deployment kam qo‘shimcha muhit talab qiladi, lekin blue-green kabi bir zumda to‘liq switch va rollback bermaydi. Yuqori riskda canary avval kichik cohortda, keyin rolling replacement sifatida qo‘llanishi mumkin.
Capacity hisobi
Rolling deployment paytida eski va yangi replica soni vaqtincha desired qiymatdan farq qiladi. maxSurge qo‘shimcha instance uchun compute, IP, volume attachment va quota borligini talab qiladi. maxUnavailable juda katta bo‘lsa trafik qolgan podlarni to‘ydiradi; nol bo‘lsa qo‘shimcha capacitysiz jarayon boshlanmasligi mumkin. PodDisruptionBudget voluntary disruptionni cheklaydi, lekin deployment strategiyasining o‘rnini bosmaydi. Scheduler pending pod sababini, autoscalerning kechikishini va zone bo‘yicha taqsimotni rolloutdan oldin hisobga olish kerak.
Stateful workload uchun identity va volume biriktirish tartibi ham strategiyaga kiritiladi. Replica birma-bir yangilanganda leader yoki quorum saqlanmasligi mumkin; controllerning oddiy availability hisobi application consensus talabini bilmaydi.
Bog‘liq tushunchalar
Rolling update, Deployment strategy, Availability, Readiness check, Connection draining, Canary deployment, Rollback