အလုပ်မလုပ်ဘဲ Kubernetes အစုအဝေးကို အဆင့်မြှင့်တင်ခြင်း။

သင်၏ Kubernetes အစုအဝေးအတွက် အဆင့်မြှင့်တင်ခြင်းလုပ်ငန်းစဉ်

တစ်ချိန်ချိန်တွင်၊ Kubernetes အစုအဝေးကို အသုံးပြုသည့်အခါ၊ လည်ပတ်နေသော node များကို အပ်ဒိတ်လုပ်ရန် လိုအပ်သည်။ ၎င်းတွင် ပက်ကေ့ဂျ်အပ်ဒိတ်များ၊ kernel အပ်ဒိတ်များ၊ သို့မဟုတ် အသစ်သော စက်ရုပ်ပုံများကို ဖြန့်ကျက်ခြင်း ပါဝင်သည်။ Kubernetes အခေါ်အဝေါ်အရ ဒါကို ခေါ်ပါတယ်။ "ဆန္ဒအရ အနှောင့်အယှက်ပေးခြင်း".

ဤပို့စ်သည် ပို့စ် 4 ခုတွဲ၏ တစ်စိတ်တစ်ပိုင်းဖြစ်သည်-

1. ဒီပို့စ်။
2. Kubernetes အစုအဝေးရှိ pods များကို မှန်ကန်စွာ ပိတ်ခြင်း။
3. ၎င်းကို ဖျက်လိုက်သောအခါ ပေါ့တ်တစ်ခု၏ နှောင့်နှေးခြင်းကို ရပ်စဲသည်။
4. PodDisruptionBudgets ကိုအသုံးပြု၍ Kubernetes Cluster စက်ရပ်ချိန်ကို ရှောင်ရှားနည်း

(အနီးစပ်ဆုံး။ မဝေးတော့သောအနာဂတ်တွင် စီးရီးရှိ ကျန်ရှိသော ဆောင်းပါးများကို ဘာသာပြန်ဆိုရန် မျှော်လင့်သည်)

ဤဆောင်းပါးတွင်၊ သင့် cluster တွင်လည်ပတ်နေသော node များအတွက် လုံးဝစက်ရပ်သွားစေရန် Kubernetes မှပေးသော ကိရိယာအားလုံးကို ဖော်ပြပါမည်။

ပြtheနာကိုသတ်မှတ်ခြင်း

ကျွန်ုပ်တို့သည် အစပိုင်းတွင် နုံအသောချဉ်းကပ်နည်းကို အသုံးပြု၍ ပြဿနာများကို ဖော်ထုတ်ပြီး ဤချဉ်းကပ်မှု၏ ဖြစ်နိုင်ချေရှိသော အန္တရာယ်များကို အကဲဖြတ်ကာ စက်ဝန်းတစ်လျှောက်တွင် ကျွန်ုပ်တို့ကြုံတွေ့နေရသည့် ပြဿနာတိုင်းကို ဖြေရှင်းရန် အသိပညာကို တည်ဆောက်ပါမည်။ ရလဒ်မှာ ကျွန်ုပ်တို့၏အလုပ်မလုပ်သည့်ပန်းတိုင်ကိုရရှိရန် lifecycle hooks၊ အဆင်သင့်စစ်ဆေးခြင်းများနှင့် Pod အနှောင့်အယှက်ဘတ်ဂျက်များကို အသုံးပြုသည့် ဖွဲ့စည်းမှုတစ်ခုဖြစ်သည်။

ကျွန်ုပ်တို့၏ခရီးစတင်ရန်၊ ခိုင်မာသောဥပမာတစ်ခုကိုယူကြပါစို့။ ကျွန်ုပ်တို့တွင် အပလီကေးရှင်းတစ်ခုသည် နောက်ကွယ်တွင် pods နှစ်ခုဖြင့် လုပ်ဆောင်နေသည့် Node နှစ်ခု၏ Kubernetes အစုအဝေးတစ်ခုရှိသည် ဆိုကြပါစို့။ Service:

ကျွန်ုပ်တို့၏ Kubernetes အစုအဝေးနှစ်ခုတွင် လုပ်ဆောင်နေသော Nginx နှင့် Service ဖြင့် pods နှစ်ခုဖြင့် စတင်ကြပါစို့။

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ အစုအဝေးရှိ အလုပ်သမား node နှစ်ခု၏ kernel ဗားရှင်းကို အပ်ဒိတ်လုပ်လိုပါသည်။ ဒါကို ဘယ်လို လုပ်မလဲ။ ရိုးရှင်းသောဖြေရှင်းချက်မှာ မွမ်းမံထားသောဖွဲ့စည်းမှုပုံစံဖြင့် node အသစ်များကိုစတင်ရန်နှင့် အသစ်များကိုစတင်စဉ်တွင် node အဟောင်းများကိုပိတ်ရန်ဖြစ်သည်။ ၎င်းသည် အလုပ်ဖြစ်ချိန်တွင်၊ ဤချဉ်းကပ်မှုတွင် ပြဿနာအနည်းငယ်ရှိလိမ့်မည်-

