Monday, September 13, 2021

Tuning Profiles for System Optimization

                     ဒီ article မှာတော့ linux system တစ်ခုရဲ့ performance ကို ဘယ်လိုမျိုး optimize လုပ်လို့ရမလဲ ဘယ် tool ကို အသုံးပြုပြီး optimize လုပ်မလဲဆိုတာ ပြောပြသွားမှာဖြစ်ပါတယ်။ 


Why do we need performance tuning?

                    System တစ်ခုကို performance optimize ဘာလို့ လုပ်ဖို့လိုတာလဲ ဆိုတော့ နားလည်သလို ပြောရရင် system တစ်ခု running ဖြစ်နေဖို့အတွက် components တွေကတော့ သူ့အပိုင်းနဲ့ သူ လိုအပ်ကြပါတယ်။ အဲ့ထဲမှာမှ ဒီ system ကိုအသုံးပြုရခြင်းရဲ့ အဓိက ရည်ရွယ်ချက်ကို aware ဖြစ်ဖို့ လိုအပ်ပါတယ်။ ဥပမာ ဒီ system သည် application purpose အတွက်လား ဒါမဟုတ် database purpose အနေနဲ့ အသုံးပြုဖို့လား ဒါမဟုတ် network services (dns,dhcp,ftp,nfs,etc..) တွေ သုံးဖို့လား စသည်ဖြင့် ရည်ရွယ်ချက်ကို သိထားဖို့ လိုအပ်ပါတယ်။ ဒီ purpose ကို သိပြီဆိုရင် အကယ်၍များ ကိုယ်အသုံးပြုလိုတဲ့ services တွေက system မှာ performance ကောင်းကောင်း မလုပ်နိုင်ဘူး performance ကျနေတယ်ဆိုရင် ကျွန်တော်တို့ system ကို optimize လုပ်ပေးဖို့ လိုအပ်တယ်လို့ ယူဆ နိုင်ပါတယ်။


What is tuned?

                ဆိုတော့ ဒီ system တစ်ခုကို performance optimization ကို ပြုလုပ်ဖို့အတွက် tuned service ကို အသုံးပြုနိုင်ပါတယ်။ ဒီ tuned service မှာ pre-defined လုပ်ထားတဲ့ default profile တွေလဲ ပါ၀င်ပါတယ်။ Tuned ရဲ့  profiles တွေကို ကိုယ့် system နဲ့ သက်ဆိုင်တဲ့ performance optimization အတွက် အသုံးပြုရမှာဖြစ်ပါတယ်။

                RHEL မှာတော့ performance tuning အတွက် သီးသန့်  specialist exam တစ်ခုရှိပြီး အခု ဒီ tuned အသုံးပြုပုံထက် ပိုပြီး advance topic တွေပါ၀င်တယ်။ အခု tuned article ကတော့ RHCSA8 ရဲ့ exam objective တစ်ခု အနေနဲ့ ပါ၀င်လာတာဖြစ်ပါတယ်။ 

Types of Tuned

            Tuned service မှာ static and dynamic tuning type နှစ်မျိုး ရှိပါတယ်။ Static ဆိုတာကတော့ ဒီ profile တစ်ခု ကို အသုံးပြုထားရင် ဒီ profile မှာ သတ်မှတ်ထားတဲ့ optimization တွေကိုပဲ system အပေါ်မှာ သက်ရောက်နေမှာဖြစ်ပြီး dynamic tuning ကကျတော့ system တစ်ခုလုံးရဲ့ အခြေအနေကို monitor လုပ်ပြီး အလိုက်သင့် performance optimization လုပ်ပေးနေမှာဖြစ်ပါတယ်။  Default အားဖြင့် dynamic tuning က disable ဖြစ်နေပြီး /etc/tuned/main.conf file မှာ 'dynamic_tuning' value ကို '1' ပြင်လိုက်ရင် enable ဖြစ်ပါတယ်။ 


Let's get started!!!


1. Install tuned Package and start the tuned service

              အရင်ဆုံး tuned package ကို install လုပ်မယ် service start and enable လုပ်ထားမယ်။



2. Using tuned-adm command

                tuned service install လုပ်ပြီးပြီ ဆိုရင် အသုံးပြုဖို့ရန် အတွက်က 'tuned-adm' command ကို အသုံးပြုပါတယ်။ အရင်ဆုံး tuned-adm ရဲ့ help မှာ tuned-adm ကို အသုံးပြုပြီး ဘာတွေလုပ် လုပ်မနိုင်မလဲ ဆိုတာ ပြောပြထားပေးတယ်။



3. tuned-adm list

            tuned-adm list command ကို အသုံးပြုလိုက်ရင် အပေါ်မှာ ပြောခဲ့တဲ့ tuned ရဲ့ pre-defined profile တွေ ကို ပြပေးမှာဖြစ်ပါတယ်။ Profiles တွေကို tuned မှာ အဓိက component ဖြစ်ပါတယ်။ ဒီ profile တွေကို အသုံးပြုပြီး system optimize လုပ်တာဖြစ်ပါတယ်။



4. tuned-adm active & tuned-adm recommend

                လက်ရှိ system သည် ဘယ် profile ကို အသုံးပြုနေလဲ ဘယ် profle က အသုံးပြုဖို့ recommend ဖြစ်လဲဆိုတာကို သိချင်ရင် tuned-adm active and recommand command ကို အသုံးပြုပြီး ကြည့်နိုင်ပါတယ်။ လက်ရှိအသုံးပြုနေတာသည် virtual-guest profile ဖြစ်ပြီး recommend ပေးထားတာသည်လဲ virtual-guest ပဲဖြစ်ပါတယ်။ 



5. Let's trying using different profile

                အိုကေ ဒါဆို tuned-adm ကို အသုံးပြုပြီး different profile တစ်ခု change ကြည့်မယ်။ ဥပမာ ဒီ system က database purpose အတွက် အသုံးပြုထားတယ်ဆိုရင် disk and network io performance တွေ ကောင်းဖို့အတွက် "throughput-performance" profile ကို ပြောင်းကြည့်ကျမယ်။ အောက်ပုံမှာဆိုရင် profile ချိန်း ဖို့အတွက် 'tuned-adm profile <profile-name>' ကို အသုံးပြုထားတာဖြစ်ပါတယ်။ tune-adm active ဖြင့် ကြည့်တဲ့အခါ လက်ရှိ ပြောင်းထားတဲ့ profile ကို ပြပေးမှာဖြစ်ပါတယ်။



6. Combining two profile with tuned

                Profile ကို တစ်ခုထဲ မဟုတ်ပဲ​ profile နှစ်မျိုး ကို ပေါင်းပြီးတော့လဲ အသုံးပြုနိုင်ပါတယ်။ ဒါပေမယ့် အသုံးပြုတဲ့ profile နှစ်ခု က reasonable တော့ ဖြစ်ဖို့လိုပါတယ်။ ဥပမာ HPC (high performance computing) လိုမျိုး utilization မြင့်တဲ့ profile နဲ့ powersave profile ကို သွားတွဲထားလို့ အဆင်မပြေသလိုပေါ့။ အောက်ပုံမှာ"desktop" and "powersave" profile နှစ်ခု ကို merge လုပ်ပြီး အသုံးပြု ထားပါတယ်။ 



7. Disable the tuned service

                tuned service ကို အသုံးမပြုချင်ဘူးဆိုရင်တော့ tuned-adm off command ဖြင့် disable ပြုလုပ်ထားလိုက်လို့ရပါတယ်။ 



