Rolling update — xizmatning eski instancelarini yangi versiya bilan bosqichma-bosqich almashtiradigan deployment usulidir. Barcha instance bir vaqtda to‘xtatilmagani uchun xizmat mavjudligi saqlanishi mumkin. Jarayon parallel yangilanadigan birliklar soni, health mezoni va xato holatidagi siyosat bilan boshqariladi.
Yangilanish ketma-ketligi
Orchestrator eski instance yoki allocationlarning bir qismini tanlaydi, yangi versiyani ishga tushiradi va readiness checkdan o‘tkazadi. Yangi instance minimal sog‘lom vaqt davomida barqaror bo‘lsa, keyingi guruh yangilanadi. Eski va yangi versiya rollout davomida bir vaqtda trafik qabul qilishi mumkin.
Max unavailable xizmatning nechta instance vaqtincha ishlamasligini, max surge esa replikalar ustidan nechta qo‘shimcha instance yaratilishini cheklaydi. Resource capacity surge uchun yetarli bo‘lmasa yangi pod pending qolishi mumkin. In-place replacementda esa mavjudlik budjeti ehtiyotkor tanlanadi.
Health tekshiruvlari
Liveness processni qayta boshlash zarurligini, readiness esa trafik qabul qilishga tayyorligini bildiradi. Startup check sekin yuklanadigan applicationni muddatidan oldin nosog‘lom deb belgilashdan saqlaydi. Faqat TCP port ochilganini tekshirish database migration yoki cache warm-up tugaganini ko‘rsatmasligi mumkin.
Min healthy time yangi instance qisqa muddat yaxshi ko‘rinib, keyin yiqilishini aniqlash uchun kutadi. Healthy deadline ichida mezon bajarilmasa deployment failed bo‘ladi. Metric-based analysis error rate va latencyni eski versiya bilan solishtirishi mumkin.
Moslik talablari
Ikki versiya parallel ishlagani API va database backward compatibilityni talab qiladi. Yangi kod schema ustunini qo‘shib ishlatishi, eski kod esa hali mavjud bo‘lishi mumkin. Expand–contract migration avval mos qo‘shimcha kiritadi, kodlar yangilangach eski tuzilmani keyingi release da olib tashlaydi.
Message format va cache key ham mixed-version davrida mos bo‘lishi kerak. Yangi producer eski consumer o‘qiy olmaydigan majburiy field yuborsa rolloutning yarmi ishlamaydi. Contract test bu o‘tish holatini tekshiradi.
Session va ulanishlar
Instance to‘xtatilishidan oldin load balancer undan yangi trafikni olib tashlaydi, process esa mavjud connectionlarni grace period ichida yakunlaydi. PreStop hook yoki drain endpoint yordam beradi. Juda qisqa termination timeout faol requestni uzadi, juda uzun vaqt rolloutni sekinlashtiradi.
In-memory session eski instance bilan yo‘qolishi mumkin. Shared session store yoki stateless token uzluksizlikni ta’minlaydi. Sticky session rollout paytida foydalanuvchini eski versiyada ushlab qolishi va yangilanishni baholashni qiyinlashtirishi mumkin.
Xato va qaytarish
Rollout progress qilmasa pause qilinadi. Auto-rollback eski specificationga qaytishi mumkin, ammo database yoki tashqi side effectni avtomatik bekor qilmaydi. Rollback artifacti, konfiguratsiyasi va migration mosligi oldindan sinovdan o‘tadi.
Rolling update kichik blast radius beradi, lekin canary kabi aniq trafik kohorti va chuqur tahlilni har doim bermaydi. Yuqori riskli release uchun avval canary, keyin rolling replacement birga ishlatilishi mumkin.
Capacity va disruption budget
Rolling jarayon replikalar, node maintenance va autoscaler bilan bir vaqtda ishlashi mumkin. Pod disruption budget rejalashtirilgan uzilishda minimal mavjud instance sonini saqlaydi, lekin nosoz instance ni sog‘lom qilmaydi. Clusterda surge uchun bo‘sh capacity bo‘lmasa update deadlockka yaqin holatga kelishi mumkin.
Stateful workload
Stateful instance tartibli identity va volumega ega bo‘lsa, parallel update cheklangan bo‘ladi. Replica leader avval yoki keyin yangilanishi consensus protokoliga bog‘liq. Data format yangi versiyada bir tomonlama o‘zgarsa eski binary rollback qila olmaydi. Snapshot va compatibility sinovi talab qilinadi.
Kuzatuv
Deployment controller statusi bilan birga real request metric va version distribution ko‘riladi. Desired replica yangilangani barcha connection yangi versiyaga o‘tdi degani emas. Uzoq yashovchi worker va queue consumer eski buildda qolmaganini inventar tasdiqlaydi.
Bog‘liq tushunchalar
Deployment, Rollout, Readiness check, Canary deployment, Rollback, Availability, Expand–contract migration