“ဒါက Development issue ပါ။”

“Code ကတော့ အဆင်ပြေပါတယ်။ Infrastructure issue ပါ။”

“QA မှာတုန်းက pass ဖြစ်ပါတယ်။”

“Requirement က ဒီလိုပေးထားတာပါ။”

“Security rule ကြောင့်ဖြစ်တာပါ။

ဒီအကြောင်းပြချက်တွေက technical perspective ကနေကြည့်ရင် မှန်ကောင်းမှန်နိုင်ပါတယ်။

ဒါပေမယ့် Incident ဖြစ်တိုင်း “ဘယ် Team ရဲ့အမှားလဲ?” ဆိုတာကိုပဲ ရှာနေကြပြီဆိုရင် Technical Problem တစ်ခုတည်း မဟုတ်တော့ပါဘူး။ Engineering Culture ရဲ့ Problem တစ်ခု ဖြစ်လာပါတယ်။

Production is a shared responsibility

Production Application တစ်ခုကို Development Team တစ်ခုတည်းက တည်ဆောက်ထားတာ မဟုတ်ပါဘူး။

Development က application ကို တည်ဆောက်တယ်။ QA က quality ကို စစ်ဆေးတယ်။ DevOps/SRE က deployment, infrastructure နဲ့ reliability ကို ထိန်းသိမ်းတယ်။ Security က system ကို ကာကွယ်တယ်။ Product/Management က requirements နဲ့ priorities ကို သတ်မှတ်တယ်။

ဒါကြောင့် Service တစ်ခုရဲ့ success ဟာ Team အားလုံးရဲ့ success ဖြစ်သလို failure ဖြစ်လာတဲ့အခါမှာလည်း Team တစ်ခုတည်းကို အပြစ်ပုံချလို့ မရပါဘူး။

ဒါကြောင့် Shared Responsibility ဆိုတာ Team တိုင်းမှာတာဝန်ရှိတယ်လို့ ဆိုလိုရင်းဖြစ်ပါတယ်။

Team တိုင်းမှာ ကိုယ့်အပိုင်းအတွက် clear ownership and accountability ရှိရပါမယ်။

Developer တစ်ယောက်အတွက် code merge လုပ်ပြီးတာနဲ့ ownership ဆိုတာမပြီးသွားပါဘူး။ Production မှာ issue ဖြစ်လာရင် troubleshooting နဲ့ resolution မှာ ပါဝင်ဖို့လိုပါတယ်။

QA အတွက် “Testing မှာ pass ဖြစ်တယ်” ဆိုတာနဲ့ မပြီးပါဘူး။ ဘာကြောင့် ဒီ scenario ကို မဖမ်းမိခဲ့တာလဲ၊ test coverage ဘယ်နေရာမှာ တိုးတက်ဖို့လိုသလဲ ပြန်ကြည့်ဖို့လိုပါတယ်။

DevOps/SRE အတွက်လည်း “Application issue ပါ” ဆိုပြီး ticket လွှဲပေးလိုက်တာနဲ့ မပြီးပါဘူး။ Infrastructure, logs, metrics, deployment history နဲ့ resource utilization တွေကနေ evidence ရှာပြီး resolution ရတဲ့အထိ ပူးပေါင်းဖို့လိုပါတယ်။

Security အတွက်လည်း “Policy အရ block ထားတာပါ” ဆိုတာနဲ့ မပြီးပါဘူး။ Security requirement ကို မလျှော့ဘဲ Business နဲ့ Application ဆက်လက်အလုပ်လုပ်နိုင်မယ့် solution ကို အတူရှာဖို့လိုပါတယ်။

Blameless doesn't mean accountability-free

ဒီနှစ်ခုကို မရောထွေးဖို့ အရေးကြီးပါတယ်။

Blameless Culture ≠ No Accountability

Blameless ဆိုတာ အမှားလုပ်သူကို ရှာပြီး အပြစ်ပေးဖို့မဟုတ်တာပါ။

Accountability ဆိုတာတော့ ကိုယ့်အပိုင်းမှာ ဖြစ်ခဲ့တာကို လက်ခံပြီး ပြင်ဆင်ဖို့၊ သင်ယူဖို့နဲ့ ထပ်မဖြစ်အောင် တိုးတက်အောင်လုပ်ဖို့ ဖြစ်ပါတယ်။

Incident တစ်ခုမှာ—

“Who caused this?” ဆိုတာ ထက် “What failed, how do we recover, and how do we prevent it from happening again?” ဆိုတာကို အရင်မေးသင့်ပါတယ်။

Leadership plays an important role

Blame Culture ဖြစ်လာခြင်းဟာ Engineers တွေရဲ့ ပြဿနာတစ်ခုတည်း မဟုတ်ပါဘူး။

လူတစ်ယောက် အမှားလုပ်တိုင်း အပြစ်ပေးခံရမယ့် Environment ဖြစ်နေမယ်ဆိုရင် Engineers တွေက naturally ကိုယ့်ကိုယ်ကို ကာကွယ်ဖို့ ကြိုးစားလာကြပါတယ်။

အဲဒီအခါ အမှားကို ဝန်ခံတာထက် အခြား Team ကို လွှဲချတာ၊ problem ကို ဖုံးကွယ်တာ၊ risky decisions မယူရဲတာတွေ ဖြစ်လာနိုင်ပါတယ်။

ဒါကြောင့် Leadership ရဲ့ တာဝန်က Accountability ကို တောင်းဆိုရင်း Psychological Safety ကိုပါ တည်ဆောက်ပေးဖို့ ဖြစ်ပါတယ်။

“Who made the mistake?” လို့ မေးတာထက်—

What happened?

ဖြစ်စဉ်တစ်ခုလုံးကို အချက်အလက်တွေအပေါ် အခြေခံပြီး နားလည်အောင် အရင်လေ့လာသင့်ပါတယ်။

What allowed it to happen?

လူတစ်ယောက်ရဲ့ အမှားကိုပဲ ရှာဖွေမယ့်အစား System, Process နဲ့ Control တွေထဲမှာ ဘာတွေလိုအပ်နေခဲ့သလဲဆိုတာ ရှာဖွေသင့်ပါတယ်။

Why didn't we detect it earlier?

Monitoring, Alerting, Testing နဲ့ Observability တွေမှာ ဘာတွေတိုးတက်ဖို့လိုသလဲ ပြန်လည်သုံးသပ်သင့်ပါတယ်။

How can we recover faster next time?

Recovery Process, Rollback Plan, Automation နဲ့ Incident Response Process တွေကို ပိုကောင်းအောင် ပြင်ဆင်သင့်ပါတယ်။

What should we change in our system or process?

Incident ကနေ ရရှိခဲ့တဲ့ သင်ခန်းစာတွေကို လက်တွေ့ကျတဲ့ Improvement Actions တွေအဖြစ် ပြောင်းလဲသင့်ပါတယ်။

Who owns the improvement action?

Action Item တစ်ခုချင်းစီအတွက် ရှင်းလင်းတဲ့ Owner နဲ့ သတ်မှတ်ထားတဲ့ အချိန်ကာလ ရှိသင့်ပါတယ်။

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

Strong teams don't avoid failure. They learn from it.

High-performing Engineering Team ဆိုတာ Incident မဖြစ်တဲ့ Team မဟုတ်ပါဘူး။

Incident ဖြစ်လာတဲ့အခါ တစ်ယောက်နဲ့တစ်ယောက် အပြစ်မလွှဲချဘဲ ကိုယ့်အပိုင်းကို ကိုယ်တာဝန်ယူပြီး အတူတူဖြေရှင်းနိုင်တဲ့ Team ဖြစ်ရပါမယ်။

ပြီးတော့ Incident ပြီးသွားတဲ့အခါ—

“Fixed.” ဆိုတဲ့နေရာမှာမရပ်ဘဲ — “What did we learn, and what are we changing?” ဆိုတာကို ဆက်မေးနိုင်တဲ့ Team ဖြစ်ရပါမယ်။

နောက်ဆုံးမှာ ကျွန်တော်တို့ တည်ဆောက်ချင်တာက Blame Culture မဟုတ်ဘဲ Ownership Culture ဖြစ်သင့်ပါတယ်။

Own your part. Support the team. Fix the system. Learn from the failure.

ကောင်းမွန်တဲ့ Engineering Culture ဆိုတာ ဘယ်သူ့ကို အပြစ်တင်ရမလဲဆိုတာ ရှာဖွေနေတာ မဟုတ်ပါဘူး။ Team အားလုံး အတူတကွ တာဝန်ယူပြီး ပူးပေါင်းလုပ်ဆောင်နိုင်တဲ့ Culture တစ်ခုကို တည်ဆောက်ခြင်းပဲ ဖြစ်ပါတယ်။

#EngineeringCulture #Accountability #Ownership #Teamwork

ဒါပေမယ့် Organization ကြီးလာတာနဲ့အမျှ Team members တွေ ပိုများလာပြီး၊ AWS Accounts, Environments, Projects နဲ့ Infrastructure resources တွေလည်း တဖြည်းဖြည်း များပြားလာပါတယ်။ ဒီအချိန်မှာ Terraform ကို တစ်ဦးချင်း သို့မဟုတ် Team အတွင်းမှာသာ ရိုးရိုးအသုံးပြုတဲ့ပုံစံကနေ ကျော်လွန်ပြီး Infrastructure changes တွေကို ဘယ်လို Manage မလဲ၊ Review နဲ့ Approval ကို ဘယ်လို Control လုပ်မလဲ၊ Deployment ကို ဘယ်လို Automate လုပ်မလဲ ဆိုတဲ့ ပြဿနာတွေ ပေါ်လာနိုင်ပါတယ်။

Terraform ကိုယ်တိုင်မှာ environment များစွာအတွက် code reuse ကို ကောင်းကောင်း handle လုပ်ပေးတဲ့ native mechanism မရှိပါဘူး။ VPC module တစ်ခုကို dev, staging, prod သုံးခုစလုံးမှာ သုံးမယ်ဆိုပါစို့။ terraform workspace ဆိုတာ ရှိပေမယ့် ဒါက variable value ကိုပဲ ကွဲပြားစေတာမျိုးဖြစ်ပြီး၊ backend configuration၊ provider version၊ module source version စတာတွေကို environment အလိုက် သီးခြားစီမံဖို့ မလုံလောက်ပါဘူး။ လက်တွေ့မှာ team တွေက folder သုံးခုစီကို .tf file တွေ manually copy ချထားကြတယ်။ အကယ်၍များ VPC module ထဲမှာ bug fix တစ်ခု လိုအပ်လာရင် folder သုံးခုလုံးကို လိုက်ပြင်ရတယ်။ တစ်နေရာမှာသာမေ့သွားခဲ့ရင် environment တွေအကြား config drift တွေဖြစ်လာနိုင်ပါတယ်။

နောက်ထပ် Terraform CLI ကိုယ်တိုင်မှာ production ပြောင်းမယ်ဆိုရင် approval နှစ်ဆင့်လိုမယ် ဆိုတဲ့ governance concept မပါဝင်ပါဘူး။ ဥပမာ အနေနဲ့ Engineer တစ်ယောက်က production RDS instance ကို resize လုပ်ချင်လို့ သူ့ရဲ့laptop ကနေ terraform apply ဆိုပြီး run လိုက်ရုံနဲ့ production ချက်ချင်းပြောင်းသွားနိုင်တယ်။ code review, PR approval, second-person-sign-off ဘာမှကိုမလိုအပ်ဘူး။ ဘယ်သူကတော့ ဘယ်အချိန်မှာ ဘာပြောင်းခဲ့လဲ ဆိုတဲ့ audit trail ကို မသိနိုင်ဘူး။

ဒီလိုမျိုး Scale ကြီးလာတဲ့ Environment မှာ ကြုံတွေ့ရနိုင်တဲ့ Challenges တွေကို ဖြေရှင်းဖို့အတွက် Terragrunt, Atlantis နဲ့ AWX တို့ကို သုံးရခြင်းပဲဖြစ်ပါတယ်။

Terragrunt

Terragrunt က Terraform ကို replace လုပ်တာမဟုတ်ပါဘူး။ Terraform အပေါ်မှာ orchestration layer တစ်ခုအနေနဲ့ အသုံးပြုတယ့် configuration wrapper tool တစ်ခုပဲဖြစ်ပါတယ်။ သူရဲ့အဓိက ဖြေရှင်းပေးတဲ့ ပြဿနာက code duplication ပါ။ ဥပမာအနေနဲ့ - VPC module တစ်ခုကို dev, staging, prod သုံးခုစလုံးမှာ သုံးမယ်ဆိုပါစို့။ Terragrunt မပါဘဲဆိုရင် folder သုံးခုစီမှာ Terraform code တွေ တူတူထပ်ရေးရမှာပါ။ ဒါပေမယ့် Terragrunt ကတော့ VPC module ရဲ့ actual logic ကို modules repo တစ်ခုတည်းမှာပဲ ထားလိုက်ပြီး၊ terragrunt.hcl file တစ်ခုစီက ဒီ module ကို point လုပ်ပြီး variable တွေကိုပဲ ကွဲပြားအောင် ပေးလိုက်တာပါ။ Root level terragrunt.hcl တစ်ခုမှာ S3 backend, DynamoDB lock table, provider configuration စတာတွေကို တစ်ခါတည်း define လုပ်ထားလို့ရပါတယ်။ Environment အသစ်ထပ်ချင်ရင် folder အသစ်တစ်ခုဆောက်ပြီး variable ပဲ ချိန်ရုံပါပဲ။

Atlantis

Terragrunt က code structure ကို ကောင်းအောင် စီစဉ်ပေးပေမယ့်၊ ဘယ်သူက ဘယ်အချိန် apply လုပ်လို့ရလဲ ဆိုတဲ့ ပြဿနာကို မဖြေရှင်းနိုင်သေးပါဘူး။ ဒါကို Atlantis က handle လုပ်ပေးတယ်။ example အနေနဲ့ Engineer တစ်ယောက်က production RDS instance size ကို db.t3.medium ကနေ db.r5.large ပြောင်းချင်တယ်ဆိုပါစို့။

• Git Repo ထဲကterragrunt.hcl ထဲက instance class ကို ပြောင်းပြီး Pull Request တင်မယ်။

• GitHub/GitLab webhook နဲ့ ချိတ်ဆက်ထားတဲ့ Atlantis က PR ကို auto-detect လုပ်ပြီး terraform plan ကို automatic run လုပ်ပေးတယ်။

• Plan output ကို PR comment အနေနဲ့ ပြန်တင်ပေးတယ် — DevOps or SRE က ဒီ plan ကို review လုပ်လို့ရတယ်။ Approve လုပ်လိုက်မှသာ atlantis apply ဆိုတဲ့ comment ရေးမှသာ actual apply ဖြစ်ပါတယ်။ Atlantis က state lock ကို automatic handle လုပ်ပေးလို့ engineer နှစ်ယောက် တစ်ပြိုင်တည်း run လုပ်လို့ conflict ဖြစ်စရာ မရှိတော့ဘူး။

ဒါကတော့ Terraform apply process ထဲကို code review + approval workflow + audit log ကို ထည့်ပေးလိုက်တာပါ။ Compliance အတွက်လည်း ဘယ်သူက ဘာပြောင်းခဲ့လဲ ဆိုတာကို Git history ထဲမှာပဲ တွေ့နိုင်ပါတယ်။

AWX

Terragrunt နဲ့ Atlantis ပေါင်းလိုက်ရင် infrastructure provisioning (VPC, EC2, RDS ဆောက်တာ) ကို ကောင်းကောင်းစီမံနိုင်ပါပြီ။ ဒါပေမယ့် infrastructure ဆောက်ပြီးတာနဲ့ အလုပ်မပြီးသေးပါဘူး — server တွေထဲမှာ ဆက်လက်လုပ်ဆောင်ရမယ့် operational tasks တွေ ရှိသေးတယ်။ Terraform ဆိုတာ declarative provisioning tool ဖြစ်တဲ့အတွက် ongoing config management၊ ad-hoc task execution တွေအတွက် design မလုပ်ထားပါဘူး။ ဒါကြောင့် ဒီနေရာမှာ AWX (Ansible Tower open-source version) ဝင်လာတာပါ။ Terragrunt/Atlantis က EC2 instances ၂၀ လုံးကို provision လုပ်ပြီးပြီဆိုပါစို့။ ခုနောက်ထပ် လိုအပ်တာတွေက:

• Application code deployment

• Nginx config update, SSL certificate renewal

• Security patch apply

• Database backup script run

စတာတွေကို AWX ကို web UI ကနေ Ansible playbooks တွေကို schedule/trigger လုပ်ပါတယ်။

အပေါ်မှာ tools အကြောင်းတွေကို ရှင်းပြပြီးပြီဆိုတော့ ဒီတစ်မှာ code repository structure ကိုပြောချင်ပါတယ်။ Infrastructure နဲ့ Application code အားလုံးကို Repository တစ်ခုတည်းထဲမှာ ထည့်ထားမယ့်အစား Responsibility အလိုက် Repository ခွဲထားတာ ပိုသင့်တော်ပါတယ်။ ကျွန်တော်ကတော့ ဒီမှာ iac-infra-repo, config-mgmt-repo နဲ့ app-code-repo ဆိုပြီး 3ခု ခွဲထားသင့်တယ်လို့ အကြံပေးချင်ပါတယ်။

Repository ခွဲရခြင်းရဲ့ အဓိကအကြောင်းရင်းကတော့ Separation of Concerns ကြောင့်ဖြစ်ပါတယ်။ Infrastructure changes နဲ့ Application release cycle ဟာမတူပါဘူး။ Repository သာခွဲထားရင် application release လုပ်တိုင်း Terraform pipeline ပြန် run စရာမလိုတော့ပါဘူး။ အကယ်၍များ repository တစ်ခုထဲမှာ Infrastructure + Ansible + Application အားလုံးရှိနေခဲ့ရင် accidental change တစ်ခုကြောင့် unrelated component တွေကိုပါ ထိခိုက်နိုင်ပါတယ်။ ဒါကြောင့် Infra IaC နဲ့ Ansible ကို Application code တစ်ခုနဲ့ tightly coupled မဖြစ်အောင်ထားဖို့အကြံပြုပါတယ်။ Part 1 ကို ဒီလောက်နဲ့ပဲ ခဏရပ်ထားပါမယ်။

Stay tuned for Part 2! 🚀

Why We Didn't Choose a Managed Kubernetes Service

ဒီ project ကို စတင် design လုပ်စဉ်ကာလတုန်းက Enterprise Kubernetes အနေနဲ့ရှိနေတဲ့ RedHat OpenShift ရော Managed Kubernetes services ဖြစ်တဲ့ Amazon EKS တို့ကိုလည်း ထည့်သွင်းစဉ်းစားခဲ့ပါတယ်။ Managed services တွေက control plane management, automated upgrades, built-in high availability, နဲ့ operational overhead လျော့နည်းခြင်း စတဲ့ အားသာချက်များစွာ ရှိပါတယ်။ သို့သော် ဒီ project ရဲ့ customer requirements က Managed Kubernetes platform ကို ရွေးချယ်ခြင်းက အသင့်တော်ဆုံး option မဖြစ်ခဲ့ပါဘူး။

ပထမဦးစွာ customer environment ဟာ on-premises infrastructure ပေါ်မှာ အခြေခံထားပြီး၊ data sovereignty နဲ့ regulatory compliance requirements တွေကြောင့် workloads အချို့ကို public cloud ပေါ်သို့ ပြောင်းရွှေ့ရန် ကန့်သတ်ချက်များ ရှိနေခဲ့ပါတယ်။ အထူးသဖြင့် financial sector workloads ဖြစ်တာကြောင့် infrastructure control နှင့် data location ကို အပြည့်အဝ ထိန်းချုပ်နိုင်ခြင်းသည် အရေးကြီးသော requirement တစ်ခုဖြစ်ခဲ့ပါသည်။

