Kubernetes တွင် အက်ပလီကေးရှင်းတစ်ခု ဖန်တီးရန် လိုအပ်ချက်များ

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

ဤဟောပြောပွဲသည် "Kubernetes ရှိ Slum Night School“ ညနေကျောင်း၏ အဖွင့်သီအိုရီ ဟောပြောပွဲကို ကြည့်ရှုနိုင်ပါသည်။ Youtube တွင်၊ အစီအစဉ်တစ်ခုအဖြစ် အုပ်စုဖွဲ့ထားသည်။. ဗီဒီယိုထက် စာသားကို နှစ်သက်သူများအတွက် ဤဆောင်းပါးကို ပြင်ဆင်ထားပါသည်။

ကျွန်ုပ်၏အမည်မှာ Pavel Selivanov ဖြစ်ပြီး၊ လက်ရှိတွင် ကျွန်ုပ်သည် Mail.ru Cloud Solutions တွင် ထိပ်တန်း DevOps အင်ဂျင်နီယာဖြစ်ပြီး၊ ကျွန်ုပ်တို့သည် တိမ်များကို ဖန်တီးကာ စီမံခန့်ခွဲမှု kubernetes စသည်တို့ကို ပြုလုပ်ပါသည်။ ယခုကျွန်ုပ်၏လုပ်ငန်းတာဝန်များတွင် ဖွံ့ဖြိုးတိုးတက်မှုအကူအညီ၊ ဤတိမ်တိုက်များကို ထုတ်လွှတ်ခြင်း၊ ကျွန်ုပ်တို့ရေးသားသည့် အပလီကေးရှင်းများကို ဖြန့်ကျက်ခြင်းနှင့် ကျွန်ုပ်တို့၏အသုံးပြုသူများအတွက် ကျွန်ုပ်တို့ပေးဆောင်သည့် ကိရိယာများကို တိုက်ရိုက်တီထွင်ဖန်တီးခြင်းတို့ ပါဝင်ပါသည်။

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

ယေဘူယျအားဖြင့်၊ Kubernetes သည် ဗားရှင်း 1.3 ဖြစ်ကောင်းဖြစ်နိုင်သည် နှင့် နို့စို့အရွယ်တွင် 1.2 ဖြစ်ကောင်းဖြစ်နိုင်ချိန်တွင် စတင်ခဲ့သည်။ ယခုအခါ ၎င်းသည် နို့စို့အရွယ်တွင်မဟုတ်တော့ဘဲ Kubernetes ကိုလုပ်ဆောင်လိုသော အင်ဂျင်နီယာများအတွက် စျေးကွက်တွင် ကြီးမားသောဝယ်လိုအားရှိနေကြောင်း ထင်ရှားပါသည်။ ကုမ္ပဏီများသည် ထိုကဲ့သို့သောလူများအတွက် အလွန်မြင့်မားသော လိုအပ်ချက်ရှိသည်။ ထို့ကြောင့် ဤဟောပြောချက်သည် အမှန်ပင် ပေါ်လာသည်။

ကျွန်တော်ပြောမယ့် အစီအစဉ်အတိုင်းပြောရင် ဒီပုံစံအတိုင်းပဲ၊ ကွင်းစကွင်းပိတ်မှာ (TL;DR) လို့ရေးထားတယ် - “ရှည်လွန်းတယ်။ မဖတ်နဲ့။" ယနေ့ကျွန်ုပ်၏တင်ပြချက်သည် အဆုံးမဲ့စာရင်းများပါ၀င်ပါမည်။

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

အဘယ်ကြောင့်ဆိုသော် ယေဘုယျအားဖြင့်၊ ဤအချက်အလက်သည် “ctrl+c၊ ctrl+v” ဖြစ်ပြီး၊ အခြားအရာများထဲမှ၊ developer များအတွက် လိုအပ်ချက်များကို ကျွန်ုပ်တို့ရေးသားထားသော DevOps ကဏ္ဍရှိ ကျွန်ုပ်တို့၏ Wiki မှ “ယောက်ျားတို့၊ သို့မှသာ ကျွန်ုပ်တို့သည် သင့်လျှောက်လွှာကို စတင်အသုံးပြုနိုင်ပါသည်။ Kubernetes၊ ဒါကဒီလိုဖြစ်သင့်တယ်။"

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

ယခု ကျွန်ုပ်တို့ ကြည့်ရှုမည့်အရာ

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

မှတ်တမ်းများ

Kubernetes တွင် ဤမှတ်တမ်းများကို ရွှေ့ရန် လိုအပ်သည့် မှတ်တမ်းများဖြင့် စတင်ရန် အကြံပြုပါသည်။ ယခု သင် Kubernetes တွင် အပလီကေးရှင်းတစ်ခုကို စတင်လိုက်ပါပြီ။ ဂန္တဝင်စကားအရ၊ ယခင်က အပလီကေးရှင်းများသည် ဖိုင်တစ်နေရာတွင် မှတ်တမ်းများကို အမြဲရေးခဲ့သည်။ မကောင်းသော အပလီကေးရှင်းများသည် အပလီကေးရှင်းကိုဖွင့်သည့် developer ၏ home directory တွင် ဖိုင်တစ်ခုသို့ မှတ်တမ်းများရေးခဲ့သည်။ ကောင်းမွန်သော အပလီကေးရှင်းများသည် တစ်နေရာရာရှိ ဖိုင်တစ်ခုသို့ မှတ်တမ်းများ ရေးသားခဲ့သည်။ /var/log.

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

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

Kubernetes အကြောင်းပြောရင် docker container ရဲ့တစ်နေရာရာမှာ မှတ်တမ်းတွေရေးဖို့ သင့်တော်တဲ့နေရာက အပလီကေးရှင်းကနေ Stdout/Stderr လို့ ခေါ်တဲ့ Operating System ရဲ့ standard output streams တွေကို ရေးဖို့ဆိုတာ ပေါ်လာပါတယ်။ standard error output ကို ဤသည်မှာ Docker တွင် မှတ်တမ်းများနှင့် အထူးသဖြင့် Kubernetis တွင် မှတ်တမ်းများထည့်သွင်းရန် အမှန်ကန်ဆုံး၊ အရိုးရှင်းဆုံးနှင့် ယုတ္တိအရှိဆုံးနည်းလမ်းဖြစ်သည်။ သင့်အပလီကေးရှင်းသည် Stdout/Stderr သို့ မှတ်တမ်းများရေးပါက၊ ၎င်းသည် ဤမှတ်တမ်းများနှင့် ဘာလုပ်ရမည်ကို ဆုံးဖြတ်ရန် Docker နှင့် Kubernetes add-on တို့အပေါ် မူတည်ပါသည်။ Docker သည် ၎င်း၏ အထူးဖိုင်များကို JSON ဖော်မတ်ဖြင့် တည်ဆောက်မည်ဖြစ်သည်။

ဒီနေရာမှာ မေးစရာရှိလာတာက ဒီမှတ်တမ်းတွေနဲ့ သင်ဘာဆက်လုပ်မလဲ။ အလွယ်ဆုံးနည်းက ရှင်းပါတယ်၊ ကျွန်တော်တို့ လုပ်နိုင်စွမ်းရှိတယ်။ kubectl logs ပြီးလျှင် ဤ “pods” ၏ ဤမှတ်တမ်းများကိုကြည့်ပါ။ သို့သော် ဖြစ်နိုင်သည်မှာ၊ ဤသည်မှာ အလွန်ကောင်းမွန်သော ရွေးချယ်မှုမဟုတ်ပါ - အခြားအရာတစ်ခုခုကို မှတ်တမ်းများဖြင့် လုပ်ဆောင်ရန် လိုအပ်ပါသည်။

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

ကျွန်ုပ်တို့၏ docker က ၎င်း၏ဖိုင်များထဲသို့ ထည့်သွင်းပြီး ၎င်းတို့ကို တစ်နေရာရာသို့ ပေးပို့မည့် ဤမှတ်တမ်းများကို ဖော်ရွေသောနည်းလမ်းဖြင့် ကျွန်ုပ်တို့လိုအပ်ပါသည်။ ယေဘုယျအားဖြင့်၊ ကျွန်ုပ်တို့သည် Docker စုဆောင်းသည့် မှတ်တမ်းများတည်ရှိရာနေရာကို ရိုးရိုးရှင်းရှင်းပြောနိုင်သော DaemonSet - မှတ်တမ်းစုဆောင်းသည့်ပုံစံဖြင့် Kubernetes အတွင်းရှိ အေးဂျင့်တစ်မျိုးကို ဖွင့်ပေးလေ့ရှိပါသည်။ ဤစုဆောင်းရေးအေးဂျင့်သည် ၎င်းတို့ကို ရိုးရှင်းစွာယူဆောင်သွားကာ လမ်းတစ်လျှောက်တွင် ၎င်းတို့ကို တစ်နည်းနည်းဖြင့် ခွဲခြမ်းစိပ်ဖြာပေးကာ ၎င်းတို့အား မက်တာအချက်အလက်အချို့နှင့် ကြွယ်ဝစေကာ နောက်ဆုံးတွင် ၎င်းတို့ကို တစ်နေရာရာသို့ သိုလှောင်ရန်အတွက် ပို့ပေးပါသည်။ အဲဒီမှာ ကွဲလွဲမှုတွေ ဖြစ်နိုင်တယ်။ အသုံးအများဆုံးမှာ Elasticsearch ဖြစ်ကောင်းဖြစ်နိုင်သည်၊ မှတ်တမ်းများကို သိမ်းဆည်းနိုင်ပြီး ၎င်းတို့ကို ထိုနေရာမှ အဆင်ပြေစွာ ထုတ်ယူနိုင်သည်။ ထို့နောက် တောင်းဆိုချက်တစ်ခုအား အသုံးပြု၍ ဥပမာအားဖြင့်၊ Kibana ကိုအသုံးပြု၍ ၎င်းတို့အပေါ်အခြေခံ၍ ဂရပ်ဖစ်များတည်ဆောက်ခြင်း၊ ၎င်းတို့အပေါ်အခြေခံ၍ သတိပေးချက်များတည်ဆောက်ခြင်းစသည်ဖြင့်။

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

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

နောက်ဆုံးအချက်ကတော့ ကွန်တိန်နာထဲမှာ မင်းရဲ့ application တွေရှိလေ့ရှိပြီး ဒါပါပဲ - ဒါဟာ အများအားဖြင့် လုပ်ဆောင်နေတဲ့ တစ်ခုတည်းသော လုပ်ငန်းစဉ်ပါ။ သင့်မှတ်တမ်းများနှင့်အတူ ဖိုင်များကို လှည့်ပေးမည့် မည်သည့်လုပ်ငန်းစဉ်နှင့် ပတ်သက်သည်ကို လုံးဝပြောဆိုခြင်းမရှိပါ။ မှတ်တမ်းများသည် ဖိုင်တစ်ခုသို့ စာရေးလာသည်နှင့်တပြိုင်နက်၊ ဆိုလိုသည်မှာ၊ ခွင့်လွှတ်ပါ၊ ကျွန်ုပ်တို့သည် ထုတ်လုပ်မှုဆာဗာကို စတင်ဆုံးရှုံးရတော့မည်ဖြစ်သည်။ အဘယ်ကြောင့်ဆိုသော် ပထမဦးစွာ၊ ၎င်းတို့သည် ရှာဖွေရန်ခက်ခဲသောကြောင့်၊ ၎င်းတို့ကို မည်သူမျှ ခြေရာခံခြင်းမရှိသည့်အပြင် ၎င်းတို့ကို မည်သူကမျှ မထိန်းချုပ်နိုင်သောကြောင့်ဖြစ်သည်- ထို့ကြောင့်၊ ဆာဗာပေါ်ရှိ နေရာလွတ်မကုန်မချင်း ဖိုင်သည် အဆုံးမရှိကြီးထွားလာသောကြောင့်ဖြစ်သည်။ ထို့ကြောင့်၊ အထူးသဖြင့် Kubernetes တွင် Docker တွင် လော့ဂ်အင်ဝင်ခြင်းသည် ဆိုးရွားသော အကြံဥာဏ်တစ်ခုဖြစ်သည်။

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

