Kubernetes တွင် ပထမဆုံး အပလီကေးရှင်းကို အသုံးပြုသောအခါ လွဲချော်မှုငါးခု

Aris Dreamer မှ ပျက်ကွက်

အပလီကေးရှင်းကို Kubernetes (Helm သို့မဟုတ် ကိုယ်တိုင်အသုံးပြု၍ဖြစ်စေ) သို့ လွှဲပြောင်းရန် လုံလောက်သည်ဟု လူအများက ထင်မြင်ကြပြီး ပျော်ရွှင်မှုရှိလာမည်ဖြစ်သည်။ ဒါပေမယ့် အရာအားလုံးက ဒီလောက်ရိုးရှင်းတာတော့ မဟုတ်ပါဘူး။

အဖွဲ့ Mail.ru တိမ်တိုက်ဖြေရှင်းချက် DevOps အင်ဂျင်နီယာ Julian Gindy မှ ဘာသာပြန်ထားသော ဆောင်းပါးတစ်ပုဒ်။ ရွှေ့ပြောင်းအခြေချမှု လုပ်ငန်းစဉ်အတွင်း မိမိကုမ္ပဏီ ကြုံတွေ့ခဲ့ရသည့် ချို့ယွင်းချက်များကို ပြောပြသည်။

အဆင့်တစ်- Pod တောင်းဆိုမှုများနှင့် ကန့်သတ်ချက်များကို သတ်မှတ်ပါ။

ကျွန်ုပ်တို့၏ pods များလည်ပတ်မည့် သန့်ရှင်းသောပတ်ဝန်းကျင်ကို သတ်မှတ်ခြင်းဖြင့် စတင်ကြပါစို့။ Kubernetes သည် pod အစီအစဉ်ဆွဲခြင်းနှင့် ပျက်ကွက်ခြင်းတွင် ကောင်းမွန်သည်။ သို့သော် အောင်မြင်စွာလုပ်ဆောင်ရန် အရင်းအမြစ်မည်မျှလိုအပ်သည်ကို ခန့်မှန်းရန်ခက်ခဲပါက အချိန်ဇယားဆွဲသူသည် တစ်ခါတစ်ရံတွင် pod တစ်ခုကို မထားရှိနိုင်တော့ကြောင်း တွေ့ရှိရပါသည်။ ဤနေရာတွင် အရင်းအမြစ်များနှင့် ကန့်သတ်ချက်များ တောင်းဆိုမှုများ ပေါ်လာသည်။ တောင်းဆိုချက်များနှင့် ကန့်သတ်ချက်များကို သတ်မှတ်ရန် အကောင်းဆုံးနည်းလမ်းနှင့် ပတ်သက်၍ ဆွေးနွေးငြင်းခုံမှုများ အများအပြားရှိသည်။ တစ်ခါတစ်ရံတွင် ဤအရာသည် သိပ္ပံပညာထက် အနုပညာတစ်ခုထက်ပိုသည်ဟု ထင်ရ၏။ ဒါကတော့ ကျွန်တော်တို့ရဲ့ ချဉ်းကပ်မှုပါ။

Pod တောင်းဆိုမှုများ pod ကိုအကောင်းဆုံးနေရာချရန်စီစဉ်သူမှအသုံးပြုသောအဓိကတန်ဖိုးဖြစ်သည်။

မှ Kubernetes စာရွက်စာတမ်း: စစ်ထုတ်မှုအဆင့်သည် Pod တစ်ခုကို စီစဉ်နိုင်သည့် ဆုံမှတ်အစုအဝေးကို သတ်မှတ်သည်။ ဥပမာအားဖြင့်၊ PodFitsResources စစ်ထုတ်မှုသည် node တစ်ခုမှ သီးခြားအရင်းအမြစ်တောင်းဆိုမှုများကို ဖြည့်ဆည်းရန် node တွင် လုံလောက်သောရင်းမြစ်များ ရှိ၊ မရှိ ကြည့်ရှုစစ်ဆေးသည်။

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