8. Where are the location of tuned profiles

                    tuned ရဲ့ pre-defined profiles တွေကို '/usr/lib/tuned' directory အောက်မှာ သိမ်းထားပြီး profile တစ်ခုချင်းစီ မှာ tuned.conf ဆိုတဲ့ config file တစ်ခုပါရှိတယ်။ Customize profile တွေအသုံးပြုချင်ရင်တော့ /etc/tuned directory အောက်မှာ ထားပြီး အသုံးပြုနိုင်ပါတယ်။





            အိုကေ ဒါကတော့ tuned service ကို အသုံးပြုပြီး system တစ်ခုကို optimization ဘယ်လို ပြုလုပ်နိုင်လသလဲ ဆိုတဲ့ article ဖြစ်ပါတယ်။ Detail လေး ထပ်ပြီးတော့ ဖတ်ချင်ရင်တော့ ဒီလင့်မှာ ဖတ်နိုင်ပါတယ်။


That's it 😊

Thank you!!!                        
Share:

Saturday, September 4, 2021

Let's set up your own public authoritative-only dns

             ဒီ article လေးကတော့ ကိုယ့်ဆီမှာ VPS Web Server တစ်ခု ရှိမယ် hosting site က ပေးတဲ့ Managed 

DNS နဲ့  public မထွက်ချင်ဘူး ကိုယ့်ဘာသာကို DNS server setup လုပ်ပြီး Authoritative DNS တစ်ခုလုပ်ကြည့်

မယ် ဆိုတဲ့ စိတ်ကူးရတုန်း စမ်းဖြစ်သွားတဲ့ article လေးဖြစ်ပါတယ်။ 

Share:

Monday, August 30, 2021

Grub in a nutshell

                 ဒီ article လေးမှာ grub bootloader အကြောင်းလေးရှင်းပြမှာဖြစ်ပါတယ်။ အရင်ဆုံး Grub အလုပ်လုပ်ပုံလေးကို ပြောပြပါမယ်။ 

What is Grub? 

            Grub ဆိုတာက Linux system တွေမှာအသုံးပြုတဲ့ bootloader ဖြစ်ပါတယ်။ Bootloader ဆိုတာက Linux OS ကို boot တက်အောင် ပြုလုပ်ပေးတဲ့ service တစ်ခု ဖြစ်ပါတယ်။ Grub အကြောင်းရှင်းရင်းနဲ့ Linux OS ရဲ့ boot procedure အကြမ်းဖြင်းလေးကို ထည့်ပြောချင်ပါတယ်။ 

Share:

Wednesday, February 3, 2021

What I learned about Kubernetes - Multi Container and Init Container

                 ဒီ article မှာတော့ Kubernetes ရဲ့ multi-container နဲ့ init-container အကြောင်းလေးကိုပြောသွားမှာဖြစ်ပါတယ်။

So, What's multi container in kubernetes?

            multi-container ဆိုတာက kubernetes ရဲ့ Pod တစ်ခုအတွင်းမှာ တစ်ခုထက်ပိုတဲ့ container တွေ ထားပြီး အသုံးပြတာဖြစ်ပါတယ်။ ပုံမှန်အားဖြင့် Pod တစ်ခု container တစ်ခု သတ်မှတ်ပေမယ့်လဲ တစ်ချို့ အခြေအနေတွေမှာဆိုရင်လဲ Pod တစ်ခု အတွင်းမှာ multi-container အသုံးပြုလို့ရပါတယ်။ ဆိုတော့ Pod တစ်ခု အတွင်းမှာ "main" container နဲ့ "sidecar" container ဆိုပြီး main container ကို အထောက်အပံ့ ပေးတဲ့ container အနေနဲ့ တည်ဆောက်ပါတယ်။

            ဒီလိုအခြေနေမျိုးမှာ Pod တစ်ခုအတွင်းရှိ container နှစ်ခု အချင်းချင်း communicate လုပ်ဖို့အတွက် i.e volume sharing, network services etc.. တွေအတွက် သီးခြား setup လုပ်ပေးစရာမလိုပါဘူး။

So, How to create a multi-container pod?

            Multi container pod ဖန်တီး ဖို့အတွက် definition file ထဲက spec: array အောက်မှာ နောက်ထပ် container တစ်ခု ထပ်ထည့်ပြီး creat လုပ်တာဖြစ်ပါတယ်။ အောက်ပုံမှာဆိုရင် Pod definition file ထဲမှာ main container ဆိုပြီး "nginx" app နဲ့ caching service ကို လုပ်ဆောင်ပေးမယ့် "redis" app နှစ်ခု ကို ဥပမာအနေနဲ့ တည်ဆောက်ပြထားတာဖြစ်ပါတယ်။


What is another type called Init-container in kubernetes?

                Init-container သည်လဲပဲ multi-container လိုမျိုးပဲ Pod တစ်ခုအတွင်းမှာ တစ်ခုထက်ပိုတဲ့ containers  တွေ တည်ဆောက်ပြီး အသုံးပြုတဲ့ ပုံစံမျိုးဖြစ်ပါတယ်။ multi-container type နဲ့ မတူညီတဲ့အချက်က multi-container က Pod တစ်ခုအတွင်းမှာ ရှိတဲ့ container နှစ်ခုဆို နှစ်ခု စလုံး running ဖြစ်နေရမှာဖြစ်ပြီး container နှစ်ခု ရှိရင် နှစ်ခု ထဲက တစ်ခု failed ဖြစ်ပါက Pod restart ကျသွားမှာဖြစ်ပါတယ်။

                 init-container type ကျတော့ Pod တစ်ခုအတွင်း container နှစ်ခု စလုံး အမြဲတမ်း running ဖြစ်နေစရာမလိုပဲ  main container process မစတင်ခင်မှာ init-container ရဲ့ process က အရင် run ပြီး complete ဖြစ်ရမှာဖြစ်ပါတယ်။ ဥပမာအားဖြင့် main container အတွက် လိုအပ်တဲ့ codes or binariesတွေကို pulling လုပ်ပေးတဲ့ container လိုမျိုး တွေဆိုရင် သူတို့ရဲ့ process က အမြဲတမ်း running ဖြစ်နေဖို့မလိုပါဘူး။

                အောက်ပုံမှာဆိုရင် main-container တစ်ခုနဲ့ init-container တစ်ခု ပါရှိပါတယ်။ Init-container process က အရင် running ဖြစ်နေတဲ့အချိန်မှာ main-container process သည် pending state ဖြစ်နေတာကိုတွေ့မှာဖြစ်ပါတယ်။ Init-container ရဲ့ process ပြီးသွားမှသာ main-container process သည် running စဖြစ်တာကိုတွေ့ရမှာဖြစ်ပါတယ်။ 




For your detail information, pls follow this guide 

https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

ဒါကတော့ kubernetes ရဲ့ multi-container နဲ့ init-container အကြောင်းကိုရှင်းပြထားတာဖြစ်ပါတယ်။

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!!!



Share:

What I learned about Kubernetes - (Scheduling - Taints & Tolerations, Node-Selector & Node-Affinity)

                        ဒီ article မှာတော့ Scheduling Episode ရဲ့ အဆက် အနေနဲ့ Taints and Tolerations အကြောင်း Node Selector and Node Affinity အကြောင်းတို့ကို ဆက်လက် ပြောပြသွားမှာဖြစ်ပါတယ်။

So, Let's get started...


What are Taints and Tolerations?


                   အဓိက ကတော့ Pod တွေကို ဘယ် node တွေ ပေါ်မှာ run စေချင်လဲ မ run စေချင်ဘူးလဲ ဆိုတာကို manage လုပ်ရာတွင် အသုံးပြုပါတယ်။ အဲ့တော့ ဥပမာ အနေနဲ့ ပြောရရင် ရပ်ကွက်ထဲက play-ground တစ်ခုမှာ ကြက်တောင်ရိုက်ဖို့ နေရာလေးတစ်ခု လုပ်ပေးထားတယ် အဲ့တော့ ကြက်တောင်ရိုက်ဖို့ လာတဲ့ သူတွေပဲ ဒီနေရာမှာ ကြက်တောင်လာရိုက်ကြတယ်ပေါ့။ ဒီနေရာမှာ ကြက်တောင်ရိုက်ဖို့ နေရာက Node ဖြစ်ပြီး သူကို့ လာအသုံးပြုမယ့် သူတွေက Pod တွေအနေနဲ့ သတ်မှတ်မယ်။ အဲ့အတွက်ကြောင့် Node က Taint  အနေနဲ့ ကြက်တောင်ရိုက်ရန်ဆိုပြီး သတ်မှတ်ထားတော့ကြောင့် ဒီ Taint နဲ့ သတ်ဆိုင်တဲ့ ကြက်တောင်ရိုက်ဖို့လာတဲ့ Toleration ရှိတဲ့ Pod တွေသာ လာကစားခွင့်ပြုတယ့်သဘောဖြစ်ပါတယ်။

