Container နှင့် Kubernetes ဘယ်နေရာမှာ ကိုက်ညီသလဲ

နားလည်ထားရမယ့် အချက်

Container တစ်ခုသည် app နှင့် dependency များကို portable unit တစ်ခုအဖြစ် ထုပ်ပိုးထားသည် — ထိုအပိုင်းကို Docker tutorial တွင် အသေးစိတ် ဖော်ပြထားပြီးဖြစ်ပြီး ဒီ lesson သည် သင့်တွင် run ရမည့် container တစ်ခု ရှိပြီးသားဟု ယူဆထားသည်။ ဒီမှာ မေးထားသည့် မေးခွန်းက ဘယ်နေရာတွင် run မည်နည်း ဆိုတာသာဖြစ်သည်။

အရိုးရှင်းဆုံးအချက်မှာ PaaS-style platform တစ်ခုပေါ်တွင် container တစ်ခုတည်းသာ run ခြင်းဖြစ်သည် — container image ကို push လိုက်ပြီး platform က run ခြင်း၊ restart ခြင်း၊ URL ပေးခြင်းတို့ကို orchestration ဗဟုသုတ လိုအပ်မှုနီးပါးမရှိဘဲ ကိုင်တွယ်ပေးသည်။

နောက်အချက်မှာ major cloud provider ပေါ်ရှိ managed container service ဖြစ်သည် — ဆက်လက်ပြီး managed ဖြစ်နေသော်လည်း configuration surface ပိုများသည် — scaling rule၊ networking၊ resource limit တို့ကို PaaS ရိုးရိုးထက် ပိုတိကျစွာ ချိန်ညှိနိုင်သော်လည်း setup ပိုမိုလုပ်ရန်နှင့် concept ပိုသင်ယူရန် လိုအပ်သည်။

အဝေးဆုံးအချက်မှာ Kubernetes cluster အပြည့်အစုံဖြစ်ပြီး scheduling၊ networking၊ scaling၊ service အများအပြား orchestration အပေါ် control အများဆုံးပေးသော်လည်း operational expertise အများဆုံးလည်း တောင်းဆိုသည်။

Complexity ကို တုံ့ပြန်မှုအဖြစ် ရွှေ့ပါ၊ default မဟုတ်ပါ

Progression ပေါ်တွင် ညာဘက်သို့ ရွေ့လျားခြင်းသည် သင်တကယ်ကြုံခဲ့ရသော complexity အပေါ် တုံ့ပြန်မှုဖြစ်သင့်ပြီး default choice မဖြစ်သင့်ပါ။ Kubernetes tutorial တွင် orchestration အသေးစိတ်ကို အပြည့်အစုံ ဖော်ပြထားပြီး ဒီ lesson သည် container တစ်ခု ဘယ်နေရာတွင် run သင့်သလဲ ဆုံးဖြတ်ခြင်းအကြောင်းသာဖြစ်သည်။

text

CONTAINER PLATFORM PROGRESSION
------------------------------
SIMPLEST                                          MOST COMPLEX
   |                                                    |
   v                                                    v
SINGLE CONTAINER   -->  MANAGED CONTAINER   -->   KUBERNETES
   ON A PaaS              SERVICE (cloud)           CLUSTER

  push image           more config surface       most control,
  platform handles      (scaling, network,        most ops skill
  run/restart/url        resource limits)          required

  fits: 1 app,          fits: a few services,     fits: dozens of
  small/med traffic      finer scaling control     interdependent
                                                    services, real
                                                    orchestration need

  MOVE RIGHT ONLY WHEN COMPLEXITY YOU HIT DEMANDS IT

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

Team 1: web service တစ်ခုတည်း၊ traffic သိပ်မများ၊ dedicated ops person မရှိ — PaaS-style platform ကိုက်ညီသည်
Team 2: service သုံးခု အချင်းချင်း ဆက်သွယ်ရသည်၊ traffic ရုတ်တရက် spike ဖြစ်တတ်သည်၊ autoscaling ကို ပိုတိကျစွာ ထိန်းချုပ်ချင်သည် — managed container service ကိုက်ညီသည်
Team 3: service ဒါဇင်ချို့ အချင်းချင်း ချိတ်ဆက်နေသည်၊ coordinated scaling လိုအပ်သည်၊ cluster operations နားလည်သူများ ရှိပြီးသား — Kubernetes သည် တရားဝင် case ဖြစ်သည်

