What I learned about Kubernetes - (Deployment)

                        ဒီ article ကတော့ kubernetes ရဲ့ deployment အကြောင်းပဲဖြစ်ပါတယ်။ အရင် article တွေမှာ ကျွန်တော်တို့ Pod, ReplicaSet တို့အကြောင်း ပြောခဲ့ပြီးပြီ အခု ဒီ Deployment ကတော့  Pod တည်ဆောက်ခြင်းရဲ့ နောက်ဆုံး  type တစ်ခု ပဲဖြစ်ပါတယ်။ သူ့မှာ ရှေ့က ပြောပြခဲ့ Standalone Pod create လုပ်တာတွေ နောက် ReplicaSet နဲ့ Pod ကို တွဲပြီး အသုံးပြုတာတွေ က နောက်ဆုံး ဒီ Deployment နဲ့ တွဲပြီး တစ်ခါထဲ တည်ဆောက်လို့ရပါတယ်။ Deployment ထဲ မှာ ReplicaSet ပါ ပါ၀င်ပြီးသားဖြစ်ပါတယ်။

So, What are the benefits of using Deployment Type?

                       Deployment type ကို အသုံးပြုခြင်းအားဖြင့် Pod တွေပေါ်မှာ Deployment provides လုပ်ပေးနိုင်တဲ့ features တွေက 

1. Rolling Updates

2. Undo Changes

3. Pause and Resume Changes

တွေပဲဖြစ်ပါတယ်။ သူက Pod တွေကို Update လုပ်ပေးနိုင်တယ် ဥပမာ nginx version 1.18 လက်ရှိသုံးနေတဲ့ Pod တွေကို nginx version 1.19 or something သူ update လုပ်ပေးနိုင်တယ်။ Update လုပ်နေစဥ် အချိန်မှာလဲ ဥပမာ Pod တွေ အကုန်လုံးကို တစ်ပြိုင်နက် update လုပ်မှာလား ဒါမဟုတ် တစ်ခုချင်းစီ service disruption မဖြစ်စေပဲ လုပ်စေချင်လား, Update လုပ်နေရင်းနဲ့ ပြန်ပြီး changes တွေကို Undo ပြန်လုပ်ချင်လား, လုပ်နေစဥ် process ကို pause ထားမလား resume ပြန်စ မလား စတဲ့ feature တွေ ကို Deployment type က provide လုပ်ပေးနိုင်ပါတယ်။

How to create Deployment Type?

                Deployment type ကို ဘယ်လို create လုပ်မလဲဆိုတော့ deployment သည်လဲပဲ replicaset creation လုပ်တဲ ့ ပုံစံနဲ့ အတူတူပဲဖြစ်ပါတယ်။ Deployment definition file ထဲမှာ ထုံးစံအတိုင်း 

1. apiVersion: apps/v1

2. kind:

3. metadata:

4. spec:

တို့ကတော့ အမြဲပါ၀င်ရမှာဖြစ်ပြီး ကွဲပြားသွားတာ တစ်ခုက kind: Deployment ဆိုပြီး သတ်မှတ်ရမှာဖြစ်ပါတယ်။ သူ့မှာ ကျန်တာတွေဖြစ်တဲ့ replicas: ပါမယ် နောက် selector: တွေ ပါ၀င်မှာဖြစ်ပါတယ်။ အောက်ပုံမှာ sample deployment definition file ကို ပြထားပါတယ်။

Sample Nginx Deployment Definition File

How to generate a deployment definition file (YAML)?

                ဒါ ကျွန်တော်တို့ deployment မှမဟုတ်ပါဘူး YAML file တစ်ခုကို ဘယ်လို generate လုပ်ပြီး အသုံးပြုလို့ရလဲ ဆိုတာလေး ပြောချင်လို့ဖြစ်ပါတယ်။ ဒီ YAML syntax တွေကို အခုလို generate လုပ်ရင်လုပ် မလုပ်ရင် kubernete documentation ကနေ reference ယူပြီး တည်ဆောက်ကြရမှာဖြစ်ပါတယ်။

Generating YAML file

                

                    Deployment definition file create လုပ်ပြီးရင် $kubectl create command ကိုအသုံးပြုပြီး တည်ဆောက်ပါမယ်။ တည်ဆောက်ပြီးသွားတဲ့အခါ replicaset  ပါ တစ်ခါထဲ တည်ဆောက်သွားတာကို $kubectl get all command ဖြင့်ကြည့်တဲ့အခါ တွေ့ရမှာဖြစ်ပါတယ်။

Creating Deployment

So now you know how to create the deployment then what's next......???