Example: အနေနဲ့က ဒီ Specific Node  ပေါ်မှာ dedicated team တစ်ခုက အသုံးပြုပဲ Pod တွေကိုပဲ ပေး run စေချင်တယ်။ အဲ့လိုအခြေနေမျိုးတွေမှာ တစ်ခြား team တွေနဲ့ မလျောစေချင်တဲ့အခါ အသုံးပြုပါတယ်။

Which commands is being used to taint a node?


            $kubectl taint node <node-name> key=value:taint-effect ဆိုပြီး Node တစ်ခုပေါ်မှာ Taint ကို သတ်မှတ်ပါတယ်။ Taint တစ်ခု သတ်မှတ်တဲ့ နေရာမှာ key=value:taint-effect က အဓိကကျတယ်။ ဒီ key=value ကို Pod မှာ define လုပ်ပြီး Pod သည် ဒီ Node ပေါ်မှာ run ခွင့် ရှိမရှိဆုံးဖြတ်ထားဖြစ်ပါတယ်။

How many types of Taint effect can define on a node?


                Node ပေါ်မှာ Taint အမျိုးအစား ၃ မျိုး သတ်မှတ်နိုင်ပါတယ်။

1. NoSchedule : 

            key=value:NoSchedule ဆိုပြီး သတ်မှတ်ထားရင် ဒီ key=value နဲ့ ကိုက်ညီတဲ့ Pod တွေမှလွဲပြီး ဒီ Node ပေါ်မှာ တစ်ခြား Pod တွေ run ဖို့ schedule လုပ်ပေးမှာမဟုတ်ဘူးလို့ သတ်မှတ်ပါတယ်။ အဲ့တော့ ကြက်တောင်ရိုက်ဖို့ လာတဲ့ သူတွေမှလွဲပြီး ကျန်တဲ့သူတွေကို ပေးမသုံးဘူးဆိုတဲ့သဘောဖြစ်ပါတယ်။

2. PreferNoSchedule: 

            key=value:PreferNoSchedule ဆိုပြီး သတ်မှတ်ရင် ဒီ key=value နဲ့ မကိုက်ညီတဲ့ Pod တွေ ကို  ဒီ Node ပေါ်မှာ မ run နိုင်အောင် ကြိုးစားပေးမယ် ဒါပေမယ့် လုံး၀ မသုံးမပြုနိုင်တာတော့မဟုတ်ဘူး။ ဥပမာ ကြက်တောင်ရိုက်ဖို့အတွက် လုပ်ပေးထားသော်လည်း ပိုက်ကျော်ခြင်း ခတ်ဖို့အတွက် နေရာမရှိတော့တဲ့အခါမျိုးမှာ No Choice အနေနဲ့ အသုံးပြုခွင့်ပေးလိုက်တဲ့သဘောမျိုးဖြစ်ပါတယ်။

3. NoExecute:

           key=value:NoExecute ဆိုပြီးတော့ သတ်မှတ်လိုက်ရင် လက်ရှိ Node မှာ run နေတဲ့ Pod တွေက သတ်မှတ်လိုက်တဲ့ NoExecute Taint effect ကို Toleration မရှိခဲ့ရင် run ခွင့် ရှိတော့မှာမဟုတ်ဘူး ထိုနည်းတူ new pod တွေလဲ Toleration မရှိခဲ့ရင် node ပေါ်မှာ run ဖို့အတွက် schedule သတ်မှတ်မှာ မဟုတ်တော့ပါဘူး။


Here comes, defining a toleration on Pod...


            အခုဆို Node က Taint တွေသတ်မှတ်လိုက်တယ် သတ်မှတ်လိုက်တဲ့ Taint တွေနဲ့ သက်ဆိုင်တဲ့ toleration တွေကို Pod မှာ define လုပ်ပေးရပါတယ်။ 

Sample Pod Definition File with Toleration 

apiVersion: v1
kind: Pod
metadata:
        name: nginx
spec:
    containers:
        - name: nginx-container
           image: nginx

    tolerations:
        - key:" app"
          operator: "Equal"
          value: nginx
           effect: NoSchedule


                အပေါ်မှာပြထားတဲ့ အတိုင်း spec: အောက်မှာ tolerations: တစ်ခု သတ်မှတ်ပြီး app=blue:NoSchedule ဆိုတဲ့ key=value:taint-effect အရ ဒီ Pod သည် app=nginxTaint effect သတ်မှတ်ထားတဲ့ node တွေပေါ်မှာ run လို့ရပြီး ကျန်တဲ့ value သတ်မှတ်ထား သော Pod တွေကို Node ပေါ်မှာ run ဖို့  schedule ပေးလုပ်မှာမဟုတ်ပါဘူး။

                အောက်ပုံမှာဆိုရင် အရင်ဆုံး မိမိ ရဲ့ node name ကို သိဖို့အတွက် $kubetcl get nodes ဆိုပြီး ရှာမှာဖြစ်ပြီး ကျွန်တော်က လက်ရှိမှာ minikube ကို အသုံးပြုထားပါတယ် nodename ကတော့ "minikube" ဖြစ်ပါတယ်။ ပြီးရင် default အားဖြင့် node ပေါ်မှာ Taint သတ်မှတ်ထားခြင်းမရှိပါဘူး။ $kubectl describe node minikube နဲ့ကြည့်တဲ့အခါ Taints: မှာ ဘာမှမသတ်မှတ်ထားတာ တွေ့ရမှာဖြစ်ပါတယ်။





Defining a Taint on a Node


                
                အိုကေ ဒါဆို ကျွန်တော်တို့ Node ပေါ်မှာ Taint key=value တစ်ခု သတ်မှတ်မယ်။ သတ်မှတ်လိုက်တဲ့ Key=Value က လာပြီး run မယ့် Pod app သည် nginx ဖြစ်ရမယ် ဖြစ်ပြီး app=nginx မဟုတ်ခဲ့လျှင် NoSchedule လို့ သတ်မှတ်ထားတဲ့အတွက် တစ်ခြား app=nginx မဟုတ်တဲ့ Pod တွေ လာ run လို့ ရမှာမဟုတ်ပါဘူး။    
                    


Defining a Tolerations on Nginx-Pod and Redis-Pod definition file


                အခု node ပေါ်မှာ Taint သတ်မှတ်ပြီးတဲ့နောက် Pod definition file ထဲမှာ Tolerations သတ်မှတ်ပေးရမှာဖြစ်ပါတယ်။ ဒါမှ ဒီ node ပေါ်မှာ run နိုင်မယ့် Pod ဖြစ်မဖြစ် ဆုံးဖြတ်နိုင်မှာဖြစ်ပါတယ်။ အောက်ပုံ မှာဆိုရင် Nginx-Pod နဲ့ Redis-Pod ကို compare လုပ်ပြပေးထားပါတယ်။ သူတို့ရဲ့ Tolerations Key=Value တွေ သတ်မှတ်ထားပါတယ်။