ဤအခြေအနေမျိုးတွင်၊ အစီအစဉ်ဆွဲသူသည် မကြာခဏဆိုသလို အစေ့များကို "ညှစ်ထုတ်" ပြီး ၎င်းတို့ကို အချိန်ဇယားဆွဲရန် မဖြစ်နိုင်သောကြောင့် ထိန်းချုပ်မှုလေယာဉ်သည် အပလီကေးရှင်းတွင် အရင်းအမြစ်မည်မျှလိုအပ်မည်ကို မသိသောကြောင့်၊ အစီအစဉ်ဆွဲခြင်းဆိုင်ရာ အယ်လဂိုရီသမ်၏ အဓိကအစိတ်အပိုင်းတစ်ခုဖြစ်သည်။

Pod ကန့်သတ်ချက်များ pod တစ်ခုအတွက် ပိုမိုရှင်းလင်းသော ကန့်သတ်ချက်ဖြစ်သည်။ ၎င်းသည် ကွန်တိန်နာအတွက် အစုအဖွဲ့မှခွဲဝေပေးမည့် အများဆုံးအရင်းအမြစ်ပမာဏကို ကိုယ်စားပြုသည်။

တဖန်၊ တရားဝင်စာရွက်စာတမ်း− ကွန်တိန်နာတစ်ခုတွင် မမ်မိုရီကန့်သတ်ချက် 4 GiB ရှိပါက၊ kubelet (နှင့် container runtime) သည် ၎င်းအား တွန်းအားပေးမည်ဖြစ်သည်။ Runtime သည် ကွန်တိန်နာအား သတ်မှတ်ထားသော အရင်းအမြစ်ကန့်သတ်ချက်ထက်ပို၍ အသုံးပြုခြင်းမှ တားဆီးသည်။ ဥပမာအားဖြင့်၊ ကွန်တိန်နာတစ်ခုအတွင်းရှိ လုပ်ငန်းစဉ်တစ်ခုသည် ခွင့်ပြုမှတ်ဉာဏ်ပမာဏထက် ပိုမိုအသုံးပြုရန် ကြိုးစားသောအခါ၊ စနစ် kernel သည် "မှတ်ဉာဏ်မရှိသော" (OOM) အမှားတစ်ခုဖြင့် လုပ်ငန်းစဉ်ကို အဆုံးသတ်သည်။

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

အကောင်းဆုံးကတော့၊ ကျွန်ုပ်တို့သည် စနစ်အတွင်းရှိ အခြားသော လုပ်ငန်းစဉ်များကို အနှောင့်အယှက်မဖြစ်စေဘဲ လုပ်ငန်းစဉ်တစ်ခု၏ ဘဝစက်ဝန်းအတွင်း pod တစ်ခု၏ အရင်းအမြစ်လိုအပ်ချက်များကို ပြောင်းလဲစေလိုသည် - ၎င်းသည် ကန့်သတ်ချက်များကို သတ်မှတ်ရခြင်း၏ ရည်ရွယ်ချက်ဖြစ်သည်။

ကံမကောင်းစွာဖြင့်၊ သတ်မှတ်ရမည့်တန်ဖိုးများနှင့်ပတ်သက်၍ တိကျသောညွှန်ကြားချက်များကို ကျွန်ုပ်မပေးနိုင်သော်လည်း ကျွန်ုပ်တို့ကိုယ်တိုင် အောက်ပါစည်းမျဉ်းများကို လိုက်နာပါသည်-

1. ဝန်စမ်းသပ်ကိရိယာကို အသုံးပြု၍ ကျွန်ုပ်တို့သည် အသွားအလာ၏ အခြေခံအဆင့်ကို တုပပြီး pod ရင်းမြစ်များ (မှတ်ဉာဏ်နှင့် ပရိုဆက်ဆာ) အသုံးပြုမှုကို စောင့်ကြည့်လေ့လာပါသည်။
2. pod တောင်းဆိုမှုများကို မထင်သလို နိမ့်သောတန်ဖိုး (အရင်းအမြစ် ကန့်သတ်ချက် 5 ဆခန့်ရှိသော တောင်းဆိုမှုတန်ဖိုး) ကို သတ်မှတ်ပြီး စောင့်ကြည့်ပါ။ တောင်းဆိုမှုများသည် အဆင့်အလွန်နိမ့်သောအခါ၊ လုပ်ငန်းစဉ်သည် မစတင်နိုင်ဘဲ၊ မကြာခဏ လျှို့ဝှက်ဝှက်ထားသော Go runtime အမှားများကို ဖြစ်စေသည်။

ပိုမိုမြင့်မားသောအရင်းအမြစ်ကန့်သတ်ချက်များသည် pod သည်ရရှိနိုင်လောက်အောင်အရင်းအမြစ်များရှိသောပစ်မှတ် node တစ်ခုလိုအပ်သောကြောင့်အချိန်ဇယားဆွဲခြင်းကိုပိုမိုခက်ခဲစေသည်ကိုကျွန်ုပ်သတိပြုမိပါသည်။

မမ်မိုရီ 4 GB ကဲ့သို့ အလွန်မြင့်မားသော အရင်းအမြစ်ကန့်သတ်ချက်ရှိသော ပေါ့ပါးသော ဝဘ်ဆာဗာတစ်ခု ပိုင်ဆိုင်သည့် အခြေအနေတစ်ခုကို စိတ်ကူးကြည့်ပါ။ ဤလုပ်ငန်းစဉ်ကို ရေပြင်ညီအတိုင်း အတိုင်းအတာအထိ ချဲ့ထွင်ရန် လိုအပ်ပြီး ပေါ့ဒ်အသစ်တစ်ခုစီသည် ရရှိနိုင်သော မမ်မိုရီ အနည်းဆုံး 4 GB ရှိသော node ပေါ်တွင် အချိန်ဇယားဆွဲထားရန် လိုအပ်ပါသည်။ ထိုသို့သော node မရှိပါက၊ အစုအဝေးသည် ဤ pod ကိုလုပ်ဆောင်ရန် အချိန်အနည်းငယ်ကြာနိုင်သည်။ လျင်မြန်ချောမွေ့စွာ ချဲ့ထွင်ရန် သေချာစေရန် အရင်းအမြစ်တောင်းဆိုမှုများနှင့် ကန့်သတ်ချက်များကြား အနည်းဆုံးကွာခြားချက်ကို ရရှိရန် အရေးကြီးပါသည်။

အဆင့်နှစ်- အသက်ရှင်မှုနှင့် အဆင်သင့်စစ်ဆေးမှုများကို သတ်မှတ်ပါ။

၎င်းသည် Kubernetes အသိုင်းအဝိုင်းတွင် မကြာခဏ ဆွေးနွေးလေ့ရှိသည့် အခြားအသေးစိတ်အကြောင်းအရာတစ်ခုဖြစ်သည်။ ၎င်းတို့သည် ဆော့ဖ်ဝဲလ်၏တည်ငြိမ်သောလည်ပတ်မှုအတွက်ယန္တရားကိုပေးဆောင်ပြီး စက်ရပ်ချိန်ကိုအနည်းဆုံးဖြစ်စေသောကြောင့် Liveness နှင့် Readiness စစ်ဆေးမှုများကို ကောင်းစွာနားလည်ရန်အရေးကြီးပါသည်။ သို့ရာတွင်၊ မှန်ကန်စွာပြင်ဆင်သတ်မှတ်ခြင်းမပြုပါက ၎င်းတို့သည် သင့်အပလီကေးရှင်း၏စွမ်းဆောင်ရည်ကို ပြင်းထန်စွာအကျိုးသက်ရောက်နိုင်သည်။ အောက်တွင် နမူနာနှစ်ခုလုံး၏ အနှစ်ချုပ်ဖြစ်သည်။

ဘဝ ကွန်တိန်နာအလုပ်လုပ်နေသလားကိုပြသပါ။ မအောင်မြင်ပါက kubelet သည် ကွန်တိန်နာကိုသတ်ပြီး ၎င်းအတွက် ပြန်လည်စတင်သည့်မူဝါဒကို ဖွင့်ထားသည်။ ကွန်တိန်နာတွင် Liveness Probe မတပ်ဆင်ထားပါက၊ ၎င်းတွင်ဖော်ပြထားသည့်အတိုင်း ပုံသေအခြေအနေသည် အောင်မြင်လိမ့်မည်။ Kubernetes စာရွက်စာတမ်း.

Liveness probes များသည် စျေးသက်သက်သာသာသာဖြစ်သင့်သည်၊ ဆိုလိုသည်မှာ ၎င်းတို့သည် မကြာခဏလည်ပတ်နေပြီး အက်ပ်လီကေးရှင်းကို Kubernetes မှ အသိပေးသင့်သောကြောင့် အရင်းအမြစ်များစွာကို အသုံးမပြုရပါ။

သင်သည် စက္ကန့်တိုင်းတွင် လုပ်ဆောင်ရန် ရွေးချယ်ခွင့်ကို သတ်မှတ်ပါက၊ ၎င်းသည် တစ်စက္ကန့်လျှင် တောင်းဆိုချက် 1 ခု ထပ်လောင်းမည်၊ ထို့ကြောင့် ဤအသွားအလာကို လုပ်ဆောင်ရန် နောက်ထပ်အရင်းအမြစ်များ လိုအပ်မည်ဖြစ်ကြောင်း သတိပြုပါ။

ကျွန်ုပ်တို့၏ကုမ္ပဏီတွင်၊ Liveness စစ်ဆေးမှုများသည် ဒေတာ (ဥပမာ၊ အဝေးထိန်းဒေတာဘေ့စ် သို့မဟုတ် ကက်ရှ်) မှ အပြည့်အဝမရရှိနိုင်လျှင်ပင် အပလီကေးရှင်းတစ်ခု၏ အဓိကအစိတ်အပိုင်းများကို စမ်းသပ်သည်။

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

နမူနာ အသငျ့ ကွန်တိန်နာသည် တောင်းဆိုချက်များကို ဆောင်ရွက်ပေးရန် အဆင်သင့်ဖြစ်မဖြစ်ကို ဖော်ပြသည်။ အဆင်သင့်လုပ်ဆောင်မှု မအောင်မြင်ပါက၊ အဆုံးမှတ်ထိန်းချုပ်သူသည် pod နှင့်ကိုက်ညီသည့်ဝန်ဆောင်မှုအားလုံး၏ အဆုံးမှတ်များမှ pod ၏ IP လိပ်စာကို ဖယ်ရှားသည်။ ၎င်းကို Kubernetes စာရွက်စာတမ်းများတွင်လည်း ဖော်ပြထားသည်။

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

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

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

SELECT small_item FROM table LIMIT 1

ဤသည်မှာ Kubernetes တွင် ဤတန်ဖိုးနှစ်ခုကို ကျွန်ုပ်တို့ configure လုပ်ပုံဥပမာတစ်ခုဖြစ်သည်။

livenessProbe: 
 httpGet:   
   path: /api/liveness    
   port: http 
readinessProbe:  
 httpGet:    
   path: /api/readiness    
   port: http  periodSeconds: 2

သင်သည် နောက်ထပ်ဖွဲ့စည်းပုံရွေးချယ်စရာအချို့ကို ထည့်သွင်းနိုင်သည်-

• initialDelaySeconds - ကွန်တိန်နာ၏ပစ်လွှတ်မှုနှင့် probes စတင်မှုအကြားစက္ကန့်မည်မျှကြာလိမ့်မည်။
• periodSeconds - နမူနာပြေးမှုကြားကာလကို စောင့်ဆိုင်းပါ။
• timeoutSeconds - အိုးကို အရေးပေါ်ဟု သတ်မှတ်ပြီးနောက် စက္ကန့်အရေအတွက်။ ပုံမှန်အချိန်ကုန်။
• failureThreshold ပြန်လည်စတင်ခြင်းအချက်ပြမှုကို pod သို့မပို့မီ စမ်းသပ်မှုမအောင်မြင်သည့်အရေအတွက်ဖြစ်သည်။
• successThreshold အဆင်သင့်အခြေအနေသို့ ကူးပြောင်းခြင်းမပြုမီ အောင်မြင်သော စမ်းသပ်မှုအရေအတွက် ( pod စတင်ချိန် သို့မဟုတ် ပြန်လည်ကောင်းမွန်လာသောအခါတွင် ပျက်ကွက်ပြီးနောက်)။

အဆင့် ၃- Pod ၏ ပုံသေကွန်ရက်မူဝါဒများကို သတ်မှတ်ခြင်း။

Kubernetes တွင် ပုံမှန်အားဖြင့် "ပြားသော" ကွန်ရက်မြေမျက်နှာသွင်ပြင် ရှိပြီး pod အားလုံးသည် တစ်ခုနှင့်တစ်ခု တိုက်ရိုက်ဆက်သွယ်သည်။ အချို့ကိစ္စများတွင် ဤအရာသည် မလိုလားအပ်ပေ။

ဖြစ်နိုင်ချေရှိသော လုံခြုံရေးပြဿနာမှာ တိုက်ခိုက်သူသည် ကွန်ရက်ပေါ်ရှိ pods များအားလုံးသို့ traffic ပေးပို့ရန် အားနည်းချက်ရှိသော application တစ်ခုတည်းကို အသုံးပြုနိုင်သည်။ လုံခြုံရေးနယ်ပယ်များစွာတွင်ကဲ့သို့ပင်၊ အထူးအခွင့်အရေးအနည်းဆုံးနိယာမသည် ဤနေရာတွင် အကျုံးဝင်ပါသည်။ အကောင်းဆုံးမှာ၊ ကွန်ရက်မူဝါဒများသည် pods များကြားတွင် မည်သည့်ချိတ်ဆက်မှုများကို ခွင့်ပြုထားသနည်း၊ မည်သည့်အရာသည် ချိတ်ဆက်မှုများကို အတိအလင်းဖော်ပြသင့်သည်။

ဥပမာအားဖြင့်၊ အောက်ပါသည် သီးခြား namespace တစ်ခုအတွက် အဝင်အသွားအလာအားလုံးကို ငြင်းပယ်သည့် ရိုးရှင်းသောမူဝါဒဖြစ်သည်-

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:  
 name: default-deny-ingress
spec:  
 podSelector: {}  
 policyTypes:  
   - Ingress

ဤဖွဲ့စည်းမှုပုံစံကို မြင်ယောင်ခြင်း-

(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
ပိုပြီးအသေးစိတ် ဒီမှာ.

အဆင့်လေး- Hooks နှင့် Init Containers များဖြင့် စိတ်ကြိုက်အပြုအမူ

ကျွန်ုပ်တို့၏ အဓိကပန်းတိုင်များထဲမှတစ်ခုမှာ ဆော့ဖ်ဝဲအင်ဂျင်နီယာများအတွက် အချိန်မဆွဲဘဲ Kubernetes တွင် ဖြန့်ကျက်မှုများ ပံ့ပိုးပေးရန်ဖြစ်သည်။ အပလီကေးရှင်းများကိုပိတ်ရန်နှင့် ၎င်းတို့၏အသုံးပြုထားသောအရင်းအမြစ်များကို ထုတ်လွှတ်ရန် ရွေးချယ်စရာများစွာရှိသောကြောင့် ၎င်းမှာခက်ခဲသည်။

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

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

lifecycle: 
 preStop:
   exec:
     command: ["/usr/local/bin/nginx-killer.sh"]

ဒီမှာ nginx-killer.sh:

#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
   echo "Waiting while shutting down nginx..."
   sleep 10
done

နောက်ထပ် အလွန်အသုံးဝင်သော ပါရာဒိုင်းတစ်ခုမှာ သီးခြားအက်ပ်လီကေးရှင်းများ စတင်ခြင်းကို ကိုင်တွယ်ရန် init containers များကို အသုံးပြုခြင်း ဖြစ်သည်။ အပလီကေးရှင်းမစတင်မီတွင် သင့်တွင် အရင်းအမြစ်-များသော ဒေတာဘေ့စ် ရွှေ့ပြောင်းခြင်းလုပ်ငန်းစဉ်တစ်ခုရှိလျှင် ၎င်းသည် အထူးသဖြင့် အသုံးဝင်ပါသည်။ ပင်မအပလီကေးရှင်းအတွက် ထိုသို့သောကန့်သတ်ချက်ကို မသတ်မှတ်ဘဲ ဤလုပ်ငန်းစဉ်အတွက် ပိုမိုမြင့်မားသောအရင်းအမြစ်ကန့်သတ်ချက်ကိုလည်း သင်သတ်မှတ်နိုင်သည်။

နောက်ထပ် အသုံးများသော အစီအစဉ်မှာ ပင်မအပလီကေးရှင်း မော်ဂျူးကိုယ်တိုင်မှ လျှို့ဝှက်ချက်များကို ခွင့်ပြုချက်မရှိဘဲ ဝင်ရောက်ခွင့်ကို တားဆီးပေးသည့် ဤအထောက်အထားများကို ပင်မ module သို့ ပေးဆောင်သည့် init container အတွင်းရှိ လျှို့ဝှက်ချက်များကို ရယူရန်ဖြစ်သည်။

ထုံးစံအတိုင်း စာတမ်းကိုးကား: init containers သည် အပလီကေးရှင်း၏ ကွန်တိန်နာပုံ၏ လုံခြုံရေးကို ထိခိုက်စေမည့် အသုံးပြုသူကုဒ် သို့မဟုတ် အသုံးအဆောင်များကို လုံခြုံစွာ လုပ်ဆောင်ပါသည်။ မလိုအပ်သောကိရိယာများကို သီးခြားထားရှိခြင်းဖြင့်၊ သင်သည် အပလီကေးရှင်း၏ ကွန်တိန်နာပုံ၏ တိုက်ခိုက်မှုမျက်နှာပြင်ကို ကန့်သတ်ထားသည်။

အဆင့်ငါး- Kernel ဖွဲ့စည်းမှု

နောက်ဆုံးအနေနဲ့၊ ပိုပြီးအဆင့်မြင့်တဲ့နည်းပညာအကြောင်းပြောကြရအောင်။

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

သို့သော်၊ Kubernetes သည် သီးခြား pod တစ်ခုအတွက် kernel parameters များကိုသာ ပြောင်းလဲနိုင်သော အခွင့်ထူးခံကွန်တိန်နာတစ်ခုအား လုပ်ဆောင်ရန် ခွင့်ပြုသည်။ ဤသည်မှာ ဖွင့်ထားသော ချိတ်ဆက်မှု အများဆုံး အရေအတွက်ကို ပြောင်းလဲရန် ကျွန်ုပ်တို့ အသုံးပြုခဲ့သည့် အရာဖြစ်သည်-

initContainers:
  - name: sysctl
     image: alpine:3.10
     securityContext:
         privileged: true
      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

ဤသည်မှာ မကြာခဏ မလိုအပ်ဘဲ ပိုမိုအဆင့်မြင့်သော နည်းပညာတစ်ခုဖြစ်သည်။ သို့သော် သင့်အက်ပ်လီကေးရှင်းသည် လေးလံသောဝန်ထုပ်ဝန်ပိုးကို ရင်ဆိုင်ရန် ရုန်းကန်နေရပါက၊ သင်သည် ဤဆက်တင်အချို့ကို ပြုပြင်ပြောင်းလဲရန် ကြိုးစားနိုင်သည်။ ဤလုပ်ငန်းစဉ်နှင့်ပတ်သက်သော နောက်ထပ်အချက်အလက်များနှင့် မတူညီသောတန်ဖိုးများ သတ်မှတ်ခြင်း- အမြဲလိုလို တရားဝင်စာရွက်စာတမ်းများတွင်.

နိဂုံးချုပ်

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

Kubernetes သို့ ပြောင်းရွှေ့ခြင်းတစ်လျှောက်လုံးတွင်၊ "Load Testing Cycle" ကို လိုက်နာရန် အရေးကြီးသည်- အက်ပ်လီကေးရှင်းကို ဖွင့်ပါ၊ ၎င်းကို ဝန်အောက်တွင် စမ်းသပ်ပါ၊ မက်ထရစ်များနှင့် အတိုင်းအတာ အပြုအမူများကို စောင့်ကြည့်ပါ၊ ဤဒေတာကို အခြေခံ၍ ဖွဲ့စည်းမှုပုံစံကို ချိန်ညှိပါ၊ ထို့နောက် ဤစက်ဝန်းကို ထပ်လုပ်ပါ။

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

ဤမေးခွန်းများကို သင့်ကိုယ်သင် အမြဲမေးပါ-

1. အပလီကေးရှင်းများမှ အရင်းအမြစ်မည်မျှသုံးစွဲပြီး ဤပမာဏသည် မည်သို့ပြောင်းလဲမည်နည်း။
2. စစ်မှန်သော အတိုင်းအတာလိုအပ်ချက်များကား အဘယ်နည်း။ ပျမ်းမျှအားဖြင့် အပလီကေးရှင်းသည် အသွားအလာမည်မျှရှိမည်နည်း။ အသွားအလာ အထွတ်အထိပ် ကော။
3. ဝန်ဆောင်မှုကို မည်မျှအတိုင်းအတာအထိ ချဲ့ထွင်ရန် လိုအပ်မည်နည်း။ အသွားအလာလက်ခံရန် pods အသစ်များသည် မည်မျှမြန်မြန်ဆန်ဆန် လည်ပတ်ရန် လိုအပ်သနည်း။
4. အစေ့များကို မည်မျှ ကောင်းမွန်စွာ ပိတ်နိုင်သနည်း။ လုံးဝလိုအပ်ပါသလား။ အချိန်မဆိုင်းဘဲ ဖြန့်ကျက်အောင်မြင်ရန် ဖြစ်နိုင်ပါသလား။
5. လုံခြုံရေးအန္တရာယ်များကို မည်ကဲ့သို့ လျှော့ချရန်နှင့် အပေးအယူခံရသော pods များထံမှ ပျက်စီးဆုံးရှုံးမှုကို မည်သို့ကန့်သတ်မည်နည်း။ မည်သည့်ဝန်ဆောင်မှုများသည် ၎င်းတို့မလိုအပ်သော ခွင့်ပြုချက်များ သို့မဟုတ် အသုံးပြုခွင့်များ ရှိပါသလား။

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

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

နောက်ထပ်ဖတ်စရာများ

1. ထုတ်လုပ်မှုပတ်ဝန်းကျင်ရှိ ကွန်တိန်နာများနှင့် Kubernetes လည်ပတ်ခြင်းအတွက် အကောင်းဆုံးအလေ့အကျင့်များနှင့် အကောင်းဆုံးအလေ့အကျင့်များ.
2. Kubernetes အတွက် အသုံးဝင်သော ကိရိယာ 90+- ဖြန့်ကျက်ခြင်း၊ စီမံခန့်ခွဲခြင်း၊ စောင့်ကြည့်ခြင်း၊ လုံခြုံရေးနှင့် အခြားအရာများ.
3. Telegram ရှိ Kubernetes ဝန်းကျင်တွင် ကျွန်ုပ်တို့၏ချန်နယ်.

source: www.habr.com