ဒုတိယအနေဖြင့် cost optimization သည် အရေးကြီးသော factor တစ်ခု ဖြစ်ခဲ့ပါသည်။ Managed Kubernetes services များသည် operational complexity ကို လျော့ချပေးနိုင်သော်လည်း cluster management fees, data transfer charges, storage costs, နှင့် additional cloud services များကြောင့် ရေရှည် operating cost များ မြင့်တက်လာနိုင်ပါသည်။ Customer ရဲ့ budget planning အရ existing infrastructure resources များကို အမြင့်ဆုံး အသုံးချနိုင်မည့် open-source based architecture ကို ပိုမိုနှစ်သက်ခဲ့ပါသည်။

နောက်ထပ်အချက်တစ်ခုမှာ infrastructure flexibility ဖြစ်ပါသည်။ Native Kubernetes platform ကို ကိုယ်တိုင်တည်ဆောက်ခြင်းအားဖြင့် networking, ingress, storage, security policies, နှင့် cluster lifecycle management များကို customer requirements အတိုင်း စိတ်ကြိုက် customize ပြုလုပ်နိုင်ခဲ့ပါသည်။ Vendor-specific limitations များကို စဉ်းစားရန် မလိုအပ်သလို vendor lock-in risk ကိုလည်း လျှော့ချနိုင်ခဲ့ပါသည်။

ဒီအကြောင်းအရင်းများကြောင့် Managed Kubernetes platform တစ်ခုကို အသုံးပြုခြင်းထက် HAProxy, Istio Ingress Gateway, Longhorn Storage နှင့် Kubernetes open-source ecosystem ကို အခြေခံသည့် Native Kubernetes HA architecture ကို ရွေးချယ်ခဲ့ခြင်းဖြစ်ပါသည်။ ဒီ project မှာ operational responsibility များ ပိုမိုများပြားလာသော်လည်း customer requirements, budget constraints နှင့် long-term infrastructure strategy များနှင့် ပိုမိုကိုက်ညီသည့် solution တစ်ခုကို ရရှိခဲ့ပါသည်။

Architecture Overview

ဒီ setup မှာ core design က high availability ကို အဓိကထားပါတယ်။ Control Plane access အတွက် HAProxy ကို external load balancer အဖြစ် သုံးခဲ့ပြီး, Kubernetes API server traffic ကို master nodes တွေဆီ distribute လုပ်ခဲ့ပါတယ်။ Node တစ်ခု down သွားရင်လည်း cluster access မပြတ်သွားအောင် VIP-based failover pattern ကို ထည့်သုံးခဲ့ပါတယ်။

Application traffic အတွက် Istio Ingress Gateway ကို အသုံးပြုခဲ့ပါတယ်။ simple Ingress controller ထက်ပိုပြီး traffic routing, retries, canary release, mTLS, and observability အတွက် ပိုကောင်းတဲ့ control ရခဲ့ပါတယ်။

Persistent storage အတွက် Longhorn ကို သုံးခဲ့ပါတယ်။ Stateful workloads တွေအတွက် replication, backup, snapshot, and recovery လိုအပ်ချက်တွေကို Longhorn က fairly well handle လုပ်ပေးနိုင်ပါတယ်။ ဒါပေမယ့် production မှာတော့ storage tuning က မဖြစ်မနေလိုပါတယ်။

Control Plane HA Architecture

Kubernetes HA Cluster တစ်ခု၏ အသက်သွေးကြောသည် ၎င်း၏ Control Plane (Master Nodes) ပဲဖြစ်ပါသည်။ API Server သို့မဟုတ် Etcd သည် တစ်စုံတစ်ရာ ချို့ယွင်းသွားပါက Cluster တစ်ခုလုံး လည်ပတ်နိုင်စွမ်း ရပ်တန့်သွားမည် ဖြစ်ပါသည်။ ထို့ကြောင့် Control Plane များ ပျက်ယွင်းမှုမရှိစေရန်အတွက် အနည်းဆုံး Master Node (3) nodes ကို အသုံးပြုခဲ့ပြီး၊ Cluster ၏ State များကို သိမ်းဆည်းရန်အတွက် Etcd ကို ခိုင်မာစွာ တည်ဆောက်ခဲ့ပါသည်။

API Server Load Balancing with Keepalived and HAProxy

Master Node 3 ခုလုံးရှိ kube-apiserver သို့ ဝင်ရောက်လာသော Request များကို မျှဝေပေးနိုင်ရန် Load Balancing နှင့် Node တစ်ခုကျသွားပါက အလိုအလျောက် အခြား Node သို့ ပြောင်းလဲချိတ်ဆက်ပေးနိုင်ရန် Failover အတွက် HAProxy နှင့် Keepalived ကို ပေါင်းစပ်အသုံးပြုခဲ့ပါသည်။

Keepalived Mechanism

Keepalived သည် Virtual Router Redundancy Protocol (VRRP) ကို အသုံးပြု၍ physical IP address များအပေါ်တွင် Virtual IP (VIP) တစ်ခုကို ဖန်တီးပေးပါသည်။ ဥပမာအားဖြင့် Master Node သုံးခု၏ IP များသည် 10.238.40.162, 10.238.40.163, 10.238.40.164 ဖြစ်ပါက၊ VIP အဖြစ် Network အတွင်း အလွတ်ရှိနေသော 10.238.40.166 ကဲ့သို့သော IP တစ်ခုကို သတ်မှတ်နိုင်ပါသည် ။ ဤအဆင့်တွင် Master Node များအကြား အချင်းချင်း Heartbeats ကို စဉ်ဆက်မပြတ် ဖလှယ်နေကြပြီး Primary Node အဖြစ် တာဝန်ယူထားသော Server သည် ရုတ်တရက် Down သွားပါက ၊ Keepalived သည် VIP ကို အခြား ကျန်ရှိနေသော Backup Node သို့ ချက်ချင်း ရွှေ့ပြောင်းပေးခြင်းဖြင့် Cluster ကို အဆက်မပြတ် လည်ပတ်နိုင်စေပါသည် ။

HAProxy Mechanism

HAProxy သည် VIP ၏ Port 6443 သို့ ဝင်ရောက်လာသော TCP Request များကို Master Node များရှိ API Server များထံသို့ Round-robin စနစ်ဖြင့် ဖြန့်ဝေပေးပါသည် ။ အကယ်၍ Master Node တစ်ခုခုရှိ kube-apiserver သည် အလုပ်မလုပ်တော့ပါက HAProxy ၏ Health Check စနစ်က ၎င်းကို အလိုအလျောက် ဖယ်ရှားပေးမည် ဖြစ်ပါသည်။

example အနေနဲ့ HAProxy ရဲ့ configuration ကိုထည့်ပေးထားပါတယ်။

global
    log /dev/log local0
    log /dev/log local1 notice
    maxconn 20000
    daemon

defaults
    mode tcp
    log global
    retries 3
    timeout connect 10s
    timeout client 300s
    timeout server 300s

frontend kubernetes-apiserver
    bind *:6443
    mode tcp
    option tcplog
    default_backend kubernetes-master-nodes

backend kubernetes-master-nodes
    mode tcp
    balance roundrobin
    option tcp-check
    server master1 10.238.40.162:6443 check fall 3 rise 2
    server master2 10.238.40.163:6443 check fall 3 rise 2
    server master3 10.238.40.164:6443 check fall 3 rise 2

ဤ Configuration တွင် fall 3 rise 2 သည် အလွန်အရေးကြီးပါသည်။ ဆိုလိုသည်မှာ ဆက်တိုက် (၃) ကြိမ် Health Check ကျရှုံးမှသာ Server ကို Downtime အဖြစ်သတ်မှတ်မည်ဖြစ်ပြီး၊ ပြန် up လာသောအခါ ဆက်တိုက် (၂) ကြိမ် အောင်မြင်မှသာ Up အဖြစ် ပြန်လည်လက်ခံမည် ဖြစ်ရာ၊ Network မငြိမ်မသက်ဖြစ်မှုကြောင့် Serverများ မကြာခဏ Flapping ဖြစ်ခြင်း ကို ကာကွယ်ပေးနိုင်ပါသည်။

Kubeadm Configuration and Control Plane Endpoint

Cluster ကို စတင်တည်ဆောက်ရာတွင် (kubeadm init) ဆိုပြီး ပုံမှန် Node IP တစ်ခုတည်းကို အသုံးပြုမည့်အစား Keepalived မှ ဖန်တီးထားသော VIP ကို controlPlaneEndpoint အဖြစ် မဖြစ်မနေ သတ်မှတ်ရပါမည် ။ သို့မှသာ Worker Node များနှင့် အခြား Control Plane Node များသည် Cluster သို့ ချိတ်ဆက်ရာတွင် အဆိုပါ VIP (Load Balancer) မှတစ်ဆင့် အမြဲတမ်းချိတ်ဆက်နိုင်မည်ဖြစ်ပြီး HA စနစ်ကို အပြည့်အဝ အသက်ဝင်စေမည်ဖြစ်သည် ။

ဤကဲ့သို့ controlPlaneEndpoint ကို ကြိုတင်ပြင်ဆင်ခြင်းမရှိဘဲ Single Control Plane အဖြစ် ဦးစွာတည်ဆောက်ပြီးမှ၊ နောင်တစ်ချိန်တွင် HA သို့ ပြောင်းလဲရန် kubeadm တွင် ထောက်ပံ့ထားခြင်းမရှိဘဲ ရှုပ်ထွေးသော ပြဿနာများကို ဖြစ်ပေါ်စေနိုင်ပါသည်။

example အနေနဲ့ Cluster Configuration လဲကြည့်ရှုနိုင်ပါသည်။

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.31.0
controlPlaneEndpoint: "10.238.40.166:6443"
networking:
  podSubnet: "10.244.0.0/16"
  serviceSubnet: "10.96.0.0/12"

အဆိုပါ Config ကို အသုံးပြု၍ Cluster ကို Init လုပ်ပြီးနောက်၊ အခြားသော Master Node များကို ချိတ်ဆက်သည့်အခါ --control-plane နှင့် --certificate-key flag များကို အသုံးပြု၍ Certificates ကို လုံခြုံစွာ မျှဝေရယူနိုင်မည် ဖြစ်ပါသည်။

Container Runtime Transition: Containerd and Systemd Cgroup Driver

Kubernetes ရဲ့ version 1.24 အထက်ကနေစပြီး Dockershim ကိုဖြုတ်လိုက်ပြီး Docker အစား containerd ကို အဓိက Container Runtime (CRI) အဖြစ် အသုံးပြုလာကြပါသည် ။ Containerd ကို အသုံးပြုရာ၌ Cgroup (Control Group) Driver ကို စနစ်တကျ ချိန်ညှိမှုသည် အလွန်အရေးကြီးသော အဆင့်တစ်ခု ဖြစ်ပါသည်။

Issues Arising from Cgroup Driver Mismatches

Linux Server များတွင် Pod များ၏ CPU နှင့် Memory ကဲ့သို့သော resources တွေကို manage လုပ်ရန် cgroups ကို အသုံးပြုပါသည်။ သာမန်အားဖြင့် Container Runtime များသည် cgroupfs ကို အသုံးပြုလေ့ရှိသော်လည်း၊ ဥပမာ - Ubuntu, RHEL သည် OS ရဲ့ Process ID (PID 1) အဖြစ် systemd ကို အသုံးပြုကြပါသည်။

အကယ်၍ Kubernetes ၏ Kubelet နှင့် Containerd သည် cgroupfs ကို သုံးနေပြီး၊ OS သည် systemd ကို သုံးနေပါက၊ စနစ်တစ်ခုတည်းတွင် cgroup manager နှစ်ခု ပြိုင်တူအလုပ်လုပ်နေမည် ဖြစ်ပါသည်။ ဤကဲ့သို့ Mismatch ဖြစ်ပေါ်ပါက resources management ကိုပိုရှုပ်ထွေးသွားစေပြီး၊ Node များ ရုတ်တရက် အလုပ်မလုပ်တော့ခြင်း၊ သို့မဟုတ် resources မလုံလောက်မှုကြောင့် ပြဿနာများကို ဖြစ်ပေါ်စေနိုင်ပါသည်။

The Solution and Optimal Configuration

ဤပြဿနာကို ဖြေရှင်းရန်အတွက် kubelet နှင့် containerd နှစ်ခုစလုံးကို systemd cgroup driver ကိုသာ တူညီစွာ အသုံးပြုရန် ပြင်ဆင်ပေးရမည် ဖြစ်ပါသည်။ Containerd ၏ အဓိက config file ဖြစ်သော /etc/containerd/config.toml တွင် အောက်ပါအတိုင်း SystemdCgroup = true ဟု ထည့်သွင်းပေးရမည်ဖြစ်သည်။