Creating a Pod


            အရင်ဆုံး nginx-pod ကို စတင် create လုပ်ပါမယ်။ Nginx-Pod က Taint အနေနဲ့ သတ်မှတ်ထားတဲ့ Key=Value match ဖြစ်တဲ့အတွက် $kubectl get pods နဲ့ ကြည့်တဲ့ အခါ "running" ဖြစ်နေမှာဖြစ်ပါတယ်။



             အောက်ပုံမှာ ထပ်မံပြီး redis-pod ကို create လုပ်လိုက်တဲ့အခါမှာ Taint အနေနဲ့ သတ်မှတ်ထားတဲ့ Key=Value နဲ့ မကိုက်ညီတဲ့အတွက် create လုပ်ပြီးပေမယ့်လဲ effect: NoSchedule ဖြစ်လို့ running မဖြစ်ပဲ​ "pending" ဆိုပြီးပြနေတာကို တွေ့ရမှာဖြစ်ပါတယ်။  တစ်ကယ်က ကျွန်တော်က minikube အသုံးပြုထားတဲ့အတွက် node တစ်ခုထဲဖြစ်နေတာဖြစ်ပီး ပုံမှန် node က တစ်ခု ထက်ပိုရှိနေမယ်ဆိုရင် တစ်ခြား node ပေါ်မှာ သွား run မှာဖြစ်ပါတယ်။ 
    



How about Taint with PreferNoSchedule Effect?


                ကျွန်တော်တို့ NoSchedule နဲ့ အသုံးပြုပြီးနောက်မှာ PreferNoSchedule ကို အသုံးပြုကြည့်ရအောင်။
အောက်ပုံမှာဆိုရင် Node ပေါ်မှာ Taint effect ကို PreferNoSchedule အဖြစ် အသုံးပြုထားတယ် အဲ့အတွက်  Kube-Scheduler က တစ်ခြား ရွေးစရာ Node မရှိခဲ့ဘူးဆိုရင် app=nginx မဟုတ်ခဲ့သည့်တိုင်အောင် Pod ကို လက်ရှိ Taint သတ်မှတ်ထားတဲ့ node ပေါ်မှာ run ခွင့်ပေးမှာဖြစ်ပါတယ်။ အခုပုံမှာဆိုရင် app=redis ဖြစ်နေပေမယ့်လည်း running ဖြစ်နေတာကို တွေ့ရမှာဖြစ်ပါတယ်။




What if we use Taint with NoExecute Effect?


                NoExecute ဆိုပြီး Node ပေါ်မှာ သတ်မှတ်လိုက်လျှင် အခုလက်ရှိ run နေတဲ့ Pod တွေမှာ Key=Value:Effect က သတ်မှတ်ထားတဲ့ Taint နဲ့ match မဖြစ်ဘူးဆိုရင် Pods တွေက ချက်ချင်း terminate ဖြစ်သွားမှာဖြစ်ပြီး အသစ်လာ run မယ့် Pod တွေမှာလဲ သတ်မှတ်ထားတဲ့ Teffect ကို Toleration မရှိဘူးဆိုရင် Node  ပေါ်မှာ လာရောက် run ခွင့် ရှိမှာမဟုတ်ပါဘူး။

   အခုအောက်ပုံမှာဆိုရင် 



1. လက်ရှိ Taint effect သည် PreferNoSchedule ဖြစ်ပြီး တစ်ဖက်မှာ Pods တွေသည်လဲ running state ဖြစ်နေဆဲဖြစ်ပါတယ်။ 

2. အဲ့ဒီမှာ ကျွန်တော်တို့ လက်ရှိ Taint effect ကို ပြန်ဖျက်ချင်တယ်ဆိုရင် Taint သတ်မှတ်တဲ့ command ကို ပဲပြန်အသုံးပြုပြီး နောက်ဆုံးမှာ "-" minus symbol လေး ထည့်ပြီး ပြန်ဖျက်ရတာဖြစ်ပါတယ်။ အခု ချိန်ထိ က တစ်ဖက်မှာ Pods တွေက run နေတုန်းပဲဖြစ်ပြီး ဘာလို့လဲဆိုတော့ လက်ရှိ Node ပေါ်မှာ ဘာ Taint effect မှမရှိသေးလို့ဖြစ်ပါတယ်။

3. နောက်ဆုံး အဆင့်မှာ ကျွန်တော်တို့ Taint effect "NoExecute" ဆိုပြီးသတ်မှတ်လိုက်ပြီ အဲ့ဒီအခါမှာ လက်ရှိ Pods တွေရဲ့ Tolerations မှာ NoExecute ကို မသတ်မှတ်ထားတဲ့အတွက် ချက်ချင်းဆိုသလို Node ပေါ်ကနေ terminate လုပ်ခံရတာဖြစ်ပါတယ်။

4. အိုကေ ဒါဆို နောက်ထပ်တစ်ဆင့်အနေနဲ့ Nginx-Pod မှာ  Tolerations ကိုပြန်ပြင်မယ် ဒီတစ်ခေါက်မှာတော့ app=nginx:NoExecute ဆိုပြီး သတ်မှတ်လိုက်ပြီးတော့ Pod ကို ပြန် create လုပ်ကြည့်တဲ့အခါမှာ သတ်မှတ် ထားတဲ့ Taint ကို Tolerations ရှိတဲ့အတွက် running ဖြစ်နေတာကိုတွေ့ရမှာဖြစ်ပါတယ်။






What is Node-Selector?


            Taints and Tolerations အပိုင်းပြီးသွားတဲ့အခါ အခု နောက်တစ်ခုအနေနဲ့က Node-Seletctor အကြောင်းဖြစ်ပါတယ်။ 

Different between Taints and Tolerations and Node-Selector


           Taint and Tolerations combo က Node-Selector နဲ့ ဘာကွာလဲဆိုတော့ Taint and Tolerations သည် သူတို့ သတ်မှတ်ထားတဲ့ Taint effect တွေကို Tolerations ရှိတဲ့ Pod တွေလာရောက် run နိုင်တယ်လို့ သတ်မှတ်ထားတာဖြစ်ပြီး တစ်ချို့ အခြေအနေတွေမှာ ချွင်းချက်အနေနဲ့ Taint effect နဲ့ မကိုက်သော်လည်း run ခွင့်ပေးပြီး      Node-Selector ကျတော့ လုံး၀ကို ဒီ Pod သည် ဒီ Node မှာပဲ run ကို run ရမယ် scheduler သည် ဒီ node ပေါ်မှာပဲ​ ဒီ Pod ကို assign ချရမယ်ဆိုတဲ့ သဘောမျိုးဖြစ်ပါတယ်။

Example: အနေနဲ့က Kubernetes Cluster Environment မှာ လက်ရှိ သုံးနေတဲ့ Node တွေရဲ့ Size ချင်း မညီမျှတဲ့အခါ ပြောချင်တာက Hardware Resources တွေ မတူတဲ့ အခါမှာ small resources ပဲ ရှိတဲ့ Node တွေပေါ်မှာ Pod တွေ အများကြီး overload ဖြစ်အောင်မသုံး စေချင်တဲ့ အခါ ဝန်မပိစေချင်တဲ့အခါမျိုး တွေမှာ အသုံးပြုပါတယ်။

How to determine which node is large or small?


            အဲ့တော့ ဘယ် node ကတော့ Large ဖြစ်ပြီး ဘယ် node ကတော့ small node ဖြစ်တယ်ဆိုတာ ကို ကျွန်တော်တို့ "Labels" နဲ့ Key=Value ဆိုပြီး Node ပေါ်မှာ သတ်မှတ်ပြီး ဆုံးဖြတ်ပါတယ်။

Which command to define a label on a node?


            $kubectl label node <node-name> <label-key>=<label-value> ဆိုပြီးတော့ အသုံးပြုပြီး သတ်မှတ်ပါတယ်။ အောက်ပုံမှာ ပြထားပါတယ်။



Label ကို ပြန်ပြီး remove လုပ်ချင်တယ်ဆိုရင်တော့ $kubectl label node minikube size- ဆိုပြီး အသုံးပြုပါတယ်။




Let's try to create Pod with Node-Selector 


