လက်တွေ့ လေ့ကျင့်ခန်း အစုံ ၂

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

ဒီ round က round ၁ ထက် အဆင့်မြင့်ပါတယ် — skill တစ်ခုချင်းစီကို ခွဲစမ်းမယ့်အစား တစ်ခါတည်း ပေါင်းသုံးရမှာပါ။ ConfigMap/Secret ကို ဘယ်အချက်နဲ့ ခွဲသတ်မှတ်ရမလဲ ဆုံးဖြတ်ခြင်း, HPA ရဲ့ min/max/target ကို traffic pattern အလိုက် တွက်ချက်ခြင်း, production rollback plan ကို document အနေနဲ့ ရေးဆွဲခြင်း — ဒါတွေ ပါဝင်ပါတယ်။ Task တစ်ခုကို ၁၀ မိနစ်ခန့် ယူပါ.

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

Task 1: Config data ၅ ခု (API_URL, LOG_LEVEL, DB_PASSWORD, FEATURE_FLAG, JWT_SECRET) ကို ConfigMap/Secret ၂ ခုအဖြစ် ခွဲသတ်မှတ်ပြီး ဘာကြောင့်ဒီလို ခွဲလဲ ရှင်းပါ။ Task 2: Web app တစ်ခု average traffic 50 req/sec ရှိပြီး, peak time မှာ 500 req/sec အထိ တက်တတ်တယ်ဆိုရင် HPA ရဲ့ min/max replica ကို ခန့်မှန်းရေးပါ (pod တစ်ခုက ~50 req/sec ကိုင်နိုင်တယ်လို့ ယူဆပါ)။ Task 3: Production deployment v3 ကို rollout ပြီးနောက် error rate 20% အထိ တက်လာတယ်ဆိုရင် ဘယ် command အစီအစဉ်နဲ့ response လုပ်မလဲ ရေးပါ (rollback plan)။ Task 4: RBAC Role တစ်ခုကို 'CI/CD pipeline က Deployment update လုပ်ခွင့်ပဲ ရှိစေချင်တယ်, pod delete/Secret ကြည့်ခွင့် မပေးချင်ဘူး' ဆိုတဲ့ requirement အတွက် ရေးဆွဲပါ။

• ConfigMap/Secret ကို ခွဲသတ်မှတ်ရတဲ့ criteria ရေးထားပြီ
• HPA min/max ကို traffic data အခြေခံပြီး ခန့်မှန်းရေးထားပြီ
• Production rollback plan နှင့် scoped RBAC Role ရေးဆွဲထားပြီ

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

# Task 2 - HPA sizing
Average: 50 req/sec, 1 pod handles ~50 req/sec -> min replicas ~= 1-2
Peak: 500 req/sec / 50 req/sec per pod = 10 pods needed at peak
-> min: 2 (headroom for normal spikes + 1 for safety)
-> max: 10 (covers documented peak)

# Task 3 - rollback plan
1. kubectl rollout status deployment/web-deployment  (confirm stuck/bad)
2. kubectl rollout undo deployment/web-deployment    (revert to last good)
3. kubectl rollout status deployment/web-deployment  (confirm recovery)
4. Check error rate metric back to baseline
5. File incident notes: what broke in v3, before retrying

ConfigMap/Secret ခွဲခြားစံနှုန်း၊ HPA sizing ခန့်မှန်းချက်၊ rollback plan နှင့် scoped RBAC Role တစ်ခု ရရှိလာမည်။