Kubernetes ရှိ အသက်ရှင်ခြင်းဆိုင်ရာ စစ်ဆေးခြင်းများသည် အန္တရာယ်ရှိနိုင်သည်။

မှတ်ချက်။ ဘာသာပြန်: Zalando မှ ဦးဆောင်အင်ဂျင်နီယာ၊ Henning Jacobs သည် အသက်ရှင်ခြင်း (အဆင်သင့်ဖြစ်ခြင်း) probes များ၏ ရည်ရွယ်ချက်နှင့် ၎င်းတို့၏ မှန်ကန်သောအသုံးပြုမှုကို နားလည်ရန်အတွက် Kubernetes အသုံးပြုသူများကြား ပြဿနာများကို ထပ်ခါတလဲလဲ သတိပြုမိပါသည်။ ထို့ကြောင့်၊ သူသည် နောက်ဆုံးတွင် K8s မှတ်တမ်း၏ အစိတ်အပိုင်းဖြစ်လာမည့် ဤ capacious note တွင် သူ၏အတွေးများကို စုဆောင်းခဲ့သည်။

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

ကျွန်ုပ်၏လုပ်ဖော်ကိုင်ဖက် Sandor သည် မကြာသေးမီက တွစ်တာတွင် သူကြုံတွေ့ရသော အဖြစ်များဆုံး အမှားအယွင်းများဖြစ်သည့် အဆင်သင့်/အသက်ရှင်သန်မှုဆိုင်ရာ ပစ္စတင်များကို အသုံးပြုခြင်းနှင့် သက်ဆိုင်သည်-