1. အခု အရင်ဆုံး Node မှာ Size=Large ဆိုပြီး Label define လုပ်ထားတယ်။ ပြီးတော့ တစ်ဖက်မှာက ကျွန်တော် Nginx-Pod definition file မှာ "nodeSelector: Large" ဆိုပြီး သတ်မှတ်ထားတဲ့အတွက် ဒီ Nginx-Pod သည် Node label size=Large ဆိုပြီး define လုပ်ထားတဲ့ Node တွေပေါ်မှာ run လို့ရတာကိုတွေ့ရမှာဖြစ်ပါတယ်။




2. အောက်ပုံမှာ ကျတော့ Redis-Pod တစ်ခုရဲ့ "nodeSelector: small" ဆိုပြီးတော့ သတ်မှတ်ထားသည့်အတွက် Node Label Size=Large သတ်မှတ်ထားတဲ့  Node ပေါ်မှာ run လို့ မရပဲ Pending ဖြစ်နေတာကို တွေ့မှာဖြစ်ပါတယ်။




What is Node-Affinity?


                Node-Affinity နဲ့ Node-Selector အဓိက အလုပ်လုပ်ပုံခြင်းက အတူတူပဲဖြစ်ပြီး ဘာကွာသွားလဲ ဆိုရင် node-affinity က pod placement on node ပိုင်းမှာ node-selector ထက်ပိုပြီး ရွေးချယ်စရာ options ပိုင်း မှာ ပိုပြီးများပါတယ်။ Node-Selector က Large or Small အဲ့လိုမျိုး တစ်မျိုးထဲပဲ သတ်မှတ်လို့ ရနိုင်ပြီး Node-Affinity မှာဆိုရင်တော့ Value နှစ်ခု ကို တစ်ပြိုက်နက် သတ်မှတ်နိုင်တာတွေ ဥပမာ "Large or Medium" ဒါမဟုတ် "Not Small" စတဲ့ advance features တွေ ကို သတ်မှတ်နိုင်ပါတယ်။


How does node-affinity work?


                    Node-Affinity ဘယ်လိုမျိုး အလုပ်လုပ်သလဲဆိုတော့ သူလဲပဲ Node မှာ သတ်မှတ်ရမယ့် Label ရှိမယ် နောက် အဲ့ Label နဲ့ ကိုက်ညီမယ့်  Pod မှာ သတ်မှတ်ရမယ့် Affinity-Rule ရှိမယ်။ ဒီ Lable နဲ့ Affinity-Rule တွေ ကိုက်ညီမှ  Kube-Scheduler က Pod ကို Node ပေါ်မှာ run ခွင့် ပေးမှာ ဖြစ်ပါတယ်။ Node-Affinity မှာ.... 

Type-1 (requiredDuringSchedulingIgnoredDuringExecution)

Type-2 (perferredDuringSchedulingIgnoredDuringExecution)

Type-3 (requiredDuringSchdeulingRequiredDuringExecution)

ဆိုပြီး Type ၃မျိုး ရှိတယ်။


Type-1 (requiredDuringSchedulingIgnoredDuringExecution)


               Affinity rule သတ်မှတ် ထားတဲ့ Pod တစ်ခု ကို စ create လုပ်ပြီးတဲ့နောက် အဲဒီ Pod run မယ့် Node သည် Pod ရဲ့ affinity rule နဲ့ ကိုက်ညီမယ့် Label define မလုပ်ထားဘူးဆိုရင် သူနဲ့ ကိုက်ညီမယ့် Node တစ်ခု ရှိလာတဲ့အထိ ကို အချိန် တစ်ခုထိ စောင့်နေပြီး လုံးဝကို မရှိတော့ဘူးဆိုရင်တော့ Pod ကို Kube-Scheduler က run ခွင့်ပေးမှာမဟုတ်တော့ပါဘူး။ ဒါကြောင့် သူ့ကို Required Typeလိုခေါ်ပြီး  Pod တစ်ခု run ဖို့က Affinity-rules နဲ့ label define လုပ်ထားတဲ့ node လိုကိုလိုအပ်တဲ့ Type အမျိုးအစားလို့သတ်မှတ်ပါတယ်။

Type-2 (perferredDuringSchedulingIgnoredDuringExecution)


                Type-1 Required Type နဲ့ ဆန့်ကျင်စွာ ကိုက်ညီမယ့် Node တစ်ခု ရှာမတွေ့ ခဲ့ ဘူးဆိုရင်တောင် Pod မှာ သတ်မှတ်ထား တဲ့ Affinity-Rule ကို Ignore လုပ်ပြီး အဆင်ပြေမယ့် Node တစ်ခုခုမှာ Kube-Scheduler က run ခွင့် ပေးလိုက်မှာဖြစ်ပါတယ်။

Both Type-1 and Type-2 က လက်ရှိ scheduled ဖြစ်ပြီးသား running ဖြစ်နေပြီးသား Pod တွေ ပေါ်မှာ Node-Affinity rules တွေ changes ဖြစ်ခဲ့ရင်တောင် "IgnoreDuringExecution"  ဖြစ်တဲ့အတွက်  Ignore လုပ်ပြီး ဆက်လက် running ဖြစ်နေမှာဖြစ်ပါတယ်။

Type-3 (requiredDuringSchdeulingRequiredDuringExecution)


            RequiredDuringScheduling ဖြစ်တဲ့အတွက် Type-1 နဲ့ တူမယ် နောက်ထပ် တစ်ခုက "RequiredDuringExecution" ဖြစ်တဲ့အတွက် running လုပ်နေစဥ်မှာ Affinity-Rule changes လုပ်လိုက်လျှင် လက်ရှိ node  ပေါ်မှာ run နေတဲ့ Pod တွေရဲ့ affinity-rules နဲ့ မကိုက်ညီတော့တဲ့အခါ Pods တွေကို ဖယ်ထုတ်ပစ်မှာ ဖြစ်ပါတယ်။


Node-Affinity rule က ကျွန်တော်လဲ ဖတ်လေ ရှုတ်လေ ပဲ :P anyway.. Let's continue....

Deploying a Pod with node-affinity rules


                အခု ကျွန်တော်တို့ Node-Affinity rule သတ်မှတ်ပြီးတော့ Pod တည်ဆောက်ကြည့်ရအောင်။ Node Label ကတော့ size=Large ဆိုပြီး Node-Selector မှာသတ်မှတ်ခဲ့တဲ့အတိုင်းပဲ သတ်မှတ်ထားမယ်။ နောက် Pod ရဲ့ definition file ထဲမှာ Node-Affinity rules ကိုသတ်မှတ်ပြီး create လုပ်ကြည့်မှာဖြစ်ပါတယ်။

                    အောက်ပုံမှာဆိုရင် Node Label က size=Large ဖြစ်တဲ့အတွက် သူ့အပေါ်မှာ လာ run မယ့် Pod ရဲ့ Affinity-Rule သည် Large or Medium ဖြစ်ရမယ်ဆိုပြီး Nginx-Pod definition file ထဲမှာ သတ်မှတ်ထားတာဖြစ်ပါတယ်။ ပြီးရင် create လုပ်ပြီး တဲ့ အခါ Node ရဲ့ Label နဲ့ Affinity-Rule နဲ့ ကိုက်ညီတဲ့အတွက် running ဖြစ်နေတာကို တွေ့မှာဖြစ်ပါတယ်။ ဒီနေရာမှာ Operator : In ဆိုတာကို သုံးသွားပါတယ်။ တစ်နည်းအားဖြင့် အကျုံးဝင်တဲ့ values တွေ ဆိုပြီးသတ်မှတ်ပါတယ်။




                        အောက်ပုံမှာဆိုရင်လဲ Pod ရဲ့ Node-Affinity rule ကို Operator change ပြီး အသုံးပြုသွားတာဖြစ်ပါတယ်။ ဒီမှာတော့ operator: NotIn , Values: Small ဆိုပြီးသတ်မှတ်ထားတဲ့အတွက် Node Label သည် as long as "Small" မသတ်မှတ်ထားဘူးဆိုရင် ဒီ Pod သည် ဒီ Node ပေါ်မှာ အသုံးပြုနိုင်ပါတယ်။  



                        အခုအောက်ပုံမှာကျတော့ Node-Affinity Rule မှာ Operator ကို "Exists" ဆိုပြီး အသုံးပြုသွားတာတွေ့ရပါမယ်။ Exists ဆိုတဲ့ operator ရဲ့ အလုပ်လုပ်ပုံက သူ့မှာ value သတ်မှတ်စရာ မလိုပဲ as long as Node Label ဖြစ်တဲ့ key: size တာ တူညီခဲ့တယ်ဆိုရင် ဘယ်လို size မျိုးပဲဖြစ်ပေစ Large, Medium or Small စဥ်းစားမနေပဲနဲ့ Pod ကို ဒီ  Node ပေါ်မှာ run နိုင်မှာဖြစ်ပါတယ်။ 