• node အဟောင်းများကို ပိတ်လိုက်သောအခါတွင် ၎င်းတို့တွင် လုပ်ဆောင်နေသော pods များကိုလည်း ပိတ်သွားပါမည်။ သပ်ရပ်စွာပိတ်ရန်အတွက် အစေ့များကို ရှင်းလင်းရန် လိုအပ်ပါက အဘယ်နည်း။ သင်အသုံးပြုနေသော virtualization စနစ်သည် ရှင်းလင်းရေးလုပ်ငန်းစဉ်ပြီးမြောက်ရန် မစောင့်နိုင်ပါ။
• node အားလုံးကို တစ်ချိန်တည်းပိတ်ရင် ဘာဖြစ်မလဲ။ pods များသည် node အသစ်များသို့ ရွေ့သွားစဉ်တွင် သင့်တင့်လျောက်ပတ်သော စက်ရပ်ချိန်ကို ရရှိပါမည်။

ကျွန်ုပ်တို့သည် node သို့ ပြောင်းလဲမှုများ ပြုလုပ်နေစဉ် ကျွန်ုပ်တို့၏ အလုပ်သမား လုပ်ငန်းစဉ်များ မည်သည့်အရာမျှ မလည်ပတ်ကြောင်း သေချာစေရန်အတွက် pods အဟောင်းများမှ pods များကို ချောမွေ့စွာ ရွှေ့ပြောင်းရန် နည်းလမ်း လိုအပ်ပါသည်။ သို့မဟုတ် နမူနာတွင်ကဲ့သို့၊ ကျွန်ုပ်တို့သည် အစုအဝေး၏ ပြီးပြည့်စုံသော အစားထိုးမှုကို ပြုလုပ်သောအခါ (ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် VM ပုံများကို အစားထိုးခြင်းဖြစ်သည်)၊ ကျွန်ုပ်တို့သည် လုပ်ဆောင်နေသည့် အပလီကေးရှင်းဟောင်းများမှ node အသစ်များသို့ လွှဲပြောင်းလိုပါသည်။ နှစ်ခုလုံးတွင်၊ ကျွန်ုပ်တို့သည် node အဟောင်းများပေါ်တွင် pods အသစ်များကို အချိန်ဇယားဆွဲခြင်းမှ တားဆီးပြီး လုပ်ဆောင်နေသည့် pods အားလုံးကို ၎င်းတို့ထံမှ နှင်ထုတ်လိုပါသည်။ ဤရည်မှန်းချက်များအောင်မြင်ရန်ကျွန်ုပ်တို့သည် command ကိုသုံးနိုင်သည်။ kubectl drain.

node တစ်ခုမှ pods အားလုံးကို ပြန်လည်ဖြန့်ဝေခြင်း။

Drain လုပ်ဆောင်ချက်သည် node တစ်ခုမှ pods အားလုံးကို ပြန်လည်ဖြန့်ဝေနိုင်စေပါသည်။ မြောင်းများကို လုပ်ဆောင်နေစဉ်တွင်၊ node အား အချိန်ဇယားဆွဲ၍မရသောအဖြစ် အမှတ်အသားပြုပါသည် (အလံ NoSchedule) ၎င်းသည် ၎င်းတွင် အစေ့အသစ်များ မပေါ်စေရန် တားဆီးသည်။ ထို့နောက် node မှ pods များကို ဖယ်ထုတ်ပြီး၊ node ပေါ်တွင် လက်ရှိလုပ်ဆောင်နေသော container များကို ပိတ်ကာ signal ပေးပို့ခြင်း TERM အိုးတစ်လုံးထဲတွင် ကွန်တိန်နာများ။

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

• သင်၏လျှောက်လွှာကို တင်သွင်းပြီးပါက ပြေပြေလည်လည် အဆုံးအဖြတ်ပေးနိုင်ရမည်။ TERM အချက်ပြ။ pods များကို နှင်ထုတ်သည့်အခါ Kubernetes သည် အချက်ပြမှုတစ်ခု ပေးပို့သည်။ TERM ကွန်တိန်နာများသည် သတ်မှတ်ထားသော အချိန်အတိုင်းအတာတစ်ခုအထိ ရပ်တန့်ရန် စောင့်ဆိုင်းပြီးနောက် ၎င်းတို့ မရပ်တန့်ပါက ၎င်းတို့အား အတင်းအကြပ် ရပ်စဲသွားမည်ဖြစ်သည်။ မည်သို့ပင်ဆိုစေ၊ သင့်ကွန်တိန်နာသည် အချက်ပြမှုကို မှန်ကန်စွာ မရိပ်မိပါက၊ ၎င်းတို့သည် လက်ရှိလုပ်ဆောင်နေပါက ၎င်းတို့ကို မှားယွင်းစွာ မီးငြှိမ်းသတ်နိုင်ဆဲဖြစ်သည် (ဥပမာ၊ ဒေတာဘေ့စ် အရောင်းအ၀ယ် လုပ်ဆောင်နေသည်)။
• သင့်လျှောက်လွှာပါရှိသော pods များအားလုံး ဆုံးရှုံးသွားပါမည်။ ကွန်တိန်နာအသစ်များကို node အသစ်များတွင် စတင်သောအခါ သို့မဟုတ် သင်၏ pods များကို controllers မပါဘဲ အသုံးပြုပါက၊ ၎င်းတို့သည် လုံးဝပြန်လည်စတင်မည်မဟုတ်ပါ။

