Namespaces

စိတ်လျှော့ပါ။ ဒီခန်းကို စာအုပ်လိုမဟုတ်ဘဲ စကားပြောသလိုပဲ၊ နားလည်လွယ်အောင် ရှင်းပါမယ်။

ခဏလေး ဒီလိုပဲ စဉ်းစားကြည့်

Cluster ကြီးတစ်ခုမှာ team အများကြီး app အများကြီး run နေရင် resource name တွေ collide ဖြစ်နိုင်ပါတယ် (team နှစ်ခုလုံးက 'database' လို့ deployment နာမည်ပေးထားရင်)။ Namespace က virtual cluster လိုမျိုးပါ — namespace တစ်ခုစီထဲမှာ resource name တွေ unique ဖြစ်ရင် လုံလောက်ပါတယ် (namespace အချင်းချင်း တူနိုင်ပါတယ်)။ Default ဖြင့် `default` namespace ထဲမှာ resource တွေ create ဖြစ်ပါတယ် — `kube-system` က Kubernetes ကိုယ်တိုင် internal component တွေ run တဲ့ namespace ပါ။

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Team တွေ ခွဲချင်ရင် `dev`, `staging`, `production` ဆိုပြီး namespace သုံးခု create လုပ်ပြီး, environment တစ်ခုစီအတွက် Deployment/Service ကို namespace သတ်သတ်ထဲမှာ deploy ပါတယ် — `kubectl apply -f app.yaml -n staging` ဆိုတာမျိုးပါ။ Namespace တစ်ခုချင်းစီအတွက် resource quota (CPU/memory limit) ချထားလို့ရပါတယ် — team တစ်ခုက resource အကုန်စားသွားပြီး team တခြားကို ထိခိုက်စေတာမျိုး ကာကွယ်နိုင်ပါတယ်။

Namespace = cluster အတွင်း resource logical group ခွဲထားခြင်း
Namespace အချင်းချင်း resource name တူနိုင်ပါတယ် (collision မဖြစ်)
Environment (dev/staging/prod) ခွဲဖို့ namespace အသုံးများပါတယ်

အတူတူ ကြည့်မယ်

bash

# Create a namespace
kubectl create namespace staging

# Deploy into a specific namespace
kubectl apply -f app.yaml -n staging

# List resources in a namespace
kubectl get pods -n staging

# See all namespaces
kubectl get namespaces

You should see

NAME              STATUS   AGE
default           Active   10d
kube-system       Active   10d
staging           Active   5s

၅ မိနစ် စမ်းကြည့်

`staging` namespace တစ်ခု create လုပ်ပြီး web-deployment ကို အဲဒီ namespace ထဲမှာ deploy ကြည့်ပါ (`-n staging` ထည့်ပေးရမည်) — `default` namespace ရဲ့ pod တွေနဲ့ ခွဲထားတာ တွေ့ရမှာပါ။

သတိလေးတစ်ချက်

Namespace က network isolation ကိုတော့ default ဖြင့် မပေးပါ — namespace ကွာနေတဲ့ pod တွေအချင်းချင်း default အားဖြင့် ဆက်သွယ်လို့ ရနေဆဲပါ (NetworkPolicy ထားမှ တားနိုင်ပါတယ်)။