Kubernetes Architecture and Fundamentals

ဒီအပတ်မှာတော့ Kubernetes ရဲ့ Architecture မှာ ဘာတွေပါဝင်လဲ။ ပါဝင်တဲ့ အရာတွေက ဘယ်လိုအလုပ်လုပ်လဲ ဆိုတာမျိုးတွေကိုရေးပါမယ်။

ဆိုတော့ ပုံမှာ မြင်ရတဲ့ အတိုင်း Kubernetes ရဲ့ Architecture မှာ Master Node ပါမယ်။ Worker Node ပါမယ်။ Master Node အရေအတွက် နဲ့ Worker Node အရေအတွက်ကတော့ Availability လိုအပ်ချက်အရ အမျိုးမျိုးကွဲပြားနိုင်ပါတယ်။ ယေဘုယျအားဖြင့် Master Node နဲ့ worker Node ပါဝင်တယ်လို့သိနိုင်ပါတယ်။ ဟုတ်ပြီ ဒါဆိုဒီနေရာမှာ ပြောစရာက Node ဆိုတာဘာလဲ။ Master Node နဲ့ Worker Node ကရောဘာလဲ။ သူတို့မှာဘာ Components တွေပါဝင်ပြီး တစ်ခုချင်းစီက ဘာတွေလုပ်ကြလဲဆိုတာဆက်ပြောပါမယ်။

Node

Node ဆိုတာက တော့ physical ဒါမှမဟုတ် Virtual Machine တစ်ခုခုကိုဆိုလိုတာပါ။ Containers တွေ Run တဲ့နေရာပေါ့။ အဲလို Run နိုင်ဖို့ Docker, Containerd, or CRI-O စသဖြင့် Container Runtime တစ်ခုခုရှိရပါမယ်။ Nodes တွေထဲမှာမှ Woker Nodes တွေတစ်ခုချင်းစီကို Manage လုပ်တာကတော့ Master Node(s) ပါ။

Master Node

Control Plane လို့လည်းခေါ်ပါတယ်။ API Server, Schedular, Controller Manager, ETCD စတဲ့ Main Componentsတွေ ပါဝင်ပါတယ်။ Kubelet, Kube-proxy, Container Runtime တို့လည်းရှိရပါမယ်။

Worker Node

Application Workloads(pods) တွေ အမှန်တကယ် run တဲ့နေရာပါ။ Kubelet, Kube-proxy, Container Runtime စတဲ့ Components တွေပါဝင်ပါတယ်။

ဒီနေရာမှာ ပြောချင်တာက

• Master Node ပေါ်က Kubelet က Master Node မှာပါဝင်တဲ့ Components တွေကို pods တွေအဖြစ်နဲ့ run ပါတယ်။
• Worker Node ပေါ်က Kubelet ကတော့ Master Node ပေါ်မှာရှိတဲ့ API Server ကနေလာတဲ့ Instruction ပေါ်မူတည်ပြီး Application Pods တွေကို Create, Delete, Update စသဖြင့် Action ယူပေးတာပါ။
• Master Node ပေါ်မှာ User Pods (Application Pods) တွေကို မ Run ပါဘူး။ များသောအားဖြင့် ဒီ Application Workloads(pods) တွေက Worker Nodes တွေပေါ်မှာပဲရှိပါတယ်။

Pods

Pod ဆိုတာကတော့ Kubernetes မှာ Smallest Deployable Unit လို့လည်းခေါ်ပါတယ်။ သူ့မှာ Container အနည်းဆုံးတစ်လုံး ဒါမှမဟုတ် တစ်လုံးထက်ပိုပြီး Group လိုက်လည်းပါဝင်နိုင်ပါတယ်။ Pod မှာပါတဲ့ Containers တွေက Storage Volumes နဲ့ Network ကို အတူ Share ပြီးသုံးပါတယ်။

Controlplane components

API Server

Kubernetes Cluster ထဲကို ဝင်လာတဲ့ Request အားလုံးရဲ့ Entrance ဒါမှမဟုတ် Main Gate ဖြစ်ပါတယ်။ Authentication, Validation, Request Forwarding စတာတွေကို လုပ်ပါတယ်။ ETCD နဲ့ တိုက်ရိုက်ထိတွေ့တဲ့ တစ်ခုတည်းသော Component လည်းဖြစ်ပါတယ်။

Schedular

Pod ကို ဘယ် Node မှာ Run မလဲ ဆုံးဖြတ်ပေးပါတယ်။ CPU, RAM, Storage တွေနဲ့ တခြားသော Constraints တွေကိုကြည့်ပြီး သင့်တော်တဲ့ Node ကိုရွေးပါတယ်။

Controller Manager