version = 2
[plugins]
  [plugins."io.containerd.grpc.v1.cri"]
    [plugins."io.containerd.grpc.v1.cri".containerd]
      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
        [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
          runtime_type = "io.containerd.runc.v2"
          [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
            SystemdCgroup = true

Config ကို ပြင်ဆင်မှုများ ပြီးပါက systemctl restart containerd နှင့် systemctl restart kubelet တို့ကို လုပ်ဆောင်ပေးခြင်းဖြင့် Node များ တည်ငြိမ်စွာ အလုပ်လုပ်လာမည်ကို တွေ့မြင်ရမည် ဖြစ်ပါသည်။

Network Foundation: MetalLB, CNI, and MTU Optimization

Kubernetes Cluster တစ်ခု၏ Performance သည် ၎င်း၏ အောက်ခြေရှိ Network အပေါ်တွင် များစွာမူတည်နေပါသည်။ အထူးသဖြင့် On-Premises Environment တွင် Cloud Provider များ၏ အထောက်အပံ့မပါဝင်သဖြင့် ကွန်ရက်ပိုင်း ကို ကိုယ်တိုင် အပြည့်အဝ တာဝန်ယူ တည်ဆောက်ရပါသည်။

Configuring MetalLB Layer 2 for Bare-Metal

Cloud Providers များ (ဥပမာ - AWS, GCP) တွင် Kubernetes Service ကို LoadBalancer type ဖြင့် ထုတ်လိုက်ပါက Cloud ၏ Load Balancer (ဥပမာ ALB, NLB) ကို အလိုအလျောက် ချိတ်ဆက်ပေးပြီး Public IP တစ်ခုကို ရရှိပါသည်။ သို့သော် On-Premises တွင် ထိုသို့လုပ်ဆောင်ပေးမည့် အရာမရှိသောကြောင့် LoadBalancer Service များကို ဖန်တီးပါက အမြဲတမ်း <pending> အခြေအနေတွင်သာ ရှိနေမည်ဖြစ်ပါသည်။ ဤ ပြသနာကို ဖြေရှင်းရန် MetalLB ကို အသုံးပြုရပါသည်။

MetalLB သည် Layer 2 (ARP/NDP) သို့မဟုတ် BGP mode များဖြင့် အလုပ်လုပ်နိုင်ပါသည်။ BGP သည် အဆင့်မြင့် Router များလိုအပ်ပြီး ပြင်ဆင်ရ ရှုပ်ထွေးသော်လည်း၊ Layer 2 mode သည် အထူးတလည် ပြင်ဆင်မှု များစွာမလိုအပ်ဘဲ ရိုးရှင်းစွာ အလုပ်လုပ်နိုင်သည့်အတွက် On-premises ပတ်ဝန်းကျင်များတွင် တွင်ကျယ်စွာ အသုံးပြုကြပါသည်။

MetalLB အား လုပ်ငန်းလည်ပတ်ရန်အတွက် IP Address များ ခွဲဝေချထားပေးရန် IPAddressPool နှင့် ၎င်း IP များကို Network အတွင်းသို့ ကြေငြာရန် L2Advertisement Custom Resources (CRDs) များကို အသုံးပြုရပါသည်။

MetalLB Layer 2 Example Configuration

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: production-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.100.240-192.168.100.250
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: production-advertisement
  namespace: metallb-system
spec:
  ipAddressPools:
  - production-pool

Layer 2 mode တွင် အလုပ်လုပ်ပုံမှာ၊ LoadBalancer Service တစ်ခု ဖန်တီးလိုက်သည်နှင့် MetalLB သည် production-pool ထဲမှ IP တစ်ခုကို assign ချပေးပါသည်။ ထို့နောက် Cluster အတွင်းရှိ Node တစ်ခုခုပေါ်တွင် အလုပ်လုပ်နေသော MetalLB Speaker pod သည် အဆိုပါ IP အတွက် ARP request များကို လက်ခံဖြေကြားပေးရန် (Announce) ကို တာဝန်ယူလိုက်ပါသည်။ ထို့ကြောင့် ပြင်ပမှ လာသော ကွန်ရက်လမ်းကြောင်းများသည် အဆိုပါ Node သို့ ရောက်ရှိသွားပြီး၊ ၎င်းမှတစ်ဆင့် Kube-Proxy က သက်ဆိုင်ရာ Application Pod များထံသို့ ဆက်လက်ပေးပို့ပါသည်။

The Silent Threat: CNI and MTU Mismatches

Cluster ၏ ကွန်ရက်ချိတ်ဆက်မှုများအတွက် Calico သို့မဟုတ် Cilium ကဲ့သို့သော Container Network Interface (CNI) များကို အသုံးပြုလေ့ရှိပါသည် ။ ဤနေရာတွင် အထူးဂရုပြုရမည့် အရေးကြီးဆုံး ကွန်ရက်ပိုင်းဆိုင်ရာ ကန့်သတ်ချက်မှာ MTU (Maximum Transmission Unit) သတ်မှတ်ချက် ဖြစ်ပါသည်။ MTU သည် ကွန်ရက်ပေါ်တွင် တစ်ကြိမ်လျှင် ပို့လွှတ်နိုင်သော အကြီးဆုံး Packet အရွယ်အစားကို ကိုယ်စားပြုပါသည်။

သာမန် Physical Network ၏ Ethernet MTU သည် အများအားဖြင့် 1500 bytes ဖြစ်ပါသည်။ သို့သော် Calico သို့မဟုတ် Flannel ကဲ့သို့သော CNI များသည် Pod များအကြား ဆက်သွယ်ရန်အတွက် VXLAN သို့မဟုတ် IP-in-IP ကဲ့သို့သော Encapsulation နည်းလမ်းများကို အသုံးပြုကြပါသည်။ ဤသို့ အသုံးပြုသည့်အခါ မူလ Packet ပေါ်တွင် Header အသစ်များ ထပ်မံပေါင်းထည့်ရပါသည် ။ VXLAN သည် 50 bytes နေရာယူပြီး၊ IP-in-IP သည် 20 bytes နေရာယူပါသည်။ ထို့ကြောင့် CNI ၏ လက်တွေ့အသုံးပြုနိုင်သော MTU သည် Physical MTU ထက် အနည်းဆုံး 50 bytes နည်းပါးနေရပါမည်။ (ဥပမာ - 1450 bytes)

Consequences of an MTU Mismatch

အကယ်၍ Node ၏ MTU (1500) နှင့် CNI ၏ MTU ကိုက်ညီမှုမရှိဘဲ (ဥပမာ CNI တွင်လည်း 1500 ဟု မှားယွင်းစွာ သတ်မှတ်မိပါက)၊ Network Packet များသည် ကွန်ရက်ထဲသို့ ရောက်သောအခါ ခွင့်ပြုထားသော အရွယ်အစားထက် ကြီးမားနေသဖြင့် Packet Fragmentation များ အဆက်မပြတ် ဖြစ်ပေါ်စေနိုင်ပါသည်။

လက်တွေ့လုပ်ငန်းခွင်တွင် ဤ MTU Mismatch ကြောင့် အောက်ပါဆိုးကျိုးများကို ကြုံတွေ့ရတတ်ပါသည်။

1. Database Transactions Failures: data အမြောက်အမြား ပို့လွှတ်ရသော Database များသည် Latency မြင့်တက်လာပြီး Connection များ ပြတ်တောက်သွားတတ်ပါသည်။

2. Longhorn Storage Replication Impact: Storage Network သည် MTU အလွန်အရေးကြီးပါသည်။ MTU မှားယွင်းနေပါက Storage Volume များ Sync လုပ်ရာတွင် အလွန်နှေးကွေးသွားပြီး Volume များ Degraded ဖြစ်ခြင်း၊ Rebuild ပြုလုပ်မှု failed ဖြစ်ခြင်းများကြုံတွေ့ရနိုင်ပါသည်။

ဤပြဿနာများကို ရှောင်ရှားရန် ping -s 1450 -M do <Node-IP> ကဲ့သို့သော Command များဖြင့် Packet Fragmentation ဖြစ်မဖြစ် စစ်ဆေးသင့်ပြီး၊ calico-config ConfigMap အတွင်းရှိ mtu တန်ဖိုးကို မိမိ၏ Infrastructure နှင့် ကိုက်ညီအောင် တိကျစွာ လျှော့ချသတ်မှတ်ပေးရန် လိုအပ်ပါသည်။

Storage Optimization: Tuning Longhorn for Production

Kubernetes တွင် Stateful Application များ (ဥပမာ - Databases, Message Queues) အတွက် Persistent Storage သည် မရှိမဖြစ်လိုအပ်ပါသည်။ Longhorn သည် Rancher မှ ဖန်တီးထားသော Cloud-Native Storage စနစ်ဖြစ်ပြီး ရိုးရှင်းလွယ်ကူသော်လည်း၊ Production Environment မှာ အသုံးပြုရန်အတွက် သေချာစွာ Tuning လုပ်ဖို့လိုအပ်ပါသည်။

Disaster Recovery and Backup Automation

Longhorn မှာ data locality and replica strategy ကို ထိန်းချုပ်ပေးနိုင်ပါတယ်။ ဒီ feature ကို properly tune လုပ်ထားရင် workload latency ကို လျှော့ပေးနိုင်ပါတယ်။ System Error၊ Human Error ဖြစ်ပေါ်ပါက data များ မဆုံးရှုံးစေရန်အတွက်လည်း အောက်ပါ Backup Strategy များကို ချမှတ်အကောင်အထည်ဖော်သင့်ပါသည်။

• External Backup Target: AWS S3, Google Cloud Storage, သို့မဟုတ် Office Network တွင်းရှိ NFS Server တစ်ခုခုကို External Backup Target အဖြစ် သတ်မှတ်သင့်ပါသည်။ Cluster ထဲက data များ မဆုံးရှုံးအောင် Backup Storage မှ Data များကို အလွယ်တကူ ပြန်ပြီး Restore လုပ်နိုင်မည်ဖြစ်ပါသည်။

• Recurring Backups : အရေးကြီးသော Volume များအားလုံးအတွက် အလိုအလျောက် Backup ယူသည့် အစီအစဉ်များ (Cron jobs) ကို StorageClass မှတစ်ဆင့်သော်လည်းကောင်း (ဥပမာ - recurringJobSelector) အသုံးပြု၍ Longhorn UI မှတစ်ဆင့်သော်လည်းကောင်း သတ်မှတ်ထားရပါမည် ။ ဤသို့ပြုလုပ်ခြင်းဖြင့် data များ လုံခြုံမှုကို အာမခံနိုင်ပါသည်။

• Snapshot Management and Space Efficiency: Longhorn သည် Replica များ ပြန်လည်တည်ဆောက်ရာတွင် system မှ အလိုအလျောက် Snapshot များကို ဖန်တီးပါသည်။ ဤ Snapshot များသည် အချိန်ကြာလာသည်နှင့်အမျှ Diskspace များကို စားသုံးလာမည်ဖြစ်ရာ ၎င်းတို့ကို ပုံမှန်ရှင်းလင်းပေးမည့် (Cleanup) Recurring Job များကိုလည်း မဖြစ်မနေ ထည့်သွင်းစဥ်းစားရပါမည် ။ ထို့အပြင် File System အဟောင်းများကို ရှင်းလင်းရန် filesystem-trim လုပ်ငန်းစဉ်များကိုပါ အချိန်မှန် လုပ်ဆောင်ပေးခြင်းဖြင့် Storage စွမ်းဆောင်ရည်ကို ထိန်းသိမ်းထားနိုင်ပါသည်။

Advanced Traffic Management: Istio Ingress Gateway

Application များဆီသို့ External မှ ဝင်ရောက်လာသော HTTP/HTTPS (Ingress Traffic) များကို စီမံခန့်ခွဲရန်အတွက် ရိုးရှင်းသော Nginx Ingress ကို အသုံးပြုနိုင်သော်လည်း၊ ပိုမိုရှုပ်ထွေးသော Microservices Architecture များအတွက် အဆင့်မြင့် လုပ်ဆောင်ချက်များကို ပေးစွမ်းနိုင်သော Istio Ingress Gateway ကို အသုံးပြုခြင်းသည် အကောင်းဆုံး ရွေးချယ်မှုဖြစ်ပါသည်။

Advantages of Istio Ingress Gateway

Istio Ingress Gateway သည် Istio Service Mesh ၏ အစိတ်အပိုင်းတစ်ခုဖြစ်ပြီး Envoy Proxy ကို အခြေခံ၍ တည်ဆောက်ထားပါသည်။ ၎င်းသည် Cluster အတွင်းသို့ ဝင်ရောက်လာသော Traffic များအားလုံးအတွက် တစ်ခုတည်းသော Single Entry Point အဖြစ် လုပ်ဆောင်ပေးကာ Load Balancing, SSL/TLS Termination (Certificate Management), နှင့် Authentication ကဲ့သို့သော လုံခြုံရေး လုပ်ဆောင်ချက်များကို ပံ့ပိုးပေးပါသည်။

Istio တွင် Traffic Management ကို ဖွဲ့စည်းရာ၌ Traditional Ingress Resource ထက် ပိုမိုပြောင်းလွယ်ပြင်လွယ်ရှိသော Custom Resources နှစ်ခုဖြစ်သည့် Gateway နှင့် VirtualService တို့ကို တွဲဖက်အသုံးပြုရပါသည်။

• Gateway Resource: မည်သည့် Port များ (example - TCP Port 80, 443) ကို open ထားမည်၊ မည်သည့် Hostname များကို လက်ခံမည် နှင့် SSL/TLS Certificate များကို မည်သို့ ချိတ်ဆက်မည် စသည်တို့ကို အတိအကျ သတ်မှတ်ပေးသည့် အစိတ်အပိုင်း ဖြစ်ပါသည်။

• VirtualService Resource: Gateway မှ တစ်ဆင့် အောင်မြင်စွာ ဝင်ရောက်လာသော Traffic များကို မည်သည့် Kubernetes Service များထံသို့ မည်သည့် Routing Rules ဖြင့် ပို့ဆောင်မည်ကို အသေးစိတ် သတ်မှတ်ပေးပါသည်။

Advanced Use Cases of VirtualService

လက်တွေ့လုပ်ငန်းခွင်တွင် VirtualService ကို အသုံးပြု၍ Routing များကို ပြုလုပ်နိုင်ပါသည်။ ဥပမာအားဖြင့် -

• Path-based Routing: Hostname တစ်ခုတည်းမှ ဝင်လာသော Traffic များကို URL Path အလိုက် (ဥပမာ - /api/users နှင့် /api/payments) မတူညီသော Microservices များထံ တိကျစွာ ခွဲဝေပို့ဆောင်ခြင်း။

• Traffic Shifting (Canary Releases): Software Version အသစ်တစ်ခုကို Deployment လုပ်ရာ တွင် အန္တရာယ်ကင်းစေရန်အတွက် Traffic ၏ 90% ကို ယခင် Version အဟောင်း (v1) သို့ ပို့ပြီး ကျန် 10% ကိုသာ Version အသစ် (v2) သို့ ပို့ဆောင်စမ်းသပ်ခြင်းတို့ကို လွယ်ကူစွာ လုပ်နိုင်ပါသည်။

• Resiliency & Fault Tolerance: Network ချို့ယွင်းမှုများအတွက် retries နှင့် timeout များကို Application Code ထဲတွင် ရေးစရာမလိုဘဲ Istio ဘက်မှ တပါတည်း ထည့်သွင်းသတ်မှတ်ပေးနိုင်ခြင်းကြောင့် အားသာချက်တစ်ခုဖြစ်ပါသည်။

ဒါပေမယ့် complexity ကတော့ တိုးလာမှာပါပဲ။ HAProxy နဲ့ Istio ကြားမှာ PROXY protocol သုံးပြီး original client IP ကို preserve လုပ်ရတဲ့အပိုင်းလိုမျိုးက beginner-friendly မဟုတ်ပါဘူး။ Debugging လုပ်ရတာလည်း ပိုပြီး harder ဖြစ်နိုင်ပါတယ်။ ဒါကြောင့် ကျွန်တော်တို့ ရရှိခဲ့တဲ့ lesson ကတော့ Istio က powerful ဖြစ်ပေမယ့်, production environment မှာ design ကို simple, observable, and well-documented ဖြစ်အောင် ထားရမယ်ဆိုတာပါ။

Monitoring Is Part of the Architecture

Monitoring မပါဘဲ production cluster တည်ဆောက်တာက blindfold လိုပါပဲ။ Cluster က running ဖြစ်နေတယ်လို့ထင်ရပေမယ့် hidden pressure တွေက slowly build up ဖြစ်နေတတ်ပါတယ်။ ဒါကြောင့် Prometheus, Grafana, metrics-server, and alerting rules တွေကို မဖြစ်မနေ ထည့်ခဲ့ပါတယ်။ Especially storage capacity, latency, node disk usage, API server health, and control plane reachability တို့ကို close watch လုပ်ထားရပါတယ်။ Production experience က သင်ပေးတာကတော့ “it works” ဆိုတာနဲ့မလုံလောက်ဘဲ “we can see it, measure it, and recover it quickly” ဖြစ်ရမယ်ဆိုတာပဲဖြစ်ပါတယ်။

The Final Takeaway

ဒီ project ကနေ အကြီးမားဆုံး ရခဲ့တဲ့ lesson ကတော့ open-source stack တွေကို combine လုပ်ပြီး production-grade platform တစ်ခုတည်ဆောက်လို့ရတယ်ဆိုတာပါ။ ဒါပေမယ့် success ကို open source tools တွေကပဲ မပေးပါဘူး။ Architecture decisions, careful tuning, testing, and operational discipline က အဓိကပဲဖြစ်ပါတယ်။

HAProxy က control plane ကို stable access ပေးတယ်။ Istio က application traffic ကို smart way နဲ့ manage လုပ်ပေးတယ်။ Longhorn က stateful workloads အတွက် resilient storage layer တစ်ခုဖြစ်လာတယ်။ ဒါပေမယ့် ဒါတွေအားလုံးကို production-ready ဖြစ်အောင်လုပ်ဖို့ network, runtime, storage, and monitoring တို့ကို end-to-end အဖြစ် စဉ်းစားရပါတယ်။

Thanks for reading, and I appreciate your time.

Sc3p73R

Engineer တော်တော်များများက Terraform နဲ့ Crossplane ဘယ်ဟာ ပိုကောင်းလဲ လို့ ယှဉ်လေ့ရှိကြပေမဲ့၊ တကယ့် လက်တွေ့ Industry ရဲ့ အကောင်းဆုံး Practice ကတော့ အဲ့ဒီနှစ်ခုကို ယှဉ်သုံးတာထက် Hybrid Approach ကတော့ အကောင်းဆုံးပဲ ဖြစ်ပါတယ်။ အရင်ဆုံးအနေနဲ့ ကျွန်တော်တို့ ဒီ Tools နှစ်ခုရဲ့ အားသာချက် အားနည်းချက်တွေကို သိဖို့လိုပါတယ်။

Terraform

Terraform ဟာ Infrastructure Provisioning အတွက် အသင့်တော်ဆုံးပါပဲ။ Multi-Cloud Provider ကို support ပေးပြီး၊ ကျယ်ပြန့်တဲ့ Infrastructure ကြီးတစ်ခုလုံးကို တည်ဆောက်တဲ့နေရာမှာ အရမ်းကို Mature ဖြစ်တဲ့ tool တစ်ခုပါ။ သို့သော် သူရဲ့ အားနည်းချက်က Maintenance မှာပါ။ ကျွန်တော်တို့က Terraform ကိုအသုံးပြုပြီး AWS ပေါ်မှာ Infrastructure တစ်ခုတည်ဆောက်ထားတယ်ပဲဆိုပါတော့ဗျာ။ တစ်ယောက်ယောက်ကများ AWS Console ထဲဝင်ပြီး Manual သွားပြင်လိုက်တယ်ထားပါတော့။ ဒီလိုမျိုး Configuration Drift မျိုးကို Terraform ကနေမှ ချက်ချင်းမသိနိုင်ပါဘူး။ Terraform က state ကို track လုပ်ပြီး plan/apply မှာ current state နဲ့ desired config ကို compare လုပ်ပါတယ်။ Drift ကိုလည်း refresh အဆင့်နဲ့ plan/apply အတွင်းမှာ detect လုပ်နိုင်ပေမဲ့၊ Crossplane လို always-on controller မဟုတ်နေပါဘူး။

Crossplane

Crossplane သည် open-source Kubernetes extension တစ်ခု ဖြစ်ပြီး Kubernetes cluster တစ်ခုကို universal control plane တစ်ခုအဖြစ် ပြောင်းလဲပေးနိုင်သော framework တစ်ခု ဖြစ်ပါတယ်။ သူရဲ့ အဓိက ရည်ရွယ်ချက်ကတော့ platform team များအနေဖြင့် cloud provider များ၏ Infrastructure များကို standard Kubernetes API များမှတစ်ဆင့် စီမံခန့်ခွဲနိုင်ရန်နှင့် application developer များအတွက် self-service အခြေအနေကို ဖန်တီးပေးရန် ဖြစ်သည် ။ သူရဲ့ အလုပ်လုပ်ပုံကတော့ Terraform လို တစ်ခါ run ပြီး ရပ်သွားတာမျိုး မဟုတ်ဘဲ၊ Kubernetes Controller တွေလိုပဲ 24/7 အမြဲတမ်း စောင့်ကြည့်နေတာပါ။ အကယ်၍ Console ကနေ manual သွားဖျက်လိုက်ရင်တောင် သူက ချက်ချင်းသိပြီး မူလအတိုင်း အလိုအလျောက် ပြန်တည်ဆောက်ပေးပါတယ်။ သို့သော် Crossplane ကို Run ဖို့အတွက် Kubernetes Cluster တစ်ခုတော့ အရင်ရှိနေဖို့ လိုအပ်ပါတယ်။

The Ultimate Combo

အိမ်တစ်လုံးဆောက်ပြီဆိုရင် foundation အရင်ချရသလိုပါပဲ။ ပထမဆုံးအနေနဲ့ Cloud Environment ရဲ့ Infrastructure တွေကိုတည်ဆောက်ပြီဆိုရင်လဲ Terraform နဲ့ တည်ဆောက်ပါမယ်။

• VPC, Subnet, Route Tables တွေ ဖန်တီးမယ်။

• IAM Roles တွေ၊ Security Groups တွေ သတ်မှတ်မယ်။

• အရေးအကြီးဆုံးဖြစ်တဲ့ Kubernetes Cluster (EKS, GKE, or AKS) စတာတွေကို တည်ဆောက်ပါမယ်။ ဒီအဆင့်မှာတော့ Terraform ကို အသုံးပြုတာက အမြန်ဆုံးနဲ့ အစိတ်ချရဆုံး ဖြစ်ပါတယ်။

Terraform နဲ့ ဆောက်ထားတဲ့ Kubernetes Cluster လေး ရလာပြီဆိုရင်၊ အဲ့ဒီ Cluster ထဲမှာ Crossplane ကို Install လုပ်လိုက်ပါမယ်။ အဲ့ဒီအချိန်ကစပြီး ကိုယ့်ရဲ့ Application တွေအတွက် လိုအပ်တဲ့ ကျန်တဲ့ resource တွေကို Terraform နဲ့ ဆက်မဆောက်တော့ပါဘူး။

• Application တစ်ခုက Database (ဥပမာ- AWS RDS) လိုချင်ရင် Crossplane ကနေတစ်ဆင့် ဆောက်ပါမယ်။

• S3 Buckets တွေ၊ Message Queues (SQS) တွေ၊ Caching (ElastiCache) တွေကို Crossplane သုံးပြီး K8s YAML file လေးတွေနဲ့ပဲ request လုပ်ပါတော့မယ်။

GitOps (eg - ArgoCD, Flux) ကို အသုံးပြုတဲ့အခါ အရာအားလုံးအတွက် Single Source of Truth ကို Git Repository ထဲမှာပဲ ထားပါတယ်။ Terraform သီးသန့်ဆိုရင် App deployment က ArgoCD နဲ့သွားပြီး၊ Infrastructure က Terraform CI/CD pipeline နဲ့သွားနေတာမို့ Workflow နှစ်ခု ကွဲနေတတ်ပါတယ်။ ဒါပေမဲ့ Crossplane ကို သုံးလိုက်တဲ့အခါမှာ Database ဆောက်တဲ့ Code ရော၊ App ကို Deploy လုပ်တဲ့ Helm Chart ရော အကုန်လုံးက Kubernetes Manifest YAML တွေ ဖြစ်သွားပါတယ်။ Developer တွေက application code အသစ်ထည့်လိုက်တာနဲ့ တစ်ပြိုင်နက်၊ အဲ့ဒီ app အတွက် လိုအပ်မယ့် database အသစ်ကိုပါ git ထဲကနေ တစ်ခါတည်း commit လုပ်လိုက်လို့ ရပါတယ်။ ArgoCD က အဲ့ဒီ YAML တွေကို မြင်တာနဲ့ App ကို K8s ပေါ်မှာ Deploy လုပ်ပေးသလို၊ Crossplane ကနေတစ်ဆင့် AWS ပေါ်မှာ Database ကိုပါ အလိုအလျောက် သွားဆောက်ပေးသွားမှာပါ။ ဒါဟာ App ရော Infra ကိုပါ တစ်ပြိုင်နက်တည်း အပြောင်းအလဲလုပ်နိုင်တဲ့ True GitOps workflow ပဲဖြစ်ပါတယ်။

Sc3p73R

Kubernetes Dashboard ဘာကြောင့် deprecated ဖြစ်သွားတာလဲ

အဓိကအကြောင်းရင်းကတော့ maintenance ဆက်မလုပ်နိုင်တော့တာပါ။ Repository ကို archive လုပ်တဲ့အခါ “lack of active maintainers and contributors” လို့ တိတိကျကျ ဖော်ပြထားပြီး၊ archive ဖြစ်သွားတာနဲ့အတူ project သည် read-only ဖြစ်သွားပါတယ်။ Kubernetes Dashboard က general-purpose web UI အဖြစ် ရပ်တည်ခဲ့ပေမယ့် maintainers များနည်းလာခြင်းကြောင့် long-term support အတွက် အားနည်းသွားခဲ့ပါတယ်။

နောက်တစ်ချက်က modern Kubernetes environments တွေအတွက်လိုအပ်တဲ့extensibility နဲ့ flexible deployment model တွေကို နောက်ပိုင်း tool များက ပိုကောင်းကောင်းဖြည့်ဆည်းလာတာပါ။ Kubernetes Dashboard documentation မှာတောင် Helm-based installation သာ support လုပ်ပြီး multi-container setup, gateway proxy စတဲ့ architecture တွေကို မှီခိုနေရတာကို တွေ့ရပါတယ်။ အဲဒီလို setup က legacy dashboard experience ထက် ပိုမိုပြောင်းလဲနေတဲ့အတွက် platform လိုအပ်ချက်တွေနဲ့ မကိုက်တော့ပါဘူး။

Headlamp ဆိုတာဘာလဲ

Headlamp က Kubernetes cluster တွေကို browser ကနေ စီမံနိုင်တဲ့ modern web UI တစ်ခုဖြစ်ပါတယ်။ Official site ရဲ့ docs အရ Headlamp ကို Kubernetes cluster ထဲမှာ deploy လုပ်လို့ရသလို desktop application အဖြစ်လည်း run လို့ရ ပါတယ်။ Project ကို “easy-to-use and extensible Kubernetes web UI” လို့ ဖော်ပြထားပြီး Kubernetes SIG UI အောက်က official Kubernetes sub-project တစ်ခုအဖြစ် ရပ်တည်နေပါတယ်။ headlamp ရဲ့ github repository ကိုလည်းလေ့လာလို့ရအောင်ထည့်ပေးထားပါတယ်။

Headlamp Github: kubernetes-sigs/headlamp: A Kubernetes web UI that is fully-featured, user-friendly and extensible

Headlamp ကို ဘယ်သူတွေ develop လုပ်တာလဲ

Headlamp ဟာ open-source project ဖြစ်ပြီး official FAQ အရ maintainers list ကို repository ရဲ့ OWNERS_ALIASES file ထဲမှာထားပါတယ်။ ဒီ project က CNCF ရဲ့ Sandbox project တစ်ခု ဖြစ်ပြီး၊ community contributors တွေ ပါဝင်ပြီး develop လုပ်ကြပါတယ်။ Official site ကလည်း Headlamp ကို Kubernetes SIG UI နဲ့ ချိတ်ဆက်ထားတဲ့ Kubernetes sub-project အဖြစ် ဖော်ပြထားပါတယ်။ ဆိုလိုတာကတော့ Headlamp သည် တစ်ခုတည်းသော vendor product မဟုတ်ဘဲ Kubernetes community-driven project တစ်ခုဖြစ်ပါတယ်။

ဘာကြောင့် Headlamp ကို သုံးသင့်လဲ

ပထမဆုံးအကြောင်းရင်းကတော့ active development ရှိနေခြင်းပါ။ Kubernetes Dashboard က archive ဖြစ်သွားပြီး read-only ဖြစ်သွားတဲ့အချိန်မှာ Headlamp ကတော့ official docs, releases, installation guides, plugin docs တွေနဲ့ actively update လုပ်နေဆဲပါ။

ဒုတိယအချက်က multi-mode deployment ပါ။ In-cluster deploy လည်းရ၊ desktop app လည်းရပါတယ်။ Local workstation နဲ့ isolated clusters တွေကို manage လုပ်ချင်သူတွေအတွက် desktop mode ကအသုံးဝင်ပြီး၊ team/shared access အတွက်တော့ cluster ထဲမှာ deploy လုပ်တာက ပိုအဆင်ပြေပါတယ်။

တတိယအချက်က RBAC-based security model ပါ။ Headlamp က cluster access ကို directly မယူဘဲ Kubernetes RBAC ကို အခြေခံပြီး API server နဲ့ connect လုပ်ပါတယ်။ Headlamp ရဲ့ recommended login method က Service Account token ဖြစ်ပြီး၊ user permissions ကို Kubernetes native way နဲ့ ထိန်းချုပ်နိုင်ပါတယ်။

စတုတ္ထအချက်ကတော့ plugin system ပါ။ Official FAQ မှာ Headlamp ကို highly customizable လို့ ဖော်ပြထားပြီး plugin system က core functionality တွေကို တိုးချဲ့နိုင်တယ်လို့ ဆိုထားပါတယ်။ အဖွဲ့အစည်းတစ်ခုချင်းစီရဲ့ workflow, branding, internal tooling နဲ့ ကိုက်ညီအောင် ပြင်ဆင်ဖို့ အရေးကြီးတဲ့အားသာချက်တစ်ခုပဲဖြစ်ပါတယ်။

Headlamp Installation step by step

1. Prerequisite Check

သင့်မှာ Kubernetes cluster တစ်ခုရှိပြီး kubectl က အဲဒီ cluster ကို access လုပ်နိုင်ရပါမယ်။ Helm သုံးမယ်ဆို Helm လည်း install လုပ်ထားရပါမယ်။ Headlamp ကိုအသုံးပြုရန် in-cluster installation နဲ့ desktop application နှစ်မျိုးလုံး support လုပ်ပါတယ်။

2. Helm Repo Add

Headlamp ကို cluster ထဲ deploy လုပ်ဖို့ အလွယ်ဆုံးနည်းက Helm ကိုအသုံးပြုခြင်းပဲဖြစ်ပါတယ်။ Helm repo add ဖို့အတွက် helm package ကိုတော့ install ပြီးသားဖြစ်ရပါမယ်။ Official docs အတိုင်း follow လုပ်ပြီးလဲ installation လုပ်နိုင်ပါတယ်။

helm repo add headlamp https://kubernetes-sigs.github.io/headlamp/
helm repo update
helm install my-headlamp headlamp/headlamp --namespace kube-system --create-namespace

3. Accessing Web UI

သင့် cluster ရဲ့ ingress (သို့မဟုတ်) service exposure method အလိုက် Headlamp UI ကိုဖွင့်နိုင်ပါတယ်။ Docs မှာ in-cluster deployment ကို ingress နဲ့တွဲသုံးရတဲ့ common use case လို့ ဖော်ပြထားပါတယ်။

4. Authentication / Login

Headlamp docs အရ login လုပ်ရာမှာ client certificate သို့မဟုတ် bearer token သုံးနိုင်ပါတယ်။ Recommended method ကတော့ Service Account token ဖြစ်ပြီး RBAC နဲ့ပဲ access control လုပ်ပါတယ်။ Example အနေနဲ့ service account တစ်ခု create လုပ်ပြီး cluster-admin binding ချိတ်ဆက်နိုင်ပါတယ်။ Headlamp ကို local desktop app အဖြစ်လည်း run လို့ရပါတယ်။ Linux, Mac, Windows support ရှိပြီး unrelated clusters ကို local ကနေ manage လုပ်ချင်သူတွေအတွက် သင့်တော်ပါတယ်။

5. Use OIDC

Headlamp က OIDC စနစ်ကို ပံ့ပိုးထားတာကြောင့် Cluster အသုံးပြုသူတွေအနေနဲ့ "Sign in" ကို နှိပ်ရုံနဲ့တင် အလွယ်တကူ Log in ဝင်ရောက်နိုင်မှာ ဖြစ်ပါတယ်။ OIDC ကို အသုံးပြုရန်အတွက် Headlamp သည် ၎င်းကို မည်သို့ configure လုပ်ရမည်ကို သိရှိရန် လိုအပ်သောကြောင့် သင်၏ OIDC provider ထံမှ သက်ဆိုင်သော argument များကို Headlamp သို့ ပေးဆောင်ရမည်ဖြစ်သည်။

ref: https://headlamp.dev/docs/latest/installation/in-cluster/oidc/

နိဂုံးချုပ်

Kubernetes Dashboard က archive ဖြစ်ပြီး maintenance မလုပ်တော့တဲ့အခြေအနေမှာ Headlamp က ပိုပြီး modern ဖြစ်တဲ့ replacement တစ်ခုပါ။ Official Kubernetes SIG UI sub-project ဖြစ်တာ၊ in-cluster နဲ့ desktop နှစ်မျိုးလုံး support လုပ်တာ၊ RBAC-based security model သုံးတာ၊ plugin system နဲ့ customize လုပ်လို့ရတာတွေကြောင့် production-friendly Kubernetes UI အဖြစ် သုံးဖို့ သင့်တော်ပါတယ်။

အချိန်ပေးပြီးဖတ်ရှုပေးတဲ့အတွက် ကျေးဇူးတင်ပါတယ်။

kubectl-like Command Structure

eksdemo ဟာ kubectl လိုပဲ သုံးပါတယ်။ example:

• eksdemo get nodegroup

❯ eksdemo get nodegroup --cluster vtmm-cluster-1
+---------+--------+-----------------------+-------+-----+-----+-----------------+-----------+----------------+
|   Age   | Status |         Name          | Nodes | Min | Max |     Version     |   Type    |  Instance(s)   |
+---------+--------+-----------------------+-------+-----+-----+-----------------+-----------+----------------+
| 5 hours | ACTIVE | eks-master-node       |     1 |   1 |   2 | 1.32.9-20250920 | ON_DEMAND | c7i-flex.large |
| 6 hours | ACTIVE | eks-worker-node-group |     1 |   1 |   2 | 1.32.9-20250920 | ON_DEMAND | c7i-flex.large |
+---------+--------+-----------------------+-------+-----+-----+-----------------+-----------+----------------+

ဒီလို တူညီတဲ့ပုံစံကြောင့် kubectl နဲ့ ရင်းနှီးပြီးသားသူတွေအတွက် eksdemo ကို သုံးရတာ အလွန်လွယ်ကူပါတယ်။ get, create, delete ဆိုတာတွေကို အဓိကသုံးပါတယ်။

kubectl ထက် ဘာတွေပိုထူးခြားလဲ။

eksdemo ရဲ့ အဓိက အားသာချက်ကတော့ Kubernetes object တွေကို AWS resource တွေနဲ့ ချိတ်ဆက်ပြီး ပြသနိုင်စွမ်း ဖြစ်ပါတယ်။

• Viewpoint ကွာခြားမှု:

  • kubectl က Kubernetes API ကိုပဲ အဓိကထားပြီး အလုပ်လုပ်ပါတယ်။ Cluster ထဲက resource တွေကိုပဲ ပြသနိုင်ပါတယ်။

  • eksdemo ကတော့ Kubernetes API ရော၊ AWS API ကိုပါ တစ်ပြိုင်တည်း အသုံးပြုပါတယ်။ ဒါကြောင့် Kubernetes resource တစ်ခုနဲ့ ဆက်စပ်နေတဲ့ AWS resource ကိုပါ တစ်ပါတည်း ဖော်ပြပေးနိုင်ပါတယ်။

      ❯ eksdemo get ec2-instance
      +---------+------------+---------------------+--------------------------------+----------------+------------+
      |   Age   |   State    |         Id          |              Name              |      Type      |    Zone    |
      +---------+------------+---------------------+--------------------------------+----------------+------------+
      | 6 hours | running    | i-06dbfbc142668cb88 |                                | c7i-flex.large | us-east-1a |
      | 6 hours | running    | i-0497519f86b5f5981 |                                | c7i-flex.large | us-east-1c |
      +---------+------------+---------------------+--------------------------------+----------------+------------+
    

      ❯ eksdemo get vpc
      +-----------------------+-----------------------------+----------------+--------------+
      |          Id           |            Name             |  IPv4 CIDR(s)  | IPv6 CIDR(s) |
      +-----------------------+-----------------------------+----------------+--------------+
      | vpc-00bce47ab8ea38db0 | *                           | 172.31.0.0/16  | -            |
      +-----------------------+-----------------------------+----------------+--------------+
      * Indicates default VPC
    

  • Viewing Node:

    • kubectl get nodes လို့ရိုက်ရင် Kubernetes node တွေရဲ့ နာမည်၊ status, role, version စတာတွေကိုပဲ မြင်ရပါမယ်။

    • eksdemo get node လို့ရိုက်ရင်တော့ အဲ့ဒီ Kubernetes node ရဲ့ အောက်မှာ run နေတဲ့ EC2 Instance ID, Instance Type, Subnet ID, AMI (Amazon Machine Image) စတဲ့ AWS အချက်အလက်တွေကိုပါ တစ်ခါတည်း တွဲပြီးပြပေးပါတယ်။

        ❯ eksdemo get node --cluster vtmm-cluster-1
        +---------+--------------------+---------------------+----------------+------------+-----------------------+
        |   Age   |        Name        |     Instance Id     |      Type      |    Zone    |       Nodegroup       |
        +---------+--------------------+---------------------+----------------+------------+-----------------------+
        | 6 hours | ip-172-31-33-128.* | i-0497519f86b5f5981 | c7i-flex.large | us-east-1c | eks-master-node       |
        | 6 hours | ip-172-31-89-30.*  | i-06dbfbc142668cb88 | c7i-flex.large | us-east-1a | eks-worker-node-group |
        +---------+--------------------+---------------------+----------------+------------+-----------------------+
        * Names end with "ec2.internal"
      

command usage အသေးစိတ်အတွက်ကိုလည်း eksdemo ရဲ့ repo လေးကို အောက်မှာထည့်ပေးထားပါတယ်။

အားလုံးပဲအချိန်ပေးပြီးဖတ်ရှုပေးတဲ့အတွက်ကျေးဇူးတင်ပါတယ်။

Initializing your control-plane node

ဒီမှာတော့ ကျွန်တော်တို့ Setup လုပ်မှာက Master Node က တစ်လုံးပဲ အသုံးပြုထားတာဆိုတော့အောက်ပါအတိုင်းပဲ အသုံးပြုပြီး run လို့ရပါတယ်။ တကယ်လို့ ကျွန်တော်တို့က kubeadm init နောက်မှာ ဘာ command တွေထည့်ရမလဲဆိုတာကို မသိဘူးဆိုရင်တော့ kubeadm init —help ဆိုပြီးတော့ စစ်ကြည့်နိုင်ပါတယ်။

kubeadm init --help

ဒါဆိုရင်တော့ control-plane အနေနဲ့ အသုံးပြုမယ့် node ပေါ်မှာ cluster ကို initialize စလုပ်တော့မှာပဲဖြစ်ပါတယ်။

kubeadm init --pod-network-cidr 192.168.0.0/16

Output

[init] Using Kubernetes version: v1.33.4
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action beforehand using 'kubeadm config images pull'
W0820 07:57:40.979712   92014 checks.go:846] detected that the sandbox image "registry.k8s.io/pause:3.8" of the container runtime is inconsistent with that used by kubeadm.It is recommended to use "registry.k8s.io/pause:3.10" as the CRI sandbox image.
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local mdo25-master] and IPs [10.96.0.1 10.230.66.136]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [localhost mdo25-master] and IPs [10.230.66.136 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [localhost mdo25-master] and IPs [10.230.66.136 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "super-admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests"
[kubelet-check] Waiting for a healthy kubelet at http://127.0.0.1:10248/healthz. This can take up to 4m0s
[kubelet-check] The kubelet is healthy after 1.508544566s
[control-plane-check] Waiting for healthy control plane components. This can take up to 4m0s
[control-plane-check] Checking kube-apiserver at https://10.230.66.136:6443/livez
[control-plane-check] Checking kube-controller-manager at https://127.0.0.1:10257/healthz
[control-plane-check] Checking kube-scheduler at https://127.0.0.1:10259/livez
[control-plane-check] kube-controller-manager is healthy after 8.305962353s
[control-plane-check] kube-scheduler is healthy after 12.083902309s
[control-plane-check] kube-apiserver is healthy after 16.004208401s
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Skipping phase. Please see --upload-certs
[mark-control-plane] Marking the node mdo25-master as control-plane by adding the labels: [node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers]
[mark-control-plane] Marking the node mdo25-master as control-plane by adding the taints [node-role.kubernetes.io/control-plane:NoSchedule]
[bootstrap-token] Using token: any80c.eqbktrknvek1dklk
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 10.230.66.136:6443 --token any80c.eqbktrknvek1dklk \
        --discovery-token-ca-cert-hash sha256:575ef91069b8af3c00ca7f0fb91f9cf1313aaa070860ac63a3612c197448d4c5

ပြီးသွားရင်တော့ အထက်ပါအတိုင်းမြင်ရမည်ဖြစ်ပြီး Cluster Setup အောင်မြင်သည့်အခါ Your Kubernetes control-plane has initialized successfully! ဆိုပြီးပြနေမည်ဖြစ်သည်။ နောက်ထပ် Kubernetes Cluster ကို manage လုပ်ဖို့အတွက် Kubernetes Config ကို User Directory အောက်က .kube အောက်ထဲသို့ထည့်ပေးရပါမယ်။

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
export KUBECONFIG=/etc/kubernetes/admin.conf

အဲ့ဒါဆိုရင်တော့ Cluster ရဲ့ Node Info ကိုကြည့်ဖို့အတွက် kubectl get nodes command လေးနဲ့ခေါ်ပြီးကြည့်ကြည့်ပါမယ်။

kubectl get nodes
NAME           STATUS     ROLES           AGE     VERSION
mdo25-master   NotReady   control-plane   6m39s   v1.33.3

ဒါဆိုရင်တော့ Cluster Setup လုပ်တယ့် အဆင့်က ပြီးသွားပြီဖြစ်ပါတယ်။ Status မှာ NotReady ဖြစ်နေတာကတော့ Container Network Interface (CNI) Plugin တွေ မသွင်းရသေးသည့်အတွက် NotReady ဖြစ်နေခြင်းဖြစ်ပါသည်။ ဒါကိုတော့ နောက်ထပ် lab တွေကျမှပဲ ပြောပြပေးသွားပါမယ်။ တခြား node တွေ ထပ် join ချင်ရင်တော့ Join ချင်တဲ့ Node မှာ Kubeadm init လုပ်ပြီးတော့ Output မှာပြထားတဲ့ အတိုင်း kubeadm join command ကိုအသုံးပြုပေးရမှာပါပဲဖြစ်ပါတယ်။

kubeadm join 10.230.66.136:6443 --token any80c.eqbktrknvek1dklk \
        --discovery-token-ca-cert-hash sha256:575ef91069b8af3c00ca7f0fb91f9cf1313aaa070860ac63a3612c197448d4c5

Installing and Configuring Prerequisites

Kubernetes Cluster Setup မလုပ်ခင်မှာ လိုအပ်တဲ့ Network Configuration တွေ Cluster အတွက် လိုအပ်သည့် Container Runtime တွေကို အရင်ဆုံးဆုံးအနေနဲ့ Installing လုပ်သွားမှာပဲဖြစ်ပါတယ်။

Enable IPv4 packet forwarding

Network Config အနေနဲ့ကတော့ IPv4 packet forwarding ဆိုသည့် Kernel Option တစ်ခုကို Enable လုပ်ပေးဖို့လိုအပ်ပါတယ်။ IPv4 packet forwarding မရှိခဲ့ရင် network interfaces အမျိုးစုံအကြား network traffic တွေပေးပို့တဲ့အခါမှာ အဆင်မပြေနိုင်တာတွေရှိနိုင်ပါတယ်။ ဥပမာ အနေနဲ့ ပြောရရင် pod-to-pod communication လိုဟာမျိုးတွေပေါ့။ ကျွန်တော်တို့ Cluster ရဲ့ Node A ပေါ်မှာ pod တစ်ခုရှိတယ်ပဲထားပါတော့ဗျာ။ အဲ့ဒီ Node A ရဲ့ pod ကနေ တခြား Node B မှာရှိတယ့် pod ကို packet လေးတွေပို့ချင်တယ်ဆိုပါတော့။ ဒီ packet တွေရောက်ဖို့အတွက်က IPv4 packet forwarding ကို enable လုပ်ထားမှသာ Node A ရဲ့ physical network adapter ကနေတစ်ဆင့် Node B ရဲ့ Network Adapter ကိုဖျက်ပြီးတော့ Node B ရဲ့ pod ကို packet တွေရောက်မှာဖြစ်ပါတယ်။ ဒီ IPv4 packet forwarding kernel option ကို enable လုပ်ထားမှသာ Kubernetes ထဲမှာ အသုံးပြုမယ့် Network CNI Plugin တွေအတွက်လည်းကောင်းမွန်စွာအလုပ်လုပ်မှာ ဖြစ်ပါတယ်။

# sysctl params required by setup, params persist across reboots
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
EOF

# Apply sysctl params without reboot
sudo sysctl --system

net.ipv4.ip_forward ကို 1 ဆိုပြီး setup လုပ်လိုက်တဲ့ ပြန်ခေါ်ကြည့်လို့ output က 1 ပြန်ရတယ်ဆိုရင်တော့ ipv4 packet forwarding enable ဖြစ်နေပါပြီ။

sysctl net.ipv4.ip_forward

Output

ubuntu@mdo25-master:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

နောက်ထပ်အနေနဲ့ cgroups drivers ကို သတ်မှတ်ရမယ်ပေါ့နော်။ ဒါပေမယ့် cgroups drivers ကိုသီးသန့်သွားပြီး လုပ်စရာမလိုတော့ပဲ Kubernetes ရဲ့ v1.22 version ကနေစပြီးတော့ cgroup drivers နေရာမှာ ဘာမှ မသတ်မှတ်ထားခဲ့ရင် kubeadm က default အနေနဲ့ systemd ကိုအသုံးပြုသွားမယ်ဆိုတာမျိုးက ရှိတယ့်အတွက် ထွေထွေထူးထူးတော့ ဘာမှလုပ်စရာမလိုတော့ပါဘူး။ ကျွန်တော်တို့ အသုံးပြုသွားမယ့် Ubuntu Linux Distribution ကလဲ cgroup drivers အနေနဲ့က systemd ကိုပဲသုံးထားတာပဲဖြစ်တယ်။ ဒါကြောင့် cgroup drivers နဲ့ပတ်သက်ပြီးတော့ ဘာမှမသတ်မှတ်တော့ပါဘူး။

Container Runtimes

Container Runtimes အနေနဲ့ကတော့ ဒီ lab မှာ containerd ကိုအသုံးပြုမှာဖြစ်သည့်အတွက် containerd ကို installation လုပ်သွားမှာ ဖြစ်ပါတယ်။

Containerd

Containerd ဆိုတာကတော့ ကျွန်တော်သိတယ့်အတိုင်းပဲ container တွေကို manage လုပ်ဖို့အတွက်သုံးတဲ့ tool တစ်ခုပဲဖြစ်ပါတယ်။ part 1 မှာပြောပြခဲ့အတိုင်း containerd manage လုပ်ဖို့အတွက် ctr ဆိုတယ့် cli tool နဲ့အသုံးပြုပါတယ်။ သူကတော့ docker command တွေနဲ့ အနည်းငယ် different ဖြစ်နေမည်ဖြစ်ပြီး docker က သုံးခဲ့သလိုမျိုးအသုံးပြုချင်ရင်တော့ nerdctl ဆိုတဲ့ cli tool ကိုအသုံးပြုလို့ရပါတယ်။ Kubernetes cluster တစ်ခုထဲမှာ kubelet က container runtime နဲ့ ချိတ်ဆက်ဖို့ Container Runtime Interface (CRI) ကိုသုံးပါတယ်။ အရင်တုန်းကတော့ docker ကို CRI အဖြစ် အသုံးပြုခဲ့တာဖြစ်ပြီးတော့ အခုနောက်ပိုင်းမှာတော့ containerd ကိုသာ CRI အဖြစ် native support လုပ်ပါတယ်။

sudo apt install containerd

containerd ကို install လုပ်တယ့်နေရာမှာ သူရဲ့ dependency ဖြစ်တယ့် runc ကိုပါတစ်ပါတည်း သွင်းသွားမည်ဖြစ်သည်။ containerd ကတော့ high-level runtime ဖြစ်ပြီးတော့ runc ကတော့ low-level runtime အနေနဲ့ ရှိပါတယ်။ containerd က စေခိုင်းသမျှကိုမှ runc အနေနဲ့ container တွေဖန်တီးတဲ့ ကိစ္စရပ်မျိုးတွေကို လုပ်ဆောင်ပေးတာပဲဖြစ်ပါတယ်။

ubuntu@mdo25-master:~$ sudo apt install containerd
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  runc
The following NEW packages will be installed:
  containerd runc
0 upgraded, 2 newly installed, 0 to remove and 62 not upgraded.
Need to get 45.7 MB of archives.
After this operation, 172 MB of additional disk space will be used.
Do you want to continue? [Y/n]

Installation လုပ်ပြီးသွားရင်တော့ containerd service လေးကောင်းမွန်စွာ အလုပ်လုပ်မလုပ်ကို စစ်ချင်သည့် အတွက်

systemctl status containerd

ဆိုပြီး စစ်ကြည့်ပါမယ်။

active (running) ဖြစ်နေပြီ ဖြစ်သည့်အတွက် containerd service က ကောင်းမွန်စွာအလုပ်လုပ်နေပြီလို့ သတ်မှတ်လို့ရပါတယ်။ containerd ကို installation လုပ်ပြီးသွားပြီဆိုတော့ နောက်ထပ်အနေနဲ့ cgroup driver တွေကို configure လုပ်ပေးဖို့လိုအပ်ပါတယ်။

Configuring cgroup driver

cgroup driver ကို configuring လုပ်တဲ့နေရာမှာ ကျွန်တော်တို့ အသုံးပြုထားတဲ့ Ubuntu Linux Distribution က systemd ကိုအသုံးပြုထားတယ့်အတွက် systemd cgroup driver ကို configure လုပ်မှာပဲဖြစ်ပါတယ်။ သူရဲ့ config file လေးကတော့ /etc/containerd/config.toml ဆိုပြီးတော့သွားဆောက်ပေးမှာပဲဖြစ်ပါတယ်။ အရင်ဆုံးအနေနဲ့ /etc အောက်ထဲမှာ containerd ဆိုတယ့် directory တစ်ခုဆောက်ပေးရမှာပဲဖြစ်ပါတယ်။

sudo mkdir /etc/containerd

ပြီးရင်တော့ containerd config ကို create လုပ်ပါမယ်။

containerd config default > /etc/containerd/config.toml

အထက်ပါ command ကိုအသုံးပြုပြီးသွားတဲ့ အခါမှာ /etc/containerd/config.toml ထဲမှာ config တွေ ရောက်နေမည်ဖြစ်ပါသည်။ အဲ့ထဲမှာမှ အောက်ပါပြထားတဲ့အတိုင်း SystemdCgroup နေရာမှာ false ကို true ဆိုပြီး ပြောင်းပေးရမည်ဖြစ်ပါသည်။

ပြီးသွားရင်တော့ config changes ကို containerd ကသိအောင်လို့ containerd service ကို restart ချပေးရပါမယ်။

systemctl restart containerd

ပြီးသွားရင်တော့ containerd service proper ပြန်အလုပ်လုပ်မလုပ်လုပ်ကို systemctl status containerd နဲ့တစ်ချက်စစ်ကြည့်ချင်ရင် စစ်ကြည့်လို့ရပါသည်။ ဘာလို့ပြန်စစ်ခိုင်းတာလဲဆိုတော့ best practice အနေနဲ့လဲ ဖြစ်အောင်တစ်ခုခု changes လုပ်ပြီးတိုင်း restart ချတဲ့အခါ service က ကောင်းမွန်စွာ အလုပ်လုပ် မလုပ်ကို သိစေနိုင်ရန်အတွက်ကြောင့် ဖြစ်ပါတယ်။

Disable Swap

Swap Configuration အနေနဲ့ကတော့ swap ကို disable လုပ်ပေးရမှာပဲဖြစ်ပါတယ်။ node မှာ swap ကိုသာ disable မလုပ်ခဲ့ရင် kubelet service ကို run လိုက်ပြီဆိုတာနဲ့ swap memory ကို detected ဖြစ်နေတဲ့အခါ kubelet service ဟာ ကောင်းကောင်းအလုပ်မလုပ်နိုင်ပဲ fail သွားတာမျိုးတွေ ရှိတတ်ပါတယ်။ အရင်ဆုံးအနေနဲ့ swap က အလုပ်လုပ်နေလားတစ်ချက်အရင်စစ်ကြည့်ပါမယ်။

free -m

Output

root@mdo25-master:~# free -m
               total        used        free      shared  buff/cache   available
Mem:            7936         478        6866           4         843        7457
Swap:              0           0           0

လက်ရှိ ကျွန်တော့်ရဲ့ vm ထဲမှာတော့ swap က မသုံးထားတဲ့အတွက် ထွေထွေထူးထူး ပိတ်စရာတော့မလိုပါဘူး။ တကယ်လို့ Swap ကိုအသုံးပြုထားတယ်ဆိုရင်တော့

swap off -a

အထက်ပါ command ကိုအသုံးပြုပြီး swap ကို disable လုပ်နိုင်သလို /etc/fstab ထဲမှာလည်း swap memory ကို အလုပ်မလုပ်အောင် comment သွားပိတ်ပေးရပါမယ်။

Installing kubeadm, kubelet and kubectl

ဒီအဆင့်မှာတော့ Kubernetes အတွက် လိုအပ်မည့် package ကို စတင် install လုပ်မှာပဲဖြစ်ပါတယ်။

• kubeadm - ကတော့ cluster ကို bootstrap လုပ်ဖို့အတွက်အသုံးပြုရမည့် command ဖြစ်ပါတယ်။

• kubelet - ကတော့ Kubernetes Cluster တစ်ခုလုံးရဲ့ အရေးကြီးဆုံးအစိတ်အပိုင်းတွေထဲက တစ်ခုဖြစ်ပြီး Node တိုင်းမှာ အလုပ်လုပ်တဲ့ service တစ်ခုဖြစ်ပါတယ်။

• kubectl - ကတော့ kubernetes cluster ကို manage လုပ်ဖို့ command line utility tool ပဲဖြစ်ပါတယ်။

ကျွန်တော်တို့က Kubernetes Cluster ကို Ubuntu Linux Distribution ကိုအသုံးပြုမှာဆိုတော့ Debian-based distributions တွေအတွက် Kubernetes Repo တွေကို add ပေးရပါမယ်။ ဒီ Lab မှာတော့ Kubernetes ရဲ့ latest version ဖြစ်တဲ့ v1.33 ကို အသုံးပြုမည်ဖြစ်ပါတယ်။

Update the apt package index and install packages needed to use the Kubernetes apt repository

sudo apt-get update
# apt-transport-https may be a dummy package; if so, you can skip that package
sudo apt-get install -y apt-transport-https ca-certificates curl gpg

Download the public signing key for the Kubernetes package repositories.

# If the directory `/etc/apt/keyrings` does not exist, it should be created before the curl command, read the note below.
# sudo mkdir -p -m 755 /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.33/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

Add Kubernetes apt repository

echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.33/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

Update the apt package index, install kubelet, kubeadm and kubectl, and pin their version:

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

Enable the kubelet service before running kubeadm:

sudo systemctl enable --now kubelet

အဲ့တာဆိုရင်တော့ Kubernetes Cluster Setup လုပ်ဖို့အတွက် လိုအပ်တာတွေအကုန် installation လုပ်ပြီးပြီဖြစ်သည့်အတွက် Part 3 မှာတော့ Cluster Setup လုပ်တဲ့ဟာကို ထပ်မံရေးသားပေးသွားပါမယ်။

အချိန်ပေးပြီးဖတ်ရှုပေးတဲ့အတွက်ကျေးဇူးတင်ပါတယ်။

What is Kubernetes?

Kubernetes ကတော့ Open Source Container Orchestration Platform တစ်ခုဖြစ်ပြီး Google ကနေ Developed လုပ်ခဲ့တာပဲဖြစ်ပါတယ်။ အခုလက်ရှိမှာတော့ Kubernetes ကို Cloud Native Computer Foundation က နေ ကြီးကြပ်နေတာပဲဖြစ်ပါတယ်။ Kubernetes ကတော့ container orchestration tool တစ်ခုဖြစ်တယ့်အတွက် Orchestration Platform အနေနဲ့ပဲ အခြေခံပြီး ထွက်လာတာပေါ့နော်။ Container တွေကို manage လုပ်ဖို့အတွက်ကျတော့ သူ့ထဲမှာမပါဘူး။ ဒါကြောင့် Container Runtime နဲ့ပတ်သက်ပြီးတော့ Container Runtime ဖြစ်တယ့် Docker ပေါ်ကို Relies လုပ်ရတယ်ပေါ့နော်။ နောက်ပိုင်းမှာတော့ ဘာတွေဖြစ်လာလဲဆိုတော့ Kubernetes က Dockershim ကိုဖြုတ်ပြီးတော့ Containerd ကို သူရဲ့ Container Runtime အဖြစ်သုံးလာခဲ့ပါတယ်။ Kubernetes က Support လုပ်တဲ့ Container Engine မှာဆိုရင် Containerd အပြင် CRI-O ဆိုတာလဲရှိသေးတယ်။ Docker Engine ကိုပဲဆက်ပြီးအသုံးပြုချင်တယ်ဆိုရင်လဲ cri-dockerd ဆိုတယ့် tool ကို ကြားခံအသုံးပြုလို့ရပေမယ့် Containerd focus ဖြစ်တယ့်အတွက် တခြားဟာတွေတော့အများကြီးမပြောတော့ပါဘူး။

CRI-O ကိုတော့ Redhat က Develop လုပ်ထားတဲ့ container runtime ဖြစ်ပြီးတော့ သူကကျ containerd လိုမဟုတ်ပဲ low-level ဖြစ်တယ့် runc ကို တန်းပြီးတော့ manage လုပ်နိုင်တယ်။ ပိုပြီးတော့ lightweight ဖြစ်တယ့် runtime အနေနဲ့ ရှိနေတယ်ပေါ့နော်။ Containerd မှာဆိုရင် low-level ဖြစ်တယ့် runc ကို တိုက်ရိုက် manage မလုပ်နိုင်ပဲ containerd-shim ကနေမှတစ်ဆင့် runc ကို manage လုပ်တယ်။ runc ကနေမှ container တွေဖန်တီးတဲ့ ကိစ္စမျိုးတွေကို လုပ်ဆောင်ပေးတာပေါ့နော်။ CRI-O ကတော့ Redhat ရဲ့ Openshift မှာပဲ အဓိကသုံးတာဖြစ်တယ်။ ဒါမယ့် ကျွန်တော်တို့ Kubernetes Community Version မှာလဲ Containerd အစား CRI-O ကိုလဲ သုံးချင်ရင် သုံးလို့ရတယ်ပေါ့နော်။ ဒီမှာတော့ ကျွန်တော်တို့က Containerd ကိုပဲ သုံးသွားမှာဖြစ်တယ့်အတွက် Containerd နဲ့ပတ်သက်တာတွေပဲ ပြောပါမယ်။

ကျွန်တော်တို့ Environment မှာ Containerd ကိုအသုံးပြုထားတယ်ဆိုရင် containerd တွေကို manage လုပ်ဖို့အတွက် ctr ဆိုတယ့် tool ကိုအသုံးပြုပြီး manage လုပ်ရတယ်။ ctr ကတော့ containerd နဲ့ တွဲပြီးအလုပ်လုပ်တဲ့ cli tool ဖြစ်တယ်။ ဒါမယ့် သူက Docker မှာအသုံးပြုခဲ့တယ့် Command တွေနဲ့ နည်းနည်းကွဲတယ်။ Docker မှာလို manage လုပ်တဲ့ပုံစံအတိုင်းကို ctr မှာသွားပြီးတော့ သုံးလို့မရဘူး။ ဒါကြောင့် docker လိုပဲ manage လုပ်ချင်တယ်ဆိုရင်တော့ nerdctl ဆိုတယ့် tool ကိုအသုံးပြုလို့ရတယ်။ Nerdctl က Containerd ကို manage လုပ်တဲ့ docker compactible cli tool တစ်ခုဖြစ်တယ်။ အောက်မှာတော့ Nerdctl ရဲ့ github repo လေးထည့်ပေးထားပါတယ်။ အသေးစိတ်လေ့လာချင်ရင် လေ့လာလို့ရပါတယ်။

Kubernetes Distribution

Kubernetes Distribution တွေကတော့ အများကြီးရှိကြပါတယ်။ Enterprise မှာဆိုရင် Redhat OpenShift, Mirantis Kubernetes Engine, VMware မှာဆိုရင်လဲ Tanzu စသဖြင့်ပေါ့နော်။ Cloud မှာဆိုရင်လဲ သူ့ရဲ့ Cloud Provider ပေါ်မူတည်ပြီး Google မှာဆိုရင် GKE, AWS မှာဆိုရင် EKS, Azure မှာဆိုရင် AKS စသဖြင့်ရှိကြတယ်။ ဒါတွေကတော့ Managed Kubernetes Platform တွေပဲဖြစ်ပါတယ်။ Community Version မှာဆိုရင်တော့ ကျွန်တော်တို့ အခုအသုံးပြုမယ့် Open Source Kubernetes ပေါ့။ သူ့ကိုတော့ တစ်နည်းအားဖြင့် Vanilla Kubernetes လို့လဲခေါ်ကြတယ်။ ကျွန်တော်တို့ရဲ့ Organization မှာ Container နဲ့ပတ်သက်တဲ့ application တွေကို develop လုပ်ပြီးအသုံးပြုတော့မယ်ပေါ့နော်။ အရင်ဆုံးအနေနဲ့ စတင်ပြီးစဥ်းစားရမှာကတော့ ကျွန်တော်တို့ ဘယ် Kubernetes Distribution ကိုသုံးသင့်လဲဆိုတာမျိုးပေါ့။ ထားပါတော့ ကျွန်တော်တို့ Infrastructure မှာ Existing အနေနဲ့ VMware vSphere လိုမျိုးရှိတယ်ဆိုရင် နောက်ထပ် VMware Tanzu ကိုပဲ Add on Subscription ထပ်ဝယ်ပြီးသုံးမလားပေါ့။ ဒါမှမဟုတ် ကျွန်တော်တို့ အသုံးပြုနေတယ့် Product တွေက Redhat နဲ့ပတ်သက်ပြီး Redhat JBoss တို့ တခြား Red Hat 3scale API Management လိုဟာမျိုးတွေ သုံးထားတာမျိုးတွေရှိရင်တော့ ကျွန်တော်တို့အနေနဲ့ စဥ်းစားသင့်တာက Redhat OpenShift Container Platform လိုဟာမျိုးကို စဥ်းစားရမှာပေါ့နော်။ ဒီလိုပဲ ကျွန်တော်တို့ Product တွေက AWS မှာ သုံးထားတယ်ဆိုရင်တော့ EKS လိုမျိုး Elastic Kubernetes Service လိုဟာမျိုးကိုအသုံးပြုသင့်တယ်ပေါ့နော်။ ဒါတွေကတော့ ကိုယ့်ရဲ့ Organization nature ပေါ်မူတည်ပြီးတော့ ရွေးချယ်ရမယ့် ကိစ္စဖြစ်ပါတယ်။ ဒီလောက်ဆိုရင်တော့ Kubernetes Distribution ရွေးချယ်တာနဲ့ ပတ်သက်ပြီးသိမယ်လို့ထင်ပါတယ်။

ကျွန်တော်တို့က Open Source ဖြစ်တယ့် Kubernetes ကိုပဲ အသုံးပြုမှာဆိုတော့ Open Source နဲ့ပတ်သက်တာကိုပဲဆက်ပြီးတော့ သွားကြပါမယ်။ Local Kubernetes Cluster ကို Setup လုပ်ဖို့အတွက် Tool တွေကတော့ မျိုးစုံရှိတယ်ပေါ့နော်။ Minikube ဆိုတာကိုပဲသုံးမလား။ Kind ဆိုတယ့် tool ကိုပဲသုံးမလားပေါ့နော်။ Kind ကတော့ Kubernetes In Docker ပေါ့ Kubernetes Cluster Setup လုပ်တဲ့အခါမှာ Node တွေလိုတယ်။ အဲ့ဒါကိုမှ အဲ့ဒီ Node တွေကို Docker Container အနေနဲ့ ပြန်ပြီး run တဲ့ပုံစံမျိုးအနေနဲ့သုံးပါတယ်။ ကျွန်တော်တို့ အသုံးပြုမှာကတော့ Production အတွက် ready ဖြစ်တယ့် kubeadm ဆိုတယ့် tool ကိုပဲ အသုံးပြုသွားမှာပဲဖြစ်ပါတယ်။ လောလောဆယ်တော့ စာအရမ်းရှည်သွားမှာဆိုးတဲ့အတွက် ဒီလောက်နဲ့ပဲ ခဏရပ်ထားပါမယ်။ Part -2 မှာတော့ Kubeadm နဲ့ Cluster Setup လုပ်တယ့် အကြောင်းကို ထပ်ပြောပြသွားမှာပဲဖြစ်ပါတယ်။

အချိန်ပေးပြီးဖတ်ရှုသည့်အတွက်ကျေးဇူးတင်ပါတယ်။

• Import

• Synchronization

• Export တို့ပဲဖြစ်ပါတယ်။ ဒီ section မှာအဓိကပြောပြသွားမှာကတော့ Export လုပ်နေစဥ်အတွင်းမှာဖြစ်နိုင်တယ့် error များကို ပြောပြသွားမှာပဲဖြစ်ပါတယ်။

Microsoft Entra Connector ကနေ synchronization လုပ်နေစဥ် အတွင်း Identity တွေကို Microsoft Entra Id ကို export လုပ်နေချိန်မှာ error ဖြစ်နိုင်ပါတယ်။ Entra Connector မှာ name format အနေနဲ့ vitaltechmm.onmicrosoft.com သတ်မှတ်ခဲ့ပြီးတော့ Microsoft Entra ID ကို (add, update, delete) စသည့် operation တွေကို export လုပ်နေစဥ်အတွင်းမှာ Microsoft Entra connect (Sync Engine) ရဲ့ Microsoft Entra directory failed ခြင်းကြောင့်ပဲဖြစ်ပါတယ်။ ဖြစ်နိုင်ခြေရှိတဲ့ error တွေကတော့ -

• Data mismatch errors

• ObjectTypeMismatch

• Duplicate attributes

• Data validation failures

• LargeObject တို့ပဲဖြစ်ပါတယ်။

1. Data Mismatch Errors (InvalidSoftMatch)

Microsoft Entra Connect (sync engine) ကနေမှ directory object တွေကို Local AD ကနေ Entra ID ကို add or update စတဲ့ အလုပ်တွေကို instruction စပေးတယ်ပေါ့ဗျာ။ Sync လုပ်လိုက်တဲ့အချိန်မှာ Local AD က sourceAnchor attribute နဲ့ Microsoft Entra ID မှာရှိတဲ့ object ရဲ့ ImmutableId attribute နှစ်ခုကို တိုက်စစ်ပြီး match ဖြစ်သွားတယ်ပေါ့ဗျာ။ အဲ့လိုဖြစ်သွားတာမျိုးကို Hard Match လို့ခေါ်ပါတယ်။ Hard Match ဖြစ်သွားရင်တော့ Entra Connect က existing Entra Id object ကို update လုပ်ပါမယ်။

နောက်ထပ် အနေနဲ့ Microsoft Entra ID ကိုရောက်လာတဲ့ sourceAnchor attribute နဲ့ immutalbleId attribute ကို Hard Match လုပ်တယ်ပေါ့ဗျာ။ ဒါပေမယ့် any object တိုင်းမှာ match ဖြစ်နေတာကို ရှာမတွေ့တဲ့အခါ နောက်ထပ်အနေနဲ့ ProxyAddresses နဲ့ UserPrincipalName attributes တွေ match ဖြစ်မဖြစ်ထပ်ရှာတယ်။ Soft Match ဖြစ်သွားတဲ့အခါမှာလဲ Entra Connect က existing Entra ID object နဲ့ on-premises AD object ကို link လုပ်ဖို့ ကြိုးစားတယ်။ အဲ့ဒါကိုကျတော့ Soft Match လို့ခေါ်ပါတယ်။

InvalidSoftMatch Error ဖြစ်ရသည့် အကြောင်းရင်း ကတော့ Example - johndoe@vitaltechmm.com ဆိုတဲ့ user ကို Entra ID မှာ manually create လုပ်ထားတယ်ပေါ့ဗျာ။ On-Prem AD မှာ johndoe@vitaltechmm.com ဆိုတဲ့ user ကရှိနေတယ်။ အဲ့ဒီ user ကို sync တဲ့အခါမှာ Entra ID မှာရှိတယ့် johndoe user နဲ့ email address တူနေပါလိမ့်မယ်။ အဲ့ဒါကြောင့် Hard Match ဖြစ်မှာမဟုတ်ဘူး။ ဘာလို့လဲဆိုတော့ sourceAnchor နဲ့ immutableId မတူတဲ့အတွက်ကြောင့်ပဲဖြစ်ပါတယ်။ ဒါကြောင့်မလို့ သူက Soft Match လုပ်ဖို့ ထပ်ကြိုးစားပါလိမ့်မယ်။ အဲ့မှာတော့ UserPrincipalName(UPN) or ProxyAddresses တွေက တူနေတယ့်အတွက် soft match ဖြစ်လိမ့်မယ်။ ဒါပေမယ့် sourceAnchor နဲ့ immutableId က မတူတဲ့အတွက် InvalidSoftMatch error ဖြစ်ရခြင်းပဲဖြစ်ပါတယ်။

Entra Connect က တူညီတဲ့ Entra ID object နဲ့ on-premises AD object ကို link မလုပ်နိုင်ဘူး။ ဒါကြောင့် duplicate user ဖြစ်နိုင်တယ် (Entra ID မှာ manually create ထားတဲ့ user နဲ့ sync လုပ်လာတဲ့ user နှစ်ခု ဖြစ်နေပါလိမ့်မယ်)။

How To Fix InvalidSoftMatch Error

Entra ID မှာ manually create ထားတဲ့ user ကို delete လုပ်ပြီး sync ပြန်လုပ်ပါ။ ဒါမှမဟုတ် User ကို delete မလုပ်ချင်ရင်တော့ On-premises AD user ရဲ့ sourceAnchor ကို Entra ID user ရဲ့ immutableId နဲ့တူအောင် လုပ်ပါ။ ဒါမှ Hard Match ဖြစ်ပြီးတော့ InvalidSoftMatch error မဖြစ်တော့ပါဘူး။

အချိန်ပေးပြီး ဖတ်ရှုပေးသည့်အတွက်လည်း ကျေးဇူးတင်ပါတယ်ခင်ဗျ။ ကျန်တဲ့ Error Type ကိုတော့ နောက်ထပ် blog တွေမှာ ထပ်ရေးသွားပေးပါ့မယ်ခင်ဗျ။

Author By: Sc3p73R

Reference: Microsoft Documentation

Overview

CrowdStrike Falcon Sensor ကို ဒီ lab မှာတော့ Helm Chart ကိုအသုံးပြုပြီး install လုပ်မှာဖြစ်ပါတယ်။ Helm Chart ကတော့ kubernetes ပေါ်တွင် falcon sensor install လုပ်ရန် အတွက် လိုအပ်တဲ့ kubernetes resource တွေကို pre-configured လုပ်ပေးထားမည်ဖြစ်ပြီးတော့ helm chart နဲ့ installation လုပ်သည့်အခါတွင် falcon-sensor pod လေးကတော့ Daemonset အနေနဲ့ run သွားမှာပဲဖြစ်ပါတယ်။ ဒီနေရာမှာတော့ Helm တို့ Daemonset အကြောင်းတွေကိုတော့ ပြောသွားတော့မှာမဟုတ်ပါဘူး။

Prerequisites

Prerequisites အနေကတော့ အောက်ပါအတိုင်းပဲဖြစ်ပါသည်။

• you have Helm 3.x or later installed

• your kubernetes cluster nodes are either x86_64 or ARM64, but not both

• your kubernetes vendor supports Helm 3

• you must be a cluster administrator to deploy a Helm chart to the cluster.

• By default, the Helm chart is installed in the default namespace. Best practice is to create a new namespace. See Install the chart archive for info.

• The Falcon sensor for Linux as a DaemonSet should be used as the container image to deploy to a Kubernetes node.

• The Falcon sensor for Linux as a DaemonSet must run as a privileged container so that the sensor can access the kernel.

• The Falcon sensor for Linux as a DaemonSet should be deployed to a Kubernetes environment that grants node access or installation via a Kubernetes DaemonSet.

• The Falcon sensor for Linux as a DaemonSet creates /opt/CrowdStrike on the Kubernetes nodes. Do not delete this folder.

နောက်ထပ်သိရမှာကတော့ CrowdStrike က Region ပေါ်အခြေခံပြီးတော့ သူ့ရဲ့ Cloud Domain URL တွေကလည်းမတူညီပါဘူး။ ဒါတွေကိုသိအောင်လို့ ကျွန်တော်အောက်မှာ List လုပ်ပေးထားပါတယ်။

Cloud domains for US-1

ts01-b.cloudsink.net
lfodown01-b.cloudsink.net
lfoup01-b.cloudsink.net
https://falcon.crowdstrike.com
https://assets.falcon.crowdstrike.com
https://assets-public.falcon.crowdstrike.com
https://api.crowdstrike.com
https://firehose.crowdstrike.com

CrowdStrike Cloud US-2 domains

ts01-gyr-maverick.cloudsink.net
lfodown01-gyr-maverick.cloudsink.net
lfoup01-gyr-maverick.cloudsink.net
https://falcon.us-2.crowdstrike.com
https://assets.falcon.us-2.crowdstrike.com
https://assets-public.falcon.us-2.crowdstrike.com
https://api.us-2.crowdstrike.com
https://firehose.us-2.crowdstrike.com

CrowdStrike Cloud EU-1 domains

ts01-lanner-lion.cloudsink.net
lfodown01-lanner-lion.cloudsink.net
lfoup01-lanner-lion.cloudsink.net
https://falcon.eu-1.crowdstrike.com
https://assets.falcon.eu-1.crowdstrike.com
https://assets-public.falcon.eu-1.crowdstrike.com
https://api.eu-1.crowdstrike.com
https://firehose.eu-1.crowdstrike.com

CrowdStrike Cloud US-GOV-1 domains

ts01-laggar-gcw.cloudsink.net
sensorproxy-laggar-g-524628337.us-gov-west-1.elb.amazonaws.com
lfodown01-laggar-gcw.cloudsink.net
ELB-Laggar-P-LFO-DOWNLOAD-1265997121.us-gov-west-1.elb.amazonaws.com
https://falcon.laggar.gcw.crowdstrike.com
laggar-falconui01-g-245478519.us-gov-west-1.elb.amazonaws.com
https://api.laggar.gcw.crowdstrike.com
https://firehose.laggar.gcw.crowdstrike.com
falconhose-laggar01-g-720386815.us-gov-west-1.elb.amazonaws.com

CrowdStrike Cloud US-GOV-2 domains

ts01-us-gov-2.cloudsink.crowdstrike.mil
lfodown01-us-gov-2.cloudsink.crowdstrike.mil
https://falcon.us-gov-2.crowdstrike.mil
https://api.us-gov-2.crowdstrike.mil
https://firehose.us-gov-2.crowdstrike.mil

တို့ပဲဖြစ်ပါတယ်။

Multi-architecture sensor image

CrowdStrike ရဲ့ Falcon Sensor ကတော့ Linux image version 7.15 နဲ့ နောက်ပိုင်းတွေမှာတော့ Multi-Architecture နဲ့လုပ်ထားတဲ့ image တွေဖြစ်လာပါတယ်။ ဆိုလိုရင်းကတော့ Falcon Sensor ရဲ့ ဒီ Image တစ်ခုတည်းကိုပဲ x86_64 and aarch64 nodes တွေပေါ်မှာ တစ်ပြိုင်နက်အသုံးပြုလို့ရလာတာပဲဖြစ်ပါတယ်။ နမူနာအနေနဲ့ အောက်မှာ Linux image version 7.15 နဲ့ 7.14 ကို ယှဥ်ပြပေးထားပါတယ်။

The Falcon sensor for Linux Image 7.15 and later

Syntax: falcon-sensor:<release_number>-<build_number>-<baseImage_number>.falcon-linux.Release.<cloud-env>

Example: falcon-sensor:7.15.0-15501-1.falcon-linux.Release.US-1

The Falcon sensor for Linux Image 7.14 and earlier

Syntax: falcon-sensor:<release_number>-<build_number>-<baseImage_number>.falcon-linux.<architecture>.Release.<cloud-env>

Example: falcon-sensor:7.14.0-14401-1.falcon-linux.x86_64.Release.US-1

Example အတိုင်း 7.14 နဲ့ အစောပိုင်း version တွေဆိုရင် falcon sensor image တွေကို x86_64 Architecture အတွက်ဆို release သပ်သပ် aarch64 အတွက်ဆို release သပ်သပ်ထုတ်ခဲ့ပါတယ်။ 7.15 version ကနေစပြီးတော့ falcon sensor image တွေကို သပ်သပ်မထုတ်တော့ပဲ multi-architecture အဆင်ပြေအောင် ထုတ်ခဲ့တာပဲဖြစ်ပါတယ်။

Deploy with Helm

Step 1: Create an API client ID and secret

အရင်ဆုံး အနေနဲ့ CrowdStrike falcon sensor ရဲ့ image ကို pull လို့ရဖို့အတွက် ကျွန်တော်တို့ရဲ့ CrowdStrike Portal ထဲကနေ API client id နဲ့ secret ကို create လုပ်ပေးရမှာပဲဖြစ်ပါတယ်။ ဘယ်မှာသွား create ရမလဲဆိုတော့ https://falcon.crowdstrike.com ထဲကို ဝင်ပြီးတော့ Support and resources > Resources and tools > API clients and keys ထဲမှာ အသစ် create လုပ်ပေးရပါမယ်။

ရလာတဲ့ api clients and keys ကို မှတ်ထားပြီးတော့ ကျွန်တော်တို့ရဲ့ စက်ထဲမှာပဲ environment variables ကြေညာပေးရမှာဖြစ်ပါတယ်။

export FALCON_CLIENT_ID=<YOUR_FALCON_CLIENT_ID>

export FALCON_CLIENT_SECRET=<YOUR_FALCON_CLIENT_SECRET>

Step 2: Get your CID with checksum

နောက်တစ်ဆင့်အနေနဲ့ Falcon console ထဲကနေပဲ Customer ID checksum ကိုသွားယူပြီး variable အဖြစ်ကြေညာပေးရမှာပဲဖြစ်ပါတယ်။

export FALCON_CID=<YOUR_CID_WITH_CHECKSUM>

Pull the image from the CrowdStrike registry

နောက်ထပ်အနေနဲ့ CrowdStrike registry က falcon-sensor image ကို pullလုပ်ရမှာပဲဖြစ်ပါတယ်။

curl -sSL -o falcon-container-sensor-pull.sh "https://raw.githubusercontent.com/CrowdStrike/falcon-scripts/main/bash/containers/falcon-container-sensor-pull/falcon-container-sensor-pull.sh"
chmod +x falcon-container-sensor-pull.sh

ပြီးသွားရင်တော့ ကျွန်တော်တို့စက်ထဲရောက်လာသည့် falcon-container-sensor-pull.sh script လေးကို အောက်ပါအတိုင်း run ပေးရပါမယ်။

./falcon-container-sensor-pull.sh \
  -u $FALCON_CLIENT_ID \
  -s $FALCON_CLIENT_SECRET \
  --list-tags \
  -t falcon-sensor

အဲ့တာဆိုရင်တော့ OUTPUT အနေနဲ့

{
  "name" : "falcon-sensor",
  "tags" : [ "6.35.0-13206.falcon-linux.x86_64.Release.US-2", 
… 
"7.15.0-15501-1.falcon-linux.Release.US-2" ]
}

အခုလိုမျိုးပြမှာပဲဖြစ်ပါတယ်။

နောက်ထပ်အနေနဲ့ CrowdStrike registry နဲ့ image tag တို့ကို variable အနေနဲ့ သတ်မှတ်ပေးရမှာဖြစ်ပါတယ်။

Set variables for the CrowdStrike registry and the image tag:

export FALCON_IMAGE_REPO=registry.crowdstrike.com/falcon-sensor/<cloud_tag>/release/falcon-sensor
export FALCON_IMAGE_TAG=7.15.0-15501-1.falcon-linux.Release.<cloud_region>

Note: <cloud_tag> မှာတော့ မိမိရဲ့ crowdstrike cloud domain ကိုထည့်ပေးရမည်ဖြစ်ပါသည်။ region အလိုက် <cloud_tag> တွေက ကွဲမှာဖြစ်ပြီးတော့ us-1, us-2, eu-1, govcloud စသဖြင့် မိမိ region အလိုက်ထည့်ပေးရမှာပဲ ဖြစ်ပါတယ်။ <cloud_region> လဲထိုနည်းတူစွာပါပဲ <cloud_region> မှာ သူရဲ့သက်ဆိုင်ရာ region - US-1, US-2, EU-1, GOV-1 တို့ကို ထည့်ပေးရပါမယ်။ ကျွန်တော်ကတော့ ပုံပါအတိုင်း US-2 region ဖြစ်တယ့်အတွက် <cloud_tag> နေရာမှာ us-2 ကို ထည့်ပေးရမည်ဖြစ်ပြီး <cloud_region> နေရာမှာ US-2 ဆိုပြီး change ပေးရမှာပဲဖြစ်ပါတယ်။

အပေါ်က variable သတ်မှတ်ခဲ့တယ့် အဆင့်တွေ အကုန်လုပ်ဆောင်ပြီးရင်တော့ CrowdStrike registry ကနေ image ကို directly pull လုပ်လို့ရဖို့အတွက် pull token တွေကို create လုပ်ပေးရမှာပဲဖြစ်ပါတယ်။

Set variables for the CrowdStrike registry:

./falcon-container-sensor-pull.sh \
-u $FALCON_CLIENT_ID \
-s $FALCON_CLIENT_SECRET \
--dump-credentials

အခုလိုမျိုး run လိုက်တာနဲ့ Output အနေနဲ့ CrowdStrike registry username နဲ့ password ရမှာပဲဖြစ်ပါတယ်။

OUTPUT

CSRegistryUsername:fc-<userName>
CSRegistryPassword:ABC...123

အဲ့ဒီရလာတဲ့ registry Username နဲ့ Password ကို Image Pull လို့ရဖို့အတွက် variables သတ်မှတ်ပေးရမှာပဲဖြစ်ပါတယ်။

Create the pull token to pull images directly from the CrowdStrike registry:

export PARTIALPULLTOKEN=$(echo -n "$FALCON_ART_USERNAME:$FALCON_ART_PASSWORD" | base64 -w 0)
export FALCON_IMAGE_PULL_TOKEN=$(echo "{\"auths\":{\"registry.crowdstrike.com\":{\"auth\":\"$PARTIALPULLTOKEN\"}}}" | base64 -w 0)

Note: The pull token for the CrowdStrike registry does not expire.

Step 4: Add the CrowdStrike Helm chart client

နောက်တစ်ဆင့်အနေနဲ့ CrowdStrike ရဲ့ Helm Chart repo ကိုထည့်သွင်းပေးရမှာဖြစ်ပါတယ်။

helm repo add crowdstrike https://crowdstrike.github.io/falcon-helm
helm repo update
helm repo list

helm repo list လုပ်ကြည့်လိုက်တာနဲ့ crowdstrike repo ကိုမြင်နေရမှာပဲဖြစ်ပါတယ်။

NAME         URL
crowdstrike  https://crowdstrike.github.io/falcon-helm

နောက်ထပ် Falcon sensor repo ကို variables သတ်မှတ်ပေးရပါမယ်။

Set a variable for the Falcon sensor Helm chart:

export FALCON_SENSOR_REPO=crowdstrike/falcon-sensor

Step 5: Install the Falcon sensor on your cluster

အပေါ်ကအဆင့်တွေအားလုံးပြီးသွားပြီဆိုရင်တော့ Falcon sensor ကို ကျွန်တော်တို့ရဲ့ kubernetes cluster ထဲမှာ Install လုပ်လို့ရပီပဲဖြစ်ပါတယ်။

Create a namespace for the sensor and set the security context:

export FALCON_NAMESPACE=falcon-system
kubectl create namespace $FALCON_NAMESPACE
kubectl label ns --overwrite $FALCON_NAMESPACE pod-security.kubernetes.io/enforce=privileged

နောက်ထပ်တစ်ဆင့်အနေနဲ့ pod တွေကို label ထိုးပေးမှာပဲဖြစ်ပါတယ်။ ဒါကတော့ Optional ဖြစ်ပြီးတော့ namespace ထဲမှာရှိနေတဲ့ pod တွေကို specific configuration နဲ့ resources တွေအတွက်ကို policies တွေသတ်မှတ်ရလွယ်ကူစေမှာပဲဖြစ်ပါတယ်။

Install the Falcon sensor in the namespace:

helm install falcon-sensor $FALCON_SENSOR_REPO \
  -n $FALCON_NAMESPACE \
  --set falcon.cid=$FALCON_CID \
  --set node.image.repository=$FALCON_IMAGE_REPO \
  --set node.image.tag=$FALCON_IMAGE_TAG \
  --set node.image.registryConfigJSON=$FALCON_IMAGE_PULL_TOKEN

Install လုပ်တာ successfully ဖြစ်ရင်တော့ အောက်ပါအတိုင်း output ရမှာပဲဖြစ်ပါတယ်။

NAME: falcon-sensor
LAST DEPLOYED: Wed Oct 11 14:20:01 2023
NAMESPACE: falcon-sensor
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thank you for installing the CrowdStrike Falcon Helm Chart!
Access to the Falcon Linux and Container Sensor downloads at registry.crowdstrike.com are
required to complete the install of this Helm chart. If an internal registry is used instead of registry.crowdstrike.com.
the containerized sensor must be present in a container registry accessible from Kubernetes installation.
CrowdStrike Falcon sensors will deploy across all nodes in your Kubernetes cluster after
installing this Helm chart. The default image name to deploy a kernel sensor to a node is `falcon-node-sensor`.
When utilizing your own registry, an extremely common error on installation is accidentally forgetting to add your containerized
sensor to your local image registry prior to executing `helm install`. Please read the Helm Chart's readme
for more deployment considerations.

အဲ့တာဆိုရင်တော့ falcon-sensor pod တွေ running ဖြစ်မဖြစ်သိအောင်လို့ စစ်ကြည့်ပါမယ်။

kubectl get pod -n falcon-system

Output:

kubectl get pod -n falcon-system
NAME                  READY   STATUS    RESTARTS       AGE
falcon-sensor-2z8nf   1/1     Running   13 (66d ago)   120d
falcon-sensor-ckz89   1/1     Running   9 (66d ago)    120d
falcon-sensor-nfjk2   1/1     Running   7 (66d ago)    120d
falcon-sensor-wvz85   1/1     Running   9 (66d ago)    120d
falcon-sensor-zpjn2   1/1     Running   1 (66d ago)    112d

running ဖြစ်နေပီဆိုတော့ ကျွန်တော်တို့ ရဲ့ deployment state ကအောင်မြင်သွားပီပဲဖြစ်ပါတယ်။

ကျွန်တော်ရေးခဲ့တာ အမှားများပါခဲ့ရင်လဲ လာရောက်ပြောကြားနိုင်ပါတယ်ခင်ဗျ။ အားလုံးပဲ အချိန်ပေးပြီးဖတ်ရှုပေးတယ့်အတွက်ကျေးဇူးတင်ပါတယ်။

Author By: Sc3p73R

Reference: CrowdStrike Documentation

1. Delete Old License Directory

2. Download License Key

3. Install License

4. Review License

Delete Old License Directory.

Download License Key.

အရင်ဆုံး ကျွန်တော်တို့က Licenses Folder ကို Directory မှာ ရှာပြီးဖျက်ပေးရမှာဖြစ်ပါတယ်။ ဖျက်ပြီးသွားရင် အောက်က Step တွေအတိုင်း တစ်ဆင့်ချင်းလုပ်သွားရုံပါပဲ။

License Key ကိုလဲ Portal ကနေ Generate & Download လုပ်ထားပေးဖို့လဲလိုပါတယ်။

Install License Key

A) Go To Backup Exec --> Installation and Licensing

B) Select --> Install Features and Licenses on this Backup Exec Server.