စက်ရပ်ခြင်းမှ ရှောင်ကြဉ်ခြင်း။

node တစ်ခုပေါ်ရှိ drain operation ကဲ့သို့သော စိတ်ဆန္ဒအလျောက် အနှောင့်အယှက်များမှ ရပ်တန့်နေချိန်ကို လျှော့ချရန်အတွက် Kubernetes သည် အောက်ပါ မအောင်မြင်မှုများကို ကိုင်တွယ်ရန် ရွေးချယ်စရာများကို ပံ့ပိုးပေးသည်-

• စဲဆစ်
• Lifecycle ချိတ်
• PodDisruptionBudgets

ကျန်စီးရီးများတွင်၊ pod ရွှေ့ပြောင်းခြင်း၏သက်ရောက်မှုကို လျော့ပါးသက်သာစေရန် ဤ Kubernetes အင်္ဂါရပ်များကို အသုံးပြုပါမည်။ ပင်မအိုင်ဒီယာကို လိုက်လျှောက်ရန် ပိုမိုလွယ်ကူစေရန်၊ အောက်ပါ အရင်းအမြစ်ဖွဲ့စည်းပုံဖြင့် အထက်ဖော်ပြပါ ကျွန်ုပ်တို့၏ ဥပမာကို အသုံးပြုပါမည်။

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

ဤဖွဲ့စည်းပုံသည် အနည်းငယ်မျှသာ ဥပမာတစ်ခုဖြစ်သည်။ Deploymentအစုအဝေးရှိ nginx pods များကို စီမံခန့်ခွဲသည်။ ထို့အပြင်၊ ဖွဲ့စည်းမှုပုံစံသည် အရင်းအမြစ်ကို ဖော်ပြသည်။ Serviceအစုအဝေးတစ်ခုရှိ nginx pods များကို ဝင်ရောက်ကြည့်ရှုရန် အသုံးပြုနိုင်သည်။

စက်ဝန်းတစ်လျှောက်လုံးတွင်၊ ကျွန်ုပ်တို့သည် စက်ရပ်ချိန်ကို လျှော့ချရန်အတွက် နောက်ဆုံးတွင် Kubernetes မှ ပံ့ပိုးပေးသည့် စွမ်းရည်များအားလုံးကို ပါဝင်စေရန် ဤဖွဲ့စည်းပုံကို ထပ်တလဲလဲ ချဲ့ထွင်ပါမည်။

AWS နှင့် ထို့ထက်ပို၍ ရပ်တန့်နေချိန် လုံးဝမရှိသော Kubernetes အစုအဝေး၏ အပ်ဒိတ်များကို အပြည့်အ၀ စမ်းသပ်ပြီး ဗားရှင်းအတွက်၊ သွားရောက်ကြည့်ရှုပါ။ Gruntwork.io.

ကျွန်ုပ်တို့၏ဘလော့ဂ်ရှိ အခြားဆောင်းပါးများကိုလည်း ဖတ်ပါ-

• စက်ရပ်ချိန်နှင့် ဒေတာဘေ့စ်များကို သုည
• Kubernetes- စနစ်အရင်းအမြစ်စီမံခန့်ခွဲမှုကို စတင်သတ်မှတ်ရန် အဘယ်ကြောင့် အလွန်အရေးကြီးသနည်း။
• Tekton ပိုက်လိုင်း - Kubernetes-ဇာတိပိုက်လိုင်းများ
• Nginx အတွက် ပြောင်းလဲနေသော မော်ဂျူးများကို တည်ဆောက်ခြင်း။
• Hashicorp ကောင်စစ်ဝန်၏ Kubernetes ခွင့်ပြုချက်အား နိဒါန်း
• ခွင့်ပြုချက်မရှိဘဲ ClickHouse မှ ClickHouse သို့ ပြောင်းရွှေ့ခြင်းသည် မည်သည့်အရာဆီသို့ ဦးတည်သွားသနည်း။

source: www.habr.com