What are rollout and versioning in deployment?

                Deployment မှာ Rollout ဆိုတာက new deployment တစ်ခု create ပြုလုပ်ပြီးသွားတဲ့ အခါ new rollout တစ်ခု လို့ခေါ်ပြီးတော့ revision-1 ဆိုပြီး သတ်မှတ်ပါတယ်။ နောက်ထပ် deployment အသစ်တစ်ခု ထပ် create လုပ်လိုက်ရင် နောက်ထပ် rollout အသစ်, revision-2 ဆိုပြီး  ခေါ်ဆိုပါတယ်။ ဥပမာ ပထမဆုံး Deployment လုပ်လိုက်တဲ့ အခါ သုံးနေတဲ့ nginx version က 1.0 အဲ့ဒါကို revision-1 လို့ ခေါ်တယ် ထပ်ပြီး nginx version 2.0 ကို upgrade လုပ်လိုက်တဲ့ အခါမှာ လက်ရှိ existing Deployment က revison-1 ကနေ revison-2 ပြောင်းလဲသွားတာဖြစ်ပါတယ်။

How to check rollout history and status?

                ကိုယ် တည်ဆောက်လိုက်တဲ့ Deployment ရဲ့ rollout status and history ကို ကြည့်ချင်ရင် $kubectl rollout status ကိုသုံးပြီး history ကိုကြည့်ချင်ရင်တော့ $kubectl rollout history command ကို အသုံးပြုရပါတယ်။

So, How do we upgrade the Pod, and what is the Pod upgrade plan?

                Deployment type ကို အသုံးပြုထားတဲ့ Pod တွေကို upgrade လုပ်နိုင်တဲ့ နည်းလမ်း ၂ မျိုး ရှိပါတယ်။

1. Rolling Update (default)

2. Recreate

                    Rolling update ကိုသုံးပြီး Upgrade ပြုလုပ်မယ်ဆိုရင် existing pod တွေသည် one to one upgrade ပုံစံမျိုး သွားမည်ဖြစ်ပါတယ်။ ပြောချင်တာက  Upgrade စလုပ်ပြီ ဆိုရင် rolling update က new replicaset တစ်ခုကို အရင်ဆုံး create လုပ်တယ် create လုပ်ပြီးတဲ့အချိန်မှာ လက်ရှိ existing pods တွေကို control လုပ်နေတဲ့ လက်ရှိ replicaset ကနေ တစ်ကြိမ်မှာ Pod တစ်ခုချင်းစီ down ပြီး တစ်ချိန်ထဲမှာပဲ new pod တစ်ခုကို new replicaset ဆီမှာ up လုပ်ပေးပါတယ်။  Rolling Update က Deployment ရဲ့ default strategyType ဖြစ်ပြီး သက်သက် define လုပ်ပေးစရာ မလိုပါဘူး။

                         အောက်ပုံကို ကြည့်မယ်ဆိုရင် "nginx-dp.yaml" definition file ထဲမှာ လက်ရှိ nginx version က 1.18.0 ကနေ nginx:1.19 ကို editor (vim) နဲ့ ၀င်ပြီး ပြောင်းလိုက်ပါတယ်။ ပြီးတော့ $kubectl apply ကိုအသုံးပြုပြီး Upgrade လုပ်လိုက်တယ်။ Upgrade လုပ်ပြီးသွားတဲ့အချိန်မှာ $kubectl describe deployment nginx နဲ့ ခေါ်ကြည့်လိုက်ရင် လက်ရှိ image သည် nginx:1.19 ကိုပြောင်းသွားပြီ ဖြစ်ပြီး Events session မှာ ဘယ်လိုမျိုး Pod ကို upgrade လုပ်သွားလဲဆိုတာ တစ်ချက်ချင်းစီ ဖော်ပြထားတာ ကိုတွေ့ရမှာဖြစ်ပါတယ်။ StrategyType: Rolling Update ကို သုံးထားတဲ့အတွက် တစ်ကြိမ်မှာ Pod တစ်ခု စီ Up Down လုပ်သွားတာဖြစ်ပါတယ်။ 

                    

    

                      အောက်ပုံမှာ Rolling update တစ်ခု ပြီးသွားတဲ့ အခါ new deployment တစ်ခု တည်ဆောက်လိုက်တာဖြစ်တဲ့အတွက် $kubectl rollout history နဲ့ကြည့်လျှင် revsion-2 ဖြစ်သွားတာကိုတွေ့ရမှာပါ။            

    

                $kubectl get all နဲ့ကြည့်တဲ့အခါ လက်ရှိ deployment မှာ old replicaset နဲ့ new replicaset ဆိုပြီး နှစ်ခု ဖြစ်နေတာကို တွေ့မှာဖြစ်ပါတယ်။

                    $kubectl apply command ကို မသုံးပဲ တစ်ခြား command တစ်ခု ဖြစ်တဲ့ $kubectl set command ကို သုံးပြီးလဲ rolling out upgrade ကို ပြုလုပ်နိုင်ပါတယ်။

Using $kubectl set image command to upgrade