C) Installing Licenses using .SFL files (Offline Installation):

•Click Import License File.

•Select the .SLF file and click Open.

•Click Next.

•Select a Backup Exec edition license to install and click Next.

•Select required features to install and click Next.

•Select the additional languages to be installed and click Next.

•Review install summary and click Install.

•Click Yes to close Backup Exec console and continue installation.

•Installation progress will be displayed.

•Click Finish.

Reviewing License information:

A) Go To Backup Exec --> Installation and Licensing

B) Select License Information

C) License Information page is displays:

ဒါဆိုရင် License Key ထည့်တာ Success ဖြစ်ပါတယ်။

အားလုံးပဲ အချိန်ပေးပြီး ဖတ်ရှုပေးတဲ့အတွက်လဲ ကျေးဇူးတင်ပါတယ် ခင်ဗျ။

Author By PoneMyat

ပထမဦးဆုံး Zabbix ကို Download & Install လုပ်ထားရပါမယ်။

Install လုပ်ပြီးရင်တော့ ကျွန်တော်တို့ စပြီး Config ချလို့ရပါပြီ။

Configure Zabbix server

1. Open Zabbix server configuration file

vi /etc/zabbix/zabbix_server.conf

2. Change StartVMwaeCollectors parameter

    ### Option: StartVMwareCollectors
           #       Number of pre-forked vmware collector instances.
           #
           # Mandatory: no
           # Range: 0-250
           # Default:
           # StartVMwareCollectors=0
   
           StartVMwareCollectors=2
   

