ReplicationControllers နဲ့ ReplicaSets တွေကို အသုံးပြုပြီး Pod တွေကို create လုပ်တဲ့ အခါ Cluster အတွင်း အဆင်ပြေတဲ့ သင့်လျော်တဲ့ worker node တွေ အပေါ်မှာ scheduler အလိုကျ သို့ မဟုတ် user အလိုကျ deploy လုပ်ကြပါတယ်။ ဒါပေမဲ့ တချို့ use case တွေ အတွက် replicas count အလိုက် Cluster တစ်ခုလုံး အတွင်း ပျံ့နှံ့ deploy လုပ်ချင်တာ မျိုး မဟုတ်ဘဲ၊ cluster အတွင်း ရှိသမျှ node တိုင်း အတွက် (သို့) သီးခြား node အစုအဝေး များ အတွက် node တစ်ခု လျှင် pod တစ်ခု deploy ပြုလုပ်ချင်သည့် ပုံစံမျိုး ( ဥပမာ cluster အတွင်းရှိ node တိုင်းတွင် monitoring agent များ ကို pod အနေနဲ့ deploy ပြုလုပ်ခြင်း၊ log collector များကို pod တစ်ခု အနေနဲ့ deploy ပြုလုပ်ခြင်း စသည့် use case များ ) အတွက် kubernetes က DaemonSets Controller ကို Design ထုတ်ထား ခြင်း ဖြစ်တယ်။ ဒါကြောင့်မို့ DaemonSets တွေကို အများအားဖြင့် system level operations တွေ လုပ်ဆောင်တဲ့ infrastructure နဲ့ သက်ဆိုင်တဲ့ pod တွေကို deploy လုပ်ချင် တဲ့ အခါ မျိုးမှာ အသုံးပြုကြလေ့ ရှိပါတယ်။ DaemonSets သည် ReplicationControllers နဲ့ ReplicaSets တို့ နဲ့ အလုပ်လုပ်ပုံချင်း တူညီ ကြပြီး ခြားနားသည်မှာ replica count (.spec.replicas) ပါဝင်မှု မရှိခြင်း၊ replica count အစား node count အရေအတွက် ကိုသာ အသုံးပြုခြင်း၊ node တစ်ခု လျှင် pod တစ်ခုသာ deploy ပြုလုပ်ခြင်း နှင့် kubernetes ရဲ့ scheduler ကို skip/bypass လုပ်နိုင်ခြင်း (တချို့ အခြေအနေတွင် scheduler ကို ဂရုစိုက်မှုမရှိခြင်း) စသည်တို့ ဖြစ်သည်။
DaemonSets သည် ReplicaSets ကဲ့သို့ desired replica count မရှိ သော်လည်း desired state ကို node အပေါ်တွင် မူတည်ပြီး count လုပ်သည်။ node တစ်ခု cluster အထဲသို့ တိုးလာလျင် DaemonSet ၏ pod template \(spec.template.spec\) ထဲမှ pod တစ်ခု ကို တိုးလာသည့် node အသစ်ပေါ်တွင် အလို အလျောက် ချက်ချင်း တည်ဆောက်သွားပြီး DaemonSet ၏ selector \(.spec.selector\) ထဲတွင် ရှိသော label ဖြင့် node အသီးသီး ပေါ်တွင် ရှိသော သက်ဆိုင်ရာ pod များကို managed လုပ်ပေးသည်။ node အပေါ်တွင် ရှိ နေ သော pod များတွင် DaemonSet ၏ Selector ထဲမှာ ရှိသည့် label နဲ့ ကိုက်ညီမှု မရှိသည့် အခါ မှသာ DaemonSets ၏ pod template မှ ယူ၍ DaemonSet ၏ pod ကို ဆောက်ပေးမည် ဖြစ်သည်။ node တစ်ခုကို cluster မှာ remove လုပ်ခြင်း ဖြစ်စေ၊ node down သွားခြင်း ဖြစ်စေ၊ node အပေါ်တွင် ရှိသော DaemonSets ရဲ့ pod ကို တစ်ခြား node တစ်လုံး ပေါ်သို့ ပြန် reschedule လုပ်ပေး သွားခြင်း မရှိပေ၊ မည်သည့် အကြောင်းကြောင့်ဖြင့် ဖြစ်စေ cluster ထဲမှာ node မရှိတော့ သည့်အခါ ထို DaemonSets ၏ pod သည်လည်း ရှိတော့ မည် မဟုတ်ချေ။ DaemonSets ကို သီးခြား node group များ အတွက် pod template အထဲ တွင် node selector ထည့်၍ အသုံးပြုနိုင်မည်။ ဥပမာ kubernetes cluster ထဲတွင် worker node ၄ လုံးရှိပြီး ၃ လုံးတွင် ssd တပ်ဆင် အသုံးပြု တပ်ဆင်းထားပြီ ssd အတွက် ssd ရှိသည့် node များကို သီးခြား monitoring ပြုလုပ်ချင် သည့် အခါမျိုး အစရှိသည့် ပုံစံ များတွင် သုံးကြသည် သုံးနိုင်သည်။
Scheduler သည် pod (သို့) ReplicationController/ ReplicaSet/Deployment/etc .. အစ ရှိသည်တို့ မှ တည်ဆောက်သည့် pod များကို အရည်အသွေး (သို့) အခြေအနေ နှင့် ကိုက်ညီမှု မရှိသည့် node များ ပေါ်သို့ pod များ ကို schedule မလုပ်ပေးပါ၊ ရှိနေပြီသား pod များကို လဲ node အခြေအနေနဲ့ အဆင် မပြေသည့် အခါ တွင်လဲ unschedulable ပြုလုပ်နိုင်သည့် attribute ရှိသည်။ (နောက်ပိုင်းတွင် scheduler အကြောင်း ရေးဖို့ရှိသည်။ ယခု အခါ တွင်မှု မပြည့်စုံပါ) ထိုကဲ့သို့ တချို့ အဆင်မပြေသည့် node များ ပေါ်သို့ DaemonSet သာလျှင် scheduler ကို bypass ပြုလုပ် နိုင်ပြီး DaemonSet မှ managed လုပ်ထားသော pod များသာ ထို node ပေါ်တွင် deploy ပြုလုပ်နိုင်သည်။ ဘာကြောင့်လဲ ? DaemonSets သည် system services များ အတွက် အသုံးပြု ဖို့ Design ထုတ်ထားသောကြောင့် ဖြစ်သည်။ schedule မလုပ်နိုင်သည့် ပြဿနာ ရှိသော node များ တွင် system level operation များ (ဥပမာ monitoring / logging / networking related task /etc ...) တွင် DaemonSet ကို အသုံးပြုနိုင်သည်။
# Sample Simple YAML Manifest for DaemonSet
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: ssd-monitor
spec:
selector:
matchLabels:
app: ssd-monitor
template:
metadata:
labels:
app: ssd-monitor
spec:
nodeSelector:
disk: ssd
containers:
- name: main
image: quay.io/dther/ssd-monitorအပေါ်က manifest ကို ssd-monitor.yaml အနေနဲ့ save ပြီး kubectl create -f ssd-monitor.yaml command နဲ့ DaemonSet ကို create ပြုလုပ်နိုင်ပြီး အောက်တွင် ပြထားသည့် အတိုင်း kubectl get daemonset or kubectl get ds -A ဖြင့် cluster တစ်ခုလုံးတွင် ရှိသည့် DaemonSet တွေရဲ့ information ကို retrieve လုပ်ယူနိုင်ပါသည်။ -A သည် all namespace ကို ဆိုလိုသည် (နောက်ပိုင်းတွင် namespace အကြောင်း ဆက်ရေးရန် ရှိပါသည်) kubectl describe ds ssd-monitor command ဖြင့် လက်ရှိ DaemonSet ရဲ့ အခြေအနေ အသေးစိပ် များကို သိရှိနိုင်သည်၊ troubleshoot ပြုလုပ်ရတွင် လည်း အသုံးဝင်သည်။
[dther@opslab labcluster]$ kubectl get ds -A # -A for all namespace (later explain namespace)
NAMESPACE NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
kube-system calico-node 9 9 9 9 9 <none> 125d
kube-system kube-proxy 9 9 9 9 9 beta.kubernetes.io/os=linux 125d
kube-system ssd-monitor 3 3 3 3 3 disk=ssd 125d
kube-system nodelocaldns 9 9 9 9 9 <none> 125d
metallb-system speaker 9 9 9 9 9 beta.kubernetes.io/os=linux 125d[dther@opslab labcluster]$ kubectl describe ds ssd-monitor
Name: ssd-monitor
Selector: app=ssd-monitor
Node-Selector: disk=ssd
Labels: <none>
Annotations: deprecated.daemonset.template.generation: 1
Desired Number of Nodes Scheduled: 3
Current Number of Nodes Scheduled: 3
Number of Nodes Scheduled with Up-to-date Pods: 3
Number of Nodes Scheduled with Available Pods: 3
Number of Nodes Misscheduled: 0
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=ssd-monitor
Containers:
main:
Image: quay.io/dther/ssd-monitor
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 51s daemonset-controller Created pod: ssd-monitor-wfc8r
Normal SuccessfulCreate 51s daemonset-controller Created pod: ssd-monitor-495lg
Normal SuccessfulCreate 51s daemonset-controller Created pod: ssd-monitor-vvjcp
nodeSelector တွင် disk=ssd label ပါရှိသောကြောင့် node ၉ လုံးအနက် ssd label ရှိသော node ၃ လုံးတွင်သာ pod များကို DaemonSet က deploy လုပ်ပါတယ်။ -l disk=ssd နဲ့ -l app=ssd-monitor ကတော့ label ဖြင့် လိုချင်သည့် resource ရဲ့ object များကို ဆွဲရန် အတွက် ဖြစ်ပါသည်။ -o wide ကတော့ ပုံမှန် kubectl get pod ထက် ပိုမြင်ရတဲ့ output ကို ဖေါ်ပြသည့် output format တစ်ခု ဖြစ်ပါသည်။ -o wide တွင် run နေသည့် pod ၏ node,IP အစ ရှိသည်တို့ကို ပို၍မြင်ရသည်။
[dther@opslab labcluster]$ kubectl get node -l disk=ssd
NAME STATUS ROLES AGE VERSION
node7 Ready <none> 125d v1.15.3
node8 Ready <none> 125d v1.15.3
node9 Ready <none> 125d v1.15.3
[dther@opslab labcluster]$ kubectl get pod -l app=ssd-monitor -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
ssd-monitor-495lg 1/1 Running 0 10m 10.233.69.34 node8 <none> <none>
ssd-monitor-vvjcp 1/1 Running 0 10m 10.233.97.29 node9 <none> <none>
ssd-monitor-wfc8r 1/1 Running 0 10m 10.233.95.29 node7 <none> <none>