ဆိုလိုသည်မှာ ယနေ့ခေတ်တွင် မှတ်တမ်းများကို JSON ဖော်မတ်ဖြင့် ရေးသားသင့်ပါသည်။ သင်သည် ပရင့်တစ်မျိုးမျိုး သို့မဟုတ် ထိုကဲ့သို့သော တစ်ခုခုကို ထည့်သွင်းထားသောကြောင့် နားမလည်နိုင်သော ဖော်မတ်များဖြင့် မှတ်တမ်းများကို ရေးသားသည့် သင့်တွင် နားမလည်နိုင်သော အပလီကေးရှင်းအချို့ရှိနေပါက၊ သင်သည် ပုံမှန်သစ်ခုတ်ခြင်းကို အကောင်အထည်ဖော်ရန် ခွင့်ပြုသည့် ဘောင်ပုံစံအချို့၊ အချို့သော wrapper တစ်မျိုးကို Google မှ အချိန်တန်ပြီ၊ JSON သည် ရိုးရှင်းသောဖော်မတ်ဖြစ်သောကြောင့်၊ ခွဲခြမ်းစိတ်ဖြာရန်မှာ ရိုးရှင်းသောကြောင့် JSON တွင် loggging parameters များကို ထိုနေရာတွင်ဖွင့်ပါ။

သင့် JSON သည် အချို့သောစံနှုန်းများအတိုင်း အလုပ်မလုပ်ပါက၊ မည်သည်ကိုမျှ မသိပါ၊ ထို့နောက် အနည်းဆုံး ခွဲခြမ်းစိတ်ဖြာနိုင်သော ဖော်မတ်ဖြင့် မှတ်တမ်းများကို ရေးပါ။ ဤတွင်၊ ဥပမာအားဖြင့် သင်သည် ကွန်တိန်နာအများအပြားကို သို့မဟုတ် nginx ဖြင့် လုပ်ဆောင်နေပါက၊ တစ်ခုစီတွင် ၎င်း၏ကိုယ်ပိုင် မှတ်တမ်းဆက်တင်များ ရှိသည်ဟူသည့်အချက်ကို စဉ်းစားသင့်သည်မှာ သင့်အတွက် အလွန်အဆင်မပြေဖြစ်နိုင်သည်ဟု ယူဆပါသည်။ သူတို့ကိုခွဲခြမ်းစိတ်ဖြာပါ။ အကြောင်းမှာ nginx စံနမူနာအသစ်တစ်ခုစီအတွက် ၎င်းတို့သည် မှတ်တမ်းများကို ကွဲပြားစွာရေးသားထားသောကြောင့် သင်၏ကိုယ်ပိုင် parser ရေးရန်လိုအပ်ပါသည်။ တစ်ဖန်၊ ဤ nginx ဖြစ်ရပ်များ အားလုံးသည် တူညီသော မှတ်တမ်းဖွဲ့စည်းပုံများ ပါ၀င်ပြီး ၎င်းတို့၏ မှတ်တမ်းများအားလုံးကို တစ်ပုံစံတည်း ရေးထားကြောင်း သေချာစေရန် စဉ်းစားသင့်ပါသည်။ အပလီကေးရှင်းအားလုံးတွင် အလားတူပင်ဖြစ်သည်။

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

သို့သော် stack trace သည် အမြဲတမ်း လိုင်းပေါင်းစုံ မှတ်တမ်းများနှင့် ၎င်းတို့ကို ရှောင်ရှားနည်း။ ဤနေရာတွင် မေးစရာမှာ မှတ်တမ်းတစ်ခုသည် ဖြစ်ရပ်တစ်ခု၏ မှတ်တမ်းတစ်ခုဖြစ်ပြီး၊ stactrace သည် အမှန်တကယ် မှတ်တမ်းတစ်ခုမဟုတ်ပါ။ ကျွန်ုပ်တို့သည် မှတ်တမ်းများကို စုဆောင်းပြီး ၎င်းတို့ကို Elasticsearch တွင် တစ်နေရာရာတွင် ထားရှိပြီးနောက် ၎င်းတို့ထံမှ ဂရပ်ဖစ်များကို ဆွဲထုတ်ကာ သင့်ဆိုက်တွင် အသုံးပြုသူ၏ လုပ်ဆောင်ချက်ဆိုင်ရာ အစီရင်ခံစာအချို့ကို တည်ဆောက်ပါက၊ ထို့နောက်တွင် အစုလိုက်ခြေရာခံမှုတစ်ခုရလာပါက၊ မမျှော်လင့်ထားသည့်အရာတစ်ခု ဖြစ်ပျက်နေသည်ဟု ဆိုလိုပါသည်။ သင့်အပလီကေးရှင်းတွင် မကိုင်တွယ်နိုင်သော အခြေအနေတစ်ခု။ ထို့အပြင် ၎င်းတို့ကို ခြေရာခံနိုင်သော စနစ်တစ်ခုတွင် stack trace ကို တစ်နေရာရာသို့ အလိုအလျောက် အပ်လုဒ်လုပ်ခြင်းသည် အဓိပ္ပာယ်ရှိသည်။

၎င်းသည် stack trace နှင့်အလုပ်လုပ်ရန်အထူးပြုလုပ်ထားသည့်ဆော့ဖ်ဝဲ (တူညီသော Sentry) ဖြစ်သည်။ ၎င်းသည် အလိုအလျောက်လုပ်ဆောင်စရာများကို ချက်ချင်းဖန်တီးနိုင်သည်၊ ၎င်းတို့ကို တစ်စုံတစ်ဦးထံ ပေးအပ်နိုင်သည်၊ stacttraces များဖြစ်ပေါ်လာသည့်အခါ သတိပေးချက်၊ ဤ stacttrace များကို အမျိုးအစားတစ်ခုဖြင့် အုပ်စုဖွဲ့နိုင်ပြီး၊ အစရှိသည်ဖြင့် လုပ်ဆောင်နိုင်သည်။ နိယာမအားဖြင့်၊ မှတ်တမ်းများအကြောင်းပြောသောအခါ နေရာကွက်လပ်များအကြောင်းပြောခြင်းသည် အဓိပ္ပါယ်မရှိပေ၊ အကြောင်းမှာ၊ အကြောင်းမှာ၊ ၎င်းတို့သည် မတူညီသောရည်ရွယ်ချက်များဖြင့် ကွဲပြားသောအရာများဖြစ်သောကြောင့် ဖြစ်သည်။

configuration များ

ထို့နောက် Kubernetes တွင် configuration အကြောင်း ဆွေးနွေးသည်- ၎င်းနှင့် လုပ်ဆောင်ရမည့်အရာများနှင့် Kubernetes အတွင်းရှိ အပလီကေးရှင်းများကို မည်သို့ configure လုပ်သင့်သနည်း။ ယေဘူယျအားဖြင့်တော့ Docker ဟာ containers တွေအကြောင်းမဟုတ်ဘူးလို့ ကျွန်တော်ပြောလေ့ရှိပါတယ်။ Docker သည် ကွန်တိန်နာများအကြောင်းဖြစ်သည်၊ Docker နှင့် များစွာအလုပ်မလုပ်ဖူးသူများပင်လျှင် လူတိုင်းသိပါသည်။ ထပ်ပြောပါတယ်၊ Docker က containers အကြောင်းမဟုတ်ပါဘူး။

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

ဤအရာသည် ယခင်က ကျွန်ုပ်တို့အသုံးပြုခဲ့သည်၊ ၎င်းသည် ကွန်တိန်နာများ ထွန်းကားလာသောအခါတွင် အထူးရေပန်းစားလာသည်၊ ဤအရာအား ENV (ပတ်ဝန်းကျင်) ကိန်းရှင်များဟုခေါ်သည်၊ ဆိုလိုသည်မှာ၊ သင်၏လည်ပတ်မှုစနစ်ရှိ ပတ်ဝန်းကျင်ပြောင်းလဲမှုများဖြစ်သည်။ သင့်တွင် JAVA၊ Python, Go, Perl, God တားမြစ်ထားသော application များရှိပါက၊ ၎င်းတို့အားလုံးသည် database host၊ database user၊ database password variable များကိုဖတ်နိုင်သောကြောင့် ၎င်းသည် ယေဘုယျအားဖြင့် သင့်အပလီကေးရှင်းကို configure လုပ်ရန် စံပြနည်းလမ်းတစ်ခုဖြစ်သောကြောင့်၊ ၎င်းသည် အကောင်းဆုံးဖြစ်သည်။ သင့်တွင် မတူညီသော ဘာသာစကားလေးမျိုးဖြင့် ဒေတာဘေ့စ်အစီအစဥ်တွင် တူညီသောပုံစံဖြင့် ပြင်ဆင်ထားသော အပလီကေးရှင်းများရှိသည်။ ကွဲပြားသောပုံစံများ မရှိတော့ပါ။

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

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

သင့်တွင် Deployment ကိုဖွင့်လိုက်သော Environment variable အများအပြားရှိသည် - နှင့် Environment variable လိုင်းငါးရာရှိသောအခါ ပြဿနာဖြစ်လာသည်။ ဤကိစ္စတွင်၊ သင့်တွင် ရိုးရိုးရှင်းရှင်း ဆိုးရွားသော ပတ်ဝန်းကျင်ပြောင်းလဲမှုများရှိသည် - သင့်ကိုယ်သင် ညှဉ်းပန်းနှိပ်စက်ရန် မလိုအပ်တော့ပါ။ ဤကိစ္စတွင်၊ configs ကိုစတင်အသုံးပြုခြင်းသည်အဓိပ္ပာယ်ရှိလိမ့်မည်။ ဆိုလိုသည်မှာ၊ သင်၏အပလီကေးရှင်းကို configs အသုံးပြုရန်လေ့ကျင့်ပါ။

တစ်ခုတည်းသောမေးခွန်းမှာ config များသည်သင်ထင်သည်မဟုတ်ပေ။ Config.pi သည် အသုံးပြုရန် အဆင်ပြေသော config တစ်ခုမဟုတ်ပါ။ သို့မဟုတ် သင့်ကိုယ်ပိုင်ဖော်မတ်ရှိ အချို့သော config များကို လက်ဆောင်ပေးသည် - ၎င်းသည် ကျွန်ုပ်ဆိုလိုသော config မဟုတ်ပါ။

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

ထို့ကြောင့်၊ YAML အပြင်၊ ဥပမာအားဖြင့်၊ JSON ကိုသုံးနိုင်သည်၊ ထိုနေရာမှ application configuration ကိုဖတ်ခြင်းအတွက် YAML ကဲ့သို့ ခွဲခြမ်းစိတ်ဖြာခြင်းသည် အဆင်ပြေပါသည်။ လူတွေဖတ်ရတာ သိသိသာသာကို အဆင်မပြေဘူး။ သင် format, a la ini စမ်းကြည့်နိုင်ပါတယ်။ လူသားအမြင်အရ ဖတ်ရတာ တော်တော်အဆင်ပြေပါတယ်၊ ဒါပေမယ့် အလိုအလျောက်လုပ်ဆောင်ဖို့ အဆင်မပြေနိုင်ပါဘူး၊ သင်ကိုယ်တိုင် configs တွေကို ဖန်တီးချင်တယ်ဆိုရင်တော့ ini ဖော်မတ်က ထုတ်လုပ်ဖို့ အဆင်မပြေဖြစ်နေနိုင်ပါတယ်။

မည်သို့ပင်ဆိုစေကာမူ သင်မည်သည့်ပုံစံကိုရွေးချယ်သည်၊ ဆိုလိုသည်မှာ Kubernetes ရှုထောင့်မှကြည့်လျှင် အလွန်အဆင်ပြေသည်။ ConfigMap တွင် သင်၏ config တစ်ခုလုံးကို Kubernetes တွင် ထည့်သွင်းနိုင်သည်။ ထို့နောက် ဤ configmap ကိုယူ၍ အချို့သော သီးခြား directory တွင် သင်၏ pod အတွင်းသို့ တပ်ဆင်ရန် တောင်းဆိုပါ၊ သင်၏ အပလီကေးရှင်းသည် ဤ configmap မှ configuration ကို ဖိုင်တစ်ခုကဲ့သို့ ဖတ်ပြလိမ့်မည် ။ သင့်လျှောက်လွှာတွင် configuration ရွေးချယ်စရာများစွာရှိသောအခါ ၎င်းသည် အမှန်တကယ်လုပ်ဆောင်ရန်ကောင်းသည်။ သို့မဟုတ် ၎င်းသည် ရှုပ်ထွေးသောဖွဲ့စည်းပုံမျိုးမျှသာဖြစ်ပြီး အသိုက်များရှိသည်။