3. Restart Zabbix Server.

    systemctl restart zabbix-server
   

Configure Zabbix Frontend

1. Login to Zabbix

2. Create Host in Zabbix.

   In the Host name field, enter a host name (for example, "VMware environment").

   In the Templates field, type or select the "VMware FQDN" (or "VMware") template.

   In the Host groups field, type or select a host group (for example, a new host group "VMware").

   

   • In the Macros tab, set the following host macros:

     {$VMWARE.URL} - VMware service (vCenter or ESXi hypervisor) SDK URL (https://servername/sdk)

     {$VMWARE.USERNAME} - VMware service user name

     {$VMWARE.PASSWORD} - VMware service {$VMWARE.USERNAME} user password

   • 

3. Click Add to create host.

View collected metrics

Zabbix is already monitoring your VCenter.

To View Create Host, navigate to Data Collection » Hosts

To View Collected Metrics, navigate to Monitoring » Hosts

အခုဆိုရင်တော့ Zabbix ကို အသုံးပြုပြီး ကိုယ့်ရဲ့ VCenter ကို Monitor လုပ်လို့ရပြီပဲဖြစ်ပါတယ်။

အဆင်ပြေကျမယ်လို့ မျှော်လင့်ပါတယ် ။ အားလုံးပဲ အချိန်ပေးပြီး ဖတ်ရှုပေးတဲ့အတွက်လဲ ကျေးဇူးတင်ပါတယ် ခင်ဗျ ။

Author By PoneMyat

Demo အနေနဲ့ကိုတော့ ကျွန်‌‌တော်ကတော့ html file တစ်ခုကိုအသုံးပြုပြီး static website အနေနဲ့ host လုပ်ပြသွားပါမယ်. So let’s get started ။

ပထမဆုံးအနေနဲ့ Amazon Portal ‌ကိုအရင်ဝင်ပြီး‌ ပြီး‌တော့ S3 bucket တစ်ခုကို create အရင်လုပ်ပါမယ် ။

click Search bar and type “S3”

and then click s3 button and create a bucket

create bucket လုပ်ပြီးသွားတဲ့အခါ ပထမဆုံး bucket အတွက် name တစ်ခုပေးရပါမယ် ။ Name ကတော့ ကိုယ်အဆင်ပြေတဲ့ naming ကိုပေးလို့ရပါတယ် ။

ပြီးသွားရင်တော့ ဒီနေရာမှာသတိထားရမှာက Block public access ပါပဲ, AWS က default အရ bucket ကို public access မရအောင် block လုပ်ထားပါတယ် ။

အကယ်၍ block public access ကို off မလုပ်ခဲ့ရင်တော့ user တွေက bucket ကို public ကနေ access လုပ်လို့ရမှာမဟုတ်ပါဘူး ။ ဒီတော့ ကျွန်တော်တို့ block access ကို untick လုပ်ပြီး‌တော့ current setting changes လုပ်ထားတာကို acknowledge လုပ်ပါတယ်ဆိုပြီး box မှာ tick လုပ်‌ပေးရပါမယ် ။

ပြီးရင်တော့ ကျန်တဲ့ setting တွေကို default အတိုင်းထားပြီး bucket ကို create လုပ်လိုက်ပါမယ် ။

ဒါဆိုရင်တော့ S3 dashboard မှာ create လုပ်ထားတဲ့ bucket လေးပေါ်လာပါပြီ ။

အခုကျွန်တော်တို့ backet create လုပ်ပြီးသွာပြီဆိုတော့ website အတွက်လိုအပ်တဲ့ content file ကို upload လုပ်ပါမယ် ။ Upload လုပ်ဖို့အတွက် create လုပ်ထားတဲ့ bucket ကို double click လုပ်ပြီးတော့ဝင်ပြီး file ကို upload လုပ်ပေးရပါမယ် ။

Demo မှာ‌‌တော့ html file ‌‌လေးကို upload လုပ်ပြီးသုံးထားပါတယ်. Add file ကိုနှိပ်ပြီး content file ကို ရွေးပြီး upload လုပ်လိုက်ယုံပါပဲ ။

ပြီးရင်တော့ upload ကို click လုပ်ပြီး save လုပ်လိုက်ရပါမယ် ။

Now the file has been uploaded.

File upload လုပ်ပြီးသွားတဲ့အခါကျရင် bucket က static website hosting လုပ်လို့ရအောင် static website hosing feature ကို on လုပ်ပေးရပါမယ် ။ Feature ကို on လုပ်ဖို့ဆိုရင် Properties ထဲကိုသွားရပါမယ် ။

Scroll down to the end . Static website hosting ဆိုပြီးတွေ့ပါလိမ့်မယ် ။ Edit button ကို click လုပ်ပြီးတော့ enable box ကို tick လုပ်ပေးပြီး‌‌တော့ index document ဆိုတဲ့နေရမှာ index.html ဆို ပြီး ဖြည့်ရပါမယ် ပြီးရင်တော့ကျန်တာကို default အတိုင်းထားပြီး save changes လုပ်လိုက်ပါမယ် ။

အခု static website hosting feature ကို enable လုပ်ပြီးသွားပြီဆိုတော့ နောက်ထက်တစ်ခုအနေနဲ့ bucket အတွက် policy တခုကို attach လုပ်ပေးရပါမယ် ။ Policy attach လုပ်ဖို့ဆိုရင် Permission tab ထဲက bucket policy ထဲမှာသွားပြီး edit လုပ်ပေးရပါမယ် ။

Edit လုပ်တဲ့အခါမှာ policy ရဲ့ resource နေရာမှာကိုယ့်ရဲ့ bucket name ကိုထည့်ပေးရပါမယ် ။ ဒီနေရာမှာတော့ ကျွန်တော် bucket create လုပ်ထားတဲ့ name ဖြစ်တဲ့ vitaltechmyanmar ဆိုတာကိုထည့်လိုက်မှာဖြစ်ပါတယ် ။

ပြီးသွားရင်တော့ scroll down ‌and save changes လုပ်လိုက်ပြီးရင်ရပါပြီ ။ ဒါဆိုရင် ကျွန်တော်တို့ website hosting လုပ်တဲ့ step တွေပြီးသွားပြီဆိုတော့ website ကို access တာအဆင်ပြေလားမပြေလားတချက်ကြည့်ကြည့်ရအောင် ။

ကျွန်တော်တို့ create လုပ်ထားတဲ့ website က accessရမရစမ်းဖို့အတွက်ဆိုရင်တော့ bucket ထဲက index.html ထဲကိုဝင် ပြီးတော့ properties ထဲက Object URL ကို copy လုပ်ပြီး တခြား tab တစ်ခုမှာ paste လုပ်ကြည့်ပါမယ် ။

ဒါဆို ကျွန်တော်တို့ host လုပ်ထားတဲ့ static website လေးကို public ကနေ access လုပ်လိုရသွားပါပြီ .......

အခုဆိုရင်တော့ကျွန်တော်တို့က static website တစ်ခုကို amazon ရဲ့ s3 bucket ကိုအသုံးပြုပြီးတော့ လွယ်လွယ်ကူကူတည်ဆောက်သွားတာဖြစ်ပါတယ် ။ အဆင်ပြေကျမယ်လို့ မျှော်လင့်ပါတယ် ။ အားလုံးပဲ အချိန်ပေးပြီး ဖတ်ရှုပေးတဲ့အတွက်လဲ ကျေးဇူးတင်ပါတယ် ခင်ဗျ ။

ကျနော်ဒီနေ့ Sharing လုပ်ပေးမှာကတာ့ Google Cloud Platform (GCP) ပေါ်မှာ terraform နဲ့ Infrastructure တစ်ခုကို ဘယ်လို တည်ဆောက်မလဲ ဆိုတာ ပြော‌‌ပြ ပေးသွားမှာဖြစ်ပါတယ် ။

ပထမဆုံး အနေ နဲ့ Terraform ဆိုတာဘာလဲ၊ Terraform ကို ဘာလို့ သုံးသင့်တယ် ဆိုတာ အကျဉ်းချုပ်အနေ နဲ့ မိတ်ဆက်ပေးပါမယ်။ ဒီမှာတာ့ Terraform ကို deep မပြောတော့ပါဖူး ။ ဘာလို့ဆို ဒါကို ဖတ်ပြီဆိုတည်းက Terraform ကို ဘာကြောင့် သုံးလဲ ဆိုတာ သိမယ် ထင်လို့ပါ ။ အခု blog မှာလဲ Terraform ကို အသေးစိတ် ရှင်းပြတာမဟုတ်လို့ Terraform နဲ့ Infrastructure ဘယ်လို တည်ဆောက်မလဲ ဆိုတာ ပြောပြမှာ ဖြစ်လို့ပါ။

Terraform Overview

Terraform ဆိုတာ HashiCorp ကထုတ် ပေးထားတဲ့ Infrastructure as Code (IaC) နည်းပညာတစ်ခုဖြစ်ပါတယ်။ ဒီ tool ကိုအသုံးပြုပြီး Infrastructure ကို building, changing, managing လုပ်နိုင်ပြီး safe ဖြစ်စွာ ထပ်ခါထပ်ခါ အသုံးပြုနိုင်ပါတယ် ကိုယ့်လူတို့ ဘယ်လောက်မိုက်လဲ ဒီ tool ကြီးက အမြဲတမ်း ထပ်ခါခါ ခေါင်း မကိုက်ချင်တဲ့ ကိုယ်တွေ အတွက် အဆင်ပြေတယ် ။Operator နဲ့ Infrastructure team တွေက ဒီ tool ကိုအသုံးပြုပြီး environment တွေကို automated deployment လုပ်ဖို့ (HCL )လို့ခေါ်တဲ့ သုံး HashiCorp Configuration Language ကိုသုံးထား တယ် ။ HCL က Human-readable ဖြစ်တဲ့ အတွက် ဖတ်ရတာ လွယ်ကူတယ် ကျက်ရတာ လွယ်ကူတာ မဟုတ်ဖူးနော် ။ IaC လို့ ပြောခဲ့တယ် နော် IaC ဆိုတာက User Interface မှာ သုံးရတာမဟုတ်ပဲ file ထဲ မှာ Configuration ထည့်ပြီး Infrastructure ကို management လုပ်ရတာကို ပြောချင်တာ ပါ။ Configuration ထဲမှာ Resources တွေထည့်ရမှာ Resource type/name တို့ Resources ဆိုတာ Infrastructure ရဲ့ အစိတ် အပိုင်းတွေ ဖြစ်တဲ့ VM, Security Group, Network Interface, etc...blah blah ပေါ့နော်။ အဲ့မှာ Resources ဆိုလို့ ပြောရဦးမယ် Terraform က ဘယ် Provider အတွက်လဲ ဆိုတာ အရင် အသိပေးရမှာပါ AWS လား Azure လား GCP လား Docker လား တစ်ခြား Provider တွေလဲ အများကြီးရှိပါသေးတယ် အဲ့တာမှ ဘယ် Provider ရဲ့ resources ဆိုတာ သိမှာ ဖြစ်ပါတယ်။

Terraform မှာပုံမှန် လုပ်ဆောင်ရမယ့် flow လေးတွေပြောပြပါမယ်

-Scope : ပေးထားတဲ့ Project အတွက် ဘယ် resources တွေလဲ ဆိုတာ အရင် Confirm လုပ်ရပါမယ်

-Author : Scoped parameter ပေါ်မူတည်ပြီး HCL နဲ့ Configuration file ရေးရပါမယ်

-Initialize : Project Directory အတွင်းမှာ Terraform init command run လိုက်မှသာ Project အတွက် လိုအပ်တဲ့ Provider plug-in download လုပ်သွားမှာဖြစ်ပါတယ်။

-Plan : Terraform plan ဆိုတဲ့ command run ရမှာပါ ဘာလို့ဆို ငါတို့ ဘာလုပ်ချင်တယ် ဆိုတာ ကြိုတင် ပြပေးတာပါ အကယ်၍ လိုအပ်တာ/မလိုအပ်တာ ရှိရင် ပြန်ပြင်လို့ ရအောင်ပါ။ အမှားအယွင်း နည်းအောင် ပေါ့။

-Apply : Terraform apply command က Configuration ထဲ အတိုင်း အကုန် အကောင်အထည် ဖော်တော့မှာပါ ။ State file ပါ တစ်ခါတည်း ဖန်တီး ပေးသွားမှာပါ။

State file ဆိုတာက တော့ လုပ်သမျှ Configuration တွေကို အဲ့ထဲမှာ မှတ်ပြီး ပြန်သုံးလို့လဲ ရသလို modify လဲ ပြန်လုပ်လို့ရပါတယ် ။ အဲ့ State file ကြောင့် Project တစ်ခုလုံး တစ်ခါထဲလဲ destroy လုပ်လို့ရပါတယ် ၊အမှားအယွင်းဖြစ်မှာ စိုးရိမ်ရင် backup လုပ် ကိုလုပ်သင့်ပါတယ်။ ‌‌

State file ရဲ့ feature တွေက Meta Data တွေကို Map လုပ်ပေးတယ်၊ Performance ပိုကောင်းစေတယ် (cache function)၊ Syncing လုပ်ပေးတယ် ၊ State Locking လုပ်ပေးတယ် ၊ Workspaces ခွဲပေးထားတယ် ၊ ဘာတွေလဲ ဆိုတာကတော့ ရှာဖတ်လိုက်တာ့ ရှင်းပြရင် အရမ်းရှည်သွားမှာဆိုးလို့။

ကဲ အဲ့လောက် ဆိုရင် အခုလုပ်ပြမဲ့ Infrastructure တည်ဆောက်တာကို စလိုက်ကြရအောင်ပါ။ အဓိက Project တစ်ခုလုံး မဟုတ်ပါဖူး အခြေခံ နဲ့ Sample အနေနဲ့ ပြမှာ ဖြစ်ပါတယ် ။

Step 1 : Create the configuration files

ပထမဆုံး ဒီ Lab အတွက်လိုအပ်တဲ့ Configuration file တွေအရင် တည်ဆောက်ပါမယ်။

Google Cloud Console ကို၀င်ပါ ။Activate Cloud Shell ကိုနှိပ်ပါ ။

အရင်ဆုံး account name ကိုစစ်ပါ ။

gcloud auth list

ကိုယ် အသုံးပြုမဲ့ project id မှန်မမှန်စစ်ပါ။

gcloud config list project

mkdir -p modules/instances modules/storage
touch main.tf variables.tf
touch modules/instances/{instances.tf,outputs.tf,variables.tf}
touch modules/storage/{storage.tf,outputs.tf,variables.tf}

main.tf
variables.tf
modules/
└── instances
    ├── instances.tf
    ├── outputs.tf
    └── variables.tf
└── storage
    ├── storage.tf
    ├── outputs.tf
    └── variables.tf

အခုလက်ရှိမှာ main.tf နဲ့ variables.tf က Root အနေနဲ့ ရှိနေပါတယ် သူတို့က အဓိကလုပ်ဆာင်မှာပါ။ Modules အောက်မှာရှိနေတဲ့ instances နဲ့ Storage ကို module အနေနဲ့ ခေါ်သုံးမှာ ဖြစ်ပါတယ် local module ပေါ့ဗျာ။ Terraform Registry မှာ လဲ module တွေခေါ်သုံးလို့ရပါတယ် ။ဒီ lab မှာလဲ registry ကခေါ်သုံးတာပြ ပေးမှာပါ။အောက်က ပုံထဲက အတိုင်း Cloud Shell မှာ Open Editor လေးရှိပါတယ် နှိပ်လိုက်ပါ

Step 2 : Build infrastructure

Cloud Shell မှာ ပေါ်နေတဲ့ Editor ဆိုတာလေးဖွင့်လိုက်ပါ ကျနော်တို့ခုနက ဆောက်ထားတဲ့ root variables.tf ဆိုတဲ့ file ထဲမှာ variables တွေကိုကြေညာပါမယ်။

variable "region" {
  default = "us-east4"
}

variable "zone" {
  default = "us-east4-a"
}

variable "project_id" {
  default = "your project id"
}

‌ဒါက instance နဲ့ storage modules ရဲ့ variables တွေဖြစ်ပါတယ်။ အဓိကကတော့ root ရဲ့ variables ကိုပဲ main.tf ကယူသုံးမှာဖြစ်ပါတယ်။ instance နဲ့ storage modules ရဲ့ variables.tf file မှာထည့်ပါမယ်။

variable "region" {
  type = string
}

variable "zone" {
  type = string
}

variable "project_id" {
  type = string
}

main.tf file မှာ ကိုယ်သုံးမည့် Provider ကို အရင်ကြေညာပေးရမှာပါ

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 4.0"
    }
  }
}