Deployment Controller, Node Controller, Namespace Controller စတဲ့ Controllers တွေကို Monitoring နဲ့ Self-healing လုပ်ပေးပါတယ်။ ဆိုလိုချင်တာက cluster မှာရှိနေတဲ့ အရာအားလုံးကို up and running ဖြစ်နေရဲ့လားဆိုတာ သေချာအောင်လုပ်ပါတယ်။ Pod down သွားရင် ပြန် run ပေးတယ်။ Desired state ကို Actual state ဖြစ်အောင် continuous reconcile လုပ်ပါတယ်။

ETCD

Cluster state နဲ့ configuration ကို သိမ်းထားတဲ့ key-value database ဖြစ်တယ်။ ပြောရရင် cluster ထဲမှာရှိနေတဲ့ info အားလုံးကို etcd ထဲမှာ metadata အနေနဲ့ သိမ်းထားပါတယ်။ changes ရှိလာရင်ရှိလာသမျှပေါ့။ ရှေ့မှာပြောခဲ့သလိုပဲ API server ကသာ etcd ကို read/write လုပ်နိုင်ပါတယ်။

Worker components

kubelet

API server ကပေးတဲ့ instruction ကို worker node မှာ တကယ် actionယူပြီး လုပ်ပေးတဲ့ agentလို့နားလည်နိုင်ပါတယ်။ Example ပေးရရင် အလုပ်ရှင် နဲ့ အလုပ်သမား လိုပါပဲ။ အလုပ်ရှင်က အလုပ်သမားကို ဘယ်နေရာမှာ ဘာလုပ်လိုက်ပါ ဆိုပြီး instruction ပေးတာပါ။ သူကိုယ်တိုင် အဲ့အလုပ်ကိုဝင်မလုပ်ပါဘူး။ အလုပ်သမားက လုပ်ရပါတယ်။ အလုပ်ရှင်ကတော့ top level က သူ့အလုပ်တွေပဲသူလုပ်ပါတယ်။ API server နဲ့ kubelet ကလည်း ဒီသဘောပါပဲ။ Kubelet က Pod create/delete/update လုပ်တာတွေကို actual node မှာ run မယ်။ ပြီးရင် ပြန်ပြီး report လုပ်ပါတယ်။

kube-proxy

Pod တွေ တစ်ခုနဲ့တစ်ခုကြား Pod နဲ့ service တွေကြား အပြန်အလှန် communicate လုပ်လို့ရအောင် networking rules တွေကို manage လုပ်ပေးပါတယ်။

component တစ်ခုချင်းစီရဲ့ responsibilities နဲ့ အခြေခံရည်ရွယ်ချက် တွေကိုသိသွားပြီဆိုတော့ workflow လေးနဲ့ ပြန်ပြီး recap လုပ်ပါမယ်။

1. kubectl (kubernetes client) ဆီက နေ Pod create ဖို့ request တစ်ခုက API server ပေါ်ကိုရောက်လာတယ်ဆိုပါစို့။
2. API server ကနေ authentication, validation တွေလုပ်မယ်။
3. ETCD မှာ အရင်ဆုံး data ကို store လုပ်မယ်။
4. Schedular က Pod create ဖို့လိုနေပြီဆိုတာ သိသွားပြီး သင့်တော်တဲ့ Node ကိုရှာမယ်။ ရလာရင် API server ဆီပြန်ပြောမယ်။
5. API server ကနေမှ worker node တွေပေါ်မှာရှိတဲ့ kubelet ကို command ပေးမယ်။ အဲကနေမှ လိုအပ်တဲ့ တကယ့်အလုပ်တွေကို kubelet ကတကယ်လုပ်ပြီး api server ကို ပြန် report မယ်။
6. နောက်ဆုံး client ဆီကို api server ကနေမှ create ပြီးကြောင်း ပြန် inform တယ်။ ဒီသဘောပါ။

Create တာမဟုတ်ဘဲ Update တာ Retrieve တာတွေလည်း ဒီသဘောပါပဲ။ New changes တစ်ခုခု ရှိရင် ဒါကို အမြဲစောင့်ကြည့်နေတဲ့ controller manager ကနေသိပြီး Desired state က actual state ဖြစ်မနေရင် ဖြစ်အောင်လုပ်မယ်။ Pod list တာမျိုး ဆိုရင်လည်း API server ကနေ ETCD မှာ Data retrieve ပြီး client ဆီ ပြန်ပြောပါတယ်။

ဒီလောက်ဆို kubernetes ရဲ့ architecture ဘယ်လိုရှိလဲ၊ ပါဝင်တဲ့ components တွေနဲ့ တစ်ခုချင်းရဲ့ roles and responsibilites တွေကို သိသွားပြီဖြစ်ပါတယ်။ နောက်အပတ် သောကြာနေ့မှာလည်း Kubernetes မှာ Containers တွေက ဘာလို့ Pod ထဲမှာနေပြီး Run လည်းဆိုတဲ့အကြောင်းနဲ့ Pods တွေကို ဘယ်လို Deploy လဲ ဆိုတဲ့ အကြောင်းကိုရေးပါမယ်။