မှားယွင်းစွာ စီစဉ်သတ်မှတ်ထားသည်။ livenessProbe မြင့်မားသော load အခြေအနေများကို ပိုမိုဆိုးရွားစေနိုင်သည် (နှင်းဘောလုံးပိတ်ခြင်း + ကြာမြင့်နိုင်ချေရှိသော ကွန်တိန်နာ/ လျှောက်လွှာစတင်ချိန်) နှင့် မှီခိုမှုကျဆင်းခြင်းကဲ့သို့သော အခြားဆိုးကျိုးများကို ဖြစ်ပေါ်စေသည် (ကိုလည်းကြည့်ပါ။ ကျွန်ုပ်၏မကြာသေးမီကဆောင်းပါး K3s+ACME ပေါင်းစပ်မှုတွင် တောင်းဆိုမှုအရေအတွက် ကန့်သတ်ခြင်းအကြောင်း၊. ပြင်ပဒေတာဘေ့စ်ဖြစ်သည့် ကျန်းမာရေးစစ်ဆေးခြင်းနှင့် ပေါင်းစပ်လိုက်သောအခါတွင် ပို၍ဆိုးသည် DB တစ်ခုတည်း ချို့ယွင်းချက်တစ်ခုသည် သင့်ကွန်တိန်နာအားလုံးကို ပြန်လည်စတင်မည်ဖြစ်သည်။!

အထွေထွေသတင်းစကား "အသက်ရှုလမ်းကြောင်းကို မသုံးပါနဲ့" ဤကိစ္စတွင်၊ ၎င်းသည် များစွာအထောက်အကူမပြုပါ၊ ထို့ကြောင့် အဆင်သင့်နှင့် အသက်ရှင်နေထိုင်မှု စစ်ဆေးမှုများကို ကြည့်ကြပါစို့။

မှတ်ချက်- အောက်ဖော်ပြပါ စမ်းသပ်မှုအများစုသည် Zalando ၏ အတွင်းပိုင်းဆော့ဖ်ဝဲရေးသားသူ စာရွက်စာတမ်းတွင် မူလပါဝင်ပါသည်။

အဆင်သင့်နှင့် အသက်ရှင်မှု စစ်ဆေးမှုများ

Kubernetes ဟုခေါ်သော အရေးကြီးသော ယန္တရားနှစ်ခုကို ပံ့ပိုးပေးသည်။ အသက်ရှင်ခြင်းဆိုင်ရာ စုံစမ်းစစ်ဆေးခြင်းနှင့် အဆင်သင့်ဖြစ်ခြင်းဆိုင်ရာ စုံစမ်းစစ်ဆေးမှုများ. ၎င်းတို့သည် HTTP တောင်းဆိုချက်တစ်ခုပေးပို့ခြင်း၊ TCP ချိတ်ဆက်မှုတစ်ခုဖွင့်ခြင်း သို့မဟုတ် ကွန်တိန်နာအတွင်း အမိန့်တစ်ခုလုပ်ဆောင်ခြင်းကဲ့သို့သော လုပ်ဆောင်မှုအချို့ကို အခါအားလျော်စွာလုပ်ဆောင်ကြသည်—အပလီကေးရှင်းသည် မျှော်လင့်ထားသည့်အတိုင်းအလုပ်လုပ်နေကြောင်း အတည်ပြုရန်။

Kubernetes အသုံးပြုသည်။ စေတနာစူးစမ်းမှုကွန်တိန်နာသည် အသွားအလာလက်ခံရန် အဆင်သင့်ဖြစ်သည့်အခါ နားလည်ရန်။ ၎င်း၏ ကွန်တိန်နာအားလုံး အဆင်သင့်ဖြစ်လျှင် ဘူးတစ်လုံးကို အသုံးပြုရန် အဆင်သင့်ဟု ယူဆပါသည်။ ဤယန္တရား၏အသုံးပြုမှုတစ်ခုမှာ Kubernetes ဝန်ဆောင်မှုများ (နှင့် အထူးသဖြင့် Ingress) အတွက် မည်သည့် pods များကို backends အဖြစ်အသုံးပြုသည်ကို ထိန်းချုပ်ရန်ဖြစ်သည်။

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

နေထိုင်မှု/အဆင်သင့်စစ်ဆေးမှုများ ပျက်ကွက်သည့် အပလီကေးရှင်း အပ်ဒိတ်တစ်ခုကို သင်အသုံးပြုရန် ကြိုးစားပါက Kubernetes အခြေအနေကို စောင့်ဆိုင်းနေချိန်တွင် ၎င်း၏ ဖြန့်ချိမှုကို ရပ်တန့်သွားမည်ဖြစ်သည်။ Ready အစေ့များအားလုံးမှ

နမူနာ

ဤသည်မှာ လမ်းကြောင်းတစ်ခုအား စစ်ဆေးရန် အဆင်သင့် စုံစမ်းစစ်ဆေးမှုတစ်ခု၏ ဥပမာတစ်ခုဖြစ်သည်။ /health မူရင်းဆက်တင်များဖြင့် HTTP မှတဆင့် (အကြား: 10 စက္ကန့်၊ ခဏပွဲရပ်ခြင်း: 1 စက္ကန့်၊ အောင်မြင်မှုအဆင့်: 1, ကျရှုံးခြင်းအဆင့်:3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

အကြံပြုချက်များ

1. HTTP အဆုံးမှတ်ပါရှိသော မိုက်ခရိုဝန်ဆောင်မှုများအတွက် (REST၊ စသည်ဖြင့်) အဆင်သင့်ဖြစ်မှုကို အမြဲသတ်မှတ်ပါ။အပလီကေးရှင်း (pod) သည် အသွားအလာ လက်ခံရန် အဆင်သင့်ဖြစ်မဖြစ် စစ်ဆေးပေးသည်။
2. စေတနာကို သေချာစုံစမ်းပါ။ အမှန်တကယ် ဝဘ်ဆာဗာ ဆိပ်ကမ်း၏ ရရှိနိုင်မှုကို အကျုံးဝင်သည်။:
   • "စီမံခန့်ခွဲရေး" သို့မဟုတ် "စီမံခန့်ခွဲမှု" (ဥပမာ၊ 9090) ဟုခေါ်သော စီမံခန့်ခွဲရေးဆိုင်ရာရည်ရွယ်ချက်များအတွက် ဆိပ်ကမ်းများကို အသုံးပြု၍ readinessProbeမူလ HTTP အပေါက် (8080 ကဲ့သို့) အသွားအလာကို လက်ခံရန် အဆင်သင့်ဖြစ်လျှင် အဆုံးမှတ်သည် OK သာ ပြန်သွားကြောင်း သေချာပါစေ။

     * ဒီလိုမဖြစ်ခဲ့တဲ့ Zalando မှာ အနည်းဆုံး ဖြစ်ရပ်တစ်ခုကို ကျွန်တော် သတိပြုမိပါတယ်။ readinessProbe ငါ "စီမံခန့်ခွဲမှု" ဆိပ်ကမ်းကိုစစ်ဆေးခဲ့သည်၊ သို့သော် cache ကိုဖွင့်ခြင်းပြဿနာများကြောင့်ဆာဗာကိုယ်တိုင်အလုပ်မလုပ်ပါ။

   • သီးခြားဆိပ်ကမ်းတစ်ခုသို့ အဆင်သင့်စစ်ဆေးခြင်းတစ်ခုကို ပူးတွဲထည့်သွင်းခြင်းသည် ကျန်းမာရေးစစ်ဆေးမှုတွင် ဝန်ပိုနေခြင်းကို ဖြစ်ပေါ်စေနိုင်သည် (ဆိုလိုသည်မှာ ဆာဗာရှိ thread pool သည် ပြည့်နေသော်လည်း ကျန်းမာရေးစစ်ဆေးမှုသည် အားလုံးကောင်းကြောင်း ပြသနေသေးသည်။ )
3. သေချာအောင်လုပ်ပါ ဒေတာဘေ့စ်အစပျိုးခြင်း/ရွှေ့ပြောင်းခြင်းကို အဆင်သင့်ဖြစ်ခြင်းမှ လုပ်ဆောင်ပေးသည်။;
   • ၎င်းကိုရရှိရန် အလွယ်ကူဆုံးနည်းလမ်းမှာ ကနဦးစတင်ခြင်းပြီးမြောက်ပြီးမှသာ HTTP ဆာဗာကို ဆက်သွယ်ရန်ဖြစ်သည် (ဥပမာ၊ ဒေတာဘေ့စ်တစ်ခုမှ ပြောင်းရွှေ့ခြင်း ပျံလမ်း နောက် ... ပြီးတော့။); ဆိုလိုသည်မှာ၊ ဒေတာဘေ့စ်ပြောင်းရွှေ့ခြင်းမပြီးမချင်း၊ ကျန်းမာရေးစစ်ဆေးမှုအခြေအနေကို ပြောင်းလဲမည့်အစား ဝဘ်ဆာဗာကို မစတင်ပါနှင့်*။

     * pod ပြင်ပရှိ init containers များမှ ဒေတာဘေ့စ် ရွှေ့ပြောင်းမှုများကိုလည်း လုပ်ဆောင်နိုင်သည်။ ကျွန်ုပ်သည် ကိုယ်တိုင်ပါရှိသော အပလီကေးရှင်းများကို နှစ်သက်ဆဲဖြစ်သည်၊ ဆိုလိုသည်မှာ အပလီကေးရှင်းကွန်တိန်နာတွင် ပြင်ပညှိနှိုင်းမှုမရှိဘဲ ဒေတာဘေ့စ်ကို လိုချင်သောအခြေအနေသို့ မည်သို့ဆောင်ကြဉ်းရမည်ကို သိရှိသူများဖြစ်သည်။

4. အသုံးပြုပါ httpGet ပုံမှန်ကျန်းမာရေးစစ်ဆေးသည့်နေရာများမှ အဆင်သင့်စစ်ဆေးမှုများအတွက် (ဥပမာ၊ /health).
5. default check parameters များကို နားလည်ပါ။ (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • ပုံသေရွေးချယ်မှုများသည် pod ဖြစ်လာလိမ့်မည်ဟုဆိုလိုသည်။ အဆင်သင့်မဖြစ်သေးပါ။ စက္ကန့် 30 ခန့်အကြာတွင် (3 မအောင်မြင်သောစိတ်ပိုင်းဆိုင်ရာစစ်ဆေးမှု) ။
6. နည်းပညာအစုအဝေး (ဥပမာ Java/Spring) ခွင့်ပြုပါက၊ "စီမံခန့်ခွဲသူ" သို့မဟုတ် "စီမံခန့်ခွဲမှု" အတွက် သီးခြားဆိပ်ကမ်းကို အသုံးပြုပါ-
   • ဒါပေမယ့် အချက် 2 ကို မမေ့ပါနဲ့။
7. လိုအပ်ပါက၊ ကွန်တိန်နာပူနွေးလာသည်အထိ 503 အခြေအနေကုဒ်ကို ပြန်ဖွင့်ရန် အဆင်သင့်စစ်ဆေးခြင်းအား အသုံးပြုနိုင်သည်။
   • စစ်ဆေးမှုအသစ်ကို ဖတ်ကြည့်ဖို့လည်း အကြံပြုလိုပါတယ်။ startupProbe, ဗားရှင်း 1.16 တွင်ပေါ်လာသည်။ (ကျွန်ုပ်တို့သည် ရုရှားဘာသာဖြင့် ၎င်းအကြောင်းကို ရေးသားခဲ့သည်။ ဒီမှာ - ခန့်မှန်းခြေ ဘာသာပြန်။).

သတိပြုရန်အချက်များ

1. ပြင်ပမှီခိုမှုအပေါ် အားမကိုးပါနဲ့။ (ဒေတာဂိုဒေါင်များကဲ့သို့) အဆင်သင့်/အသက်ရှင်သန်မှု စမ်းသပ်မှုများကို လုပ်ဆောင်သည့်အခါ - ၎င်းသည် ပျက်ကွက်မှုများကို ဖြစ်ပေါ်စေနိုင်သည်-
   • ဥပမာအနေဖြင့်၊ Postgres ဒေတာဘေ့စ်တစ်ခုအပေါ် မူတည်၍ အကွက် 10 ပါသော နိုင်ငံပိုင် REST ဝန်ဆောင်မှုကို ယူကြပါစို့- DB သို့အလုပ်လုပ်သောချိတ်ဆက်မှုအပေါ် မူတည်၍ စစ်ဆေးသောအခါ၊ ကွန်ရက်/DB ဘက်တွင် နှောင့်နှေးမှုရှိပါက 10 pods အားလုံးသည် ကျရှုံးနိုင်သည် - များသောအားဖြင့် ၎င်းသည် အားလုံးက တတ်နိုင်တာထက် ပိုဆိုးတယ်။
   • Spring Data သည် ဒေတာဘေ့စ်ချိတ်ဆက်မှုကို မူရင်းအတိုင်းစစ်ဆေးသည်*;

     * ဤသည်မှာ Spring Data Redis ၏ ပုံသေအပြုအမူဖြစ်သည် (အနည်းဆုံး ငါနောက်ဆုံးအကြိမ်စစ်ဆေးခဲ့သည်) သည် "ကပ်ဆိုးကြီး" ကျရှုံးမှုကို ဖြစ်စေသည်- Redis ကို အချိန်တိုအတွင်း မရရှိနိုင်သောအခါ၊ pods များအားလုံး "ပျက်ကျသည်" ။

   • ဤအဓိပ္ပာယ်တွင် "ပြင်ပ" သည် တူညီသောအပလီကေးရှင်း၏အခြား pods များကိုဆိုလိုနိုင်သည်၊ ဆိုလိုသည်မှာ၊ အကောင်းဆုံးအားဖြင့် check သည် cascading crashes ကိုကာကွယ်ရန်အတွက်တူညီသောအစုအဝေး၏အခြား pods များ၏အခြေအနေအပေါ်မမူတည်သင့်ပါ။
     • ဖြန့်ဝေထားသော အခြေအနေရှိသော အပလီကေးရှင်းများအတွက် ရလဒ်များသည် ကွဲပြားနိုင်သည် (ဥပမာ၊ ပေါ့ဒ်များတွင် မမ်မိုရီအတွင်း သိမ်းဆည်းခြင်း)။
2. အသက်ဝင်စေသော ပစ္စကို မသုံးပါနှင့် pods များအတွက် (ခြွင်းချက်များသည် ၎င်းတို့ အမှန်တကယ် လိုအပ်သည့်အခါတွင် ကိစ္စရပ်များဖြစ်ပြီး ၎င်းတို့အသုံးပြုမှု၏ သီးခြားနှင့် အကျိုးဆက်များကို သင် အပြည့်အဝ သိရှိသည်)
   • အသက်ဝင်ခြင်းဆိုင်ရာစုံစမ်းစစ်ဆေးမှုသည် ချိတ်ဆွဲထားသောကွန်တိန်နာများကို ပြန်လည်ရယူရာတွင် ကူညီပေးနိုင်သော်လည်း သင်၏လျှောက်လွှာကို အပြည့်အဝထိန်းချုပ်နိုင်သောကြောင့်၊ ချိတ်ဆွဲထားသည့်လုပ်ငန်းစဉ်များနှင့် deadlocks ကဲ့သို့သော အရာများသည် အကောင်းဆုံးမဖြစ်သင့်ပါ- အကောင်းဆုံးနည်းလမ်းမှာ အက်ပ်လီကေးရှင်းကို တမင်ပျက်ကျစေပြီး ယခင်တည်ငြိမ်သောအခြေအနေသို့ ပြန်လည်ရောက်ရှိစေရန်ဖြစ်သည်။
   • မအောင်မြင်သောအသက်ဝင်ခြင်းဆိုင်ရာစုံစမ်းစစ်ဆေးမှုသည် ကွန်တိန်နာကိုပြန်လည်စတင်စေမည်ဖြစ်ပြီး၊ ထို့ကြောင့် loading-related errors ၏အကျိုးဆက်များကိုပိုမိုဆိုးရွားသွားစေနိုင်သည်- ကွန်တိန်နာကိုပြန်လည်စတင်ခြင်းသည် စက်ရပ်ချိန်ဖြစ်စေသည် (အနည်းဆုံးအပလီကေးရှင်းစတင်သည့်ကြာချိန်အတွက်၊ 30-ထူးဆန်းသောစက္ကန့်ဟုပြောပါ)၊ အမှားအသစ်များဖြစ်ပေါ်စေသည် အခြားကွန်တိန်နာများတွင် ဝန်ကိုတိုးစေပြီး ၎င်းတို့၏ ချို့ယွင်းမှုဖြစ်နိုင်ခြေကို တိုးစေခြင်း၊
   • ပြင်ပမှီခိုမှုတစ်ခုနှင့် ပေါင်းစပ်ထားသော အသက်ရှင်မှုစစ်ဆေးမှုများသည် အဆိုးဆုံးဖြစ်နိုင်ချေရှိသော ပေါင်းစပ်မှုဖြစ်ပြီး၊ မအောင်မြင်မှုများကို ခြိမ်းခြောက်နေသည်- ဒေတာဘေ့စ်ဘက်ခြမ်းရှိ အနည်းငယ်နှောင့်နှေးခြင်းသည် သင့်ကွန်တိန်နာအားလုံးကို ပြန်လည်စတင်ရန် ဦးတည်သွားစေမည်ဖြစ်သည်။
3. အသက်ရှင်မှုနှင့် အဆင်သင့်စစ်ဆေးမှုများ၏ ကန့်သတ်ချက်များ ကွဲပြားရပါမည်။:
   • တူညီသောကျန်းမာရေးစစ်ဆေးမှုနှင့်အတူ အသက်ရှင်နေထိုင်ခြင်းဆိုင်ရာစုံစမ်းစစ်ဆေးမှုကို သင်အသုံးပြုနိုင်သော်လည်း ပိုမိုမြင့်မားသောတုံ့ပြန်မှုအဆင့် (failureThreshold) ဥပမာ၊ အဆင့်အတန်းသတ်မှတ်ပါ။ အဆင်သင့်မဖြစ်သေးပါ။ 3 ကြိမ်ကြိုးစားပြီးနောက် 10 ကြိမ်ကြိုးစားပြီးနောက်အသက်ရှင်သန်မှုစုံစမ်းစစ်ဆေးမှုမအောင်မြင်ကြောင်းစဉ်းစားပါ။
4. exec စစ်ဆေးမှုများကို မသုံးပါနှင့်ဖုတ်ကောင်ဖြစ်စဉ်များ အသွင်အပြင်ကို ဦးတည်စေသည့် သိထားသည့် ပြဿနာများနှင့် ဆက်စပ်နေသောကြောင့်၊
   • အသေးစိတ်အချက်များ: ကြည့်ပါ။ Datadog ကျွမ်းကျင်ပညာရှင်များမှတင်ဆက်သည်။.

အကျဉ်းချုပ်

• အသွားအလာ လက်ခံရန် အဆင်သင့်ဖြစ်ချိန်ကို ဆုံးဖြတ်ရန် အဆင်သင့် စစ်ဆေးမှုများကို အသုံးပြုပါ။
• အမှန်တကယ် လိုအပ်မှသာ အသက်ရှင်ခြင်းဆိုင်ရာ စစ်ဆေးခြင်းများကို အသုံးပြုပါ။
• အဆင်သင့်/အသက်ရှင်သန်မှုဆိုင်ရာ စုံစမ်းစစ်ဆေးမှုများကို မှားယွင်းစွာအသုံးပြုခြင်းသည် ရရှိနိုင်မှု လျော့နည်းခြင်းနှင့် အကျုံးမဝင်ခြင်းတို့ကို ဖြစ်စေနိုင်သည်။

အကြောင်းအရာအပေါ်အပိုပစ္စည်းများ

• Kubernetes docs- အသက်ရှင်မှုနှင့် အဆင်သင့်ဖြစ်မှုဆိုင်ရာ စုံစမ်းစစ်ဆေးမှုများကို စီစဉ်သတ်မှတ်ပါ။;
• Kubernetes ၏ ရှင်သန်မှုနှင့် အဆင်သင့် စစ်ဆေးမှုများကို ပြန်လည်ကြည့်ရှုခဲ့သည်- အခြားခြေဖဝါးတွင် သင့်ကိုယ်သင် ပစ်သတ်ခြင်းမှ ရှောင်ကြဉ်နည်း;
• NRE Labs Outage Post-mortem (သူသည် အသက်ရှင်ခြင်းအကြောင်းလည်း ပြောသည်)။

1-2019-09 မှ နံပါတ် 29 ကို အပ်ဒိတ်လုပ်ပါ။

ဒေတာဘေ့စ် ရွှေ့ပြောင်းခြင်းအတွက် init containers အကြောင်း: အောက်ခြေမှတ်စုကို ထည့်သွင်းထားသည်။

EJ က ကျွန်တော့်ကို သတိပေးတယ်။ PDB အကြောင်း- အသက်ရှင်သန်မှု စစ်ဆေးခြင်းဆိုင်ရာ ပြဿနာများထဲမှ တစ်ခုမှာ စပါးပင်များကြား ညှိနှိုင်းမှု မရှိခြင်းပင်ဖြစ်သည်။ Kubernetes ရှိသည်။ Pod Disruption Budgets (PDB) အက်ပလီကေးရှင်းတစ်ခုသည် တစ်ပြိုင်နက်တည်း ကျရှုံးမှုအရေအတွက်ကို ကန့်သတ်ရန်၊ သို့သော် စစ်ဆေးမှုများသည် PDB အား ထည့်သွင်းစဉ်းစားခြင်းမရှိပါ။ အကောင်းဆုံးအားဖြင့်၊ ကျွန်ုပ်တို့ K8s အား "၎င်း၏စမ်းသပ်မှုမအောင်မြင်ပါက pod တစ်ခုကို ပြန်လည်စတင်ရန်၊ သို့သော် အရာများကို ပိုဆိုးသွားခြင်းမှရှောင်ရှားရန် ၎င်းတို့အားလုံးကို ပြန်လည်စတင်ခြင်းမပြုပါနှင့်။"

ဘရိုင်ယန်က အဲဒါကို အပြည့်အ၀ ထည့်လိုက်တယ်။: “ဘာလဲဆိုတာ အတိအကျသိတဲ့အခါ အသက်ရှင်သန်မှုကို စမ်းသုံးပါ။ လျှောက်လွှာကိုသတ်ပစ်ရန်အကောင်းဆုံးအရာဖြစ်သည်။"(နောက်တစ်ခါ မယူသွားပါနဲ့)။

2-2019-09 မှ နံပါတ် 29 ကို အပ်ဒိတ်လုပ်ပါ။

အသုံးမပြုမီ စာရွက်စာတမ်းများကို ဖတ်ပါ။: သက်ဆိုင်သော တောင်းဆိုချက်ကို ငါဖန်တီးခဲ့သည် (အင်္ဂါရပ်တောင်းဆိုချက်) အသက်ရှင်သန်မှု စစ်ဆေးခြင်းဆိုင်ရာ စာရွက်စာတမ်းများကို ထည့်သွင်းရန်။

PS ဘာသာပြန်မှ

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

• «Kubernetes- Pod Life";
• «Google အရ ကွန်တိန်နာအသုံးပြုခြင်းအတွက် အကောင်းဆုံးအလေ့အကျင့် 7 ခု";
• «ကွန်တိန်နာအခြေခံ အပလီကေးရှင်းများ ဒီဇိုင်းရေးဆွဲခြင်းအတွက် အခြေခံမူ ၇ ချက်"။

source: www.habr.com