PS: That's a lot I need to know regarding scheduling chapters. For now, let me stop at this state and will update once I get more understanding.



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!!!



                        
Share:

What I learned about Kubernetes - (Scheduling - Manual Scheduling, Labels and Selectors)

                        ဒီ article ကတော့ Kubernetes ရဲ့ Scheduling အကြောင်းပဲဖြစ်ပါတယ်။ ဒီ Schduling အပိုင်းမှာ ပြောရမည့် အကြောင်းအရာတွေ များတဲ့အတွက် Episode 9 အပိုင်းတွေနဲ့ ခွဲပြီး ပြောတာပိုကောင်းပါမယ်။ အခု 
EP-9 အစမှာ တော့ Manual Schduling အကြောင်း နဲ့ Labels and Selectors အကြောင်းကို ပြောပါမယ်။

What is manual scheduling?

                        
                       ပုံမှန် အားဖြင့် Pod တွေကို node ပေါ် assign ချတဲ့နေရာမှာ manually လုပ်ပေးစရာမလိုပါဘူး။ Kubernetes ရဲ့ kube-scheduler က လုပ်ဆောင်ပေးပါတယ်။ Kube-scheduler က Pod assign ချတဲ့နေရာမှာ Pod တွေမှာ node name ကို သတ်မှတ်ထားတာ ရှိမရှိ ကြည့်တယ် Node name နဲ့ manually label မတက်ထားတဲ့ Pods တွေကိုပဲ auto-assign ချပေးပါတယ်။ အကယ်၍ Pod definition file မှာလဲ ဘယ် node မှာ  assing ချမလဲ ဆိုပြီး မသတ်မှတ်ထားဘူး auto scheduler service လဲ မရှိဘူးဆိုရင် Pod သည် "pending state" မှာ ရပ်နေမှာ ဖြစ်ပါတယ်။

Sample Pod Definition File with Node Name Assign for Pod Scheduling





 What are labels and selectors?


                    Label and Selector က ပြောမယ်ဆိုရင် key=value အတွဲပဲ ဖြစ်ပါတယ်။ ဒီ Key နဲ့ ရှာရင် ဒီ key နဲ့ ပတ်သတ်တဲ့ value တွေ့ ပြပေးမှာဖြစ်ပါတယ်။ Pods တွေ ကို သူ့ group နဲ ့ သူ ပြောချင်တာက Front-end pods တွေလား back-end pods တွေလား နောက် web-service pod လား database-service run နေတဲ့ pod တွေလား စသည်ဖြင့် label သတ်မှတ် ပြီး organized ဖြစ်အောင် ပြုလုပ်ထားခြင်းဖြစ်ပါတယ်။

                  Label ကို ဘာမှာထားပြီး အသုံးပြုလဲဆိုတော့ metadata: အောက်မှာ ထားပြီး သတ်မှတ်ပါတယ်။ Label သတ်မှတ်ထားခြင်း ဖြင့် စောနက ပြောသလိုပဲ ဒီ  Pod သည် ဘာအတွက် run သလဲ ဘာအမျိုးအစား Pod ဖြစ်သလဲ ဆိုတာ သိစေပါတယ်။

                Selector ကိုတော့ ကြားခံ ဆက်သွယ်ရေး တစ်ခု အနေနဲ့ ထားရှိပြီး အသုံးပြုပါတယ်။ ဥပမာ Selector ကို Pod နဲ့  ReplicaSet တို့ ကြား Replicaset က ဘယ် application run နေတဲ့ Pods တွေကို control လုပ်ရမလဲ ဆိုတာကို Selector ကို ကြည့်ပြီး ဆုံးဖြတ်ရပါတယ်။ တစ်နည်းအားဖြင့် Selector သည် ကိုယ်ယူကြည့်ချင် Pods တွေကို filtering function လုပ်ပေးတဲ့ သဘောမျိုးဖြစ်ပါတယ်။ 


  How to define a Label inside a YAML file?


                ပုံမှန်အတိုင်းပဲ ကျွန်တော်တို့ definition file ရဲ့ metadata အောက် label session မှာ define လုပ်ပေးရမှာဖြစ်ပါတယ်။ အောက်ပုံမှာ ကျွန်တော် nginx-pod and redis-pod ကို create လုပ်ပြမယ် သူတို့ ဆီမှာ ကိုယ်ပိုင် label တွေ define လုပ်ထားပါတယ်။



                        Pod တည်ဆောက်လို့အပြီးမှာ $kubectl describe pod ဖြင့် ကြည့်ရင် Labels session မှာ ကျွန်တော်တို့ သတ်မှတ်ခဲ့တဲ့ label အတိုင်းပြနေမှာဖြစ်ပါတယ်။



                         အခု အောက်ပုံမှာဆိုရင် "--selector" ကို အသုံးပြုပြီး Pod နှစ်ခုရဲ့ မတူညီတဲ့ function ပိုင်းကို filter လုပ်ပြီး ခေါ်ကြည့်တာဖြစ်ပါတယ်။                         



                        အောက်ပုံမှာဆိုရင်တော့ ထပ်ပြီး  multi-label define လုပ်ထားတာကို "selector" ကို အသုံးပြုပြီး filter လုပ်ပြထားတာဖြစ်ပါတယ်။ Labels မျိုးစုံသတ်မှတ်လို့ရတယ်, တစ်ခုထက်ပိုတဲ့ ပုံစံမျိုးနဲ့လဲ သတ်မှတ်နိုင်ပါတယ်။ 



                                                                                    

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!!!






Share:

What I learned about Kubernetes - (Namespace)

                               ဒီ article မှာတော့ Kubernetes ရဲ့ namespace အကြောင်းကို ပြောချင်ပါတယ်။