သင့်တွင် configmap တစ်ခုရှိပါက၊ ဥပမာအားဖြင့်၊ configmap ကိုတပ်ဆင်ထားသည့်ဖိုင်ရှိပြောင်းလဲမှုများကိုအလိုအလျောက်ခြေရာခံရန်၊ configs များပြောင်းလဲသောအခါတွင်သင်၏ application ကိုအလိုအလျောက်ပြန်လည်စတင်ရန်သင်ကောင်းစွာသင်ပေးနိုင်သည်။ ၎င်းသည် ယေဘုယျအားဖြင့် စံပြရွေးချယ်မှုတစ်ခု ဖြစ်လိမ့်မည်။

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

ကျန်းမာရေးစစ်ဆေးမှု

နောက်တစ်ခုကတော့ Health check လို့ခေါ်ပါတယ်။ ယေဘူယျအားဖြင့်၊ ကျန်းမာရေးစစ်ဆေးမှုသည် သင့်လျှောက်လွှာတွင် အလုပ်လုပ်ကြောင်း စစ်ဆေးခြင်းဖြစ်ပါသည်။ တစ်ချိန်တည်းမှာပင်၊ ကျွန်ုပ်တို့သည် အချို့သောဝဘ်အက်ပလီကေးရှင်းများအကြောင်းကို မကြာခဏပြောနေကြပြီး ထို့ကြောင့် ကျန်းမာရေးစစ်ဆေးခြင်း၏ရှုထောင့်မှကြည့်လျှင် (ဤနေရာတွင်နှင့်နောက်ထပ်ဘာသာပြန်ဆိုခြင်းမပြုခြင်းက ပိုကောင်းသည်) ၎င်းသည် ၎င်းတို့လုပ်ဆောင်သည့် အထူး URL အချို့ဖြစ်လိမ့်မည်၊ စံနှုန်းတစ်ခု၊ /health.

ဤ URL ကိုဝင်ရောက်သည့်အခါ၊ ကျွန်ုပ်တို့၏အပလီကေးရှင်းသည် "ဟုတ်ကဲ့၊ အဆင်ပြေပါတယ်၊ အားလုံးအဆင်ပြေပါတယ်၊ 200" သို့မဟုတ် "မဟုတ်ပါ၊ အရာအားလုံးက ကျွန်ုပ်အတွက်မကောင်းပါဘူး၊ 500" ဟုပြောပါသည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့၏လျှောက်လွှာသည် http မဟုတ်၊ ဝဘ်အက်ပလီကေးရှင်းမဟုတ်ပါက၊ ယခုကျွန်ုပ်တို့သည် daemon တစ်မျိုးမျိုးအကြောင်းပြောနေကြသည်၊ ကျွန်ုပ်တို့သည်ကျန်းမာရေးစစ်ဆေးမှုများကိုမည်ကဲ့သို့လုပ်ဆောင်ရမည်ကိုရှာဖွေနိုင်သည်။ ဆိုလိုသည်မှာ၊ အပလီကေးရှင်းသည် http မဟုတ်ပါက၊ ကျန်းမာရေးစစ်ဆေးခြင်းမရှိဘဲ အရာအားလုံးသည် အလုပ်ဖြစ်နိုင်ပြီး မည်သည့်နည်းနှင့်မျှ လုပ်ဆောင်၍မရပါ။ သင်သည် ဖိုင်အတွင်းရှိ အချက်အလက်အချို့ကို အခါအားလျော်စွာ အပ်ဒိတ်လုပ်နိုင်ပြီး၊ သင်၏ daemon အတွက် အထူးအမိန့်ပေးချက်အချို့ ရှိလာနိုင်သည်။ daemon status"ဟုတ်ပါတယ်၊ အားလုံးအဆင်ပြေပါတယ်၊ daemon ကအလုပ်လုပ်တယ်၊ အသက်ရှင်နေတယ်" ဟုပြောလိမ့်မည်။

ဘာအတွက်လဲ ပထမဆုံးနှင့် အထင်ရှားဆုံးအချက်မှာ အပလီကေးရှင်း အလုပ်လုပ်နေကြောင်း နားလည်ရန် အဘယ်ကြောင့် ကျန်းမာရေးစစ်ဆေးရန် လိုအပ်သနည်း။ ငါဆိုလိုတာက မိုက်မဲလိုက်တာ၊ အခုထလိုက်တာနဲ့ အလုပ်လုပ်နေပုံရတယ်၊ ဒါကြောင့် မင်းသေချာပေါက် အလုပ်လုပ်နေတာ။ အက်ပလီကေးရှင်းကအလုပ်လုပ်နေတယ်၊ ​​ကွန်တိန်နာကအလုပ်လုပ်နေတယ်၊ ​​ဥပမာအလုပ်လုပ်တယ်၊ အားလုံးအဆင်ပြေတယ် - ထို့နောက်အသုံးပြုသူများသည်နည်းပညာဆိုင်ရာပံ့ပိုးကူညီမှုမှဖုန်းနံပါတ်အားလုံးကိုဖြတ်တောက်ပြီး“ မင်းဘာတွေလဲ...၊ အိပ်ပျော်သွားတယ် ဘာမှမဖြစ်ဘူး”

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

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

ယခုကျွန်တော်ပြောနေသည့်အရာကို Kubernetes အတွင်းရှိ Readiness/Liveness tests ဟုခေါ်သည်၊ ထို့ကြောင့်၊ ကျွန်ုပ်တို့၏ အဆင်သင့်စစ်ဆေးမှုများသည် အပလီကေးရှင်း၏ ဟန်ချက်ညီညီရရှိမှုအတွက် တာဝန်ရှိပါသည်။ ဆိုလိုသည်မှာ၊ အပလီကေးရှင်းတွင် အဆင်သင့်စစ်ဆေးမှုများကို ပြုလုပ်ပါက၊ အားလုံးအဆင်ပြေသည်၊ ဖောက်သည်လမ်းကြောင်းသည် အပလီကေးရှင်းသို့သွားမည်ဖြစ်သည်။ အဆင်သင့်စစ်ဆေးမှုများ မလုပ်ဆောင်ပါက လျှောက်လွှာတွင် ရိုးရိုးရှင်းရှင်း မပါဝင်ပါ၊ ဤဥပမာသည် ဟန်ချက်ညီခြင်းတွင် မပါဝင်ပါ၊ ၎င်းကို ဟန်ချက်ညီခြင်းမှ ဖယ်ရှားလိုက်သည်၊ ဖောက်သည်အသွားအလာ စီးဆင်းခြင်းမရှိပါ။ ထို့ကြောင့်၊ Kubernetes အတွင်းရှိ Liveness စမ်းသပ်မှုများ လိုအပ်ပြီး အပလီကေးရှင်းပိတ်သွားပါက ၎င်းကို ပြန်လည်စတင်နိုင်မည်ဖြစ်သည်။ Kubernetes တွင်ကြေငြာထားသော application တစ်ခုအတွက် liveness test သည် အလုပ်မလုပ်ပါက၊ application ကို ချိန်ညှိခြင်းမှဖယ်ရှားရုံမျှမက၊ ၎င်းကို ပြန်လည်စတင်မည်ဖြစ်သည်။

ဒီနေရာမှာ ကျွန်တော်ပြောလိုတဲ့ အရေးကြီးတဲ့ အချက်တစ်ခုကတော့ လက်တွေ့ကျတဲ့ ရှုထောင့်ကနေကြည့်ရင် အဆင်သင့်စစ်ဆေးမှုကို အများအားဖြင့် မကြာခဏ အသုံးပြုလေ့ရှိပြီး အသက်ရှင်ခြင်းစမ်းသပ်မှုထက် ပိုမကြာခဏလိုအပ်ပါတယ်။ အဘယ်ကြောင့်ဆိုသော် Kubernetes သည် ထိုသို့လုပ်ဆောင်နိုင်ပြီး ၎င်းကိုလုပ်ဆောင်နိုင်သမျှကို အသုံးပြုကြပါစို့ ဖြစ်သောကြောင့် အဆင်သင့်နှင့် အသက်ရှင်မှုစမ်းသပ်မှုများကို ရိုးရှင်းစွာပင် တွေးတောမနေဘဲ ကြေညာခြင်းသည် အလွန်ကောင်းသောအကြံမဟုတ်ပေ။ ဘာကြောင့်လဲဆိုတာ ရှင်းပြမယ်။ အဘယ်ကြောင့်ဆိုသော် စမ်းသပ်မှုတွင် နံပါတ်နှစ်အချက်မှာ သင်၏ကျန်းမာရေးစစ်ဆေးမှုများတွင် အရင်းခံဝန်ဆောင်မှုကို စစ်ဆေးရန် အကြံကောင်းဖြစ်မည်ဖြစ်သောကြောင့်ဖြစ်သည်။ ဆိုလိုသည်မှာ သင့်တွင် အချက်အလက်အချို့ကို ထုတ်ပေးသည့် ဝဘ်အက်ပလီကေးရှင်းတစ်ခုရှိပါက ၎င်းကို သဘာဝအတိုင်း တစ်နေရာမှ ယူရမည်ဟု ဆိုလိုသည်။ ဥပမာ၊ ဒေတာဘေ့စ်တစ်ခုတွင်။ ကောင်းပြီ၊ ၎င်းသည် ဤ REST API သို့ရောက်လာသော အချက်အလက်များကို တူညီသောဒေတာဘေ့စ်ထဲသို့ သိမ်းဆည်းပေးသည်။ ထို့ကြောင့်၊ သင်၏ကျန်းမာရေးစစ်ဆေးမှုသည် ဆက်သွယ်ထားသော slashhealth ကဲ့သို့ရိုးရှင်းစွာတုံ့ပြန်ပါက၊ အပလီကေးရှင်းတွင် "200၊ အိုကေ၊ အားလုံးအဆင်ပြေပါသည်" ဟုပြောပြီး တစ်ချိန်တည်းမှာပင် သင့်အပလီကေးရှင်း၏ဒေတာဘေ့စ်ကို အသုံးပြု၍မရတော့ဘဲ ကျန်းမာရေးစစ်ဆေးမှုလျှောက်လွှာတွင် "200၊ အိုကေ၊ အားလုံးအဆင်ပြေပါတယ်။ “ဒါက ကျန်းမာရေး စစ်ဆေးတာ မကောင်းဘူး။ ဒါက အလုပ်မဖြစ်သင့်ဘူး။

တောင်းဆိုချက်တစ်ခုရောက်လာသောအခါ၊ သင်၏လျှောက်လွှာဖြစ်သည်။ /health"200၊ ok" ဟု တုံ့ပြန်ရုံမျှမက၊ ဥပမာ၊ ဒေတာဘေ့စ်သို့ ဦးစွာသွားသည်၊ ၎င်းကို ချိတ်ဆက်ရန် ကြိုးစားသည်၊ ရွေးပါကဲ့သို့ပင်၊ ထိုနေရာတွင် အလွန်အခြေခံကျသော တစ်ခုခုကို လုပ်ဆောင်သည်၊ ၎င်းတွင် ချိတ်ဆက်မှုရှိမရှိ စစ်ဆေးရုံသာဖြစ်သည်။ database နဲ့ database ကို စုံစမ်းမေးမြန်းနိုင်ပါတယ်။ ဒါတွေအားလုံးအောင်မြင်ခဲ့ရင် အဖြေက "200၊ ok" မအောင်မြင်ပါက error တစ်ခုရှိနေသည်ဟုဆိုသည်၊ database is not available.