Progression သည် abstract အားဖြင့် ဘယ် platform က 'အကောင်းဆုံး' လဲဆိုတာမဟုတ်ပါ — operational complexity ကို တကယ့်လိုအပ်ချက်နှင့် ကိုက်ညီအောင် ချိန်ညှိခြင်းသာဖြစ်သည်။ Team 1 အတွက် Kubernetes ကနေ စတင်ခြင်းသည် ပြသရန် ဘာမှမရှိဘဲ operational weight တကယ်ထမ်းရန် ဖြစ်လိမ့်မည်။ Team 3 အတွက် PaaS ရိုးရိုးကနေ စတင်ခြင်းသည် ပလက်ဖောင်းရဲ့ ကန့်သတ်ချက်များနှင့် နေ့တိုင်းတိုက်ခိုက်နေရမည့် ဖြစ်ရပ်ဖြစ်လိမ့်မည်။

Container ကို run ရန် PaaS -> managed container service -> Kubernetes ဆိုသော progression သုံးဆင့်ရှိသည်
ညာဘက်သို့ ရွေ့လျားခြင်းသည် control ပိုရသော်လည်း operational complexity ပိုတောင်းသည်
Kubernetes ကို default choice မဟုတ်ဘဲ တကယ်ကြုံခဲ့ရသော orchestration complexity အပေါ် တုံ့ပြန်မှုအဖြစ် ရွေးချယ်သင့်သည်

အတူတူ စမ်းရေးကြည့်မယ်

javascript

function recommendContainerPlatform(workload) {
  const {
    numberOfServices = 1,
    needsAutoscaling = false,
    needsComplexOrchestration = false,
    teamHasOpsExpertise = false,
  } = workload;

  // Real orchestration needs plus the expertise to run them: Kubernetes is justified.
  if (needsComplexOrchestration && numberOfServices > 5 && teamHasOpsExpertise) {
    return "kubernetes-cluster";
  }

  // Several services or finer scaling control, but not full orchestration complexity yet.
  if (numberOfServices > 1 || needsAutoscaling) {
    return "managed-container-service";
  }

  // A single service with modest needs: start simple.
  return "single-container-on-paas";
}

const examples = [
  { name: "Solo dev, one API service", workload: { numberOfServices: 1 } },
  { name: "Startup, 3 services, wants finer autoscaling", workload: { numberOfServices: 3, needsAutoscaling: true } },
  { name: "Platform team, 12 services, real orchestration need, has SREs", workload: { numberOfServices: 12, needsComplexOrchestration: true, teamHasOpsExpertise: true } },
];

for (const ex of examples) {
  console.log(ex.name, "->", recommendContainerPlatform(ex.workload));
}

You should see

Solo dev, one API service -> single-container-on-paas
Startup, 3 services, wants finer autoscaling -> managed-container-service
Platform team, 12 services, real orchestration need, has SREs -> kubernetes-cluster

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

'12 services ရှိသော်လည်း teamHasOpsExpertise: false' ဖြစ်သော workload တစ်ခုကို ထည့်ကြည့်ပြီး ဘာအကြံပြုချက်ရလာသလဲ၊ ဘာကြောင့်ဒါက အလုံးစုံအတွက် ကောင်းသလဲ စဉ်းစားပါ

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

Kubernetes ကို 'အဆင့်မြင့်ဆုံး' ဖြစ်လို့ default ရွေးချယ်မှုအဖြစ် သတ်မှတ်ခြင်း

Managed container service ကို ကျော်ပြီး PaaS ရိုးရိုးနှင့် Kubernetes ကြားတွင် ရွေးစရာမရှိဟု ထင်ခြင်း

Kubernetes docs: Overview — Cloud Providers & Platforms