provider "google" {
  project = var.project_id
  region  = var.region
  zone    = var.zone
}

VPC တည်ဆောက်ဖို့ အတွက် main.tf file ထဲသို့ ထပ်ထည့်ပါ။

resource "google_compute_network" "vpc_network" {
  name = "terraform-network"
  auto_create_subnetworks  = false
}
resource "google_compute_subnetwork" "subnet_1" {
  name          = "subnet-1"
  ip_cidr_range = "10.10.10.0/24"
  region        = var.region
  network       = google_compute_network.vpc_network.self_link
}

Provider အတွက် လိုအပ်တဲ့ plug-in download ယူရန်နှင့် အကောင်ထည် ဖော်ဖို့အတွက် အောက်ပါ commands တွေ ကို တစ်ခုချင်းဆီ Run ပါ။

terraform init
terraform plan
terraform apply

Google Cloud Console ကနေ စစ်ကြည့်ပါ terraform-network ဆိုတဲ့ VPC လေး create လုပ်ပြီးပါပြီ

Step 3 : Create Instances

Instances Modules မှ instances များကို ခေါ်သုံးမှာ ဖြစ်တဲ့ အတွက် instances.tf file ထဲ instances အတွက် Configuration ကို အရင် ရေးရပါမယ်

resource "google_compute_instance" "instance-1" {
  name         = "instance-1"
  machine_type = "e2-standard-2"
  boot_disk {
    initialize_params {
      image = "debian-11-bullseye-v20240815"
    }
  }
  network_interface {
    network = var.network_name
    subnetwork = var.subnet_name
  }
}