ထို့ကြောင့်၊ ဤကိစ္စနှင့်စပ်လျဉ်း၍ ကျွန်ုပ်သည် အဆင်သင့်/အသက်ရှင်သန်မှုဆိုင်ရာ စစ်ဆေးမှုများကို တစ်ဖန်ပြန်သွားသည် - အဘယ်ကြောင့် အသင့်ဖြစ်နိုင်ခြေရှိသော စမ်းသပ်မှုတစ်ခု လိုအပ်သော်လည်း အသက်ရှင်မှုစမ်းသပ်မှုမှာ မေးခွန်းထုတ်စရာဖြစ်သည်။ ကျန်းမာရေးစစ်ဆေးမှုတွေကို ငါခုနကပြောသလို အတိအကျဖော်ပြရင်၊ ဥပမာအပိုင်းမှာ မရရှိနိုင်လို့ ပေါ်လာလိမ့်မယ်။в или со всех instanceဥပမာ၊ database တစ်ခုထဲမှာ။ အဆင်သင့်စမ်းသပ်မှုတစ်ခုကို သင်ကြေညာလိုက်သောအခါ၊ ကျွန်ုပ်တို့၏ကျန်းမာရေးစစ်ဆေးမှုများသည် ကျရှုံးစပြုလာပြီး၊ ဒေတာဘေ့စ်ကို သုံးစွဲ၍မရသော အပလီကေးရှင်းများအားလုံးသည် ဟန်ချက်ညီခြင်းမှ ရိုးရှင်းစွာပိတ်သွားကာ အမှန်တကယ်တွင် လျစ်လျူရှုထားသည့်အခြေအနေတွင်သာ “hang” ကာ ၎င်းတို့၏ဒေတာဘေ့စ်များကို စောင့်မျှော်နေပါသည်။ အလုပ်။

အကယ်၍ ကျွန်ုပ်တို့သည် အသက်ရှင်မှုစမ်းသပ်မှုကိုကြေငြာပြီးပါက၊ ကျွန်ုပ်တို့၏ဒေတာဘေ့စ်ပျက်သွားသည်ကိုမြင်ယောင်ကြည့်ပါက၊ သင်၏ Kubernetes တွင် သက်ရှိစမ်းသပ်မှုမအောင်မြင်သောကြောင့် အရာအားလုံး၏တစ်ဝက်သည် ပြန်လည်စတင်မည်ဖြစ်သည်။ ဆိုလိုသည်မှာ သင်သည် ပြန်လည်စတင်ရန် လိုအပ်သည်။ ဒါ မင်းလိုချင်တာ မဟုတ်ဘူး၊ ငါ လက်တွေ့ အတွေ့အကြုံတောင် ရှိခဲ့တယ်။ ကျွန်ုပ်တို့တွင် JS ဖြင့်ရေးသားပြီး Mongo ဒေတာဘေ့စ်သို့ ထည့်သွင်းထားသော ချတ်အက်ပ်တစ်ခုရှိသည်။ ပြဿနာမှာ Kubernetes နှင့် ကျွန်ုပ်၏အလုပ်စစချင်းတွင်၊ Kubernetes လုပ်နိုင်သည့် နိယာမအရ အဆင်သင့်၊ စမ်းသပ်မှုများ၏ အသက်ဝင်မှုကို ဖော်ပြခဲ့ပြီး၊ ထို့ကြောင့် ၎င်းကို အသုံးပြုပါမည်။ ထို့ကြောင့်၊ တစ်ချိန်ချိန်တွင် Mongo အနည်းငယ် "မှိုင်း" ဖြစ်လာပြီးနမူနာပျက်ကွက်လာသည်။ ထို့ကြောင့် မိုးရွာသွန်းမှုစမ်းသပ်ချက်အရ အစေ့များသည် “သတ်” လာသည်။

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

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

ထို့ကြောင့်၊ အဆင်သင့်နှင့် အသက်ရှင်မှုစမ်းသပ်မှုများသည် ကွဲပြားသည်၊ ထို့အပြင်၊ သင်သည် သီအိုရီအရ မတူညီသော ကျန်းမာရေးစစ်ဆေးမှုများ၊ အမျိုးအစား radii၊ အမျိုးအစား liv၊ ဥပမာနှင့် မတူညီသောအရာများကို စစ်ဆေးနိုင်ပါသည်။ အဆင်သင့်စစ်ဆေးမှုများအတွင်း၊ သင်၏ နောက်ခံများကို စစ်ဆေးပါ။ ဥပမာအားဖြင့်၊ သက်ရှိစမ်းသပ်မှုတစ်ခုတွင်၊ ရှင်သန်မှုစမ်းသပ်မှုသည် ယေဘုယျအားဖြင့် တုံ့ပြန်နိုင်သည့်အက်ပ်တစ်ခုမျှသာဖြစ်ကြောင်း ရှုထောင့်မှ မစစ်ဆေးပါ။

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

စာမေးပွဲရှိတဲ့အခါ၊ ကျန်းမာရေးစစ်ဆေးတဲ့အခါ ဘာဖြေရမယ်ဆိုတာနဲ့ ပတ်သက်ပြီး။ ဒါဟာ တကယ်ကို နာကျင်စရာပါပဲ။ ဒါကို ရင်းနှီးတဲ့သူတွေက ရယ်ကြလိမ့်မယ်၊ ဒါပေမယ့် အလေးအနက်ပြောရရင် ကိစ္စရပ်တွေရဲ့ 200% မှာ “XNUMX” လို့ဖြေတဲ့ ဝန်ဆောင်မှုတွေကို ကျွန်တော့်ဘ၀မှာ တွေ့ခဲ့ရပါတယ်။ ဆိုလိုတာက ဘယ်သူအောင်မြင်လဲ။ သို့သော် တစ်ချိန်တည်းတွင် ၎င်းတို့သည် တုံ့ပြန်မှု၏ကိုယ်ထည်တွင် “ထိုကဲ့သို့သော အမှားမျိုး” ဟု ရေးသားကြသည်။

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

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

အားလုံးအဆင်ပြေရင် အဖြေနှစ်ရာနဲ့ တုံ့ပြန်လိုက်ပါ။ မူအရ၊ မည်သည့်အဖြေ နှစ်ရာသည် သင့်အတွက် ကိုက်ညီမည်နည်း။ အစုတ်အပြဲတွေကို ကောင်းကောင်းဖတ်ပြီး အချို့သော တုံ့ပြန်မှု အခြေအနေတွေဟာ တခြားသူတွေနဲ့ မတူဘူးဆိုတာ သိရင် သင့်လျော်တဲ့ အဖြေတွေနဲ့ ဖြေပါ- 204၊ 5၊ 10၊ 15၊ ဘာပဲဖြစ်ဖြစ်။ သိပ်မကောင်းဘူးဆိုရင် "သုည သုည" နှစ်ခုပဲ ရှိတယ်။ အားလုံး ဆိုးဆိုးရွားရွား ဖြစ်နေပြီး ကျန်းမာရေး စစ်ဆေးမှု မတုံ့ပြန်ပါက ငါးရာ တစ်ခုခုဖြင့် ဖြေဆိုပါ။ တဖန်၊ မည်သို့တုံ့ပြန်ရမည်ကို နားလည်ပါက၊ မတူညီသော တုံ့ပြန်မှုအခြေအနေများသည် တစ်ခုနှင့်တစ်ခု မတူပေ။ နားမလည်ပါက 502 သည် တစ်ခုခုမှားယွင်းနေပါက ကျန်းမာရေးစစ်ဆေးမှုများကို တုံ့ပြန်ရန် သင့်ရွေးချယ်မှုဖြစ်သည်။

ဤသည်မှာ အရင်းခံဝန်ဆောင်မှုများကို စစ်ဆေးခြင်းနှင့်ပတ်သက်၍ အနည်းငယ်ပြန်ပြောပြလိုပါသည်။ ဥပမာအားဖြင့် သင်စတင်ပါက သင့်လျှောက်လွှာနောက်ကွယ်တွင် ရှိနေသည့် ဝန်ဆောင်မှုများအားလုံးကို စစ်ဆေးကြည့်ပါ - ယေဘုယျအားဖြင့် အရာအားလုံး။ မိုက်ခရိုဆားဗစ်ဗိသုကာ၏ ရှုထောင့်မှ ကျွန်ုပ်တို့ရရှိသောအရာမှာ “အချိတ်အဆက်နည်းခြင်း” ကဲ့သို့သော အယူအဆတစ်ခုရှိသည် - ဆိုလိုသည်မှာ သင်၏ဝန်ဆောင်မှုများသည် တစ်ခုနှင့်တစ်ခုအပေါ် အနည်းငယ်သာ မှီခိုနေရသောအခါတွင် ဖြစ်သည်။ ၎င်းတို့ထဲမှ တစ်ခု ပျက်ကွက်ပါက၊ ဤလုပ်ဆောင်နိုင်စွမ်းမရှိသော အခြားအရာအားလုံးသည် ရိုးရိုးရှင်းရှင်း ဆက်လက်အလုပ်လုပ်နေမည်ဖြစ်သည်။ အချို့သောလုပ်ဆောင်ချက်များသည် အလုပ်မဖြစ်ပါ။ ထို့ကြောင့် သင်သည် ကျန်းမာရေးစစ်ဆေးမှုအားလုံးကို တစ်ခုနှင့်တစ်ခု ချိတ်ဆက်မိပါက၊ အခြေခံအဆောက်အအုံတွင် တစ်ခုခု ပျက်ကွက်သွားမည်ဖြစ်ပြီး၊ ကျသွားသောကြောင့်၊ ဝန်ဆောင်မှုအားလုံး၏ ကျန်းမာရေးစစ်ဆေးမှုအားလုံးသည်လည်း ပျက်ကွက်သွားတော့သည် - နှင့် ယေဘုယျအားဖြင့် အခြေခံအဆောက်အအုံများ ပိုမိုများပြားလာပါသည်။ microservice architecture တစ်ခုလုံး No. အဲဒီမှာ အားလုံး မှောင်သွားတယ်။

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

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

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

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

အမိုက်စားပိတ်ခြင်း။

ယေဘူယျအားဖြင့်၊ Graceful Shutdown ဆိုတာ ဘာလဲ၊ ဘာကြောင့် လိုအပ်တာလဲ။ အကြောင်းတစ်ခုခုကြောင့် သင့်လျှောက်လွှာ ပျက်ကျသည့်အခါ ၎င်းသည် သင်လုပ်ဆောင်ရန် လိုအပ်သည်။ app stop - သို့မဟုတ် သင်သည် ဥပမာအားဖြင့်၊ လည်ပတ်မှုစနစ်မှ အချက်ပြမှုကို လက်ခံရရှိသည်၊ သင်၏ အက်ပ်လီကေးရှင်းသည် ၎င်းကို နားလည်ပြီး ၎င်းနှင့်ပတ်သက်သည့် တစ်ခုခုကို လုပ်ဆောင်ရမည်ဖြစ်သည်။ အဆိုးဆုံးအခြေအနေမှာ၊ သင်၏လျှောက်လွှာသည် SIGTERM ကိုလက်ခံရရှိပြီး "SIGTERM၊ ဆက်ကြရအောင်၊ အလုပ်မလုပ်နဲ့" နှင့်တူသည့်အချိန်တွင်ဖြစ်သည်။ ဤသည်မှာ ဆိုးရွားသော ရွေးချယ်မှုတစ်ခုဖြစ်သည်။

ထပ်တူနီးပါးမကောင်းတဲ့ရွေးချယ်မှုတစ်ခုကတော့ မင်းရဲ့ application က SIGTERM ကိုလက်ခံရရှိတဲ့အခါ "သူတို့က segterm လို့ပြောတယ်၊ ဆိုလိုတာကတော့ ငါတို့အဆုံးသတ်နေတယ်၊ ​​ငါမမြင်ဖူးဘူး၊ သုံးစွဲသူတောင်းဆိုချက်တွေကိုငါမသိဘူး၊ ဘယ်လိုအမျိုးအစားလဲမသိဘူး" ငါ အခု လုပ်နေတဲ့ တောင်းဆိုချက်တွေကို သူတို့က SIGTERM လို့ ပြောတယ်၊ ဆိုလိုတာကတော့ ငါတို့ ပြီးသွားပြီ" ဒါကလည်း မကောင်းတဲ့ ရွေးချယ်မှုတစ်ခုပါ။

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

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