How to rollback (undo) to the previous version of Pod?

                    အိုကေ ကျွန်တော်တို့ Pod တွေကို Upgrade လုပ်ပြီးတဲ့ နောက် issue ရှိတယ်ဆိုပါစို့ အဲ့ဒါဆိုရင် အရင် nginx version ကို ပြန်သွားဖို့ လိုလာပြီ ဖြစ်ပါတယ်။ အဲ့အခါ Deployment definition file ထဲ က nginx image version ကို ဝင်ပြင်ပြီး $kubectl apply command ဖြင့် အသုံးပြုနိုင်သလို  $kubectl rollout undo ဆိုတဲ့ command ကို အသုံးပြုပြီး rollback ပြန်သွားလို့ရပါတယ်။ $kubectl rollout undo မှာ deployment name ဖြင့် rollback ပြန်လုပ်နိုင်သလို revision number ကို ရွေးချယ်ပြီးတော့လဲ rollback ပြန်လုပ်နိုင်ပါတယ်။

                    

                    အောက်ပုံတွေမှာ ကျွန်တော်တို့ $kubectl rollout undo command ကို အသုံးပြုပြီး roll back စလုပ်ပါပြီ။ rollback လုပ်တဲ့နေရာမှာ ကျွန်တော်က revision ကို အသုံးပြုပြီး roll back လုပ်သွားပါတယ်။ Roll back ပြီးတဲ့ အခါ nginx version သည် previous version 1.18.0 ကို ပြန်ရောက်နေပြီး previous replicaset က ပြနလည် ပြီးတော့ Pods တွေကို controll လုပ်နေတာကို တွေ့ရမှာဖြစ်ပါတယ်။ နောက် $kubectl rollout hisotry နဲ့ကြည့်ရင်လည်း Revision-3 ဆိုပြီး Update ဖြစ်နေတာကိုတွေ့မှာဖြစ်ပါတယ်။

Using $kubectl rollout undo command to roll back the Pod

Previous replicaset is now re-used for replication pod

Deployment history updated to revision-3

The last one, How do we upgrade by using the "Recreate" strategy?

                 Rolling out method နဲ့ Upgrade အပြီးမှာ နောက်ထပ် method တစ်ခုဖြစ်တဲ့ "recreate" နဲ့ ဘယ်လို Upgrade လုပ်ကြမလဲဆိုတာ ပြောပါမယ်။ Rolling out နဲ့ မတူညီတဲ့ အဓိက အချက် ကတော့ "Recreate" က Pod တွေကို upgrade လုပ်တဲ့နေရာမှာ တစ်ကြိမ် တစ်ခု စီ upgrade လုပ်တာမဟုတ်ပဲ running ဖြစ်နေတဲ့ Pods တွေကို တစ်ခါထဲ scale down လုပ်ပြီး နောက်ထပ် new replicaset မှာ တစ်ပြိုက်နက် scale up လုပ်တဲ့ method ဖြစ်ပါတယ်။ "Recreate" method ကို service disruption အဖြစ်မခံနိုင်တဲ့ enviornment တွေမှာဆိုရင် မသုံးသင့်ပါဘူး။

              "Recreate" က default roll out မဟုတ်တဲ့အတွက် သူ့ကိုအသုံးပြုမယ်ဆိုရင် Deployment definition file (YAML) Strategy type မှာ  type: Recreate ဆိုပြီး define လုပ်ပေးရပါမယ်။ အောက်ပုံမှာ ပြထားပါတယ်။

Define type: Recreate

 

                    အိုကေ အောက်မှာ ကျွန်တော်တို့ Deployment definition file ကို စပြီး $kubectl apply ဖြင့် create လုပ်ပါပြီ။ Redis version 5.0.9 ဖြင့် replicaset: 3 Pod ဖြင့် လက်ရှိ running ဖြစ်နေပါတယ်။

                 အောက်ပုံမှာ ကျွန်တော်တို့ redis version ကို မြှင့်ချင်တယ် အဲ့ဒီအတွက် $kubectl set image command ကို သုံးပြီး မြှင့်လိုက်တဲ့အခါ $kubectl describe deployment command ဖြင့် ကြည့်လိုက်လျှင် Event session မှာ Rolling out method တုန်းကလို တစ်ခုချင်းစီ Upgrade လုပ်သွားတာမဟုတ်ပဲ scaleup, scale down ကို new replicaset ပေါ်သို့ တစ်ခါထဲ လုပ်သွားတာကို တွေ့မှာဖြစ်ပါတယ်။      

                        

That's it 😊 

Pls Like and Subscribe Our Root Of Info FB Page and Youtube Channel

https://www.facebook.com/rootofinfo

https://www.youtube.com/channel/UCkOi7WxhUBKONv3uD0CvuWw?view_as=subscriber

Thank you!!!