What is Namespace in Kubernetes?


                
                ကျွန်တော်တို့ အရင် Episodes တွေမှာ တည်ဆောက်ခဲ့သမျှ Deployment, Pod, ReplicaSet, Services အကုန်လုံးသည် Namespace တစ်ခုအတွင်းမှာသာဖြစ်သည်။ ဘယ် Namespace အတွင်းလဲဆိုတော့ Default Namespace တစ်ခုအတွင်းမှာ တည်ဆောက်ခဲ့တာဖြစ်ပါတယ်။ ဒီတော့ Namespace ဆိုတာ ကျွန်တော် နားလည်သလို ပြောရရင် သီးသန့် ထားတဲ့နေရာတစ်ခုဖြစ်ပါတယ်။ ဥပမာ environment တစ်ခု မှာ Application Suite တစ်ခုစီတိုင်းအတွက် အသုံးပြုထားတဲ့ Kubernetes cluster တွေ တစ်ခုနဲ့အထက်ရှိမယ် အဲ့တော့ တည်ဆောက်လိုက်သမျှ Pods တွေ Services တွေကို Default Namespace ထဲ အကုန်စုပြုံထည့်ပြီး သုံးနေရင် manage လုပ်ရတာ overhead ဖြစ်နေမှာဖြစ်တဲ့အတွက် App suite တစ်ခု Namespace တစ်ခု ပုံစံမျိုး ဒါမဟုတ် Prod Env အတွက် က Prod Namespace , UAT Env အတွက် က UAT Namespace တစ်ခု စီ ခွဲပြီး Pods တွေ Services တွေကို deploy လုပ် စတဲ့ နေရာမှာ Namespace ကို အသုံးပြုပါတယ်။

                    အောက်မှာပြထားတဲ့ပုံအတိုင်းပဲ Kubernetes cluster တစ်ခုရဲ့ Namespace တွေကို ကြည့်ချင်ရင် $kubectl get namespace command ကိုအသုံးပြုပီး ကြည့်နိုင်ပါတယ်။ ပုံတွင် Kubernetes cluster မှာ default အနေနဲ့ Namespace ၄ ခုပါရှိပါတယ်။ နောက်ထပ် command တစ်ခုဖြစ်တဲ့ $kubectl get all ကို အသုံးပြုရင် လက်ရှိ Kubernetes cluster မှာ တည်ဆောက်ထားသမျှ အားလုံးကို ပြပေးတာဖြစ်ပါတယ်။ ဒီနေရာမှာ $kubetcl get all ဆိုပြီး enter ခေါက်လိုက်တာနဲ့ result ဘာလို့ပြလဲ ဆိုတော့ ကျွန်တော်တို့ တည်ဆောက်ခဲ့သမျှ အားလုံးက "default namespace" ထဲ ရောက်သွားတဲ့အတွက် သတ်သတ်ကြီး namespace ကို mention ခေါ်စရာမလိုပဲ ကြည့်လိုရနိုင်တာဖြစ်ပါတယ်။ နောက်ထပ် command တစ်ခုကို ကြည့်မယ်ဆိုရင် $kubectl -n default get all မှာဆိုရင်တော့ -n = namespace "default namespace"ထဲမှာ တည်ဆောက်ထားသမျှ အားလုံးကို ကြည့်ချင်တယ်ဆိုရင် အခုလိုမျိုး အသုံးပြုရမှာဖြစ်ပါတယ်။










What is Kube-system namespace?


                   Kubernetes တစ်ခု စတင်တည်ဆောက်ထဲက ပါဝင်လာတဲ့ Namespace တစ်ခုဖြစ်ပါတယ်။ ဘာအတွက် အသုံးပြုလဲဆိုရင် ဒီ Kubernetes တစ်ခု run ဖို့အတွက် လိုအပ်တဲ့ services တွေ ဖြစ်တဲ့ networking, dns service, နောက် kube-{controller, scheduler, api, proxy, etc..} စတဲ့ Services တွေ အတွက် သီးသန့် ထားထားတဲ့ နေရာတစ်ခုဖြစ်ပါတယ်။






How to create a new custom namespace?


                Namespace အသစ်တစ်ခု create လုပ်ဖို့အတွက် YAML file နဲ့ create လုပ်နိုင်သလို YAML file မသုံးပဲနဲ့ တိုက်ရိုက် create ပြုလုပ်နိုင်တယ်။

Using $kubectl create namespace to create new namespace




Creating new namespace with definition file (YAML)




How to switch the default namespace?



                    လက်ရှိ default namespace က "default" namespace ဖြစ်ပြီး တည်ဆောက်လိုက်သမျှ pods တွေ services တွေက default namespace မှာ သွားထားမှာဖြစ်ပါတယ်။ default namespace ကို ပြောင်းချင်တယ်ဆိုရင် ပြောင်းနိုင်ပါတယ်။ အောက်ပုံမှာဆိုရင် default namespace ကို "prod-env" ကို ပြောင်းလိုက်တဲ့အခါ default namespace မှာ အရင်က create လုပ်ခဲ့တာတွေ ပြန်ခေါ်ကြည့်ချင်ရင် "-n default" ဆိုပြီး သုံးမှသာ ကြည့်နိုင်တော့မှာဖြစ်ပါတယ်။




                           



                                     အပေါ်ပုံမှာဆိုရင် redis pod တစ်ခု ကို default namespace ဖြစ်တဲ့ "prod-env" မှာ တစ်ခု "uat-env" namespace မှာ တစ်ခု ဆိုပြီး pod တည်ဆောက်ရာမှာ namespace ကိုဘယ်လိုမျိုး အသုံးပြုလဲ တည်ဆောက်လိုက်တဲ့ pod ကို ပြန်ခေါ်ကြည့်ရာမှာလဲ namespace အလိုက် ဘယ်လိုမျိုး ကြည့်ရလဲ​ ဆိုတာ ပြထားပါတယ်။ Prod-env ရဲ့ pods ကို ကြည့်တဲ့အခါ "prod-env" က default namespace ဖြစ်သွားတဲ့အတွက် mention ခေါ်ပြီး ကြည့်စရာမလိုတော့ဘူးဖြစ်ပါတယ်။

So, how do we define "namespace" inside the definition file (YAML) and create?


                    ကျွန်တော်တို့ YAML file ကို အသုံးပြုပီး Pods, Serivces တွေကို တည်ဆောက်ရင်း တစ်ခါထဲ namespace ကို assign လုပ်လို့ရပါတယ်။ အောက်ပုံမှာ nginx-deployment တစ်ခု ကို "uat-env" namespace မှာ ထားပြီး တည်ဆောက်ပြထားပါတယ်။ အဓိက ကတော့ "metadata session မှာ namespace: uat-env" ဆိုပြီး သတ်မှတ်လိုက်တာဖြစ်ပါတယ်။





What are Resource Quota and Limit Range in a namespace?



                Pods တွေဆိုတာလည်း ကျွန်တော်တို့ VM တွေလိုပဲ သူလဲပဲ underlying node ရဲ့ resources တွေကို မှီခိုပြီး run နေတာဖြစ်ပါတယ်။ Resources တွေဆိုတာ {CPU, MEMORY, STORAGE} စတာတွေဖြစ်တယ်။ အဲ့တော့ ဒီ Pods တွေရဲ့ resource consumption ကို ထိန်းချုပ်ဖို့အတွက် ဒီ Resource Quota နဲ့ Limit Range ကို အသုံးပြုပြီး သတ်မှတ်လို့ရပါတယ်။

Resource Quota


                Resource Quota က သူက ဒီ namespace တစ်ခုအတွင်းမှာ run နေတဲ့ pods တွေသည် total resource ဘယ်လောက်ထိကို ပေးသုံးမယ် ဆိုပြီး သတ်မှတ်တဲ့နေရာမှာ အသုံးပြုတယ်။

Limit Range


            Limit Range ဆိုတာက ကျတော့ ဒီ namespace တစ်ခု အတွင်းမှာ ရှိတဲ့ pod တစ်ခုချင်းစီ ရဲ့ resource consumption ကို ထိန်းချုပ်တဲ့ နေရာမှာ အသုံးပြုပါတယ်။


How to check whethere namespace has defined Resource Quota and Limit Range?


                $kubectl describe namespace <namespace-name> ဖြင့် ဒီ namespace မှာ resource quota and limit range policies သတ်မှတ်ထားလား ကြည့်နိုင်တယ်။




How to define Limit Range policy in a namespace?


                Limit range policy ကို namespace တစ်ခုမှာ သတ်မှတ်ဖို့အတွက် limit-range definition file (YAML) တစ်ခု create လုပ်ရပါမယ်။ ပြီးရင် $kubectl create ဖြင့် create လုပ်တဲ့အခါ limit-range policy ကို အသုံးပြုချင်တဲ့ namespace ကို ပါ တွဲပြီး create လုပ်ပေးရပါမယ်။ အောက်ပုံမှာ cpu resource limit range definition file တစ်ခု ကို တည်ဆောက်တယ် ပြီးရင် "prod-end" namespace နဲ့ တွဲပြီး သတ်မှတ်ပါတယ်။ အဲ့အခါ နောက်ပိုင်း Prod-env မှာ Pod တည်ဆောက်တဲ့အခါ ဒီ resource limit range အတွင်းပဲ Pod သည် အသုံးပြုပြီး ကျော်ပြီးအသုံးပြုရင် Error (Forbidden) ဆိုပြီး ပြမှာဖြစ်ပါတယ်။