Kubernetes ရှုထောင့်မှ ကြည့်ရသည်မှာ ဤအရာဖြစ်သည်။ Kubernetes အစုအဝေးတွင် လုပ်ဆောင်နေသော ပေါ့ဒ်တစ်ခုအား "ကျေးဇူးပြု၍ ရပ်ပါ၊ ထွက်သွားပါ" သို့မဟုတ် ကျွန်ုပ်တို့ ပြန်လည်စတင်လိုက်သည့်အခါ သို့မဟုတ် Kubernetes က Pods များကို ပြန်လည်ဖန်တီးသောအခါတွင် အပ်ဒိတ်တစ်ခု ဖြစ်ပေါ်သည့်အခါ Kubernetes သည် ပေါ့ဒ်သို့ SIGTERM မက်ဆေ့ဂျ်ကို ပေးပို့ပြီး စောင့်မျှော်နေပါသည်။ အချိန်အတန်ကြာ၊ ဤအချိန်သည် သူစောင့်ဆိုင်းရမည့်အချိန်ဖြစ်သည်၊ ၎င်းကိုလည်း စီစဉ်သတ်မှတ်ထားပြီး၊ ဒီပလိုမာများတွင် အထူးသတ်မှတ်ချက်တစ်ခုပါရှိပြီး ၎င်းကို Graceful ShutdownTimeout ဟုခေါ်သည်။ မင်းနားလည်သလိုပဲ၊ အဲဒါကို ဘာမှအတွက်လို့ မခေါ်ဘူး၊ အခု ငါတို့ပြောနေတာက ဘာအတွက်မှ မဟုတ်ဘူး။

အပလီကေးရှင်းသို့ SIGTERM ပေးပို့သည့်အချိန်နှင့် လျှောက်လွှာသည် တစ်စုံတစ်ခုအတွက် ရူးသွပ်သွားပုံရသည် သို့မဟုတ် "ပိတ်မိနေပုံ" ဖြစ်ကာ ကုန်ဆုံးတော့မည်မဟုတ်ကြောင်း နားလည်လာသောအခါတွင် ကျွန်ုပ်တို့သည် မည်မျှစောင့်ရမည်ကို အတိအကျပြောနိုင်သည်။ ၎င်းကို SIGKILL ပေးပို့ပါ၊ ဆိုလိုသည်မှာ ၎င်း၏အလုပ်ကို ပြီးမြောက်အောင် ကြိုးစားပါ။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့တွင် daemon တစ်မျိုးမျိုး လုပ်ဆောင်ထားပြီး၊ ၎င်းသည် လုပ်ဆောင်ချက်များကို လုပ်ဆောင်သည်။ daemon အလုပ်လုပ်သော ကျွန်ုပ်တို့၏ ပျမ်းမျှလုပ်ဆောင်ချက်များသည် တစ်ကြိမ်လျှင် စက္ကန့် 30 ထက် ပိုမကြာကြောင်း ကျွန်ုပ်တို့နားလည်ပါသည်။ ထို့ကြောင့်၊ SIGTERM ရောက်ရှိလာသောအခါ၊ ကျွန်ုပ်တို့၏ daemon သည် SIGTERM ပြီးနောက် စက္ကန့် 30 တွင် ပြီးဆုံးနိုင်သည်ကို ကျွန်ုပ်တို့ နားလည်ပါသည်။ ဥပမာအားဖြင့်၊ ၄၅ စက္ကန့်လောက် အချိန်ပေးပြီး SIGTERM လို့ရေးတယ်။ ပြီးရင် ၄၅ စက္ကန့်စောင့်ပါ။ သီအိုရီအရ၊ ဤအချိန်အတောအတွင်း နတ်ဆိုးသည် ၎င်း၏အလုပ်ပြီးမြောက်ပြီး သူ့အလိုလို ပြီးဆုံးသွားသင့်သည်။ သို့သော် ရုတ်တရက် မလုပ်ဆောင်နိုင်ခဲ့ပါက၊ ၎င်းသည် ကျွန်ုပ်တို့၏တောင်းဆိုမှုများကို ပုံမှန်အတိုင်းလုပ်ဆောင်တော့မည်မဟုတ်ဟု ဆိုလိုသည်။ 45 စက္ကန့်အတွင်း သင်သည် သူ့ကို ဘေးကင်းစွာ လက်မှုပ်ချလိုက်နိုင်သည်။

တကယ်တော့၊ ဒီနေရာမှာ ရှုထောင့် ၂ ခုကိုတောင် ထည့်သွင်းစဉ်းစားနိုင်ပါတယ်။ ပထမဦးစွာ၊ သင်သည် တောင်းဆိုမှုတစ်ခုကို လက်ခံရရှိပါက၊ သင်သည် ၎င်းကို တစ်နည်းနည်းဖြင့် စတင်လုပ်ဆောင်ခဲ့ပြီး အသုံးပြုသူကို တုံ့ပြန်မှုမပေးခဲ့ဘဲ၊ ဥပမာအားဖြင့် သင်သည် SIGTERM ကို ရရှိခဲ့ကြောင်း နားလည်ပါ။ ၎င်းကို ပြန်လည်ပြင်ဆင်ပြီး အသုံးပြုသူကို အဖြေပေးရခြင်းသည် အဓိပ္ပာယ်ရှိစေသည်။ ဒါက ဒီကိစ္စမှာ နံပါတ်တစ်အချက်ပါ။ ဤနေရာတွင် နံပါတ်နှစ်အချက်မှာ သင်သည် သင်၏ကိုယ်ပိုင်အက်ပ်လီကေးရှင်းကိုရေးသားပါက၊ ယေဘူယျအားဖြင့် သင်သည် သင်၏လျှောက်လွှာအတွက် တောင်းဆိုချက်ကိုလက်ခံရရှိသည့်ပုံစံဖြင့် တည်ဆောက်ကာ၊ ထို့နောက်တွင် သင်သည် အလုပ်အချို့ကိုစတင်ရန်၊ တစ်နေရာမှဖိုင်များကိုဒေါင်းလုဒ်လုပ်ခြင်း၊ ဒေတာဘေ့စ်ကိုဒေါင်းလုဒ်လုပ်ခြင်း အစရှိသည်တို့ဖြစ်သည်။ - အဲဒါ။ ယေဘူယျအားဖြင့်၊ သင်၏အသုံးပြုသူ၊ သင်၏တောင်းဆိုချက်သည် နာရီဝက်ကြာ ဆိုင်းငံ့ထားပြီး သူ့ကိုအဖြေပေးရန် သင့်အား စောင့်မျှော်နေပါသည် - ထို့နောက် ဖြစ်နိုင်သည်မှာ၊ သင်သည် ဗိသုကာလက်ရာကို လုပ်ဆောင်ရန် လိုအပ်ပါသည်။ ဆိုလိုသည်မှာ သင်၏လုပ်ဆောင်ချက်များသည် တိုတောင်းပါက SIGTERM ကို လျစ်လျူရှုပြီး ပြုပြင်မွမ်းမံခြင်းသည် အဓိပ္ပာယ်ရှိပါသည်၊ အကယ်၍ သင်၏လုပ်ဆောင်ချက်များသည် ရှည်နေပါက ဤကိစ္စတွင် SIGTERM ကို လျစ်လျူရှုရန် အဓိပ္ပါယ်မရှိပေ။ ထိုသို့သော ရှည်လျားသော လုပ်ဆောင်မှုများကို ရှောင်ရှားရန် ဗိသုကာလက်ရာကို ပြန်လည် ဒီဇိုင်းထုတ်ခြင်းသည် အဓိပ္ပာယ်ရှိလှသည်။ ဒါကြောင့် သုံးစွဲသူတွေက လှည့်ပတ်ပြီး စောင့်မနေပါနဲ့။ ကျွန်တော်မသိဘူး၊ အဲဒီမှာ websocket တစ်မျိုးမျိုးလုပ်ပါ၊ သင့်ဆာဗာက client ဆီကိုပို့မယ့် reverse hooks တွေလုပ်ပါ၊ တခြားဘာမဆို၊ ဒါပေမယ့် user ကို နာရီဝက်ကြာအောင် ဆွဲထားဖို့ အတင်းအကြပ်မလုပ်ခိုင်းဘဲ session တစ်ခုစောင့်ရုံပါပဲ။ သူ့ကိုဖြေပါ။ ဘာကြောင့်လဲ ဆိုတော့ ဘယ်နေရာမှာ ပျက်သွားမယ်ဆိုတာ ခန့်မှန်းလို့ မရဘူး။

သင်၏လျှောက်လွှာကို ရပ်ဆိုင်းသည့်အခါ၊ သင့်လျော်သော ထွက်ပေါက်ကုဒ်အချို့ကို ပေးသင့်သည်။ ဆိုလိုသည်မှာ သင့်လျှောက်လွှာကို ပိတ်ရန်၊ ရပ်တန့်ခိုင်းပြီး ၎င်းသည် ပုံမှန်အတိုင်း ရပ်တန့်သွားပါက၊ သင်သည် ထွက်ပေါက်ကုဒ် 1,5,255 ကဲ့သို့သော အချို့သော ထွက်ပေါက်ကို ပြန်ပေးရန် မလိုအပ်ပါ။ သုညကုဒ်မဟုတ်သော မည်သည့်အရာမဆို အနည်းဆုံး Linux စနစ်များတွင် မအောင်မြင်ဟု ယူဆမိပါသည်။ ဆိုလိုသည်မှာ၊ ဤကိစ္စတွင် သင်၏လျှောက်လွှာကို အမှားတစ်ခုဖြင့် အဆုံးသတ်သည်ဟု ယူဆပါသည်။ ထို့ကြောင့်၊ သင့်လျှောက်လွှာတွင် အမှားအယွင်းမရှိဘဲ ပြီးမြောက်ပါက အနုနည်းဖြင့် 0 ဟုပြောနိုင်သည်။ သင့်လျှောက်လွှာသည် အကြောင်းတစ်ခုခုကြောင့် ပျက်ကွက်ပါက၊ သင်သည် အထွက်တွင် 0 မဟုတ်ဟု ပြောနိုင်သည်။ သငျသညျဤအချက်အလက်နှင့်အတူအလုပ်လုပ်နိုင်ပါတယ်။

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

အချို့သော ပုံမှန် chat များ၏ developer များသည် ၎င်းကို မသိသောအခါ၊ websocket သည် ကွဲသွားနိုင်သည်။ သူတို့အတွက်၊ proxy မှာ တစ်ခုခုဖြစ်သွားတဲ့အခါ၊ config ကိုပြောင်းလိုက်ရုံနဲ့ reload လုပ်ပါတယ်။ ဤကိစ္စတွင်၊ သက်တမ်းရှည်သောအစည်းအဝေးများအားလုံးသည် သဘာဝအားဖြင့် စုတ်ပြဲနေပါသည်။ ဆော့ဖ်ဝဲရေးသားသူများသည် ကျွန်ုပ်တို့ထံ ပြေးလာပြီး "ယောက်ျားလေးတွေ၊ မင်းဘာလုပ်နေတာလဲ၊ ငါတို့ရဲ့ဖောက်သည်တွေအားလုံးအတွက် ချတ်ပျက်သွားပြီ!" ငါတို့ကသူတို့ကိုပြောတယ်- "မင်းဘာလုပ်တာလဲ။ သင့်ဖောက်သည်များ ပြန်လည်ချိတ်ဆက်၍မရပါ။ သူတို့က "မဟုတ်ဘူး၊ ငါတို့အစည်းအဝေးတွေကိုမစုတ်ပြတ်ဖို့လိုတယ်။" အတိုချုပ်ပြောရလျှင် ဤသည်မှာ အမှန်ပင် အဓိပ္ပါယ်မရှိပေ။ ဖောက်သည်ဘက်မှ ထည့်သွင်းစဉ်းစားရန် လိုအပ်ပါသည်။ အထူးသဖြင့် ကျွန်တော်ပြောခဲ့သလိုပဲ၊ websockets တွေလို သက်တမ်းရှည်ကြာတဲ့ session တွေနဲ့၊ အဲဒါက ပျက်သွားနိုင်ပြီး သုံးစွဲသူက သတိမထားမိဘဲ၊ အဲဒီ sessions တွေကို ပြန်လည်ထည့်သွင်းနိုင်ဖို့လိုအပ်ပါတယ်။ ပြီးတော့ အရာအားလုံးပြီးပြည့်စုံတယ်။