resource "google_compute_instance" "instance-2" {
  name         = "instance-2"
  machine_type = "e2-standard-2"
  boot_disk {
    initialize_params {
      image = "debian-11-bullseye-v20240815"
    }
  }
  network_interface {
    network = var.network_name
    subnetwork = var.subnet_name
  }
}

instances.tf file ထဲမှာ network_interface မှ ခေါ်သုံးဖို့ အတွက် instances module ရဲ့ variables.tf file ထဲ ထည့်ပါ

variable "network_name" {
  description = "The name of the Google Compute Network"
  type        = string
}
variable "subnet_name" {
  type = string
}

Instance module ကို main.tf file တွင် ညွှန်းပေးရပါမယ်။ အဲ့တာမှ instance.tf file ထဲ configuration ကိုယူသုံးမှာဖြစ်ပါတယ်။ Source မှန်အောင် ထည့်ဖို့ လိုအပ်ပါတယ်။

module "instances" {
  source    = "./modules/instances"
  region    = var.region
  zone      = var.zone
  project_id = var.project_id
  network_name = google_compute_network.vpc_network.self_link
  subnet_name = google_compute_subnetwork.subnet_1.self_link
}

အပြောင်းအလဲ လုပ်ပြီးတိုင်း လုပ်ဆောင်ပါ။

