Rolling Updates & Rollbacks

စိတ်လျှော့ပါ။ ဒီခန်းကို စာအုပ်လိုမဟုတ်ဘဲ စကားပြောသလိုပဲ၊ နားလည်လွယ်အောင် ရှင်းပါမယ်။

ခဏလေး ဒီလိုပဲ စဉ်းစားကြည့်

Pod အားလုံးကို တစ်ပြိုင်နက် version အသစ်ပြောင်းရင် (recreate strategy) traffic ကို ခဏတာ ကိုင်မထားနိုင်တဲ့ gap ဖြစ်နိုင်ပါတယ် — Deployment ရဲ့ default strategy ကတော့ 'RollingUpdate' ပါ — pod အသစ်တစ်ခု create ပြီး Ready ဖြစ်မှ pod အဟောင်းတစ်ခု ဖျက်ပါတယ်, အဲလိုနဲ့ တဖြည်းဖြည်း အားလုံးကို အသစ်ပြောင်းသွားပါတယ် — user တွေအနေနဲ့ downtime တစ်ချက်မှ မခံစားရပါဘူး။ Version အသစ်မှာ bug ပါလာရင် `kubectl rollout undo` နဲ့ version အဟောင်းကို ချက်ချင်း ပြန်ပြောင်းနိုင်ပါတယ် (Kubernetes က deployment history ကို default 10 revision မှတ်ထားပါတယ်).

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

`kubectl set image deployment/web-deployment web=my-app:v2` ဆိုတာမျိုးနဲ့ image version ပြောင်းလိုက်ရင် rolling update ချက်ချင်း စတင်ပါတယ် — `kubectl rollout status` နဲ့ progress ကို track လုပ်နိုင်ပါတယ်။ v2 မှာ bug ရှိတယ်ဆိုရင် `kubectl rollout undo deployment/web-deployment` နဲ့ v1 ကို instant ပြန်ရောက်နိုင်ပါတယ် — production incident မှာ 'ပထမဆုံးလုပ်စရာ' command တစ်ခုပါ။

RollingUpdate = pod တခြားတစ်ခုစီ တဖြည်းဖြည်း update, zero downtime
kubectl rollout status = update progress ကြည့်ခြင်း
kubectl rollout undo = version အဟောင်းကို instant ပြန်ပြောင်းခြင်း

အတူတူ ကြည့်မယ်

bash

# Update to a new image version (triggers rolling update)
kubectl set image deployment/web-deployment web=my-app:v2

# Watch the rollout happen
kubectl rollout status deployment/web-deployment

# See rollout history
kubectl rollout history deployment/web-deployment

# Something went wrong? Roll back instantly
kubectl rollout undo deployment/web-deployment

You should see

Waiting for deployment "web-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
deployment "web-deployment" successfully rolled out

၅ မိနစ် စမ်းကြည့်

web-deployment ရဲ့ image ကို version အသစ်တစ်ခု (ဥပမာ `nginx:alpine` ကနေ `nginx:latest`) ပြောင်းကြည့်ပြီး rollout status ကို watch လုပ်ကြည့်ပါ — ပြီးရင် `rollout undo` နဲ့ ပြန်ပြောင်းကြည့်ပါ။

သတိလေးတစ်ချက်

Rolling update ကို database schema breaking change နဲ့ တွဲလုပ်တဲ့အခါ အထူးသတိထားပါ — pod အဟောင်း/အသစ် ရောနေတဲ့ ကြားကာလမှာ schema နှစ်မျိုးလုံးကို support ဖြစ်အောင် ရေးထားရပါမယ်။