အရင်းမြစ်များ

အမှန်တော့ ဒီနေရာမှာ ရှင်းရှင်းလေးပဲ ပြောပြမယ်။ လက်တွေ့ဘဝကနေ ပြန်တယ်။ အရင်းအမြစ်များအကြောင်း ကျွန်တော်ကြားဖူးသမျှ အဖျားဆုံးအရာ။

ဤကိစ္စတွင် အရင်းအမြစ်များ၊ ကျွန်ုပ်ဆိုလိုသည်မှာ၊ အချို့သော တောင်းဆိုမှုများ၊ သင်၏ Kubernetes အစုအဝေးများတွင် pods များကို သင်ထည့်သွင်းနိုင်သည့် ကန့်သတ်ချက်များ။ ဆော့ဖ်ဝဲရေးသားသူထံမှကြားရသော ရယ်စရာအကောင်းဆုံးအချက်မှာ... ယခင်အလုပ်နေရာရှိ ကျွန်ုပ်၏ developer များထဲမှတစ်ဦးက "ကျွန်ုပ်၏လျှောက်လွှာကို အစုအဝေးတွင် စတင်မည်မဟုတ်ပါ။" အဲဒါက မစသေးတာတွေ့လိုက်ရတယ်၊ ဒါပေမယ့် အဲဒါက အရင်းအမြစ်တွေနဲ့ မကိုက်ညီဘူး ဒါမှမဟုတ် သူတို့က အရမ်းသေးငယ်တဲ့ ကန့်သတ်ချက်တွေကို သတ်မှတ်ထားတယ်။ အတိုချုပ်ပြောရလျှင်၊ အရင်းအမြစ်များကြောင့် အပလီကေးရှင်းကို မစတင်နိုင်ပါ။ ငါပြောသည်- "အရင်းအမြစ်များကြောင့် စတင်မည်မဟုတ်ပါ၊ သင်သည် မည်မျှလိုအပ်သည်ကို ဆုံးဖြတ်ပြီး လုံလောက်သောတန်ဖိုးကို သတ်မှတ်ပါ။" သူက “ဘယ်လိုအရင်းအမြစ်မျိုးလဲ” Kubernetes၊ တောင်းဆိုချက်များအပေါ် ကန့်သတ်ချက်များ နှင့် blah, blah, blah သတ်မှတ်ရန် လိုအပ်ကြောင်း သူ့ကို ကျွန်တော် စတင်ရှင်းပြခဲ့သည်။ ငါးမိနစ်လောက် နားထောင်ပြီး ခေါင်းညိတ်ပြီး ပြောတယ် "ကျွန်တော် ဒီကို developer တစ်ယောက်အနေနဲ့ အလုပ်လုပ်ဖို့ လာတာပါ၊ အရင်းအမြစ်တွေအကြောင်း ဘာမှ မသိချင်ပါဘူး။ ကုဒ်ရေးဖို့ ဒီကိုလာခဲ့တာ ဒါပဲ” ဝမ်းနည်းစရာပါ။ ဤသည်မှာ developer ၏အမြင်မှ အလွန်ဝမ်းနည်းစရာကောင်းသော အယူအဆတစ်ခုဖြစ်သည်။ အထူးသဖြင့် ခေတ်မီကမ္ဘာကြီးတွင် တိုးတက်သော အမျိုးအမည်မသိသူများ၊

အရင်းအမြစ်တွေ ဘာကြောင့် လိုအပ်တာလဲ။ Kubernetes တွင် အရင်းအမြစ် ၂ မျိုးရှိသည်။ အချို့ကို တောင်းဆိုမှုများ၊ အချို့ကို ကန့်သတ်ချက်ဟုခေါ်သည်။ အရင်းအမြစ်များအားဖြင့် ကျွန်ုပ်တို့သည် အခြေခံအားဖြင့် အမြဲတမ်းအခြေခံကန့်သတ်ချက်နှစ်ခုသာရှိကြောင်း ကျွန်ုပ်တို့နားလည်နိုင်မည်ဖြစ်ပါသည်။ ဆိုလိုသည်မှာ Kubernetes တွင်လည်ပတ်နေသည့်ကွန်တိန်နာအတွက် CPU အချိန်ကန့်သတ်ချက်နှင့် RAM ကန့်သတ်ချက်များ။

ကန့်သတ်ချက်တစ်ခုသည် သင့်အပလီကေးရှင်းတွင် ရင်းမြစ်တစ်ခုအား မည်ကဲ့သို့အသုံးပြုရမည်ကို ကန့်သတ်ချက်တစ်ခုပေးထားသည်။ ဆိုလိုသည်မှာ၊ သင်သည် ကန့်သတ်ချက်များထဲတွင် RAM 1GB ဟု ဆိုပါက၊ သင်၏ application သည် RAM 1GB ထက်ပို၍ အသုံးပြုနိုင်မည် မဟုတ်ပါ။ အကယ်၍ သူရုတ်တရက်အလိုရှိ၍ ၎င်းကိုပြုလုပ်ရန်ကြိုးစားပါက၊ မှတ်ဉာဏ်မရှိသော oom killer ဟုခေါ်သော လုပ်ငန်းစဉ်တစ်ခုသည် သင့်လျှောက်လွှာကို သတ်ပစ်လိမ့်မည် - ဆိုလိုသည်မှာ ၎င်းသည် ရိုးရှင်းစွာပြန်လည်စတင်မည်ဖြစ်သည်။ CPU ပေါ်မူတည်၍ အပလီကေးရှင်းများ ပြန်လည်စတင်မည်မဟုတ်ပါ။ CPU ၏စည်းကမ်းချက်များအရ၊ အပလီကေးရှင်းတစ်ခုသည် ကန့်သတ်ချက်များတွင်ဖော်ပြထားသည်ထက်ပို၍များစွာအသုံးပြုရန်ကြိုးစားပါက CPU ကို ရိုးရိုးရှင်းရှင်း တင်းကြပ်စွာရွေးချယ်မည်ဖြစ်သည်။ ၎င်းသည် ပြန်လည်စတင်ခြင်းဆီသို့ ဦးတည်မသွားပါ။ ဒါက ကန့်သတ်ချက် - ဒါက အထက်ကန့်သတ်ချက်ပါ။

တောင်းဆိုချက်တစ်ခုရှိတယ်။ တောင်းဆိုချက်တစ်ခုသည် သင်၏ Kubernetes အစုအဝေးရှိ ဆုံမှတ်များကို အပလီကေးရှင်းများဖြင့် မည်သို့ဖြည့်သွင်းသည်ကို Kubernetes က နားလည်ပုံဖြစ်သည်။ ဆိုလိုသည်မှာ တောင်းဆိုချက်သည် သင့်လျှောက်လွှာ၏ ကတိကဝတ်တစ်မျိုးဖြစ်သည်။ ၎င်းသည် ကျွန်ုပ်အသုံးပြုလိုသည့်အရာကို ပြောသည်- "ကျွန်ုပ်အတွက် ဤများစွာသော CPU နှင့် ဤများစွာသော memory ကို ကျွန်ုပ်အတွက် သိမ်းဆည်းထားစေလိုပါသည်။" ထိုကဲ့သို့သော ရိုးရှင်းသော ဥပမာ။ စုစုပေါင်း CPU 8 ခု ပါသော node တစ်ခုရှိလျှင် ဘာဖြစ်မလဲ။ ပြီးတော့ pod တစ်ခုရောက်လာပြီး 1 CPU လို့ဆိုပါတယ်၊ ဆိုလိုတာကတော့ node မှာ CPU 7 ခုကျန်ပါတယ်။ ဆိုလိုသည်မှာ၊ ၎င်းတို့တောင်းဆိုချက်များတွင် CPU 8 ခုပါသော ဤ node တွင် 1 pods များရောက်ရှိသည်နှင့်အမျှ၊ Kubernetes ၏ရှုထောင့်မှကြည့်လျှင် node သည် CPU မရှိတော့ဘဲ တောင်းဆိုမှုများပါသည့် pod များ ထပ်မံမရနိုင်ပါ။ ဤ node ပေါ်တွင်စတင်ခဲ့သည်။ အကယ်၍ node များအားလုံး CPU မှကုန်သွားပါက CPU သည် ကုန်သွားသောကြောင့် သင့် pods များလုပ်ဆောင်ရန် အစုအဝေးတွင် သင့်လျော်သော node များမရှိဟု Kubernetes မှစတင်ပြောပါမည်။

အဘယ်ကြောင့် တောင်းဆိုမှုများ လိုအပ်ပြီး အဘယ်ကြောင့် တောင်းဆိုမှုများမရှိဘဲ Kubernetes တွင် မည်သည့်အရာကိုမျှ စတင်ရန် မလိုအပ်ဟု ကျွန်ုပ်ထင်ပါသည်။ အခြေနေကို တွေးကြည့်ရအောင်။ သင့်လျှောက်လွှာကို တောင်းဆိုမှုမရှိဘဲ သင်ဖွင့်လိုက်သည်၊ Kubernetes သည် သင့်တွင် မည်မျှရှိသည်၊ မည်သည့် node များကို ၎င်းထံသို့ တွန်းပို့နိုင်သည်ကို Kubernetes မသိပါ။ ကောင်းပြီ၊ သူက တွန်းသည်၊ တွန်းသည်၊ ခုံများပေါ်သို့ တွန်းထိုးသည်။ တစ်ချိန်ချိန်တွင်၊ သင်သည်သင်၏အပလီကေးရှင်းသို့အသွားအလာစတင်လိမ့်မည်။ နှင့် အပလီကေးရှင်းများထဲမှ တစ်ခုသည် ကန့်သတ်ချက်များနှင့်အညီ ရင်းမြစ်များကို အကန့်အသတ်များအထိ ရုတ်တရက် စတင်အသုံးပြုလာသည်။ အနီးနားတွင် အခြားသော အပလီကေးရှင်းတစ်ခုရှိ၍ အရင်းအမြစ်များလည်း လိုအပ်ပါသည်။ node သည် အမှန်တကယ်တွင် အရင်းအမြစ်များ ကုန်ဆုံးသွားသည် ဥပမာ၊ OP။ node သည် အမှန်တကယ်တွင် အရင်းအမြစ်များ ကုန်ဆုံးသွားတော့သည်၊ ဥပမာ၊ ကျပန်းဝင်ရောက်မှုမှတ်ဉာဏ် (RAM)။ node တစ်ခု ပါဝါကုန်သွားသောအခါ၊ docker အားလုံး၏ ပထမဆုံးတုံ့ပြန်မှု ရပ်သွားမည်ဖြစ်ပြီး၊ ထို့နောက် cubelet၊ ထို့နောက် OS ဖြစ်သည်။ ၎င်းတို့သည် ရိုးရိုးရှင်းရှင်း သတိလစ်သွားမည်ဖြစ်ပြီး အရာအားလုံးသည် သင့်အတွက် ကျိန်းသေအလုပ်မလုပ်တော့ပါ။ ဆိုလိုသည်မှာ၊ ၎င်းသည်သင်၏ node ကိုပိတ်သွားစေပြီး၎င်းကိုသင်ပြန်လည်စတင်ရန်လိုလိမ့်မည်။ အတိုချုပ်ပြောရရင် အခြေအနေက သိပ်မကောင်းဘူး။

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

ဒေတာသိုလှောင်မှု

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

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

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

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

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

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

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

Ceph နဲ့ပတ်သက်တဲ့ သင်တန်းတစ်ခု ရှိပါမယ် ပရိုဂရမ်နှင့် ရင်းနှီးပြီး လျှောက်လွှာတင်ပါ။.

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

