استقرار نسخهٔ جدید نباید به معنای قطعی سرویس برای کاربران باشد. Kubernetes ابزارهای لازم برای استقرار بیوقفه را در اختیار میگذارد، اما تنها وقتی درست پیکربندی شوند کار میکنند. هدف این است که در طول بهروزرسانی، همیشه تعداد کافی نمونهٔ سالم برای پاسخ به ترافیک در دسترس باشد.
استراتژی پیشفرض، Rolling Update است؛ پادهای قدیمی بهتدریج با نسخهٔ جدید جایگزین میشوند. پارامترهای maxSurge و maxUnavailable کنترل میکنند که در هر لحظه چند پاد اضافه ساخته و چند پاد قدیمی حذف شود. تنظیم درست این دو تضمین میکند ظرفیت پاسخگویی هیچگاه زیر حد لازم نیفتد.
نکتهٔ حیاتی، پروبهای سلامت است. readinessProbe به Kubernetes میگوید یک پاد واقعاً آمادهٔ دریافت ترافیک است یا هنوز در حال راهاندازی. بدون این پروب، ترافیک به پادی میرسد که هنوز اتصال پایگاه دادهاش برقرار نشده و کاربر خطا میبیند. livenessProbe هم پادهای هنگکرده را تشخیص و ریاستارت میکند.
برای تغییرات پرریسک، استقرار Blue-Green امنتر است؛ نسخهٔ جدید کنار نسخهٔ فعلی بهطور کامل بالا میآید و پس از تأیید، ترافیک یکباره به آن سوئیچ میشود. اگر مشکلی بروز کند، بازگشت فوری است چون نسخهٔ قدیمی هنوز سرپاست. این روش منابع بیشتری مصرف میکند اما ریسک استقرارهای بزرگ را به کمینه میرساند.