အဖြစ်များသော Kubernetes အမှား ၁၀ ခု

မှတ်ချက်။ ဘာသာပြန်: ဤဆောင်းပါး၏ရေးသားသူများသည် ချက်ကုမ္ပဏီငယ်တစ်ခုဖြစ်သည့် pipetail မှ အင်ဂျင်နီယာများဖြစ်သည်။ ၎င်းတို့သည် Kubernetes အစုအဖွဲ့များ၏ လည်ပတ်ဆောင်ရွက်မှုနှင့် ပတ်သက်သော အလွန်ဖိအားပေးသော ပြဿနာများနှင့် အထင်အမြင်လွဲမှားမှုများ၏ အံ့သြဖွယ်ကောင်းသောစာရင်းကို စုစည်းနိုင်ခဲ့သည်။

Kubernetes ကိုအသုံးပြုပြီး နှစ်များတစ်လျှောက်တွင်၊ ကျွန်ုပ်တို့သည် အစုအဝေးအများအပြား (GCP၊ AWS နှင့် Azure) တွင် စီမံခန့်ခွဲခြင်းနှင့် စီမံခန့်ခွဲခြင်းမရှိဘဲ လုပ်ဆောင်ခဲ့သည်။ အချိန်ကြာလာသည်နှင့်အမျှ၊ အချို့သော အမှားများသည် အဆက်မပြတ် ထပ်ခါထပ်ခါ ဖြစ်နေသည်ကို သတိပြုမိလာသည်။ သို့ရာတွင်၊ ဤအရာအတွက် ရှက်စရာမဟုတ်ပါ- ကျွန်ုပ်တို့သည် ၎င်းတို့အများစုကို ကိုယ်တိုင်ပြုလုပ်ပြီးဖြစ်သည်။

ဆောင်းပါးတွင် အဖြစ်များဆုံး အမှားများ ပါ၀င်ပြီး ၎င်းတို့ကို မည်ကဲ့သို့ ပြင်ရမည်ကိုလည်း ဖော်ပြထားပါသည်။

1. အရင်းအမြစ်များ- တောင်းဆိုမှုများနှင့် ကန့်သတ်ချက်များ

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