ငါပြောခဲ့တဲ့ နောက်တချက်ကတော့ မင်းရဲ့ အပလီကေးရှင်းက လည်ပတ်နေချိန်မှာ ဖိုင်တချို့ထုတ်ပေးရင် ဘာလုပ်ရမလဲ။ ဥပမာအားဖြင့်၊ စတင်သောအခါတွင်၊ ၎င်းသည် အပလီကေးရှင်းစတင်သည့်အချိန်တွင်သာ ရရှိသည့် အချက်အလက်အချို့အပေါ်အခြေခံသည့် static file အချို့ကိုထုတ်ပေးပါသည်။ ခဏလေး။ ထိုသို့သောဒေတာများစွာမရှိပါက၊ သင်သည်လုံးဝအနှောက်အယှက်ပေးစရာမလိုပါ၊ ဤလျှောက်လွှာကိုသင်ကိုယ်တိုင်ထည့်သွင်းပြီးအလုပ်လုပ်ပါ။ ဤနေရာတွင် တစ်ခုတည်းသောမေးခွန်းမှာ ဘာလဲ၊ ကြည့်ပါ။ မကြာခဏဆိုသလို၊ WordPress ကဲ့သို့သော အမွေအနှစ်စနစ်အမျိုးမျိုး၊ အထူးသဖြင့် လိမ္မာပါးနပ်သော ပလပ်အင်အချို့ကို ပြုပြင်ထားသော၊ လိမ္မာပါးနပ်သော PHP developer များဖြင့် ၎င်းတို့သည် ၎င်းတို့အတွက် ဖိုင်တစ်မျိုးမျိုး ဖန်တီးနိုင်စေရန် ပြုလုပ်နည်းကို မကြာခဏ သိရှိကြသည်။ ထို့ကြောင့်၊ တစ်ခုသည် ဖိုင်တစ်ခုထုတ်ပေးသည်၊ ဒုတိယသည် ဒုတိယဖိုင်ကိုထုတ်ပေးသည်။ သူတို့က မတူဘူး။ ဟန်ချက်ညီခြင်းသည် သုံးစွဲသူများ၏ Kubernetes အစုအဝေးတွင် မတော်တဆဖြစ်တတ်ပါသည်။ ထို့ကြောင့်၊ ဥပမာအားဖြင့် ၎င်းတို့သည် မည်ကဲ့သို့ အတူတကွ လုပ်ဆောင်ရမည်ကို မသိကြကြောင်း ထွက်ပေါ်လာသည်။ တစ်ခုက အချက်အလက်တစ်ခုပေးတယ်၊ နောက်တစ်ခုက သုံးစွဲသူကို နောက်ထပ်အချက်အလက်တစ်ခုပေးတယ်။ ဒါက ရှောင်သင့်တဲ့အရာပါ။ ဆိုလိုသည်မှာ Kubernetes တွင်၊ သင်စတင်လိုက်သည့် အရာအားလုံးသည် အကြိမ်များစွာတွင် လုပ်ဆောင်နိုင်မည်ဟု အာမခံပါသည်။ Kubernetes သည် ရွေ့လျားနေသည့်အရာဖြစ်သောကြောင့် ထို့ကြောင့် မည်သူကိုမျှ မတောင်းဆိုဘဲ အလိုရှိတိုင်း မည်သည့်အရာကိုမဆို ရွှေ့နိုင်သည်။ ထို့ကြောင့်၊ ဤအရာကိုသင်အားကိုးရန်လိုအပ်သည်။ သာဓကတစ်ခုတွင် စတင်လုပ်ဆောင်သမျှ အရာအားလုံးသည် အနှေးနှင့်အမြန် သို့မဟုတ် နောက်ပိုင်းတွင် ကျရှုံးလိမ့်မည်။ ကြိုတင်မှာယူမှု များလေလေ၊ ပိုကောင်းလေပါပဲ။ ဒါပေမယ့် ထပ်ပြောရရင်၊ မင်းမှာ ဒီလိုဖိုင်အနည်းငယ်ရှိတယ်ဆိုရင် အဲဒါတွေကို မင်းရဲ့အောက်မှာ ထားနိုင်ပြီး၊ သူတို့က ပမာဏနည်းနည်းပဲ အလေးချိန်ရှိတယ်။ ၎င်းတို့ထဲမှ အနည်းငယ်သာရှိသေးပါက၊ ၎င်းတို့ကို ကွန်တိန်နာအတွင်းသို့ မတွန်းထုတ်သင့်ပေ။

Kubernetes တွင် ထိုသို့သော အံ့သြဖွယ်ကောင်းသောအရာတစ်ခု ရှိသည်၊ သင်သည် အသံအတိုးအကျယ်ကို အသုံးပြုနိုင်ကြောင်း ကျွန်ုပ် အကြံပေးလိုပါသည်။ အထူးသဖြင့်၊ ဗလာ dir အမျိုးအစား ပမာဏတစ်ခုရှိသည်။ ဆိုလိုသည်မှာ Kubernetes သည် သင်စတင်ခဲ့သည့်ဆာဗာရှိ ၎င်း၏ဝန်ဆောင်မှုလမ်းညွှန်များတွင် လမ်းညွှန်တစ်ခုကို အလိုအလျောက်ဖန်တီးပေးမည်ဖြစ်သည်။ သင်သုံးနိုင်စေရန်အတွက် သူသည် သင့်အား ပေးလိမ့်မည်။ အရေးကြီးတဲ့ အချက်တစ်ခုပဲ ရှိတယ်။ ဆိုလိုသည်မှာ၊ သင်၏ဒေတာကို ကွန်တိန်နာအတွင်းတွင် သိမ်းဆည်းမည်မဟုတ်သော်လည်း သင်အသုံးပြုနေသည့် host ပေါ်တွင်သာဖြစ်သည်။ ထို့အပြင်၊ Kubernetes သည် ပုံမှန်ဖွဲ့စည်းပုံအောက်တွင် အဆိုပါဗလာ dirs များကို ထိန်းချုပ်နိုင်ပြီး ၎င်းတို့၏ အမြင့်ဆုံးအရွယ်အစားကို ထိန်းချုပ်နိုင်ပြီး ၎င်းကို ကျော်လွန်ခွင့်မပြုပါ။ တစ်ခုတည်းသောအချက်မှာ အလွတ် dir တွင် သင်ရေးထားသည့်အရာသည် pod restart ကာလအတွင်း မပျောက်ပျက်သွားစေရန်ဖြစ်သည်။ ဆိုလိုသည်မှာ သင့် pod သည် မှားယွင်းပြီး ပြုတ်ကျပါက နောက်တစ်ကြိမ် ထပ်တက်လာပါက၊ အချည်းနှီးသော dir အတွင်းရှိ အချက်အလက်များသည် မည်သည့်နေရာမှ ရောက်သွားမည်မဟုတ်ပါ။ အသစ်အစမှာ သူပြန်သုံးနိုင်တယ်၊ အဲဒါကောင်းပါတယ်။ မင်းရဲ့ ပဲ့ဟာ တစ်နေရာရာမှာ ထွက်သွားရင် ဒေတာမရှိပဲ ထွက်သွားလိမ့်မယ်။ ဆိုလိုသည်မှာ၊ ၎င်းသည်အချည်းနှီးသော dir ဖြင့်စတင်သည့် node မှ pod ပျောက်သွားသည်နှင့်တပြိုင်နက်ဗလာ dir ကိုဖျက်ပစ်သည်။

အချည်းနှီးသော dir နှင့် ပတ်သက်၍ အဘယ်အရာကောင်းသနည်း။ ဥပမာအားဖြင့်၊ ၎င်းကို cache အဖြစ်အသုံးပြုနိုင်သည်။ ကျွန်ုပ်တို့၏ အပလီကေးရှင်းသည် တစ်စုံတစ်ရာကို လျင်မြန်စွာ ဖန်တီးပေးကာ သုံးစွဲသူများထံ ပေးဆောင်ကာ အချိန်အတော်ကြာ လုပ်ဆောင်ကြောင်း စိတ်ကူးကြည့်ကြပါစို့။ ထို့ကြောင့်၊ ဥပမာအားဖြင့်၊ အပလီကေးရှင်းသည် သုံးစွဲသူများထံ ထုတ်ပေးပြီး တစ်ချိန်တည်းတွင် ၎င်းကို တစ်နေရာရာတွင် သိမ်းဆည်းထားသောကြောင့် နောက်တစ်ကြိမ်တွင် အသုံးပြုသူသည် တူညီသည့်အရာအတွက် ရောက်ရှိလာပါက ၎င်းကို ချက်ချင်းထုတ်ပေးရန် ပိုမိုမြန်ဆန်မည်ဖြစ်သည်။ Empty dir ကို Memory တွင် ဖန်တီးရန် Kubernetes ကို တောင်းဆိုနိုင်သည်။ ထို့ကြောင့်၊ သင်၏ ကက်ရှ်များသည် ယေဘုယျအားဖြင့် ဒစ်ခ်ဝင်ရောက်မှုအမြန်နှုန်းအရ အလင်းအမြန်နှုန်းဖြင့် အလုပ်လုပ်နိုင်သည်။ ဆိုလိုသည်မှာ သင့်တွင် မန်မိုရီထဲတွင် အချည်းနှီးသော dir ရှိသည်၊ ၎င်းကို OS တွင် မန်မိုရီတွင် သိမ်းဆည်းထားသော်လည်း သင့်အတွက်၊ pod အတွင်းရှိ အသုံးပြုသူအတွက် ၎င်းသည် ဒေသန္တရလမ်းညွှန်တစ်ခုနှင့်တူသည်။ မည်သည့် မှော်ပညာကို အတိအကျ သင်ကြားရန် App မလိုအပ်ပါ။ သင်သည်သင်၏ဖိုင်ကိုလမ်းညွှန်တစ်ခုတွင်တိုက်ရိုက်ယူရုံသာမက၊ တကယ်တမ်းတွင်၊ OS တွင် memory ရှိသည်။ ၎င်းသည် Kubernetes ၏ စည်းကမ်းချက်များအရ အလွန်အဆင်ပြေသော အင်္ဂါရပ်တစ်ခုလည်းဖြစ်သည်။

Minio မှာ ဘာပြဿနာတွေရှိလဲ။ Minio ၏အဓိကပြဿနာမှာ ဤအရာလုပ်ဆောင်နိုင်စေရန်အတွက် ၎င်းသည် တစ်နေရာရာတွင်လည်ပတ်ရန် လိုအပ်ပြီး သိုလှောင်မှုစနစ်ဖြစ်သည့် ဖိုင်အမျိုးအစားအချို့ရှိရမည်ဖြစ်သည်။ ဤတွင် Ceph ၏တူညီသောပြဿနာများကိုကျွန်ုပ်တို့ကြုံတွေ့ရသည်။ ဆိုလိုသည်မှာ၊ Minio သည် ၎င်း၏ဖိုင်များကို တစ်နေရာတွင် သိမ်းဆည်းရမည်ဖြစ်ပါသည်။ ၎င်းသည် သင့်ဖိုင်များအတွက် HTTP interface တစ်ခုဖြစ်သည်။ ထို့အပြင်၊ လုပ်ဆောင်နိုင်စွမ်းသည် Amazon ၏ S3 ထက် သိသိသာသာ ညံ့ဖျင်းသည်။ ယခင်က၊ ၎င်းသည် သုံးစွဲသူအား မှန်ကန်စွာ ခွင့်ပြုပေးနိုင်ခြင်း မရှိခဲ့ပါ။ ယခု ကျွန်ုပ်သိသလောက်၊ ၎င်းသည် မတူညီသော ခွင့်ပြုချက်များဖြင့် ပုံးများကို ဖန်တီးနိုင်နေပြီဖြစ်သော်လည်း၊ နောက်တဖန်၊ ကျွန်ုပ်၏ထင်မြင်ယူဆချက်မှာ အဓိကပြဿနာမှာ အရင်းခံသိုလှောင်မှုစနစ် အနည်းဆုံးဖြစ်သည်။