How to create a Pod with limit range?


            Pod တစ်ခု ကို Limit Range policy သတ်မှတ်ပြီး ဘယ်လိုတည်ဆောက်မလဲ ဆိုတော့ definition file ထဲမှာ resource limit သတ်မှတ်မယ် သတ်မှတ်တဲ့ resource limit က define လုပ်ထားတဲ့ policy အတွင်း ဝင်တယ်ဆိုရင် create လုပ်ခွင့်ပေးမယ် မဝင်ခဲ့ဘူးဆိုရင်တော့ Error ပြပေးမှာဖြစ်ပါတယ်။ အောက်ပုံမှာ Nginx-Pod တစ်ခုကို cpu-resource min-200m and max-800m ဆိုပြီး တည်ဆောက်တယ် Prod-Env namespace မှာ သတ်မှတ်ထား တဲ့ policy ဖြစ်တဲ့ min-200 and max-800m အတွင်း ဝင်တဲ့အတွက် create လုပ်ခွင့်ပေးတယ်။ သတ်မှတ်ထား တဲ့ min-max range အတွင်း မဝင်ခဲ့ရင်တော့ Error ပြပြီး create လုပ်ခွင့်ပေးမှာမဟုတ်ပါဘူး။



                Pod create လုပ်ပြီးလို့ $kubectl describe pod <pod-name> ဖြင့် detail information ကြည့်တဲ့အခါ pod ရဲ့ limits မှာ cpu policy define လုပ်ထားတာ တွေ့မှာဖြစ်ပါတယ်။








                    အပေါ်ပုံမှာဆိုရင် Nginx-pod ရဲ့ အသုံးပြုမယ့် cpu-resource က သတ်မှတ်ထားတဲ့ policy အတွင်း မဝင်တဲ့ အတွက် create လုပ်ခွင့်မပေးတာတွေ့ရပါမယ်။

What if you don't define a limit range while creating a pod under a namespace with defined limit-range policy?


                    Pod တစ်ခုကို limit range မသတ်မှတ်ပဲ limit range define လုပ်ထားတဲ့ namespace တစ်ခုအောက်မှာ တည်ဆောက်လိုက်တယ်ဆိုပါစို့.. အဲ့အခါ ဘယ်လိုဖြစ်မလဲဆိုတော့ create လုပ်လိုက်တဲ့ pod သည် Policy သတ်မှတ်ထားတဲ့  default value အတိုင်း ရရှိမှာဖြစ်ပါတယ်။ 



                Limit Range က သတ်မှတ်ပေးတဲ့ default value ကို သိချင်ရင် အောက်မှာ ပြထားတဲ့ ပုံအတိုင်း $kubectl get limitrange <limitrange-name> -o yaml -n prod-env ဆိုပြီး YAML output ထုတ်ပြီး ကြည့်လို့ရပါတယ်။





Defining the CPU unit



                အခု တောက်လျှောက်သတ်မှတ်လာခဲ့တဲ့ CPU unit အကြောင်းကို အနည်းငယ်ရှင်းပြချင်ပါတယ်။ ဒီ "m" ရဲ့ အရှည် က "milicore" or "milicpu" ဖြစ်ပါတယ်။ Kubernetes မှာ သုံးတဲ့ CPU usage အတွက် unit ဖြစ်ပါတယ်။ သူ့ ရဲ့ ပုံစံကတော့ 1vCPU = 1000m ဖြစ်ပါတယ်။ 
Ref:


After learning limit-range, Let's define Resource Quota?


                    Resource Quota က အပေါ်မှာ ပြောခဲ့သလိုပဲ pod တစ်ခု ချင်းစီ ကို control လုပ်တာမဟုတ်ပဲ ဒီ namespace တစ်ခုမှာ total resource consumption ဘယ်လောက်ဆိုပြီး သတ်မှတ်တာဖြစ်ပါတယ်။

How to create a Resource Quota definition file (YAML) 

                    ထုံးစံအတိုင်း Limit Range မှာ လုပ်ခဲ့သလိုပဲ Resource Quota definition file (YAML) တစ်ခု ကို create လုပ်ပြီး သတ်မှတ်ချင်တဲ့ namespace အောက်မှာ create လုပ်ပေးရမှာဖြစ်ပါတယ်။ 




                    အပေါ်ပုံမှာ Resource  Quota policy အရ

1. pod: 10 ---> prod-env namespace အတွင်းမှာ pods 10 ပဲ အသုံးပြုနိုင်မယ်
2. requests.cpu: 7 ---> Container အားလုံးအတွက် Total CPU Request သည် vCPU=7core ထက်မကျော်ရဘူး
3. request.memory: 25Gi ---> Container အားလုံး အတွက် Total Mem Request သည် 25GB ထက်မကျော်ရဘူး
4. limit.cpu: 8 --->  Container အားလုံးအတွက် Total CPU Limit သည် vCPU=8core ထက်မကျော်ရဘူး
5. limit.memory: 32Gi ---> Container အားလုံးအတွက် Total Mem Request သည် 32GB ထက်မကျော်ရဘူး
ဆိုပြီး သတ်မှတ်ထားတာဖြစ်ပါတယ်။



How to create a Pod with Resource Quota?


                Pod create လုပ်တဲ့နေရာမှာ Resource Quota ပဲဖြစ်ဖြစ် Limit Range နဲ့ပဲ ဖြစ်ဖြစ် spec: session ရဲ့ resource: အောက်မှာ သတ်မှတ်ရမှာဖြစ်ပါတယ်။





                        အပေါ်ပုံမှာပြထားတဲ့ nginx-pod resource policy မှာဆိုရင် request for {cpu | mem} သည် {1vcpu: 1Gi} အနေနှင့် min သတ်မှတ်ထားပြီး ၎င်း nginx-pod အတွက် limit က တော့ {cpu: 2vCPU, mem:2Gi} အထိ max အသုံးပြုလို့ရနိုင် ကြောင်း သတ်မှတ်ထားတာဖြစ်ပါတယ်။ 
                        Pod ကို စ create လုပ်လိုက်ပြီး တစ်ပြိုင်နက် တစ်ဖက်ခြမ်း မှာ $kubectl get resourcequote (or) $kubectl describe namespace prod-env ကိုအသုံးပြုပြီး ကြည့်လိုက်လျှင် nginx-pod အတွက် { cpu | mem } resources စတင် ပေးလိုက်ရပြီဖြစ်လို့ default cpu and mem limit ထဲကနေ လျော့ သွားတာကို တွေ့ရမှာဖြစ်ပါတယ်။

                    အခုအောက်ပုံမှာဆိုရင် နောက်ထပ် pod "redis" ကို ထပ်တည်ဆောက်လိုက်တဲ့အခါ သတ်မှတ်ထားတဲ့ default resources value ရဲ့ range အတွင်း ဝင်နေသမျှကတော့ create လုပ်လို့ရနေအုံးမှာဖြစ်ပြီး ကျော်လွန်သွားရင်တော့ forbidden error ဆိုပြီး ပြမှာဖြစ်ပါတယ်။




                    အောက်ပုံကိုကြည့်မယ်ဆိုရင်တော့ busybox pod cpu.limit မှာ လက်ကျန် cpu limit ထပ် ပိုပြီး သတ်မှတ် ထားတဲ့အတွက် pod creation လုပ်လို့မရတာကို တွေ့ရမှာဖြစ်ပါတယ်။




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!!!





Share: