ခဏလေး ဒီလိုပဲ စဉ်းစားကြည့်
Control Plane က cluster ရဲ့ 'ဦးနှောက်' ပါ — API Server (command တွေကို လက်ခံသူ, ဟိုတယ် front desk လိုမျိုး), etcd (cluster state အားလုံးကို မှတ်ထားတဲ့ database), Scheduler (container ကို ဘယ် node ပေါ်မှာ run ရမလဲ ဆုံးဖြတ်သူ), Controller Manager (desired state ကို actual state နဲ့ ကိုက်ညီအောင် ကြည့်နေသူ) — ဒါတွေ အားလုံး ပါဝင်ပါတယ်။ Worker Node တွေကတော့ container တွေ တကယ် run နေတဲ့ server တွေပါ — node တစ်ခုစီမှာ kubelet (Control Plane ရဲ့ instruction ကို လက်ခံပြီး container run ပေးသူ) နဲ့ container runtime (Docker/containerd) ပါဝင်ပါတယ်။
လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
Restaurant chain analogy ဆက်ကြည့်ရအောင် — Control Plane က head office (branch ဘယ်နှစ်ခု ဖွင့်ရမလဲ, ဘယ် branch manager ဆုံးဖြတ်ချက်ချရမလဲ ဆုံးဖြတ်သူ) ပါ။ Worker Node တွေက branch တစ်ခုချင်းစီ (တကယ် customer ဝန်ဆောင်မှုပေးနေတဲ့ နေရာ) ပါ။ Kubectl (နောက် lesson မှာ လေ့လာမယ်) ကတော့ head office ကို instruction ပေးတဲ့ phone line ပါ — 'branch ၅ ခု ဖွင့်ပါ' လို့ ပြောလိုက်ရင် Control Plane က worker node တွေကို ခွဲဝေပေးပါတယ်။
အတူတူ ကြည့်မယ်
Kubernetes Cluster
===================
Control Plane (the "brain")
├── API Server — receives all kubectl commands
├── etcd — stores the entire cluster's state
├── Scheduler — decides which node runs what
└── Controller Manager — keeps actual state == desired state
Worker Nodes (where containers actually run)
├── Node 1: kubelet + container runtime + your pods
├── Node 2: kubelet + container runtime + your pods
└── Node 3: kubelet + container runtime + your podsControl Plane နဲ့ Worker Node ရဲ့ တာဝန်ကွာခြားချက်ကို ရှင်းပြနိုင်မည်။၅ မိနစ် စမ်းကြည့်
Node သုံးလုံးရှိတဲ့ cluster တစ်ခုမှာ Node 1 ရုတ်တရက် down သွားရင် ဘာဖြစ်မလဲ (Control Plane ဘာလုပ်မလဲ) ခန့်မှန်းပြီး ရေးကြည့်ပါ။
သတိလေးတစ်ချက်
Local learning (minikube/kind) မှာတော့ Control Plane နဲ့ Worker Node ကို VM/container တစ်ခုတည်းပေါ် ရောပြီး run ထားတတ်ပါတယ် — production cluster မှာတော့ ဒါတွေကို သီးခြား server တွေပေါ် ခွဲထားပါတယ်။