Empty dir in memory သည် ကန့်သတ်ချက်များကို မည်သို့အကျိုးသက်ရောက်သနည်း။ မည်သည့်နည်းဖြင့်မျှ ကန့်သတ်ချက်များကို မထိခိုက်စေပါ။ ၎င်းသည် host ၏မှတ်ဉာဏ်တွင်ရှိပြီး၊ သင်၏ကွန်တိန်နာ၏မှတ်ဉာဏ်တွင်မဟုတ်ပါ။ ဆိုလိုသည်မှာ၊ သင်၏ကွန်တိန်နာသည် ၎င်း၏သိမ်းပိုက်ထားသောမှတ်ဉာဏ်၏တစ်စိတ်တစ်ပိုင်းအနေဖြင့် မှတ်ဉာဏ်အတွင်းရှိ ဗလာ dir ကို မမြင်ရပါ။ ဒါကို အိမ်ရှင်က မြင်တယ်။ ထို့ကြောင့်၊ kubernetes ၏ရှုထောင့်မှကြည့်လျှင် ၎င်းကိုသင်စတင်အသုံးပြုသောအခါ၊ သင်သည်သင်၏ memory ၏အစိတ်အပိုင်းကို dir အချည်းနှီးဖြစ်စေရန် မြှုပ်နှံထားသည်ကို နားလည်ရန်ကောင်းပါသည်။ ထို့အပြင်၊ မန်မိုရီသည် အပလီကေးရှင်းများကြောင့်သာမက တစ်စုံတစ်ဦးမှ ဤအချည်းနှီးသော dirs သို့ စာရေးခြင်းကြောင့်လည်း ကုန်ဆုံးနိုင်သည်ကို နားလည်ပါ။

တိမ်တိုက်

နောက်ဆုံးခေါင်းစဉ်ခွဲက Cloudnative ပါ။ ဘာကြောင့် လိုအပ်တာလဲ။ မိုးတိမ်တောင်ဖြစ်သွားပြီ၊

ဆိုလိုသည်မှာ ခေတ်မီ cloud အခြေခံအဆောက်အအုံတွင် အလုပ်လုပ်ရန် စွမ်းဆောင်နိုင်ကာ ရေးသားထားသော အပလီကေးရှင်းများဖြစ်သည်။ သို့သော် တကယ်တမ်းတွင် Cloudnative တွင် အခြားသော အသွင်အပြင်တစ်ခုရှိသည်။ ၎င်းသည် ခေတ်မီ cloud အခြေခံအဆောက်အအုံ၏ လိုအပ်ချက်အားလုံးကို ထည့်သွင်းစဉ်းစားပေးသည့် အက်ပ်တစ်ခုသာမကဘဲ ယခုခေတ်မီ cloud အခြေခံအဆောက်အအုံနှင့် မည်သို့လုပ်ဆောင်ရမည်ကို သိရှိကာ၊ ၎င်းသည် ဤတိမ်တိုက်များတွင် အလုပ်လုပ်သည့်အချက်၏ အားသာချက်များနှင့် အားနည်းချက်များကို အခွင့်ကောင်းယူပါ။ သင်္ဘောပေါ်မှ ဆင်းပြီး တိမ်ထဲတွင် အလုပ်လုပ်ရုံမျှမကဘဲ Cloud တွင် အလုပ်လုပ်ခြင်း၏ အကျိုးကျေးဇူးများကို အသုံးချပါ။

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

တစ်ဖန်၊ ကျွန်ုပ်တို့သည် မကြာသေးမီက အမှုတစ်ခုရှိခဲ့သည်။ တန်းစီခြင်းကို စောင့်ကြည့်သည့် ထိန်းချုပ်သူ တစ်ဦးရှိသည်။ အလုပ်အသစ်အချို့ပေါ်လာသောအခါ၊ ၎င်းသည် Kubernetes သို့သွားသည် - Kubernetes အတွင်းတွင် ၎င်းသည် ပေါ့ဒ်အသစ်တစ်ခုကို ဖန်တီးသည်။ ဤ pod အား အလုပ်အသစ်အချို့ပေးကာ ဤ pod ၏ဘောင်အတွင်းတွင်၊ pod သည် အလုပ်လုပ်ဆောင်သည်၊ controller ကိုယ်တိုင်ထံ တုံ့ပြန်မှုတစ်ခုပေးပို့ပြီး controller သည် ဤအချက်အလက်ဖြင့် တစ်ခုခုလုပ်ဆောင်သည်။ ဥပမာအားဖြင့်၊ ၎င်းသည် ဒေတာဘေ့စ်တစ်ခုကို ပေါင်းထည့်သည်။ ဆိုလိုသည်မှာ၊ ဤသည်မှာ ကျွန်ုပ်တို့၏ အက်ပ်လီကေးရှင်း Kubernetes တွင် လုပ်ဆောင်နေခြင်း၏ အပေါင်းအချက်တစ်ခုဖြစ်သည်။ ကျွန်ုပ်တို့၏အပလီကေးရှင်း၏လုပ်ဆောင်နိုင်စွမ်းကို တစ်နည်းနည်းဖြင့် ချဲ့ထွင်ရန်နှင့် ပိုမိုအဆင်ပြေစေရန်အတွက် ကျွန်ုပ်တို့သည် Built-in Kubernetes လုပ်ဆောင်ချက်ကို ၎င်းကိုယ်တိုင်အသုံးပြုနိုင်ပါသည်။ ဆိုလိုသည်မှာ၊ အက်ပလီကေးရှင်းကိုဖွင့်နည်း၊ အလုပ်သမားတစ်ဦးကိုမည်သို့ဖွင့်ရပုံနှင့်ပတ်သက်သောမှော်အတတ်တစ်မျိုးမျိုးကိုမဖုံးကွယ်ပါနှင့်။ Kubernetes တွင်၊ သင်သည် အပလီကေးရှင်းကို Python ဖြင့်ရေးသားပါက အက်ပ်အတွင်း တောင်းဆိုချက်တစ်ခု ပေးပို့ပါ။

Kubernetes ကိုကျော်လွန်သွားပါက အလားတူပင်ဖြစ်သည်။ ကျွန်ုပ်တို့တွင် ကျွန်ုပ်တို့၏ Kubernetes သည် တစ်နေရာရာတွင် လည်ပတ်နေပါသည် - ၎င်းသည် cloud တစ်မျိုးမျိုးတွင်ရှိနေပါက ကောင်းပါသည်။ တစ်ဖန်၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့လည်ပတ်နေသည့်နေရာ၌ cloud ကိုယ်တိုင်၏စွမ်းဆောင်နိုင်ရည်များကို အသုံးပြုသင့်သည်ဟုပင် ကျွန်ုပ်ယုံကြည်ပါသည်။ Cloud က ကျွန်တော်တို့ကို ထောက်ပံ့ပေးတဲ့ အခြေခံအရာတွေပါ။ Balancing ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် cloud balancers ကို ဖန်တီးပြီး ၎င်းတို့ကို အသုံးပြုနိုင်သည်။ ဤသည်မှာ ကျွန်ုပ်တို့သုံးနိုင်သည့်အရာ၏ တိုက်ရိုက်အားသာချက်ဖြစ်သည်။ အဘယ်ကြောင့်ဆိုသော် cloud ချိန်ခွင်လျှာသည် ပထမဦးစွာ၊ ၎င်းသည် မည်သို့အလုပ်လုပ်ပုံ၊ မည်သို့ဖွဲ့စည်းပုံအတွက် ကျွန်ုပ်တို့ထံမှ တာဝန်ကို မိုက်မဲစွာ ဖယ်ရှားပေးသောကြောင့်ဖြစ်သည်။ ထို့အပြင် ပုံမှန် Kubernetes သည် cloud များနှင့် ပေါင်းစပ်နိုင်သောကြောင့် အလွန်အဆင်ပြေပါသည်။

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

ဒါပေမယ့် ကျွန်တော့် အတွေ့အကြုံအရတော့ ဒါဟာ ကျွန်တော် မြင်ဖူးသမျှထဲမှာ အမိုက်ဆုံးပါပဲ။ Cloudnative အစုအဝေးသည် နေ့၏အချိန်ပေါ်မူတည်၍ အတိုင်းအတာကို ချဲ့သောအခါ။ ၎င်းသည် ရုံးအနောက်ဘက်ရှိ လူများအသုံးပြုခဲ့သည့် နောက်ခံဝန်ဆောင်မှုတစ်ခုဖြစ်သည်။ ဆိုလိုသည်မှာ၊ ၎င်းတို့သည် နံနက် ၉ နာရီတွင် အလုပ်ဆင်းကြပြီး စနစ်ထဲသို့ ဝင်ရောက်ကြပြီး၊ အားလုံးလည်ပတ်နေသည့် Cloudnative အစုအဝေးသည် ဖောင်းလာပြီး အလုပ်လာသူတိုင်း အပလီကေးရှင်းဖြင့် အလုပ်လုပ်နိုင်စေရန် ဖြစ်သည်။ ၎င်းတို့သည် ည ၈ နာရီ သို့မဟုတ် ၆ နာရီတွင် အလုပ်မှထွက်ခွာသောအခါ၊ Kubernetes အစုအဖွဲ့များသည် အပလီကေးရှင်းကို မည်သူမျှအသုံးမပြုတော့ဘဲ ကျုံ့လာသည်ကို သတိပြုမိကြသည်။ စုဆောင်းငွေ 9 ရာခိုင်နှုန်းအထိ အာမခံပါသည်။ ၎င်းသည် ထိုအချိန်က Amazon တွင်အလုပ်လုပ်ခဲ့သည်၊ ထိုအချိန်က ရုရှားတွင် ဤမျှကောင်းမွန်စွာလုပ်ဆောင်နိုင်သူမရှိပါ။

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

မင်းရဲ့ အာရုံစိုက်မှုကို လိုချင်တဲ့ နောက်ဆုံးအချက်တစ်ခုရှိတယ်။ သင်၏ အက်ပ်လီကေးရှင်း၊ သင်၏အခြေခံအဆောက်အအုံသည် Cloudnative ဖြစ်စေရန်အတွက်၊ Infrastructure ဟုခေါ်သော ချဉ်းကပ်မှုပုံစံကို နောက်ဆုံးတွင် ကုဒ်တစ်ခုအဖြစ် လိုက်လျောညီထွေဖြစ်အောင် စတင်လိုက်ခြင်းသည် အဓိပ္ပာယ်ရှိပေသည်။ ဆိုလိုသည်မှာ သင်၏အပလီကေးရှင်း သို့မဟုတ် သင်၏အခြေခံအဆောက်အအုံသည် သင်၏ဖော်ပြပါကုဒ်နှင့် အတိအကျတူညီရန်လိုအပ်သည်ဟု ဆိုလိုသည်။ အပလီကေးရှင်း၊ ကုဒ်ပုံစံဖြင့် သင့်လုပ်ငန်းဆိုင်ရာ ယုတ္တိဗေဒ။ ကုဒ်အဖြစ်၎င်းနှင့်အလုပ်လုပ်သည်၊ ဆိုလိုသည်မှာ၎င်းကိုစမ်းသပ်ပါ၊ ၎င်းကိုထုတ်ပါ၊ git တွင်သိမ်းဆည်းပါ၊ ၎င်းတွင် CICD ကိုအသုံးပြုပါ။

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

ဤကိစ္စများအားလုံးကို အသေးစိတ် ဆွေးနွေးတင်ပြသွားပါမည်။ Kubernetes ဗီဒီယိုသင်တန်းများ- အငယ်တန်း၊ အခြေခံ၊ Mega. လင့်ခ်ကို လိုက်နာခြင်းဖြင့် ပရိုဂရမ်နှင့် အခြေအနေများကို သင်ကိုယ်တိုင် ရင်းနှီးနိုင်ပါသည်။ အဆင်ပြေသည့်အချက်မှာ သင်သည် အိမ်မှ စာကျက်ခြင်း သို့မဟုတ် တစ်နေ့လျှင် ၁ နာရီမှ ၂ နာရီအထိ အလုပ်ဖြင့် Kubernetes ကို ကျွမ်းကျင်ပိုင်နိုင်စွာ လုပ်နိုင်ခြင်းဖြစ်သည်။

source: www.habr.com