terraform init
terraform plan
terraform apply

instance-1 နှင့် instance-2 ဖန်တီးပြီး ဖြစ်ကြောင်း တွေ့ရပါလိမ့်မယ်

cloud console တွင် instance-1 ကိုနှိပ်ပြီး ပေးထားတဲ့ machine type, boot_disk, Network မှန်/မမှန်စစ်ဆေးကြည့်ပါ

Step 4 : Import Infrastructure

Import Infrastructure ဆိုတာကတော့ ကျနော်တို့က user interface ကနေ manual ဆောက်ထားတဲ့ objects တွေက Terraform နဲ့ ဆက်စပ်မူ မရှိပါဖူး ။ Manual ဆောက်ထားခဲ့ resources တွေကို Terraform နဲ့ manage လုပ်ချင်တယ် ဆိုရင် Terraform state file ထဲကို import လုပ်ပေးရမှာ ဖြစ်ပါတယ် ။ ဘယ်လို လုပ်ရမလဲ ပြောပြ ပေးပါမယ်။ အရင်ဆုံး ကိုယ် import လုပ်ချင်တဲ့ VM ရဲ့ machine type, boot-disk, network_interface, တွေကို configuration file မှာ တူအောင် ရေးရပါမယ် ။ အဲ့မှာ အရေးကြီး တာက meta_startup_script နဲ့ allow_stopping_for_update ကို ထည့်ပေးရမှာပါ ။ ကျနော် example တစ်ခု ပြပါမယ်

resource "google_compute_instance" "tf-instance-1" {
  name         = "tf-instance-1"
  machine_type = "e2-standard-2"
  boot_disk {
    initialize_params {
      image = "debian-11-bullseye-v20240815"
    }
  }
  network_interface {
    network = "default"
  }
  metadata_startup_script = <<-EOT
    #!/bin/bash
  EOT
  allow_stopping_for_update = true
}

ကျနော် အခု ပြထားတာ example configuration ပါ machine type တွေ name တွေ boot_disk တွေ network_interface တွေ ကိုယ် import လုပ်ချင်တဲ့ instance အသုံးပြုထားတဲ့ အတိုင်း ပြန် ပြင်ပါ ။ ပြောချင်တာ ရောက်လာပါပြီ metadata_startup_script ဆိုတာ VM up တဲ့အခါ အလိုအလျောက် လုပ်ဆောင်မည့် script ပါ bash script နဲ့လုပ်မယ်လို့လဲ ကြေညာထားပါတယ် အဲ့ VM ထဲမှာ run software တွေ setting တွေ configure ချထားတာ တွေ automated ပြန်လုပ်ပေးမယ် ပြောတာပါ ။ allow_stopping_for_update ကို true လို့ သတ်မှတ်ထားတာက instance ကိုပြန်ဖျက်ပြီး အသစ် ပြန်ဖန်တီး စရာမလိုပဲ update လုပ်ဖို့ အတွက်ပါ ။ဒါက instance configuration ကို downtime မရှိပဲ ပြင်ဖို့ အထောက်အကူ ပေးတာပါ ။ ဒီလောက်ဆို နားလည်မယ် ထင်ပါတယ် ။ကျနော်တို့ ဆက်သွားပါမယ် ။

အဲ့တာ တွေ အကုန်ပြီးသွားရင် import စလုပ်ပါမယ် ။ instance တွေကို import လုပ်ပါမယ် ။ အခု အောက်မှာ ပြထားတဲ့ Terraform import command နဲ့ import လုပ်ပါမယ် ။ ဒီနေရာမှာ မင်းအခု module အောက်မှာ ရေးထားတဲ့ configuration နဲ့ import လုပ်ချင်တဲ့ instance ရဲ့ instance id နဲ့ map လုပ်ပေးပါ ။ VM ပဲ သုံးသုံး instance ပဲ သုံး သုံး အတူတူပဲ လို့ယူဆပေးပါ အခေါ်အဝေါ်ပဲ ကွဲတာမို့။import လုပ်ရင် သတိထားရမှာက import လုပ်ထားတဲ့ instance တိုင်းကို Terraform က life cycle management ဖြစ်တဲ့ အတွက် Terraform destroy run အကုန် ပျက်မှာဖြစ်ပါတယ်

စာဖတ်သူ import လုပ်ချင်တဲ့ instance ရဲ့ id ကိုယူပြီး အောက်ပါ command အတိုင်း run ပါ

terraform import module.instances.google_compute_instance.tf-instance-1 <tf-instance-1-id>

terraform init 
terraform apply

Step 5 : Configure a remote backend

ဒါက ဘာကို ‌‌‌ပြောချင်တာလဲ ဆိုရင် Terraform state file ကို remote ကနေ ယူသုံးပြီး modify လုပ်မယ် create လုပ်မယ်ပေါ့ဗျာ ။ အရင်ဆုံး google bucket တစ်ခု ဆောက်လိုက်မယ် ဗျာ။ storage module မှာ storage.tf file မှာ configuration ရေးကြမယ် let's go ။ bucket name က unique ဖြစ်ရမယ် နော် ။

resource "google_storage_bucket" "bucket_01" {
  name                        = "qwiklabs-gcp-00-3712a4245aff"
  location                    = "US"
  force_destroy               = true
  uniform_bucket_level_access = true
}

နောက်တစ်ဆင့် module ကို main.tf file ထဲမှာ ပြန်ညွှန်းမယ် ။

module "storage" {
  source    = "./modules/storage"
  project_id = var.project_id
  region    = var.region
  zone = var.zone
}

terraform init
terraform plan
terraform apply

Bucket တစ်ခု ဖန်တီးထားကြောင်း တွေ့ရပါလိမ့်မယ် ။ bucket name က unique ဖြစ်လို့ ကျနော် က project id ထည့်သုံးထားတာပါ။

နောက်တစ်ဆင့် cloud bucket ပေါ် remote backend ကိုတင်ဖို့ main.tf file ထဲ ထည့်ရမယ် ။ ပြောရမယ် ဆို ဒီ Terraform state file တစ်ခုထဲ မှာ store လုပ်ထားတဲ့ configuration တွေ Workspace လို့ခေါ်တယ် ပေါ့ဗျာ။

terraform {
  backend "gcs" {
    bucket = "qwiklabs-gcp-00-3712a4245aff"
    prefix = "terraform/state"
  }
}

terraform init

အခုဆို Terraform ဆိုတဲ့ state file ရဲ့ folder လေးရာက် နေပါပြီ

Remote backend ကို local ကို revert ပြန်လုပ်ချင်ရင် main.tf file တွင် အောက်ပါ configuration ကို change ပါ

terraform {
  backend "local" {
    path = "terraform/state/terraform.tfstate"
  }
}

-migrate-state argument ကို ထည့်ပေးရမယ် ။

terraform init -migrate-state

ls command နဲ့ စစ်ကြည့်ပါ local ထဲကို ပေးထားတဲ့ PATH အတိုင်း ရောက် နေပါပြီ

Step 6 : Modify and update infrastructure

နမူနာ အနေ နဲ့ Infrastructure ကို Modify လုပ်ပြမယ် ။ အခု လုပ်ပြမှာက instance တစ်ခုကို ထပ် add ပြပါမယ် ။ Instance.tf file ထဲတွင် ထပ် ထည့်ပါ။

resource "google_compute_instance" "instance-3" {
  name         = "instance-3"
  machine_type = "e2-standard-2"
  boot_disk {
    initialize_params {
      image = "debian-11-bullseye-v20240815"
    }
  }
  network_interface {
    network = var.network_name
    subnetwork = var.subnet_name 
  }
}

terraform apply

အခုဆို instance-3 ဆိုတဲ့ instance လေးတစ်လုံးထပ်ရာက် နေပါပြီ

နောက်တစ်ခုက အခု ထပ်ထည့်လိုက်တဲ့ instance ကိုပဲ ဖျက်ပြမှာပါ ။ Instance.tf file မှာ instance အသစ် အတွက် Configuration ကို ဖျက်ပစ် လိုက် ။ ဒါမှ မဟုတ် # sign ခံပြီး comment ပိတ် လိုက် ရပါတယ် ။ ပြီးသွားရင် Terraform apply command ပြန်run ပါ။

terraform apply

configuration ပြင်ပြီး apply ပြန်စစ် ကြည့်ပါ instance မရှိတော့ကြောင်း တွေ့ရပါလိမ့်မယ်

ဒါက ကျနော်တို့က Terraform ကနေ manage လုပ်တာ ဖြစ်ပါတယ် ။အကယ်၍ ကျနော်တို့ က user interface ကနေ change လိုက် တယ် tag တို့ label တို့ အစရှိ သဖြင့်ပေါ့ ဗျာ အဲ့တာဆို ရင် state file မှာပါ update ဖြစ်အောင် ‌‌‌‌refresh ဆိုတဲ့ command နဲ့ update လုပ်ရမှာဖြစ်ပါတယ်။ ဥပမာ အနေ နဲ့ ကျနော် အပေါ် ‌create လုပ်ထားခဲ့ တဲ့ bucket file ကို label ထည့်ပြပါမယ် ။ Bucket ကို အမှန်ခြစ် ပေးပြီး LABELS ကိုနှိပ်လိုက်ပါ

ဒီမှာဆို Add Label နှိပ်ပြီး key နဲ့ value ဆိုပြီးပေးခဲ့ပါတယ် ။Save ခဲ့ပါ

ပြီးရင် Terraform state file မှာ update လုပ်ဖို့ refresh ဆိုတဲ့ command ကို runပါ

terraform refresh

ပြီးရင် Terraform state file မှာ update ဖြစ်လား ပြန်ကြည့်ဖို့ အောက်ပါ command ကို run ပါ

terraform show

အခုဆို label ပေးထားခဲ့တဲ့ key နဲ့ value ကိုမြင်နရပါပြီ

Step 7 : Configure a Firewall

အခု တစ်ခါ မှာ တော့ အပေါ်မှာ ဆောက်ထား ခဲ့တဲ့ VPC network ကို All IP (0.0.0.0/0)ကို Port 80 ကနေ ingress connection ကို allow ပေးမှာ ဖြစ်ပါတယ် ။ ဒီတော့ main.tf file မှာ firewall resources တွေကို ကြေညာပါမယ် ။

resource "google_compute_firewall" "tf-firewall" {
  name    = "tf-firewall"
  network = google_compute_network.vpc_network.name

  allow {
    protocol = "tcp"
    ports    = ["80"]
  }

  source_ranges = ["0.0.0.0/0"]
}

terraform init
terraform apply

အခုဆို tf-firewall ဆိုတဲ့ firewall rule ကိုတွေ့ရပါလိမ့်မယ်

Step 8 : Use a module from the Registry

အခု ပြောပြ ပေးမဲ့ အရာက တော့ Network module ကို Terraform Registry ကနေ ခေါ်သုံးမှာ ဖြစ်တယ် ။ အ‌‌ပေါ်မှာ ပြောပြခဲ့တာတွေက local မှာပဲ module ကို တည်ဆောက်ပြီး ပြောပြခဲ့တာတွေပါ ။ Version 6.0 ကို သုံးပြပါမယ် ။ Main.tf file ထဲမှာ ထည့်ပါ ။ Subnets 2 ခုနဲ့ ဆောက်ပြ ပေးထားပါတယ် ။

module "vpc" {
  source  = "terraform-google-modules/network/google"
  version = "6.0.0"

  project_id   = var.project_id
  network_name = "test-vpc"
  routing_mode = "GLOBAL"

  subnets = [
    {
      subnet_name   = "subnet-01"
      subnet_ip     = "10.10.20.0/24"
      subnet_region = var.region
    },
    {
      subnet_name   = "subnet-02"
      subnet_ip     = "10.10.30.0/24"
      subnet_region = var.region
    },
  ]
}

Terraform Registry ရဲ့ source ကိုမှန် အောင်ထည့်ပါ။ အောက်မှာ link ချပေးထားပါတယ် ။

https://registry.terraform.io/modules/terraform-google-modules/network/google/6.0.0

terraform init
terraform apply

Terraform Registry မှ ယူသုံးထားတဲ့ Network Module နဲ့ create လုပ်ထားတဲ့ VPC လေး တွေ့ရပါလိမ့်မယ်

Step 9 : Destroy Infrastructure

Terraform နဲ့ ဖန်တီးတဲ့ အရာတွေ အကုန်ဖျက်ချင်ရင် destroy ဆိုတဲ့ command နဲ့ ဖျက်လို့ပါတယ် ။ command run ပြီးတဲ့ အခါ စတင်ဖျက်မဲ့ resources list တွေ ပြပြီး အတည်ပြချက် တောင်းဆိုပါတယ် ။terraform state file ကနေ ကြည့်ပြီး အကုန် ဖျက်ပစ်မှာ ဖြစ်ပါတယ်

terraform destroy

ကျနော် ဆောက်ထားခဲ့တဲ့ resources တွေ အကုန်ဖျက်သွားမည် ဖြစ်တယ် ။Google Cloud Console တွင် ပြန်ကြည့်ကြည့်ပါ ဘာမှ မရှိတော့ ဖူး ကြည့်မ နေနဲ့ 😁

ဒီစာကို ဒီလောက်နဲ့ ပဲ နားပါမယ် စာဖတ်သူ တွေ တစ်ခုခု ရမယ်လို့ မျော် လင့်ပါတယ် ။

Author by Kyaw Thet Htun

My Linkedin Profile - https://www.linkedin.com/in/kyaw-thet-htun/

အရင်ဆုံး ကျွန်တော်တို့ Text Document အလွတ်တစ်ခု Create လုပ်ပါမယ်။ ပြီးရင် ကျွန်တော် command လေး ထည့်ပါမယ်။ Command ကို အောက်မှာ copy ယူပါ။

@echo off & cls

set IP=8.8.8.8

:top

PING -n 1 %IP% | FIND "TTL="

IF ERRORLEVEL 1 (
    SET OUT=4F
    echo Request timed out.
) ELSE (
    SET OUT=2F
)

color %OUT%

ping -n 2 -w 1000 127.0.0.1 >nul

GoTo top

set IP = 8.8.8.8 နေရာမှာ ကိုယ် Ping ထားချင်တဲ့ Server IP ဒါမှမဟုတ် Website (amazonaws.com) စသဖြင့် ကိုယ်ထားချင်တဲ့ဟာကို ပြောင်းထားလို့ရပါတယ်။

ပြီးရင် ကျွန်တော်တို့ Text File လေးကို Save ပါမယ်။ Save တဲ့အခါ bat file အနေနဲ့ Extension ပြောင်းပြီး save ပေးရပါမယ်။

ဒီ ping.bat File လေးကို Double Click or Run As Administrator နှိပ်ပြီး Run လိုက်မယ်ဆိုရင်

reply ပြန်ရင် Background က စိမ်းနေမှာဖြစ်ပြီး

reply မပြန်ရင် Background က အနီရောင်ဖြစ်နေမှာပါ။

Ping ပြန်မိသွားရင်တော့ Background က ပြန်စိမ်းလာမှာပဲဖြစ်ပါတယ်။

ဒီ Tips & Trick လေးက လွယ်ကူပြီး ရိုးရှင်းတဲ့အတွက် အသုံးတည့်မယ်လို့ မျှော်လင့်ပါတယ်။ အားလုံးပဲ အချိန်ပေးပြီး ဖတ်ရှုပေးတဲ့အတွက်လဲ ကျေးဇူးတင်ပါတယ် ခင်ဗျ။

Author By PoneMyat