CPU တောင်းဆိုမှု များတယ်။ လုံး၀မသတ်မှတ်ထားပါ သို့မဟုတ် အလွန်နိမ့်သောတန်ဖိုးရှိသည်။ (တတ်နိုင်သမျှ pods များကို node တစ်ခုစီတွင် ထားရှိရန်) ထို့ကြောင့် node များသည် overloaded ဖြစ်လာသည်။ ဝန်ထုပ်ဝန်ပိုးများသောအချိန်များတွင်၊ node ၏ လုပ်ဆောင်နိုင်စွမ်းကို အပြည့်အဝအသုံးချပြီး အလုပ်တာဝန်တစ်ခုက ၎င်း "တောင်းဆိုထားသည်" ကိုသာ လက်ခံရရှိသည် CPU ပိတ်ဆို့ခြင်း။. ၎င်းသည် အပလီကေးရှင်း၏ ကြာချိန်တိုးလာခြင်း၊ အချိန်ကုန်ခြင်းနှင့် အခြားမနှစ်မြို့ဖွယ်အကျိုးဆက်များကို ဖြစ်ပေါ်စေသည်။ (ကျွန်ုပ်တို့၏ မကြာသေးမီက ဘာသာပြန်ချက်တွင် ဤအကြောင်းပိုမိုဖတ်ရှုပါ- “Kubernetes တွင် CPU ကန့်သတ်ချက်များနှင့် ပြင်းထန်သော အတားအဆီးများ"- အနီးစပ်ဆုံး ဘာသာပြန်။)

အကောင်းဆုံးဆောင်ရွက်မှု (အလွန့်အလွန် မဟုတ် အကြံပြုထားသည်):

resources: {}

အလွန်နိမ့်သော CPU တောင်းဆိုမှု (အလွန်အမင်း မဟုတ် အကြံပြုထားသည်):

   resources:
      Requests:
        cpu: "1m"

အခြားတစ်ဖက်တွင်၊ CPU ကန့်သတ်ချက်တစ်ခုရှိနေခြင်းသည် node ပရိုဆက်ဆာကိုအပြည့်အ၀မတင်ထားလျှင်ပင် pods များအလိုက် နာရီလည်ပတ်မှုများကို ကျိုးကြောင်းဆီလျော်မှုမရှိစွာ ကျော်သွားနိုင်သည်။ တဖန်၊ ယင်းသည် နှောင့်နှေးမှုများ တိုးမြင့်လာနိုင်သည်။ ကန့်သတ်ဘောင်ပတ်လည်တွင် အငြင်းပွားမှုများ ဆက်လက်ဖြစ်ပေါ်နေသည်။ CPU CFS ခွဲတမ်း သတ်မှတ်ကန့်သတ်ချက်များပေါ်မူတည်၍ Linux kernel နှင့် CPU ပိတ်ဆို့ခြင်းအပြင် CFS ခွဲတမ်းကို ပိတ်ခြင်း... ဟုတ်မဟုတ်၊ CPU ကန့်သတ်ချက်များသည် ၎င်းတို့ဖြေရှင်းနိုင်သည်ထက် ပြဿနာများကို ပိုမိုဖြစ်ပေါ်စေနိုင်သည်။ ဒီအကြောင်းအသေးစိတ်အချက်အလက်ကို အောက်ပါလင့်ခ်မှာ ကြည့်ရှုနိုင်ပါတယ်။

အလွန်အကျွံရွေးချယ်မှု (ကတိတည်သည်) မှတ်ဉာဏ်ပြဿနာများသည် ပိုမိုကြီးမားသော ပြဿနာများဆီသို့ ဦးတည်သွားစေနိုင်သည်။ CPU ကန့်သတ်ချက်သို့ရောက်ရှိခြင်းသည် နာရီစက်ဝန်းများကို ကျော်သွားခြင်းဖြစ်ပြီး မှတ်ဉာဏ်ကန့်သတ်ချက်သို့ရောက်ရှိချိန်တွင် pod ကိုသေစေနိုင်သည်။ စောင့်ကြည့်ဖူးပါသလား။ OOMkill? ဟုတ်တယ်၊ အဲဒါ ငါတို့ပြောနေတာ အတိအကျပဲ။

ဒီလိုဖြစ်နိုင်ခြေကို လျှော့ချလိုပါသလား။ မမ်မိုရီကို အလွန်အကျွံ ခွဲဝေမထားပါနှင့် (အောက်ပါဥပမာတွင်ကဲ့သို့) မှတ်ဉာဏ်တောင်းဆိုမှုကို ကန့်သတ်ချက်အဖြစ် သတ်မှတ်ခြင်းဖြင့် အာမခံ QoS (ဝန်ဆောင်မှုအရည်အသွေး) ကို အသုံးပြုပါ။ ဤအကြောင်းပိုမိုဖတ်ရှုပါ။ Henning Jacobs တင်ဆက်မှု ( Zalando မှဦးဆောင်အင်ဂျင်နီယာ) ။

ပေါက်ကွဲနိုင်သော (OOM အသတ်ခံရဖို့ အခွင့်အလမ်းပိုများပါတယ်)

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

အာမခံ:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

အရင်းအမြစ်များကို သတ်မှတ်ရာတွင် အဘယ်အရာက အထောက်အကူဖြစ်နိုင်မည်နည်း။

နှင့် မက်ထရစ်ဆာဗာ pods (နှင့် ၎င်းတို့အတွင်းရှိ ကွန်တိန်နာများ) ဖြင့် လက်ရှိ CPU အရင်းအမြစ်သုံးစွဲမှုနှင့် မှတ်ဉာဏ်အသုံးပြုမှုကို သင်တွေ့မြင်နိုင်ပါသည်။ ဖြစ်နိုင်ချေများသည်မှာ သင် ၎င်းကို အသုံးပြုနေပြီဖြစ်သည်။ အောက်ပါ command များကိုသာ run ပါ။

kubectl top pods
kubectl top pods --containers
kubectl top nodes

သို့သော် ၎င်းတို့သည် လက်ရှိအသုံးပြုမှုကိုသာ ပြသသည်။ ၎င်းသည် သင့်အား ပြင်းအားအစီအစဥ်၏ အကြမ်းဖျင်းအကြံဥာဏ်ကို ပေးစွမ်းနိုင်သော်လည်း နောက်ဆုံးတွင် သင်လိုအပ်ပါလိမ့်မည်။ အချိန်နှင့်အမျှ တိုင်းတာမှုများတွင် အပြောင်းအလဲများ၏သမိုင်း (“အထွတ်အထိပ် CPU load က ဘာလဲ”၊ “မနေ့က မနက်က ဘယ်လောက် load လဲ” အစရှိတဲ့ မေးခွန်းတွေကို ဖြေဖို့။ ဒီအတွက် သင်သုံးနိုင်တယ်။ Prometheus, DataDog နှင့် အခြားကိရိယာများ။ ၎င်းတို့သည် မက်ထရစ်ဆာဗာမှ မက်ထရစ်များကို ရိုးရှင်းစွာရယူပြီး ၎င်းတို့ကို သိမ်းဆည်းထားကာ အသုံးပြုသူသည် ၎င်းတို့အား မေးမြန်းစုံစမ်းနိုင်ပြီး ၎င်းတို့ကို လိုက်လျောညီထွေဖြစ်အောင် ကြံစည်နိုင်သည်။

VerticalPodAutoscaler ဒါဟာခွင့်ပြု အလိုအလျောက် ဤလုပ်ငန်းစဉ်။ ၎င်းသည် CPU နှင့် မမ်မိုရီအသုံးပြုမှုမှတ်တမ်းကို ခြေရာခံပြီး ဤအချက်အလက်ပေါ်အခြေခံ၍ တောင်းဆိုချက်အသစ်များနှင့် ကန့်သတ်ချက်များကို သတ်မှတ်ပေးပါသည်။

ကွန်ပြူတာစွမ်းအားကို ထိရောက်စွာအသုံးပြုခြင်းသည် လွယ်ကူသောအလုပ်မဟုတ်ပါ။ Tetris ကို တစ်ချိန်လုံး ကစားနေသလိုပါပဲ။ ပျမ်းမျှသုံးစွဲမှုနည်းသော (~10%) ဖြင့် ကွန်ပြူတာပါဝါအတွက် အလွန်အကျွံ ပေးဆောင်ပါက၊ AWS Fargate သို့မဟုတ် Virtual Kubelet ကို အခြေခံထားသော ထုတ်ကုန်များကို ကြည့်ရှုရန် အကြံပြုအပ်ပါသည်။ ၎င်းတို့ကို ဆာဗာမဲ့/အသုံးပြုမှုတစ်ကြိမ် ငွေပေးချေမှုပုံစံဖြင့် တည်ဆောက်ထားခြင်းဖြစ်ပြီး၊ ထိုသို့သောအခြေအနေများတွင် ပိုမိုစျေးသက်သာသွားနိုင်သည်။

2. အသက်ရှင်မှုနှင့် စေတနာ စူးစမ်းမှု

မူရင်းအားဖြင့်၊ အသက်ရှင်မှုနှင့် အဆင်သင့်စစ်ဆေးမှုများကို Kubernetes တွင် ဖွင့်မထားပါ။ တခါတရံ ဖွင့်ဖို့ မေ့သွားကြတယ်...

သို့သော် ဆိုးရွားသော အမှားတစ်ခုကြောင့် ဝန်ဆောင်မှုကို ပြန်လည်စတင်ရန် သင်မည်ကဲ့သို့ စတင်နိုင်မည်နည်း။ pod တစ်ခုသည် traffic ကိုလက်ခံရန်အဆင်သင့်ဖြစ်ကြောင်း load balancer သည်မည်သို့သိသနည်း။ ဒါမှမဟုတ် ယာဉ်ကြောအသွားအလာ ပိုများလာလို့လား။

ဤစစ်ဆေးမှုများသည် တစ်ခုနှင့်တစ်ခု မကြာခဏ ရောထွေးနေတတ်သည်-

• ဘဝ - ပျက်ကွက်ပါက pod ကိုပြန်လည်စတင်သည့် "ရှင်သန်နိုင်မှု" စစ်ဆေးပါ။
• အသငျ့ — အဆင်သင့်စစ်ဆေးမှု၊ ပျက်ကွက်ပါက၊ ၎င်းသည် Pod အား Kubernetes ဝန်ဆောင်မှုမှ ဖြတ်တောက်မည် (၎င်းကို အသုံးပြု၍ စစ်ဆေးနိုင်သည်။ kubectl get endpoints) နှင့် နောက်တစ်ကြိမ် စစ်ဆေးမှုကို အောင်မြင်စွာ မပြီးမချင်း ၎င်းထံ အသွားအလာ မရောက်ပါ။

အဲဒီနှစ်ခုစလုံးကို စစ်ဆေးတယ်။ POD ၏ဘဝသံသရာတစ်ခုလုံးတွင် လုပ်ဆောင်ခဲ့သည်။. အလွန်အရေးကြီးပါသည်။

အများအားဖြင့် အထင်အမြင်လွဲမှားမှုတစ်ခုကတော့ အဆင်သင့်စစ်ဆေးခြင်းတွေဟာ စတင်ချိန်မှာပဲ လုပ်ဆောင်နေတာကြောင့် ပဲ့ဒ်က အဆင်သင့်ဖြစ်နေပြီဆိုတာကို ချိန်ခွင်လျှာက သိနိုင်စေမှာပါ (Ready) နှင့် ယာဉ်အသွားအလာကို စတင်လုပ်ဆောင်နိုင်သည်။ သို့သော်လည်း ဤသည်မှာ ၎င်းတို့အသုံးပြုရန်အတွက် ရွေးချယ်စရာများထဲမှ တစ်ခုသာဖြစ်သည်။

နောက်တစ်ချက်မှာ pod ပေါ်ရှိ traffic သည်အလွန်အကျွံဖြစ်ပြီးရှာဖွေတွေ့ရှိရန်ဖြစ်နိုင်ခြေဖြစ်သည်။ overloads ပါ။ (သို့မဟုတ် pod သည် အရင်းအမြစ်-အလေးပေးတွက်ချက်မှုများကို လုပ်ဆောင်သည်)။ ဤကိစ္စတွင်၊ အဆင်သင့်စစ်ဆေးမှုသည်ကူညီပေးသည်။ pod ပေါ်ရှိဝန်ကိုလျှော့ချပြီး "အေး". အနာဂတ်တွင် အဆင်သင့်စစ်ဆေးမှုကို အောင်မြင်စွာ ပြီးစီးအောင် လုပ်ဆောင်နိုင်မည်ဖြစ်သည်။ pod ပေါ်တွင်ဝန်ကိုထပ်မံတိုးမြှင့်. ဤအခြေအနေတွင် (အဆင်သင့်စမ်းသပ်မှု မအောင်မြင်ပါက) အသက်ရှင်ခြင်းစမ်းသပ်မှု ပျက်ကွက်မှုသည် အလွန်ဆန့်ကျင်ဘက်ဖြစ်လိမ့်မည်။ ကျန်းမာပြီး အလုပ်ကြိုးစားတဲ့ ဘူးကို ဘာကြောင့် ပြန်စတာလဲ။

ထို့ကြောင့်၊ အချို့ကိစ္စများတွင်၊ မည်သည့်စစ်ဆေးမှုမှ မှားယွင်းစွာသတ်မှတ်ထားသော ကန့်သတ်ဘောင်များဖြင့် ၎င်းတို့အား ဖွင့်ပေးခြင်းထက် ပိုမိုကောင်းမွန်ပါသည်။ အထက်တွင်ဆိုခဲ့သည့်အတိုင်းဆိုလျှင်၊ liveness check မိတ္တူများ အဆင်သင့်စစ်ဆေးပါ။ဒါဆိုရင် မင်းက ကြီးကြီးမားမား ဒုက္ခရောက်နေတယ်။ ဖြစ်နိုင်သောရွေးချယ်မှုသည် configure လုပ်ရန်ဖြစ်သည်။ အဆင်သင့်စမ်းသပ်မှုသာနှင့် အန္တရာယ်ရှိသောအသက်မွေးဝမ်းကျောင်း ဘေးဖယ်ထားလိုက်ပါ။

တူညီသောမှီခိုမှု ပျက်ကွက်သည့်အခါ စစ်ဆေးမှုနှစ်မျိုးစလုံးသည် မအောင်မြင်သင့်ပါ၊ သို့မဟုတ်ပါက ၎င်းသည် အစေ့အားလုံး၏ ပြိုကျပျက်စီးမှု (နှင်းပြိုကျခြင်းကဲ့သို့) ပျက်ကွက်မှုဆီသို့ ဦးတည်သွားစေမည်ဖြစ်သည်။ တစ်နည်းပြောရရင်တော့, ကိုယ့်ကိုယ်ကို မထိခိုက်စေနဲ့.

3. HTTP ဝန်ဆောင်မှုတစ်ခုစီအတွက် LoadBalancer

ဖြစ်နိုင်ချေ အများစုမှာ၊ သင်သည် ပြင်ပကမ္ဘာသို့ ပေးပို့လိုသော သင်၏အစုအဝေးတွင် HTTP ဝန်ဆောင်မှုများ ရှိသည်။

ဝန်ဆောင်မှုအဖြစ်ဖွင့်လျှင် type: LoadBalancer၎င်း၏ ထိန်းချုပ်ကိရိယာ (ဝန်ဆောင်မှုပေးသူပေါ် မူတည်၍) ပြင်ပ LoadBalancer (L7 တွင် မလိုအပ်ဘဲ လုပ်ဆောင်နေသော်လည်း L4 တွင်ပင်) ပံ့ပိုးပေးပြီး ညှိနှိုင်းပေးမည်ဖြစ်ပြီး ၎င်းသည် ကုန်ကျစရိတ် (ပြင်ပတည်ငြိမ် IPv4 လိပ်စာ၊ ကွန်ပြူတာစွမ်းအင်၊ တစ်စက္ကန့်လျှင် ငွေပေးချေမှု) ကို ထိခိုက်စေနိုင်သည်။ ) ထိုသို့သော အရင်းအမြစ်များစွာကို ဖန်တီးရန် လိုအပ်ခြင်းကြောင့် ဖြစ်သည်။

ဤကိစ္စတွင်၊ ဝန်ဆောင်မှုများအဖြစ် ဖွင့်လှစ်သည့် ပြင်ပဝန်ချိန်ခွင်လျှာတစ်ခုအား အသုံးပြုခြင်းသည် ပို၍ယုတ္တိတန်ပါသည်။ type: NodePort. သို့မဟုတ် ပိုကောင်းသေး၊ ချဲ့ထွင်ပါ။ nginx-ingress-controller (သို့မဟုတ် တောင်ကြီးမြို့) မည်သူတစ်ဦးတည်းဖြစ်မည်နည်း။ NodePort External load balancer နှင့်ဆက်စပ်နေသော endpoint ကိုအသုံးပြုပြီး cluster အတွင်းရှိ traffic ကိုလမ်းကြောင်းပေးလိမ့်မည်။ ingress- Kubernetes အရင်းအမြစ်များ။

အချင်းချင်းအပြန်အလှန်ဆက်သွယ်သော အခြားသော အစုအဖွဲ့ (မိုက်ခရို) ဝန်ဆောင်မှုများသည် ဝန်ဆောင်မှုများကဲ့သို့သော ဝန်ဆောင်မှုများကို အသုံးပြု၍ “ဆက်သွယ်” နိုင်သည် ClusterIP နှင့် DNS မှတဆင့် built-in ဝန်ဆောင်မှုရှာဖွေတွေ့ရှိမှုယန္တရား။ ၎င်းတို့၏ အများသူငှာ DNS/IP ကို ​​အသုံးမပြုပါနှင့်၊ ၎င်းသည် latency ကို သက်ရောက်မှုရှိပြီး cloud ဝန်ဆောင်မှုများ၏ ကုန်ကျစရိတ်ကို တိုးမြင့်စေနိုင်ပါသည်။

4. ၎င်း၏အင်္ဂါရပ်များကို ထည့်သွင်းစဉ်းစားခြင်းမရှိဘဲ အစုအဝေးတစ်ခုအား အလိုအလျောက် အရွယ်အစားသတ်မှတ်ခြင်း။

၎င်းတို့ကို အစုအဝေးတစ်ခုမှ ပေါင်းထည့်ခြင်းနှင့် ဖယ်ရှားသည့်အခါ၊ အဆိုပါ node များတွင် CPU အသုံးပြုမှုကဲ့သို့သော အခြေခံမက်ထရစ်အချို့ကို သင် အားကိုးမနေသင့်ပါ။ Pod Planning ကို များစွာ ထည့်သွင်းစဉ်းစားရပါမည်။ ကန့်သတ်ချက်များpod/node ရင်းနှီးမှု၊ အစွန်းအထင်းများနှင့် သည်းခံမှုများ၊ အရင်းအမြစ်တောင်းဆိုမှုများ၊ QoS စသည်တို့ကဲ့သို့သော၊ ဤအချက်များကို ထည့်သွင်းစဉ်းစားခြင်းမရှိသော ပြင်ပ autoscaler ကိုအသုံးပြုခြင်းဖြင့် ပြဿနာများဖြစ်ပေါ်လာနိုင်သည်။

အချို့သော pod တစ်ခုကို စီစဉ်ထားသင့်သည်ဟု မြင်ယောင်ကြည့်ပါ၊ သို့သော် ရရှိနိုင်သော CPU ပါဝါအားလုံးကို တောင်းဆိုထားသည်/တပ်ဆင်ပြီး pod အခြေအနေတစ်ခုတွင် ပိတ်မိနေသည်။ Pending. ပြင်ပ autoscaler သည် ပျမ်းမျှ လက်ရှိ CPU load (တောင်းဆိုထားသည့်အရာမဟုတ်) ကို မြင်ပြီး ချဲ့ထွင်ခြင်း မလုပ်ဆောင်ပါ။ (အတိုင်းအတာ) - အခြား node မထည့်ပါ။ ရလဒ်အနေဖြင့် ဤ pod ကိုစီစဉ်မည်မဟုတ်ပါ။

ဤကိစ္စတွင်၊ ပြောင်းပြန် အတိုင်းအတာ (အတိုင်းအတာ) - အစုအဝေးတစ်ခုမှ node ကိုဖယ်ရှားခြင်းသည် အမြဲတမ်းအကောင်အထည်ဖော်ရန် ပို၍ခက်ခဲသည်။ သင့်တွင် stateful pod တစ်ခုရှိသည် (အမြဲတမ်းသိုလှောင်မှုချိတ်ဆက်ထားသော) ရှိသည်ဟု မြင်ယောင်ကြည့်ပါ။ ဝီရိယတွဲ အများအားဖြင့် ပိုင်သည်။ သီးခြားရရှိနိုင်မှုဇုန် ဒေသအတွင်း ပုံတူကူးမထားပါ။ ထို့ကြောင့်၊ ပြင်ပ autoscaler သည် ဤ pod နှင့် node တစ်ခုကို ဖျက်ပါက၊ အချိန်ဇယားဆွဲသူသည် ဤ pod ကို အခြား node တွင် အချိန်ဇယားဆွဲထားနိုင်မည်မဟုတ်ပေ။ Pod သည်အခြေအနေတွင်ပိတ်နေလိမ့်မည်။ Pending.

Kubernetes အသိုင်းအဝိုင်းတွင် အလွန်ရေပန်းစားသည်။ cluster-autoscaler. ၎င်းသည် အစုလိုက်အပြုံလိုက်တွင်လည်ပတ်သည်၊ အဓိက cloud ပံ့ပိုးပေးသူများထံမှ API များကို ပံ့ပိုးသည်၊ ကန့်သတ်ချက်အားလုံးကို ထည့်သွင်းစဉ်းစားပြီး အထက်ဖော်ပြပါကိစ္စများတွင် အတိုင်းအတာအထိ လုပ်ဆောင်နိုင်သည်။ ၎င်းသည် သတ်မှတ်ထားသော ကန့်သတ်ချက်အားလုံးကို ထိန်းသိမ်းထားစဉ်တွင် အတိုင်းအတာအထိ ချဲ့ထွင်နိုင်ကာ ငွေကြေးကို ချွေတာနိုင်သည် (မဟုတ်ရင် အသုံးမပြုနိုင်သော စွမ်းရည်အတွက် သုံးစွဲမည်)။

5. IAM/RBAC စွမ်းရည်များကို လျစ်လျူရှုခြင်း။

ဆက်တိုက်လျှို့ဝှက်ချက်များနှင့်အတူ IAM အသုံးပြုသူများအသုံးပြုခြင်းကိုသတိပြုပါ။ စက်များနှင့် applications များ. အခန်းကဏ္ဍများနှင့် ဝန်ဆောင်မှုအကောင့်များကို အသုံးပြု၍ ယာယီဝင်ရောက်ခွင့်ကို စုစည်းပါ။ (ဝန်ဆောင်မှုအကောင့်များ).

အသုံးပြုခွင့်သော့များ (နှင့် လျှို့ဝှက်ချက်များ) ကို အပလီကေးရှင်းဖွဲ့စည်းပုံတွင် hardcode လုပ်ထားသည့်အပြင် Cloud IAM သို့ဝင်ရောက်ခွင့်ရှိသော်လည်း လျှို့ဝှက်လှည့်ပတ်မှုကို လျစ်လျူရှုထားခြင်းတို့ကို မကြာခဏ ကြုံတွေ့ရသည်။ သင့်လျော်သောနေရာတွင် အသုံးပြုသူများအစား IAM အခန်းကဏ္ဍများနှင့် ဝန်ဆောင်မှုအကောင့်များကို အသုံးပြုပါ။

kube2iam ကိုမေ့လိုက်ပြီး ဝန်ဆောင်မှုအကောင့်များအတွက် IAM အခန်းကဏ္ဍများထံ တည့်တည့်သွားပါ (တွင်ဖော်ပြထားသည့်အတိုင်း အမည်တူမှတ်စု Štěpán Vraný):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

မှတ်ချက်တစ်ခု။ အဲ့လောက်မခက်ဘူးလား။

ထို့အပြင်၊ ဝန်ဆောင်မှုအကောင့်များနှင့် ဥပမာပရိုဖိုင်များကို အထူးအခွင့်အရေးများ မပေးပါနှင့် admin и cluster-adminမလိုအပ်ရင်၊ အထူးသဖြင့် RBAC K8s များတွင် အကောင်အထည်ဖော်ရန် အနည်းငယ်ပိုခက်ခဲသော်လည်း သေချာပေါက် ကြိုးစားရကျိုးနပ်ပါသည်။

6. pods အတွက် အလိုအလျောက်ဆန့်ကျင်ဖက်တွယ်မှုအပေါ် အားမကိုးပါနှင့်

သင့်တွင် node တစ်ခုပေါ်တွင် ဖြန့်ကျက်မှုအချို့၏ ပုံတူသုံးမျိုးရှိသည်ဟု မြင်ယောင်ကြည့်ပါ။ node သည် ပြုတ်ကျပြီး ၎င်းနှင့်အတူ ပုံစံတူများ အားလုံး ပါဝင်သည်။ မနှစ်မြို့စရာ အခြေအနေ မဟုတ်လား။ သို့သော် ပုံတူများအားလုံးကို တူညီသော node တွင် အဘယ်ကြောင့် ရှိခဲ့သနည်း။ Kubernetes သည် မြင့်မားသောရရှိနိုင်မှု (HA) ကို ပေးသင့်သည်မဟုတ်လော။

ကံမကောင်းစွာဖြင့်၊ Kubernetes အစီအစဉ်ဆွဲသူသည် ၎င်း၏ကိုယ်ပိုင်အစပျိုးမှုတွင် သီးခြားတည်ရှိမှုစည်းမျဉ်းများကို မလိုက်နာပါ (ဆန့်ကျင်ဖက်ဆက်ဆံရေး) pods များအတွက်။ ၎င်းတို့ကို အတိအလင်းဖော်ပြရမည်-

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

ဒါပါပဲ။ ယခုအခါ pods များကို မတူညီသော node များပေါ်တွင် စီစဉ်ထားလိမ့်မည် (ဤအခြေအနေအား အချိန်ဇယားဆွဲနေစဉ်အတွင်းသာ စစ်ဆေးထားသော်လည်း ၎င်းတို့၏လုပ်ဆောင်မှုအတွင်းမဟုတ်ပါ - ထို့ကြောင့်၊ requiredDuringSchedulingIgnoredDuringExecution).

ဤတွင်ငါတို့အကြောင်းပြောနေတာ podAntiAffinity မတူညီသော node များပေါ်တွင် topologyKey: "kubernetes.io/hostname"၊ - မတူညီသောရရှိနိုင်မှုဇုန်များအကြောင်းမဟုတ်ပါ။ ပြည့်စုံသော HA ကိုအကောင်အထည်ဖော်ရန်၊ ဤအကြောင်းအရာကို ပိုမိုနက်ရှိုင်းစွာ တူးဆွရမည်ဖြစ်ပါသည်။

7. PodDisruptionBudgets ကိုလျစ်လျူရှုခြင်း။

Kubernetes အစုအဝေးတွင် သင့်တွင် ထုတ်လုပ်မှုဝန်တစ်ခုရှိသည်ကို မြင်ယောင်ကြည့်ပါ။ အခါအားလျော်စွာ၊ node များနှင့် cluster ကိုယ်တိုင် မွမ်းမံပြင်ဆင်ရန် (သို့မဟုတ်) ဖယ်ရှားရန် လိုအပ်သည်။ PodDisruptionBudget (PDB) သည် အစုအဝေး စီမံခန့်ခွဲသူများနှင့် အသုံးပြုသူများကြား ဝန်ဆောင်မှုအာမခံ သဘောတူညီချက်ကဲ့သို့ အရာတစ်ခုဖြစ်သည်။

PDB သည် node များမရှိခြင်းကြောင့် ဝန်ဆောင်မှုပြတ်တောက်မှုများကို ရှောင်ရှားနိုင်စေသည်-

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

ဤဥပမာတွင်၊ အစုအဝေး၏အသုံးပြုသူတစ်ဦးအနေဖြင့် သင်သည် စီမံခန့်ခွဲသူများအား ဤသို့ပြောပါ- "ဟေး၊ ကျွန်ုပ်တွင် တိရစ္ဆာန်ဥယျာဉ်တစ်ခုရှိပါသည်၊ သင်ဘာလုပ်သည်ဖြစ်စေ ဤဝန်ဆောင်မှု၏ပုံတူပုံတူ ၂ ခု အမြဲရှိစေလိုပါသည်။"

ဤအကြောင်းပိုမိုဖတ်ရှုနိုင်ပါသည်။ ဒီမှာ.

8. ဘုံအစုအဝေးတစ်ခုရှိ သုံးစွဲသူအများအပြား သို့မဟုတ် ပတ်ဝန်းကျင်များ

Kubernetes အမည်ကွက်များ (အမည်ကွက်များ) ခိုင်ခံ့သော insulation များမပေးပါ။.

ယေဘုယျအားဖြင့် အထင်အမြင်လွဲမှားသည်မှာ သင်သည် ကုန်ပစ္စည်းမဟုတ်သော load တစ်ခုကို namespace တစ်ခုထဲသို့ အသုံးချပြီး အခြားတစ်ခုသို့ prod load ကို အသုံးပြုပါက၊ တစ်ယောက်ကိုတစ်ယောက် ဘယ်လိုမှ လွှမ်းမိုးမှာ မဟုတ်ဘူး။... သို့သော်၊ အရင်းအမြစ်တောင်းဆိုမှုများ/ကန့်သတ်ချက်များ၊ ခွဲတမ်းသတ်မှတ်ခြင်းနှင့် ဦးစားပေးအတန်းများသတ်မှတ်ခြင်းတို့ကို အသုံးပြု၍ သီးခြားခွဲထုတ်ခြင်းအဆင့်ကို အောင်မြင်နိုင်သည်။ ဒေတာလေယာဉ်ရှိ အချို့သော "ရုပ်ပိုင်းဆိုင်ရာ" သီးခြားခွဲထုတ်ခြင်းကို ရင်းနှီးမှု၊ သည်းခံမှု၊ အာသဝေါတရားများ (သို့မဟုတ် nodeselectors) တို့က ပံ့ပိုးပေးသော်လည်း ထိုကဲ့သို့ ခွဲထွက်ခြင်းသည် အတော်လေး ခက်ခဲ အကောင်အထည်ဖော်ပါ။

တူညီသောအစုအဝေးတွင် အလုပ်ပမာဏနှစ်မျိုးလုံးကို ပေါင်းစပ်ရန် လိုအပ်သူများသည် ရှုပ်ထွေးမှုကို ရင်ဆိုင်ရမည်ဖြစ်သည်။ ထိုကဲ့သို့ မလိုအပ်ပါက၊ သင်တစ်ဦးတည်းရှိရန် တတ်နိုင်သည် နောက်ထပ်အစုအဖွဲ့တစ်ခု (ပြောပါ၊ အများသူငှာ cloud မှာ) ဒါဆို လုပ်တာက ပိုကောင်းပါတယ်။ ၎င်းသည် ပိုမိုမြင့်မားသော insulation အဆင့်ကိုရရှိမည်ဖြစ်သည်။

9. externalTrafficPolicy- အစုအဝေး

အစုအဝေးအတွင်းရှိ အသွားအလာအားလုံးသည် NodePort ကဲ့သို့သော ဝန်ဆောင်မှုတစ်ခုမှတစ်ဆင့် လာကြောင်း ကျွန်ုပ်တို့မကြာခဏတွေ့မြင်ရပြီး၊ ၎င်းအတွက် မူလမူဝါဒကို သတ်မှတ်ထားပါသည်။ externalTrafficPolicy: Cluster... ဆိုလိုတာက NodePort cluster ရှိ node တိုင်းတွင် ဖွင့်ထားပြီး ၎င်းတို့ထဲမှ တစ်ခုခုကို သင်အလိုရှိသော ဝန်ဆောင်မှု (pods အစုအဝေး) နှင့် အပြန်အလှန် တုံ့ပြန်ရန်အတွက် ၎င်းတို့ကို အသုံးပြုနိုင်သည်။

တစ်ချိန်တည်းမှာပင်၊ အထက်ဖော်ပြပါ NodePort ဝန်ဆောင်မှုနှင့် ဆက်စပ်နေသော အစစ်အမှန် pods များသည် အချို့သောနေရာများတွင်သာ ရနိုင်သည် ဤ node များ၏ အပိုင်းခွဲ. တစ်နည်းဆိုရသော် ကျွန်ုပ်သည် လိုအပ်သော pod မပါသော node သို့ ချိတ်ဆက်ပါက၊ ၎င်းသည် အခြား node သို့ traffic ကို ပေးပို့လိမ့်မည်၊ ဟော့ပ်တစ်ခုထည့်သည်။ နှင့် latency တိုးလာခြင်း (node ​​များသည် မတူညီသော ရရှိနိုင်မှုဇုန်/ဒေတာစင်တာများတွင် တည်ရှိပါက၊ latency သည် အလွန်မြင့်မားနိုင်သည်၊ ထို့အပြင်၊ egress traffic ကုန်ကျစရိတ်များ တိုးလာမည်)။

အခြားတစ်ဖက်တွင်၊ အချို့သော Kubernetes ဝန်ဆောင်မှုတစ်ခုတွင် မူဝါဒတစ်ခုချမှတ်ထားပါက externalTrafficPolicy: Localထို့နောက် NodePort သည် လိုအပ်သော pods များ အမှန်တကယ်လည်ပတ်နေသည့် အဆိုပါ node များတွင်သာ ဖွင့်သည်။ အခြေအနေကို စစ်ဆေးသော ပြင်ပဝန်ချိန်ခွင်လျှာကို အသုံးပြုသောအခါ (ကျန်းမာရေးစစ်ဆေးခြင်း) အဆုံးမှတ်များ (ဘယ်လိုလုပ်တာလဲ။ AWS ELB), သူ လိုအပ်သော node များသို့သာ traffic ပို့ပါမည်။နှောင့်နှေးမှု၊ တွက်ချက်မှု လိုအပ်ချက်များ၊ ထုတ်ယူသည့် ငွေတောင်းခံလွှာများအပေါ် အကျိုးရှိသော အကျိုးသက်ရောက်မှုရှိစေမည့် (ဘုံသဘောက တူညီသည်)။

သင်အသုံးပြုနေပြီဖြစ်သော အခွင့်အလမ်း မြင့်မားပါသည်။ တောင်ကြီးမြို့ သို့မဟုတ် nginx-ingress-controller HTTP အဝင်အထွက်လမ်းကြောင်းကို လမ်းကြောင်းပေးရန်အတွက် NodePort အဆုံးမှတ် (သို့မဟုတ် LoadBalancer၊ သို့မဟုတ် LoadBalancer) အနေဖြင့် HTTP အဝင်အထွက်လမ်းကြောင်းကို လမ်းကြောင်းပေးကာ၊ ဤရွေးချယ်မှုအား သတ်မှတ်ခြင်းဖြင့် အဆိုပါတောင်းဆိုမှုများအတွက် latency ကို သိသိသာသာ လျှော့ချနိုင်ပါသည်။

В ဒီထုတ်ဝေမှု ExternalTrafficPolicy၊ ၎င်း၏ အားသာချက်များနှင့် အားနည်းချက်များကို သင်ပိုမိုလေ့လာနိုင်ပါသည်။

10. အစုအဝေးများနှင့် မချည်နှောင်ပါနှင့် ထိန်းချုပ်မှုလေယာဉ်ကို အလွဲသုံးစားမလုပ်ပါနှင့်

ယခင်က၊ မှန်ကန်သောအမည်များဖြင့် ဆာဗာများကို ခေါ်ခြင်းမှာ ထုံးစံအတိုင်းဖြစ်သည်- Anton၊ HAL9000 နှင့် Colossus... ယနေ့ ၎င်းတို့ကို ကျပန်းထုတ်ပေးသော ခွဲခြားသတ်မှတ်မှုများဖြင့် အစားထိုးထားသည်။ သို့သော် အလေ့အထရှိနေဆဲဖြစ်ပြီး ယခုအခါ သင့်လျော်သောအမည်များ အစုအဝေးသို့ ရောက်သွားပါသည်။

သာမာန်ဇာတ်လမ်းတစ်ခု (ဖြစ်ရပ်မှန်များကိုအခြေခံ၍)- ၎င်းသည် အယူအဆအထောက်အထားတစ်ခုဖြင့် စတင်ခဲ့ခြင်းဖြစ်သောကြောင့် အစုအဖွဲ့တွင် ဂုဏ်ယူစရာအမည်တစ်ခုရှိသည် စမ်းသပ်ခြင်း... နှစ်တွေကြာလာခဲ့ပြီး ထုတ်လုပ်မှုမှာ အသုံးပြုနေဆဲဖြစ်ပြီး လူတိုင်းက အဲဒါကို ထိဖို့ ကြောက်ရွံ့ကြပါတယ်။

အိမ်မွေးတိရိစ္ဆာန်များအဖြစ်သို့ အစုအဖွဲ့များအဖြစ်သို့ ပြောင်းလဲခြင်းအတွက် ပျော်ရွှင်စရာ ဘာမှမရှိပါ၊ ထို့ကြောင့် လေ့ကျင့်နေစဉ် အခါအားလျော်စွာ ၎င်းတို့အား ဖယ်ရှားရန် အကြံပြုအပ်ပါသည်။ ဘေးအန္တရာယ်ပြန်လည်ထူထောင်ရေး (ဒါကကူညီလိမ့်မယ်။ chaos အင်ဂျင်နီယာ - ခန့်မှန်းခြေ ဘာသာပြန်။). ထို့အပြင်၊ ထိန်းချုပ်မှုအလွှာတွင်အလုပ်လုပ်ရန်မထိခိုက်စေပါ။ (လေယာဉ်ထိန်း). သူ့ကို ထိရမှာ ကြောက်တာက ကောင်းတဲ့လက္ခဏာတော့ မဟုတ်ပါဘူး။ စသည်တို့ဖြစ်သည်။ သေပြီ? ယောက်ျားလေးတွေ၊ မင်းတကယ်ဒုက္ခရောက်နေပြီလား။

အခြားတစ်ဖက်တွင်မူ ၎င်းကို ကြိုးကိုင်ခြယ်လှယ်ခြင်း မပြုသင့်ပေ။ အချိန်နဲ့အမျှ ထိန်းချုပ်မှုအလွှာသည် နှေးကွေးသွားနိုင်သည်။. ဖြစ်နိုင်သည်မှာ၊ ၎င်းသည် ၎င်းတို့လည်ပတ်ခြင်းမရှိဘဲ အရာဝတ္ထုအများအပြားကို ဖန်တီးထားခြင်းကြောင့်ဖြစ်သည် (Helm ကို ပုံသေဆက်တင်များဖြင့် Helm ကိုအသုံးပြုသည့်အခါ ဖြစ်ရိုးဖြစ်စဉ်တစ်ခုဖြစ်သည့်အတွက် configmaps/လျှို့ဝှက်ချက်များရှိ ၎င်း၏အခြေအနေကို အပ်ဒိတ်မလုပ်ရခြင်းဖြစ်သည် - ရလဒ်အနေဖြင့် အရာဝတ္ထုထောင်ပေါင်းများစွာ စုပုံနေပါသည်။ ထိန်းချုပ်မှုအလွှာ) သို့မဟုတ် kube-api အရာဝတ္ထုများ၏ အဆက်မပြတ်တည်းဖြတ်မှုဖြင့် (အလိုအလျောက် အတိုင်းအတာအတွက်၊ CI/CD အတွက်၊ စောင့်ကြည့်မှု၊ ဖြစ်ရပ်မှတ်တမ်းများ၊ ထိန်းချုပ်ကိရိယာများ စသည်ဖြင့်)။

ထို့အပြင်၊ ကျွန်ုပ်တို့သည် စီမံခန့်ခွဲထားသော Kubernetes ဝန်ဆောင်မှုပေးသူနှင့် SLA/SLO သဘောတူညီချက်များကို စစ်ဆေးပြီး အာမခံချက်များကို အာရုံစိုက်ရန် အကြံပြုပါသည်။ ရောင်းချသူ အာမခံနိုင်ပါသည်။ ထိန်းချုပ်မှုအလွှာရရှိနိုင်မှု (သို့မဟုတ် ၎င်း၏ အစိတ်အပိုင်းများ)၊ သို့သော် သင်ပေးပို့သော တောင်းဆိုချက်များ၏ p99 နှောင့်နှေးခြင်းမျိုး မဟုတ်ပါ။ တစ်နည်းအားဖြင့်သင်ဝင်နိုင်သည်။ kubectl get nodesနှင့် 10 မိနစ်အကြာတွင်သာ အဖြေတစ်ခုလက်ခံရယူပါ၊ ၎င်းသည် ဝန်ဆောင်မှုသဘောတူညီချက်၏ စည်းကမ်းချက်များကို ချိုးဖောက်မည်မဟုတ်ပါ။

11. အပိုဆု- နောက်ဆုံးတက်ဂ်ကို အသုံးပြုခြင်း။

ဒါပေမယ့် ဒါက classic ဖြစ်နေပါပြီ။ မကြာသေးမီက ကျွန်ုပ်တို့သည် ဤနည်းပညာကို မကြာခဏဆိုသလို တွေ့လာရပြီး၊ များစွာသော ခါးသီးသော အတွေ့အကြုံများမှ သင်ခန်းစာယူကာ tag ကို မသုံးတော့ဘဲ ဖြစ်နေသောကြောင့်ဖြစ်သည်။ :latest ဗားရှင်းများကို စတင်၍ ပင်ထိုးထားသည်။ ဟူး!

ECR ပုံတဂ်များ၏ မပြောင်းလဲနိုင်မှုကို ထိန်းသိမ်းသည်။; ဤထူးခြားသောအင်္ဂါရပ်နှင့် သင်ကိုယ်တိုင်ရင်းနှီးကျွမ်းဝင်ရန် ကျွန်ုပ်တို့ အကြံပြုအပ်ပါသည်။

အကျဉ်းချုပ်

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

အဖွဲ့အသီးသီး၏ မအောင်မြင်သော အတွေ့အကြုံများကို သင်သိနိုင်သည်။ ဤပုံပြင်များစုစည်းမှု Henning Jacobs မှ

ဤဆောင်းပါးတွင်ဖော်ပြထားသောအမှားများစာရင်းတွင်ထည့်သွင်းလိုသူများသည်ကျွန်ုပ်တို့ကို Twitter တွင်ဆက်သွယ်နိုင်သည် (@MarekBartik, @MstrsObserver).

PS ဘာသာပြန်မှ

ကျွန်ုပ်တို့၏ဘလော့ဂ်တွင်လည်းဖတ်ပါ

• «Kubernetes အစုအဝေးများကို ဒီဇိုင်းဆွဲခြင်း- မည်မျှရှိသင့်သနည်း။";
• «Kubernetes ရှိ လုံခြုံရေး ABC- အထောက်အထားပြခြင်း၊ ခွင့်ပြုချက်၊ စာရင်းစစ်ခြင်း။";
• «Kubernetes ရှိ အော်တိုစကေးချဲ့ခြင်းနှင့် အရင်းအမြစ်စီမံခန့်ခွဲမှု"(သုံးသပ်ချက်နှင့်ဗီဒီယိုအစီရင်ခံစာ);
• «Kubernetes ရှိ ConfigMaps- သိသင့်သိထိုက်သော ကွဲပြားချက်များ"။

source: www.habr.com