Kubernetes သည် ကမ္ဘာကို သိမ်းပိုက်မည်ဖြစ်သည်။ ဘယ်အချိန်မှာ ဘယ်လိုလဲ။

မျှော်လင့်ခြင်း၌ DevOpsConf Vitaly Khabarov တွေ့ဆုံမေးမြန်းခဲ့သည်။ Dmitry Stolyarov (ဒစ္စတို) နည်းပညာဒါရိုက်တာနှင့် Flant ကုမ္ပဏီကို ပူးတွဲတည်ထောင်သူ။ Vitaly သည် Flant လုပ်ဆောင်သည်များ၊ Kubernetes၊ ဂေဟစနစ်ဖွံ့ဖြိုးတိုးတက်မှု၊ ပံ့ပိုးမှုအကြောင်း Dmitry အား မေးမြန်းခဲ့သည်။ Kubernetes သည် အဘယ်ကြောင့် လိုအပ်သနည်း နှင့် ၎င်းသည် လုံးဝ လိုအပ်ခြင်း ရှိမရှိ ဆွေးနွေးခဲ့သည်။ microservices များအကြောင်း၊ Amazon AWS၊ DevOps အတွက် "ကံကောင်းမယ်" ချဉ်းကပ်မှု၊ Kubernetes ကိုယ်တိုင်က အနာဂတ်၊ ဘာကြောင့်၊ ဘယ်အချိန်၊ ဘယ်လို ကမ္ဘာကို သိမ်းပိုက်မလဲ၊ DevOps ရဲ့ အလားအလာနဲ့ အင်ဂျင်နီယာတွေ ကြိုတင်ပြင်ဆင်ထားသင့်တဲ့အရာတွေပါ။ ရိုးရှင်းမှုနှင့် အာရုံကြောကွန်ရက်များဖြင့် တောက်ပပြီး မဝေးတော့သောအနာဂတ်။

မူရင်းအင်တာဗျူး DevOps Deflop တွင် ပေါ့တ်ကာစ်တစ်ခုအနေဖြင့် နားထောင်ပါ - DevOps အကြောင်း ရုရှားဘာသာစကား ပေါ့တ်ကာစ်တစ်ခုဖြစ်ပြီး အောက်တွင် စာသားဗားရှင်းဖြစ်သည်။

ဒီမှာရော အောက်က မေးခွန်းတွေ မေးတယ်။ Vitaly Khabarov Express42 မှ အင်ဂျင်နီယာ။

"Flant" အကြောင်း

- မင်္ဂလာပါ Dima။ မင်းက နည်းစနစ်ဒါရိုက်တာပဲ"ဖယောင်းတိုင်"၎င်း၏တည်ထောင်သူလည်းဖြစ်သည်။ ကျေးဇူးပြုပြီး ကုမ္ပဏီက ဘာတွေလုပ်ဆောင်နေပြီး သင်က အဲဒီကုမ္ပဏီမှာ ရှိနေလဲဆိုတာကို ပြောပြပါ။

ကို Dmitry: အပြင်ဘက်မှ ကြည့်ရသည်မှာ ကျွန်ုပ်တို့သည် လူတိုင်းအတွက် Kubernetes ကို တပ်ဆင်ပြီး ၎င်းနှင့် တစ်စုံတစ်ခု လုပ်ဆောင်နေပုံရသည်။ ဒါပေမယ့် အဲဒါ မမှန်ပါဘူး။ ကျွန်ုပ်တို့သည် Linux နှင့် ပတ်သက်သည့် ကုမ္ပဏီတစ်ခုအနေဖြင့် စတင်ခဲ့သော်လည်း ကျွန်ုပ်တို့၏ အဓိကလုပ်ဆောင်ချက်သည် ထုတ်လုပ်မှုနှင့် ဝန်အားမြင့်မားသော turnkey ပရောဂျက်များကို ဆောင်ရွက်ပေးနေသည်မှာ အချိန်ကြာမြင့်နေပြီဖြစ်သည်။ အများအားဖြင့် ကျွန်ုပ်တို့သည် အခြေခံအဆောက်အအုံတစ်ခုလုံးကို အစမှအဆုံးတည်ဆောက်ပြီးနောက် ၎င်းကို အချိန်ကြာမြင့်စွာ တာဝန်ယူပါသည်။ ထို့ကြောင့်၊ "Flant" လုပ်သောအဓိကအလုပ်သည်ငွေရရှိသောအလုပ်ဖြစ်သည်။ တာဝန်ယူပြီး turnkey ထုတ်လုပ်မှုကို အကောင်အထည်ဖော်ပါ။.




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

Kubernetes အကြောင်း

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

ကို Dmitry: ကျွန်တော် ဒီအကြောင်းကို အကြိမ်ပေါင်းများစွာ ပြောပြီးပြီ၊ ဒါပေမယ့် ထပ်ခါတလဲလဲ ပြောဖို့ စိတ်မ၀င်စားပါဘူး။ အကြောင်းတရားနဲ့ အကျိုးတရားကြားမှာ ရှုပ်ထွေးမှုတွေ ရှိနေလို့ ဒီအကြောင်းအရာကို ထပ်ခါတလဲလဲ ပြောတာဟာ မှန်တယ်လို့ ထင်ပါတယ်။

ကျွန်တော်တို့ တကယ်လိုအပ်နေတဲ့ ကိရိယာတစ်ခုပါ။ ကျွန်ုပ်တို့သည် ပြဿနာများစွာကို ရင်ဆိုင်ခဲ့ရသည်၊ ရုန်းကန်ခဲ့ရသည်၊ ၎င်းတို့ကို ချိုင်းထောက်မျိုးစုံဖြင့် ကျော်ဖြတ်ကာ ကိရိယာတစ်ခု လိုအပ်နေသည်ဟု ခံစားခဲ့ရသည်။ ကျွန်ုပ်တို့သည် မတူညီသောရွေးချယ်စရာများစွာကိုဖြတ်သန်းခဲ့ပြီး ကျွန်ုပ်တို့၏ကိုယ်ပိုင်စက်ဘီးများကိုတည်ဆောက်ကာ အတွေ့အကြုံများရရှိခဲ့သည်။ 2013 ခုနှစ်ဝန်းကျင်တွင် Docker ကို စတင်အသုံးပြုလာသည်နှင့်တစ်ပြိုင်နက် ကျွန်ုပ်တို့သည် တဖြည်းဖြည်းနှင့် ကျွန်ုပ်တို့သည် Docker ကို စတင်အသုံးပြုသည့်နေရာသို့ ရောက်ရှိခဲ့သည်။ ၎င်း၏ပုံပန်းသဏ္ဍာန်တွင်၊ ကျွန်ုပ်တို့သည် ကွန်တိန်နာများနှင့်ပတ်သက်ပြီး အတွေ့အကြုံများစွာရှိထားပြီး၊ ကျွန်ုပ်တို့သည် "Docker" ၏ analogue တစ်ခု - Python ရှိ ကျွန်ုပ်တို့၏ကိုယ်ပိုင် ချိုင်းထောက်အချို့ကို ရေးသားထားပြီးဖြစ်သည်။ Docker ထွန်းကားလာသည်နှင့်အမျှ ချိုင်းထောက်များကို ပစ်ချကာ ယုံကြည်စိတ်ချရပြီး ရပ်ရွာလူထုက ပံ့ပိုးပေးသည့် ဖြေရှင်းချက်ကို အသုံးပြုလာနိုင်ခဲ့သည်။

Kubernetes နှင့် ဇာတ်လမ်းဆင်တူသည်။ အရှိန်ရလာသည်နှင့်အမျှ - ကျွန်ုပ်တို့အတွက် ဤဗားရှင်း 1.2 ဖြစ်သည် - ကျွန်ုပ်တို့ Docker နှင့် တစ်နည်းနည်းဖြင့် ကြိုးကိုင်ရန် ကြိုးစားခဲ့သည့် Shell နှင့် Chef နှစ်ခုလုံးတွင် ချိုင်းထောက်အမြောက်အမြား ရှိနှင့်ပြီးဖြစ်သည်။ ကျွန်ုပ်တို့သည် Rancher နှင့် အခြားဖြေရှင်းနည်းအမျိုးမျိုးကို အလေးအနက်ထား၍ ရှာဖွေနေသော်လည်း၊ ၎င်းတွင် အရာအားလုံးကို ကျွန်ုပ်တို့ပြုလုပ်ပြီး သို့မဟုတ် ပိုကောင်းသည့်အတိုင်း အတိအကျအကောင်အထည်ဖော်နိုင်သည့် Kubernetes ပေါ်လာသည်။ တိုင်ကြားစရာအကြောင်းမရှိပါ။

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

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

Kubernetes အကြောင်း

— သင် Kubernetes ကိုယ်တိုင် ဖွံ့ဖြိုးတိုးတက်မှုတွင် တိုက်ရိုက်ပါဝင်နေပါသလား။

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

— တစ်ချိန်တည်းတွင် သင်သည် Kubernetes ဝန်းကျင်တွင် သင်၏ကိရိယာများစွာကို တီထွင်နေပါသလား။

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

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

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

လမ်းကြောင်းသည် အမြဲလိုလို ဤအတိုင်းဖြစ်သည်- ကျွန်ုပ်တို့သည် အလွန်ဂရုတစိုက်ရှာဖွေပြီး ပေါင်မုန့်တစ်လုံးမှ တွန်းလှည်းတစ်စီးလုပ်နည်းအတွက် ဖြေရှင်းချက်တစ်စုံတစ်ရာမတွေ့ပါက၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ပေါင်မုန့်နှင့် ကျွန်ုပ်တို့၏ကိုယ်ပိုင် trolleybus တို့ကို ဖန်တီးပါသည်။

Flanta ကိရိယာများ

- ယခု Flant တွင် addon အော်ပရေတာများ၊ shell အော်ပရေတာများနှင့် dapp/werf ကိရိယာများ ရှိသည်ကို ကျွန်ုပ်သိပါသည်။ ကျွန်တော်နားလည်ထားသလိုပဲ၊ ဒါက မတူညီတဲ့ လူ့ဇာတိခံယူမှုမှာ တူရိယာတစ်ခုပါပဲ။ Flaunt ထဲမှာ နောက်ထပ် မတူညီတဲ့ ကိရိယာတွေ အများကြီး ရှိတယ်ဆိုတာကိုလည်း ကျွန်တော် နားလည်ပါတယ်။ ဒါအမှန်ပါပဲ?

ကို DmitryGitHub တွင် ကျွန်ုပ်တို့တွင် နောက်ထပ်များစွာရှိပါသည်။ ယခု ကျွန်တော်မှတ်မိသလောက်၊ ကျွန်ုပ်တို့တွင် လူတိုင်းနှစ်သက်သည့် Grafana အတွက် အကန့်တစ်ခုရှိသည်။ ၎င်းကို Medium တွင် Kubernetes စောင့်ကြည့်ခြင်းဆိုင်ရာ ဒုတိယဆောင်းပါးတိုင်းလိုလိုတွင် ဖော်ပြထားပါသည်။ Statusmap ဆိုသည်မှာ မည်သည်ကို အတိုချုံးရှင်းပြရန် မဖြစ်နိုင်ပါ - ၎င်းသည် သီးခြားဆောင်းပါးတစ်ခု လိုအပ်သော်လည်း၊ Kubernetes တွင် ကျွန်ုပ်တို့သည် အချိန်ကြာလာသည်နှင့်အမျှ အခြေအနေကို ပြသရန် လိုအပ်သောကြောင့် အချိန်နှင့်အမျှ အခြေအနေကို စောင့်ကြည့်ရန် အလွန်အသုံးဝင်သော အရာတစ်ခုဖြစ်သည်။ ကျွန်ုပ်တို့တွင်လည်း LogHouse ရှိသည် - ဤအရာသည် Kubernetes တွင် မှတ်တမ်းများစုဆောင်းရန်အတွက် ClickHouse နှင့် black magic ကိုအခြေခံသည့်အရာဖြစ်သည်။

အသုံးဝင်မှုများစွာ။ ထို့အပြင် ယခုနှစ်အတွင်း ပြည်တွင်းဖြေရှင်းချက်များစွာကို ထုတ်ပေးမည်ဖြစ်သောကြောင့် ပို၍ပင်ရှိပါလိမ့်မည်။ addon အော်ပရေတာအပေါ်အခြေခံသည့်အလွန်ကြီးမားသောအရာများတွင် Kubernetes အတွက် addons အများအပြားရှိသည်၊ ala သည် sert manager ကိုစနစ်တကျတပ်ဆင်နည်း - လက်မှတ်များကိုစီမံခန့်ခွဲရန်ကိရိယာ၊ ဆက်စပ်ပစ္စည်းများအမြောက်အများနှင့်အတူ Prometheus ကိုမှန်ကန်စွာတပ်ဆင်နည်း - ၎င်းတို့သည် XNUMX ခန့်ကွဲပြားသည် ဤ Prometheus တွင် ဒေတာများကို ထုတ်ယူပြီး တစ်ခုခုကို စုဆောင်းသည့် binaries တွင် အံ့သြဖွယ်အကောင်းဆုံး ဂရပ်ဖစ်နှင့် သတိပေးချက်များရှိသည်။ ဤအရာအားလုံးသည် အစုအဝေးတစ်ခုတွင် ထည့်သွင်းထားသည့် Kubernetes အတွက် addons အစုအဝေးမျှသာဖြစ်ပြီး၊ ၎င်းသည် ရိုးရှင်းသော၊ ဆန်းပြားသော၊ အလိုအလျောက်ပြောင်းလဲကာ ပြဿနာများစွာကို ဖြေရှင်းပြီးဖြစ်သည်။ ဟုတ်တယ်၊ ငါတို့အများကြီးလုပ်တယ်။

ဂေဟစနစ် ဖွံ့ဖြိုးတိုးတက်ရေး

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

ကို Dmitry: ရုရှားတွင်၊ ကျွန်ုပ်တို့၏စျေးကွက်တွင်လည်ပတ်နေသောကုမ္ပဏီများတွင်မည်သူမျှမရင်းနှီးပါ။. ဟုတ်ပါတယ်၊၊ ဒါက Mail နဲ့ Yandex တို့လို အဓိက ကစားသမားတွေ ရှိတယ်ဆိုတော့ သူတို့က Kubernetes နဲ့ တစ်ခုခုလုပ်နေတယ်၊ ​​ဒါပေမယ့် ငါတို့ထက် အများကြီးပိုတဲ့ ကမ္ဘာတဝှမ်းမှာရှိတဲ့ ကုမ္ပဏီတွေရဲ့ အလှူငွေကိုတောင် မနီးစပ်ဘူး။ လူ 80 ပါ ၀ င်သော Flan နှင့် Kubernetes တစ်ခုတည်းတွင်အင်ဂျင်နီယာ 300 ရှိသော Red Hat ကိုကျွန်ုပ်မမှားပါကနှိုင်းယှဉ်ရန်ခက်ခဲသည်။ နှိုင်းယှဉ်ရခက်ပါတယ်။ ကျွန်ုပ်တို့တွင် ကျွန်ုပ်အပါအဝင် RnD ဌာနတွင် လူ ၆ ဦးရှိပြီး ကျွန်ုပ်တို့၏ကိရိယာအားလုံးကို ဖြတ်တောက်ပေးပါသည်။ Red Hat အင်ဂျင်နီယာ ၃၀၀ နှင့် လူ ၆ ဦး နှိုင်းယှဉ်ရန် ခက်ခဲသည်။

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

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

အလုပ်ခေါင်းစဉ် DevOps အင်ဂျင်နီယာအကြောင်း အားလုံးနားလည်ပါတယ်၊ လူတိုင်းက အရာအားလုံးကို နားလည်ပြီး DevOps အင်ဂျင်နီယာတွေကို DevOps အင်ဂျင်နီယာတွေကို ခေါ်လေ့ရှိပါတယ်၊ ဒါကို ဆွေးနွေးမှာ မဟုတ်ပါဘူး။ ဤအံ့သြဖွယ်ကောင်းသော DevOps အင်ဂျင်နီယာ ၄၀ စလုံးသည် နေ့စဉ်ကြုံတွေ့နေရပြီး ပြဿနာများကို ဖြေရှင်းပေးသည်၊ ကျွန်ုပ်တို့သည် ဤအတွေ့အကြုံကို ခွဲခြမ်းစိတ်ဖြာပြီး ယေဘုယျလုပ်ဆောင်ရန် ကြိုးစားကြသည်။ ကျွန်ုပ်တို့အတွင်း၌ ကျန်ရှိနေပါက၊ တစ်နှစ် သို့မဟုတ် နှစ်နှစ်အတွင်းတွင် အဆိုပါကိရိယာသည် အသုံးမဝင်တော့ကြောင်း ကျွန်ုပ်တို့နားလည်ပါသည်။ အကြောင်းမှာ ရပ်ရွာအတွင်းရှိတစ်နေရာရာတွင် အဆင်သင့်လုပ်ထားသည့် Tula ပေါ်လာမည်ဖြစ်သည်။ ဤအတွေ့အကြုံကို အတွင်းပိုင်း၌ စုဆောင်းရာတွင် အဓိပ္ပါယ်မရှိပါ - ၎င်းသည် စွမ်းအင်နှင့် အချိန်ကို dev/null အဖြစ်သို့ ရိုးရှင်းစွာ စုပ်ယူလိုက်ပါသည်။ ပြီးတော့ ကျွန်တော်တို့ အဲဒါအတွက် လုံးဝ စိတ်မကောင်းပါဘူး။ ကျွန်ုပ်တို့သည် အရာအားလုံးကို ဝမ်းမြောက်ဝမ်းသာဖြင့် ထုတ်ဝေပြီး ၎င်းကို ထုတ်ဝေရန်၊ တီထွင်ရန်၊ မြှင့်တင်ရန်၊ မြှင့်တင်ရန် လိုအပ်ကြောင်း နားလည်သဘောပေါက်ကာ လူများက ၎င်းကို အသုံးပြုပြီး ၎င်းတို့၏ အတွေ့အကြုံကို ပေါင်းထည့်နိုင်စေရန် - ထို့နောက် အရာအားလုံး ကြီးထွားပြီး အသက်ဝင်စေပါသည်။ နှစ်နှစ်အကြာတွင် ကိရိယာသည် အမှိုက်ပုံးထဲသို့ မဝင်ပါ။ တစ်စုံတစ်ယောက်သည် သင့်ကိရိယာကို အသုံးပြုနေပြီး နှစ်နှစ်ကြာပြီးနောက် လူတိုင်းက ၎င်းကိုအသုံးပြုနေသည်မှာ ထင်ရှားသောကြောင့် ခွန်အားဆက်လက်ဖြည့်တင်းရန် သနားစရာမဟုတ်ပေ။

ဒါက dapp/werf နဲ့ ကျွန်တော်တို့ရဲ့ ကြီးမားတဲ့ဗျူဟာရဲ့ တစ်စိတ်တစ်ပိုင်းဖြစ်ပါတယ်။. အဲဒါကို စလုပ်တုန်းကတော့ လွန်ခဲ့တဲ့ ၃ နှစ်လောက်က ဖြစ်ပုံမပေါ်ဘူး။ အစပိုင်းမှာတော့ ယေဘူယျအားဖြင့် အခွံပေါ်မှာ ရှိခဲ့ပါတယ်။ ၎င်းသည် အယူအဆ၏ လွန်ကဲသော သက်သေဖြစ်သည်၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ သီးခြားပြဿနာအချို့ကို ဖြေရှင်းနိုင်သည် - ၎င်းသည် အလုပ်ဖြစ်ခဲ့သည်။ သို့သော် shell တွင်ပြဿနာများရှိသည်၊ ၎င်းကိုထပ်မံချဲ့ထွင်ရန်မဖြစ်နိုင်ပါ၊ shell ကို programming သည်အခြားအလုပ်ဖြစ်သည်။ ကျွန်ုပ်တို့သည် ပတ္တမြားတွင် စာရေးတတ်သည့် အလေ့အထရှိသောကြောင့်၊ ကျွန်ုပ်တို့သည် ပတ္တမြားတွင် တစ်ခုခုကို ပြန်လည်ဖန်တီး၍ တီထွင်၊ တီထွင်၊ တီထွင်ကာ “ငါတို့လိုချင်သည်ဖြစ်စေ မလိုချင်သည်ဖြစ်စေ မလိုချင်ဘူး” ဟူသော အသိုင်းအဝိုင်းထဲသို့ ပြေးဝင်လာခဲ့သည်။ ” Ruby ကို နှာခေါင်းကို လှည့်ကြည့်လိုက်တော့ ဘယ်လောက်ရယ်စရာကောင်းလဲ။ စစ်ဆေးရန်စာရင်းရှိ ပထမဆုံးအချက်ကို ပြည့်မီစေရန် ဤအရာအားလုံးကို Go တွင် ရေးသင့်သည်ကို ကျွန်ုပ်တို့ သဘောပေါက်ပါသည်။ DevOps ကိရိယာသည် static binary ဖြစ်သင့်သည်။. Go သို့မဟုတ် Not ဖြစ်ဖို့က သိပ်အရေးမကြီးပေမယ့် Go မှာရေးထားတဲ့ static binary က ပိုကောင်းပါတယ်။

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

dapp ကို ဘာကြောင့် ဖန်တီးခဲ့တာလဲ။

— dapp ကို ဘာကြောင့် ဖန်တီးထားသလဲ၊ ဘယ်လိုပြဿနာတွေကို ဖြေရှင်းပေးလဲဆိုတာ အတိုချုံးပြောပြနိုင်မလား။

ကို Dmitry: ပထမအကြောင်းရင်းက ပရိသတ်ထဲမှာ။ အစပိုင်းတွင်၊ Docker သည် multi-stage စွမ်းရည်များမရှိသောအခါတွင် ကျွန်ုပ်တို့သည် တည်ဆောက်မှုတွင် ကြီးမားသောပြဿနာများရှိခဲ့သောကြောင့် ကျွန်ုပ်တို့သည် multi-stage ကို ကျွန်ုပ်တို့ကိုယ်တိုင်ပြုလုပ်ခဲ့ပါသည်။ ထို့နောက် ပုံကို သန့်ရှင်းရေးလုပ်ရာတွင် ပြဿနာများစွာရှိသည်။ CI/CD လုပ်သူတိုင်းသည် စုဆောင်းထားသောပုံများ အစုအဝေးရှိနေသည့်အတွက် ပြဿနာနှင့်ရင်ဆိုင်ရပြီး မလိုအပ်သောအရာကို တစ်နည်းနည်းနဲ့ ရှင်းထုတ်ပြီး လိုအပ်တာတွေကို ချန်ထားရန် လိုအပ်ပါသည်။

ဒုတိယအကြောင်းရင်းမှာ တပ်ဖြန့်မှုဖြစ်သည်။ ဟုတ်တယ်၊ Helm ရှိတယ်၊ ဒါပေမယ့် ပြဿနာတချို့ကို ဖြေရှင်းပေးတယ်။ ရယ်စရာကောင်းလောက်အောင်၊ "Helm သည် Kubernetes အတွက် Package Manager" ဟုရေးသားထားသည်။ အတိအကျ "ဘာ" လဲ။ "Package Manager" ဟူသော စကားလုံးများလည်း ရှိသည် - Package Manager ထံမှ ပုံမှန်မျှော်လင့်ချက်ကား အဘယ်နည်း။ ကျွန်ုပ်တို့ပြောသည်မှာ- "Package Manager - အထုပ်ကို install လုပ်ပါ။" “အထုပ်ကို ပို့ပေးပြီးပြီ” လို့ သူပြောဖို့ မျှော်လင့်ပါတယ်။

ကျွန်ုပ်တို့ပြောသည်မှာ စိတ်ဝင်စားစရာကောင်းသည်- “ဦးမုံ၊ ပက်ကေ့ဂျ်ကို တပ်ဆင်ပါ” လို့ ပြန်ပြောတဲ့အခါ သူက တပ်ဆင်မှုကို စတင်လိုက်တာပါပဲ - သူက Kubernetes- “ဒီအရာကို စတင်လိုက်ပါ!” လို့ ညွှန်ပြပြီး စတင်သည်ဖြစ်စေ၊ မစတင်သည်ဖြစ်စေ အလုပ်မဖြစ်သည်ဖြစ်စေ Helm သည် ဤပြဿနာကို လုံးဝမဖြေရှင်းနိုင်ပါ။

Helm သည် Kubernetes ထဲသို့ ဒေတာများတင်သည့် စာသားကြိုပရိုဆက်ဆာတစ်ခုမျှသာဖြစ်ကြောင်း တွေ့ရှိရသည်။

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

အစီအစဉ်များ

ယခုနှစ်တွင် ဒေသဖွံ့ဖြိုးရေးကို စတင်မည်ဖြစ်သည်။ ကျွန်ုပ်တို့သည် Vagrant တွင် ယခင်ကရှိခဲ့သည့်အရာကို အောင်မြင်လိုသည် - ကျွန်ုပ်တို့သည် "vagrant up" ဟုရိုက်ပြီး virtual machines များကို အသုံးပြုခဲ့သည်။ ကျွန်ုပ်တို့သည် Git တွင် ပရောဂျက်တစ်ခုရှိနေသည့်နေရာသို့ ရောက်ချင်သည်၊ ကျွန်ုပ်တို့သည် ထိုနေရာတွင် “werf up” ဟုရေးပြီး ၎င်းသည် ဒေသဆိုင်ရာ မီနီ-Kub တွင် ဖြန့်ကျက်ထားသော၊ ဤပရောဂျက်၏ ဒေသန္တရမိတ္တူကို ယူဆောင်လာကာ ဖွံဖြိုးတိုးတက်မှုအတွက် ချိတ်ဆက်ရန် အဆင်ပြေသော လမ်းညွှန်အားလုံးနှင့်အတူ၊ . ဖွံ့ဖြိုးတိုးတက်မှုဘာသာစကားပေါ်မူတည်၍ ၎င်းကို ကွဲပြားစွာလုပ်ဆောင်သော်လည်း မည်သို့ပင်ဆိုစေကာမူ တပ်ဆင်ထားသောဖိုင်များအောက်တွင် ဒေသဆိုင်ရာဖွံ့ဖြိုးတိုးတက်မှုကို အဆင်ပြေစွာဆောင်ရွက်နိုင်ရန်။

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

သို့သော် dapp/werf သို့သွားရာလမ်းကြောင်းသည် အစပိုင်းတွင် Kubernetes နှင့် အမြဲတူသည်။ ကျွန်ုပ်တို့သည် ပြဿနာများကို ကြုံတွေ့ရပြီး ၎င်းတို့ကို ဖြေရှင်းနည်းများဖြင့် ဖြေရှင်းခဲ့သည် - ကျွန်ုပ်တို့သည် ခွံပေါ်တွင်၊ မည်သည့်အရာအတွက်မဆို ကျွန်ုပ်တို့အတွက် ဖြေရှင်းချက်အချို့ကို ရရှိခဲ့ပါသည်။ ထို့နောက် ၎င်းတို့သည် ဤဖြေရှင်းနည်းများကို တစ်နည်းတစ်ဖုံ တည့်မတ်စေရန်၊ ယေဘုယျအားဖြင့် ၎င်းတို့ကို ဤကိစ္စတွင် ကျွန်ုပ်တို့မျှဝေသည့် binaries များအဖြစ် စုစည်းရန် ကြိုးစားခဲ့သည်။

ဤဇာတ်လမ်းတစ်ခုလုံးကို ယှဉ်တွဲကြည့်ရန် အခြားနည်းလမ်းတစ်ခုရှိသည်။

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

werf ကိစ္စတွင်၊ ၎င်းသည် Kubernetes အတွက် အခြားအစိတ်အပိုင်းတစ်ခုဖြစ်သည်။ ဥပမာ werf ၏ alpha ဗားရှင်းတွင် ယခုသာလျှင် Helm ကို werf အတွင်းတွင် စုစည်းထားပြီး၊ ကျွန်ုပ်တို့ကိုယ်တိုင် လုပ်ဆောင်ရန် ငြီးငွေ့နေသောကြောင့် ဖြစ်သည်။ ဒီလိုလုပ်ရတဲ့ အကြောင်းရင်းများစွာရှိပါတယ်၊ ဘာကြောင့် werf ထဲမှာ ထွန်စက်နဲ့ ပဲ့တစ်ခုလုံးကို စုစည်းထားတာလဲဆိုတာ အသေးစိတ်ပြောပြပါ့မယ်။ RIT++ ၏ အစီရင်ခံစာတွင် ဖော်ပြထားသည်။.

ယခုအခါ werf သည် ပိုမိုပေါင်းစပ်ထားသော အစိတ်အပိုင်းတစ်ခုဖြစ်သည်။ ပြီးသွားသော စတီယာရင်ဘီး၊ စတီယာရင်ပင်ကို ရရှိသည် - ကားများအကြောင်း ကျွန်တော် သိပ်မသိသော်လည်း၊ ဤသည်မှာ ပြဿနာများစွာကို ဖြေရှင်းပေးပြီးသား ကြီးမားသော ဘလောက်တစ်ခုဖြစ်သည်။ ကျွန်ုပ်တို့သည် ကတ်တလောက်ကို ကိုယ်တိုင်သွားကြည့်ရန် မလိုအပ်ပါ၊ အခြားတစ်ခုအတွက် အစိတ်အပိုင်းတစ်ခုကို ရွေးချယ်ပါ၊ ၎င်းတို့ကို ပေါင်းစည်းနည်းကို စဉ်းစားပါ။ ကျွန်ုပ်တို့သည် ပြဿနာအများအပြားကို တစ်ပြိုင်နက်ဖြေရှင်းနိုင်သော အဆင်သင့်ပေါင်းစပ်မှုတစ်ခုကို ရရှိပါသည်။ သို့သော် အတွင်းတွင် ၎င်းကို တူညီသော open source အစိတ်အပိုင်းများမှ တည်ဆောက်ထားပြီး၊ ၎င်းသည် တပ်ဆင်မှုအတွက် Docker၊ လုပ်ဆောင်ချက်အချို့အတွက် Helm နှင့် အခြားစာကြည့်တိုက်များစွာရှိသေးသည်။ ၎င်းသည် CI/CD ကို သေတ္တာထဲမှ မြန်မြန်ဆန်ဆန် အေးမြစေရန်အတွက် ပေါင်းစပ်ကိရိယာတစ်ခုဖြစ်သည်။

Kubernetes ကို ထိန်းသိမ်းရန် ခက်ခဲပါသလား။

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

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

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

ကို Dmitry: ဒီလိုပါပဲ။

— ထုတ်လုပ်ရေးအဆင်သင့်ဖြစ်စေရန် Kubernetes ကို အစမှယူ၍ တပ်ဆင်ရန် မည်မျှခက်ခဲသနည်း။

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

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

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

" Kubernetes ကို ထိန်းသိမ်းရန် ခက်ခဲပါသလား" ဟူသော ပြဿနာ၏ အဓိပ္ပါယ်ကို ဖော်ပြနိုင်သည့် ဤအကြောင်းအရာနှင့် ပတ်သက်၍ မကြာသေးမီက ဥပမာတစ်ခု ရှိသည်။ ကျွန်ုပ်တို့သည် Kubernetes တွင် ကွန်ရက်တစ်ခုအဖြစ် Cilium ကို အကောင်အထည်ဖော်ရန် ကြိုးစားသင့်မသင့်ကို တစ်ချိန်က အလေးအနက် စဉ်းစားခဲ့သည်။

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

Linux kernel တွင် ip လမ်းကြောင်းတစ်ခု၊ overfilter တစ်ခု၊ တံတားများနှင့် သက်တမ်း 15၊ 20၊ 30 နှစ်များရှိသည့် မတူညီသော အစိတ်အပိုင်းများစွာရှိသည်။ ယေဘူယျအားဖြင့်၊ သူတို့အလုပ်လုပ်တယ်၊ အရာအားလုံးကကောင်းတယ်၊ ဒါပေမယ့် အခုက ကွန်တိန်နာတွေ စုပုံထားပြီး၊ တစ်ခုနဲ့တစ်ခုထိပ်မှာ အုတ် ၁၅ ခုပါတဲ့ မျှော်စင်တစ်ခုလိုဖြစ်ပြီး မင်းခြေထောက်တစ်ဖက်ပေါ်မှာ မတ်တပ်ရပ်နေတာဟာ ထူးဆန်းတဲ့ခံစားမှုတစ်ခုပါ။ ဤစနစ်သည် ခန္ဓာကိုယ်ရှိ အူအတက်ကဲ့သို့ ကွဲပြားမှုများဖြင့် သမိုင်းတွင် ဖွံ့ဖြိုးခဲ့သည်။ အချို့သော အခြေအနေများတွင် စွမ်းဆောင်ရည်ဆိုင်ရာ ပြဿနာများ ဥပမာ၊

အံ့သြဖွယ်ကောင်းသော BPF နှင့် kernel အတွက်ချိတ်များရေးနိုင်စွမ်းရှိသည် - ယောက်ျားများသည် kernel အတွက် ၎င်းတို့၏ကိုယ်ပိုင်ချိတ်များရေးကြသည်။ အထုပ်သည် Linux kernel ထဲသို့ရောက်လာသည်၊ ၎င်းတို့သည် input တွင်၎င်းကိုထုတ်လိုက်သည်၊ တံတားများမပါဘဲ၊ TCP မပါဘဲ၊ IP stack မပါဘဲဖြစ်သင့်သည် - အတိုချုပ်အားဖြင့်၊ Linux kernel တွင်ရေးထားသည့်အရာအားလုံးကိုကျော်ဖြတ်ပြီးတံတွေးထွေးသည် ကွန်တိန်နာထဲကို ထွက်လာတယ်။

ဘာဖြစ်တာလဲ? အလွန်မိုက်သောစွမ်းဆောင်ရည်၊ အေးမြသောအင်္ဂါရပ်များ - အေးမြသည်။ သို့သော် ကျွန်ုပ်တို့သည် ၎င်းကိုကြည့်ရှုပြီး စက်တစ်ခုစီတွင် Kubernetes API သို့ ချိတ်ဆက်သည့် ပရိုဂရမ်တစ်ခုရှိပြီး ဤ API မှရရှိသည့်ဒေတာအပေါ်အခြေခံ၍ C ကုဒ်ကိုထုတ်ပေးကာ kernel ထဲသို့ ၎င်းချိတ်များအလုပ်လုပ်စေရန် binary များကိုစုစည်းထားသည်ကိုတွေ့မြင်ရပါသည် kernel space ထဲမှာ။

တစ်ခုခု မှားသွားရင် ဘာဖြစ်မလဲ။ ငါတို့မသိဘူး။ ဒါကိုနားလည်ဖို့၊ ဒီကုဒ်အားလုံးကိုဖတ်ဖို့၊ ယုတ္တိဗေဒအားလုံးကို နားလည်ဖို့ လိုအပ်ပြီး ဘယ်လောက်ခက်ခဲတယ်ဆိုတာ အံ့သြစရာကောင်းပါတယ်။ သို့သော်၊ အခြားတစ်ဖက်တွင်၊ ဤတံတားများ၊ ပိုက်ကွန် filter များ၊ ip လမ်းကြောင်းများရှိသည် - ကျွန်ုပ်သည်၎င်းတို့၏အရင်းအမြစ်ကုဒ်ကိုမဖတ်ရသေးပါ၊ ကျွန်ုပ်တို့၏ကုမ္ပဏီတွင်အလုပ်လုပ်သောအင်ဂျင်နီယာ 40 လည်းမရှိပါ။ အချို့သော အပိုင်းများကို အနည်းငယ်သာ နားလည်နိုင်သည်။

ကွာခြားချက်ကဘာလဲ။ ip လမ်းကြောင်း၊ Linux kernel ရှိသည်၊ နှင့် tool အသစ်တစ်ခုရှိသည် - ၎င်းသည်မည်သို့ကွာခြားသနည်း၊ ကျွန်ုပ်တို့သည်တစ်ခုသို့မဟုတ်အခြားတစ်ခုကိုနားမလည်ပါ။ ဒါပေမယ့် အသစ်တစ်ခုခုကို သုံးရမှာကို ကြောက်ရွံ့နေတာ ဘာကြောင့်လဲ။ ကိရိယာက အသက် 30 ဆိုရင် နှစ် 30 မှာ bug တွေအကုန်တွေ့ပြီ၊ အမှားတွေအကုန်လုံးက တက်လာပြီး အရာရာတိုင်းကို သိဖို့မလိုပါဘူး - ၎င်းသည် black box ကဲ့သို့အလုပ်လုပ်ပြီး အမြဲတမ်းအလုပ်လုပ်ပါတယ်။ tcpdump သည် မည်သည့်အခိုက်အတန့်တွင်လည်ပတ်ရမည်ကို မည်သည့်ရောဂါရှာဖွေရေးဝက်အူလှည့်ကို လူတိုင်းသိသည်။ လူတိုင်းသည် Diagnostic utilities များကို ကောင်းစွာသိပြီး ဤအစိတ်အပိုင်းများသည် Linux kernel တွင် မည်သို့အလုပ်လုပ်သည်ကို နားလည်သည် - ၎င်းသည် မည်သို့အလုပ်လုပ်သည်ကိုမဟုတ်ဘဲ ၎င်းကိုအသုံးပြုနည်းကို နားလည်ပါသည်။

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

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

"ငါကံကောင်းလိမ့်မယ်" ချဉ်းကပ်မှုအကြောင်း

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

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

ငါ့မှာ Ubuntu 16.04 ရှိတယ်။ ၎င်းသည် ဗားရှင်းဟောင်းဖြစ်သည်ဟု သင်ပြောနိုင်သော်လည်း ၎င်းသည် LTS ဖြစ်သောကြောင့် ၎င်းကို ကျွန်ုပ်တို့ ဆက်လက်လုပ်ဆောင်နေပါသည်။ C-groups များကို မရှင်းလင်းခြင်း၏ ထူးခြားချက်မှာ systemd ရှိပါသည်။ Kubernetes သည် pods များကိုဖွင့်ပြီး C-groups များကိုဖန်တီးပြီးနောက် pods များကိုဖျက်လိုက်သည်နှင့် တစ်နည်းနည်းဖြင့် ထွက်လာသည် - အသေးစိတ်အချက်အလက်များကို ကျွန်ုပ်မမှတ်မိပါ၊ ဝမ်းနည်းပါသည် - ၎င်းစနစ်ဖြင့် အချပ်များကျန်ရှိနေပါသည်။ အချိန်ကြာလာသည်နှင့်အမျှ မည်သည့်ကားမဆို ပြင်းထန်စွာနှေးကွေးလာသည်ဟူသောအချက်ကို ဖြစ်ပေါ်စေသည်။ ဒါက highload နဲ့ ပတ်သက်တဲ့ မေးခွန်းတောင် မဟုတ်ဘူး။ အကယ်၍ အမြဲတမ်း pods များကိုဖွင့်ထားပါက၊ ဥပမာ၊ pods များကိုအဆက်မပြတ်ထုတ်ပေးသော Cron Job ရှိလျှင် Ubuntu 16.04 ပါသောစက်သည် တစ်ပတ်အကြာတွင် နှေးကွေးသွားလိမ့်မည်။ C-groups များစွာကို ဖန်တီးထားသောကြောင့် အဆက်မပြတ် မြင့်မားသော load ပျမ်းမျှရှိလိမ့်မည်။ ဤသည်မှာ Ubuntu 16 နှင့် Kubernetes ကို ရိုးရှင်းစွာ ထည့်သွင်းသူတိုင်း ကြုံတွေ့ရမည့် ပြဿနာဖြစ်သည်။

သူသည် systemd သို့မဟုတ် အခြားတစ်ခုခုကို update လုပ်သည်ဆိုပါစို့၊ သို့သော် Linux kernel တွင် 4.16 အထိ ရယ်စရာကောင်းသည် - သင် C-groups များကိုဖျက်လိုက်သောအခါ kernel တွင်ပေါက်ကြားပြီး အမှန်တကယ်မဖျက်ပါ။ ထို့ကြောင့် ဤစက်တွင် တစ်လကြာအလုပ်လုပ်ပြီးနောက်၊ မီးဖိုများအတွက် မှတ်ဉာဏ်စာရင်းဇယားများကို ကြည့်ရှုရန် မဖြစ်နိုင်တော့ပါ။ ကျွန်ုပ်တို့သည် ဖိုင်တစ်ဖိုင်ကိုထုတ်ကာ ပရိုဂရမ်တွင် လှိမ့်ကာ ဖိုင်တစ်ဖိုင်ကို 15 စက္ကန့်ကြာအောင် လှိမ့်လိုက်သည်၊ အဘယ်ကြောင့်ဆိုသော် Kernel သည် ဖျက်လိုက်ပုံပေါ်သော C-group တစ်သန်းကို သူ့အလိုလိုရေတွက်ရန် အချိန်ကြာမြင့်သောကြောင့်၊ .

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

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

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

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

— ကျွန်ုပ်၏အဆိုးမြင်သောအကဲဖြတ်မှုမှ၊ ၎င်းသည်ဤပုံသဏ္ဌာန်ဖြစ်သည်- အန္တရာယ်များမြင့်မားပြီး အက်ပ်လီကေးရှင်းအလုပ်လုပ်ရသည့်အခါ Flaunt မှပံ့ပိုးမှုလိုအပ်သည်၊ Red Hat မှဖြစ်ကောင်းဖြစ်နိုင်သည် သို့မဟုတ် သင်သည် အဆင်သင့်ဖြစ်သည့် Kubernetes အတွက်သီးသန့်လုပ်ဆောင်ထားသောသင်၏ကိုယ်ပိုင်အတွင်းပိုင်းအဖွဲ့ကိုလိုအပ်ပါသည်။ ထင်တာပဲ။

ကို Dmitry: ဓမ္မဓိဋ္ဌာန်ကျကျ၊ ဒါက ဒီလောက်ပါပဲ။ သင့်ကိုယ်ပိုင်အဖွဲ့ငယ်တစ်ခုအတွက် Kubernetes ဇာတ်လမ်းသို့ ဝင်ရောက်ခြင်းသည် အန္တရာယ်များစွာ ပါဝင်သည်။

ကွန်တိန်နာများ လိုအပ်ပါသလား။

— ရုရှားတွင် Kubernetes မည်မျှပျံ့နှံ့သည်ကို ပြောပြနိုင်ပါသလား။

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

ထို့နောက် နောက်ထပ်မေးခွန်းတစ်ခု - ကျွန်ုပ်တို့သည် ကွန်တိန်နာများ လိုအပ်ပါသလား။ ကျွန်ုပ်၏ကိုယ်ရေးကိုယ်တာခံစားချက်နှင့် Flan ကုမ္ပဏီ၏ အလုံးစုံရပ်တည်ချက်မှာ Kubernetes သည် ကိန်းဂဏန်းအမှန်တကယ်စံနှုန်းတစ်ခုဖြစ်သည်။

Kubernetes မှလွဲ၍ ဘာမှ ရှိမည်မဟုတ်ပါ။

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

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

- ဆိုလိုသည်မှာ Kubernetes သို့မပြောင်းရသေးသောကုမ္ပဏီများသည် ၎င်းသို့ပြောင်းမည် သို့မဟုတ် မေ့ပျောက်နေမည်ဖြစ်သည်။ ငါ မင်းကို မှန်မှန်ကန်ကန် နားလည်ခဲ့ရဲ့လား?

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

CI/CD နှင့်ပတ်သက်သည့်အရာအားလုံး - စဉ်ဆက်မပြတ် ပေးပို့မှုလိုအပ်သည့်နေရာတိုင်း၊ ဗားရှင်းများကို အပ်ဒိတ်လုပ်ရန် လိုအပ်သည့်နေရာတိုင်းတွင် အမှားအယွင်းများကို ခံနိုင်ရည်ရှိအောင် တည်ဆောက်ရန် လိုအပ်သည့်နေရာတိုင်းတွင် ဗားရှင်းများကို အပ်ဒိတ်လုပ်ရန်၊ တက်ကြွသောပြောင်းလဲမှုများ ပြုလုပ်ပါ - Kubernetes သာလျှင်ဖြစ်သည်။

မိုက်ခရိုဝန်ဆောင်မှုများအကြောင်း

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

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

ဥပမာအားဖြင့်၊ လူ 300 မှရေးသားထားသော monolith တစ်ခုရှိပြီး၊ ဖွံ့ဖြိုးတိုးတက်မှုတွင်ပါဝင်သူတိုင်းသည်ထိုနေရာတွင်ပြဿနာများရှိနေကြောင်းနားလည်သဘောပေါက်ပြီး၎င်းကို micro-pieces များအဖြစ်သို့ခွဲသင့်သည် - 10 အပိုင်းပိုင်းခန့်၊ တစ်ခုချင်းစီကိုလူ 30 မှရေးသားသည် အနည်းဆုံးဗားရှင်းတွင်။ ဒါက အရေးကြီးတယ်၊ လိုအပ်တယ်၊ အေးတယ်။ ဒါပေမယ့် အရမ်းမိုက်ပြီး ထက်မြက်တဲ့ ယောက်ျားလေး ၃ ယောက်က Corvalol ကို ရှာကြည့်တိုင်း သူတို့ရဲ့ ဒူးပေါ်မှာ microservices 3 ရေးတဲ့ startup တစ်ခုက ကျွန်တော်တို့ဆီ ရောက်လာတဲ့အခါ၊

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

ကနဦးမေးခွန်းအတွက်၊ တစ်ဖက်တွင် Kubernetes သည် မည်သည့်အရာက ကျိုးပေါက်သွားနိုင်သည် သို့မဟုတ် အလုပ်မဖြစ်သည်ကို ရှင်းရှင်းလင်းလင်းမသိရသေးသောကြောင့် တစ်ဖက်တွင် Kubernetes သည် အသုံးပြုရန် ကြောက်စရာကောင်းသည့်အချက်ကြားတွင် ကွဲလွဲမှုများရှိနေပါသည်။ Kubernetes မှလွဲ၍ မည်သည့်အရာမျှ ရှိမည်မဟုတ်ပါ။ ဖြေ - ရရှိလာသော အကျိုးအမြတ်ပမာဏ၊ သင်ဖြေရှင်းနိုင်သည့် အလုပ်ပမာဏကို ချိန်ဆပါ။. ဤသည်မှာ စကေး၏ တစ်ဖက်တွင် ဖြစ်သည်။ အခြားတစ်ဖက်တွင်၊ စက်ရပ်ချိန် သို့မဟုတ် တုံ့ပြန်မှုအချိန်ကျဆင်းခြင်း၊ ရရှိနိုင်မှုအဆင့် - စွမ်းဆောင်ရည်ညွှန်းကိန်းများ ကျဆင်းခြင်းနှင့် ဆက်စပ်အန္တရာယ်များရှိပါသည်။

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

Kubernetes သည် ရပ်မနေပါ။ ထပ်ပြီးမေးခွန်းထုတ်သည်- Kubernetes သည် တစ်ဖက်တွင် 4-5 binaries ဖြစ်ပြီး အခြားတစ်ဖက်တွင်၊ ၎င်းသည် ဂေဟစနစ်တစ်ခုလုံးဖြစ်သည်။ ဤသည်မှာ ကျွန်ုပ်တို့၏ စက်များတွင် ရှိသော လည်ပတ်မှုစနစ်ဖြစ်သည်။ ဒါဘာလဲ? Ubuntu သို့မဟုတ် Curios ? ၎င်းသည် Linux kernel၊ အပိုအစိတ်အပိုင်းများ အစုအဝေးဖြစ်သည်။ ဤအရာများအားလုံးကို ဤနေရာတွင် အဆိပ်ပြင်းသော မြွေတစ်ကောင်က လမ်းပေါ်မှ ပစ်ချလိုက်ပြီး ထိုနေရာတွင် ခြံစည်းရိုးတစ်ခု စိုက်ထူထားသည်။ Kubernetes သည် အလွန်လျင်မြန်ပြီး ဒိုင်းနမစ်ဖြင့် ဖွံ့ဖြိုးနေပြီး အန္တရာယ်များ၏ ပမာဏ၊ မသိနိုင်သော ပမာဏသည် လတိုင်း လျော့ကျနေပြီး၊ ထိုစကေးများသည် ပြန်လည်ချိန်ညှိလျက်ရှိသည်။

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

အကယ်၍ သင်သည် လူ 10 ယောက်ပါသော အဖွဲ့တစ်ဖွဲ့ကို လုပ်ငန်းလည်ပတ်ရန် အပ်နှံနိုင်သည့် အရွယ်အစားအထိ လုပ်ငန်းစတင်သည့် လုပ်ငန်းများနှင့် တည်ထောင်ထားသော လုပ်ငန်းများအတွက် Outsourcing လုပ်ရန် ပြင်းပြင်းထန်ထန် အကြံပြုလိုပါသည်။ ဒါကို outsource လုပ်ဖို့ သေချာပါတယ်။

Amazon နှင့် Google အကြောင်း

— Amazon သို့မဟုတ် Google မှဖြေရှင်းချက်တစ်ခုမှ host တစ်ခုကို outsource အဖြစ်သတ်မှတ်နိုင်ပါသလား။

ကို Dmitry: ဟုတ်ပါတယ်၊ ဒါက ပြဿနာအတော်များများကို ဖြေရှင်းပေးတယ်။ ဒါပေမယ့် ထပ်ပြီး ကွဲလွဲမှုတွေရှိပါတယ်။ အသုံးပြုနည်းကို သင်နားလည်ရန် လိုအပ်ပါသေးသည်။ ဥပမာအားဖြင့်၊ Amazon AWS ၏လုပ်ဆောင်မှုတွင် သေးငယ်သည့်အရာတစ်ထောင်ရှိသည်- Load Balancer ကို နွေးထွေးစေရန် လိုအပ်သည် သို့မဟုတ် "ယောက်ျားလေးတို့၊ ငါတို့အတွက် Load Balancer ကို နွေးထွေးအောင်လုပ်ပေးရမယ်" ဆိုတဲ့ တောင်းဆိုချက်ကို ကြိုတင်ရေးသားထားရပါမယ်။ ဒီ nuances တွေကို သိထားဖို့ လိုပါတယ်။

ဒါကို အထူးကျွမ်းကျင်တဲ့သူတွေဆီ လှည့်လိုက်တဲ့အခါ သာမန်အရာတွေအားလုံးနီးပါးကို ပိတ်ထားရပါတယ်။ အခု ကျွန်တော်တို့မှာ အင်ဂျင်နီယာ ၄၀ ရှိပြီး ဒီနှစ်ကုန်မှာ အယောက် ၆၀ လောက်ရှိမယ် - ဒါတွေအားလုံးကို ကျွန်တော်တို့ သေချာပေါက် ကြုံတွေ့ခဲ့ရပါတယ်။ အချို့သော ပရောဂျက်များတွင် ဤပြဿနာကို ထပ်မံကြုံတွေ့ရသော်လည်း၊ ကျွန်ုပ်တို့အချင်းချင်း အမြန်မေးပြီး ဖြေရှင်းနည်းကို သိပါသည်။

အဖြေဖြစ်နိုင်သည်- ဟုတ်ပါတယ်၊ လက်ခံထားသောဇာတ်လမ်းသည် အစိတ်အပိုင်းအချို့ကို ပိုမိုလွယ်ကူစေသည်။ မေးခွန်းမှာ ဤအိမ်ရှင်များကို ယုံကြည်ရန် အဆင်သင့်ဖြစ်မဖြစ်နှင့် ၎င်းတို့သည် သင့်ပြဿနာများကို ဖြေရှင်းပေးမည်လား။ Amazon နှင့် Google တို့သည် ကောင်းမွန်စွာ လုပ်ဆောင်ခဲ့သည်။ ကျွန်ုပ်တို့၏ကိစ္စများအားလုံးအတွက် - အတိအကျ။ ကျွန်ုပ်တို့တွင် အပြုသဘောဆောင်သော အတွေ့အကြုံများ မရှိတော့ပါ။ ကျွန်ုပ်တို့နှင့်အတူအလုပ်လုပ်ရန်ကြိုးစားခဲ့သည့်အခြားတိမ်တိုက်များအားလုံးသည် ပြဿနာများစွာကိုဖန်တီးသည် - Ager နှင့် ရုရှားနိုင်ငံရှိအရာအားလုံးနှင့် မတူညီသောအကောင်အထည်ဖော်မှုများတွင် OpenStack အမျိုးမျိုး- Headster၊ Overage - သင်လိုချင်သမျှ။ ၎င်းတို့အားလုံးသည် သင်မဖြေရှင်းလိုသော ပြဿနာများကို ဖန်တီးကြသည်။

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

Kubernetes ကို ဘယ်သူတွေ လိုအပ်လဲ။

— ထို့အပြင် Kubernetes ကို မည်သူ လိုအပ်သနည်း။ Kubernetes အတွက် သီးသန့်လာရောက်သည့် ပုံမှန် Flaunt client သည် မည်သူက Kubernetes သို့ ပြောင်းသင့်သနည်း။

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

ကျွန်ုပ်တို့၏ဖောက်သည်များသည် မတူညီသောအရာများကိုမျှော်လင့်ထားသော်လည်း လူတိုင်းသည် ၎င်းတို့တွင်အချို့သောပြဿနာများရှိသည့်အတွက် ကောင်းမွန်သောအံ့ဖွယ်အမှုများကို စောင့်မျှော်နေကြသည်၊ ယခု - ခုန်ကူးပါ။ - Kubernetes သည် ၎င်းတို့ကို ဖြေရှင်းပေးလိမ့်မည်။ လူတွေက အံ့ဖွယ်တွေကို ယုံကြည်ကြတယ်။ သူတို့စိတ်ထဲတွင် အံ့ဩစရာမရှိဟု နားလည်ကြသော်လည်း သူတို့၏စိတ်ထဲတွင် သူတို့မျှော်လင့်ထားသည် - ဤ Kubernetes သည် ယခု ကျွန်ုပ်တို့အတွက် အရာအားလုံးကို ဖြေရှင်းပေးမည်ဆိုပါက၊ သူတို့သည် ဤမျှလောက်ပြောနေကြသည် ။ ရုတ်​တရက်​ သူ အခု နှာ​ချေ ! - ငွေကျည်ဆံ နှာချေ! — ကျွန်ုပ်တို့တွင် 100% အလုပ်ဖွင့်ချိန် ရှိသည်၊ developer များအားလုံးသည် ထုတ်လုပ်မှုတွင် အကြိမ် 50 ရရှိသည့်အရာကို ထုတ်လွှတ်နိုင်ပြီး ၎င်းသည် ပျက်စီးခြင်းမရှိပါ။ ယေဘုယျအားဖြင့် အံ့ဖွယ်တစ်ပါး။

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

Kubernetes လိုအပ်သူများ၏မေးခွန်းကိုဖြေဆိုခြင်း - မည်သူမျှ Kubernetes မလိုအပ်ပါ။

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

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

ကျွန်ုပ်တို့ သို့မဟုတ် အခြားမည်သူမဆို Kubernetes လိုအပ်နေသည့်အသုံးအနှုန်းသည် မမှန်ပါ။

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

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

နောက်ဆုံးအဖြေမှာ - သင် Kubernetes မလိုအပ်ပါ။ သင့်ပြဿနာများကို သင်ဖြေရှင်းရန် လိုအပ်သည်။

သင်အောင်မြင်နိုင်သောအရာမှာ-

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

အမှန်တကယ် လိုအပ်ချက်များ နှစ်ခုရှိသည်- ယုံကြည်စိတ်ချရမှုနှင့် တက်ကြွမှု/ပြောင်းလွယ်ပြင်လွယ်မှု။ လက်ရှိ IT ပရောဂျက်မျိုးတွေကို လုပ်နေတဲ့သူတိုင်းဟာ ဘယ်လိုလုပ်ငန်းမျိုးမှာပဲဖြစ်ဖြစ်၊ ကမ္ဘာကြီးကို ဖြေလျှော့ပေးဖို့အတွက် ပျော့ပျောင်းတဲ့၊ ဒါကို နားလည်တဲ့သူတိုင်းဟာ ဒီလိုအပ်ချက်တွေကို ဖြေရှင်းဖို့ လိုအပ်ပါတယ်။ မှန်ကန်သောချဉ်းကပ်မှုဖြင့် Kubernetes၊ မှန်ကန်သောနားလည်မှုနှင့် လုံလောက်သောအတွေ့အကြုံရှိခြင်းဖြင့် ၎င်းတို့ကို သင်ဖြေရှင်းနိုင်မည်ဖြစ်သည်။

serverless အကြောင်း

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

ကို Dmitry: ဤနေရာတွင် ကျွန်ုပ်သည် ရှေ့ကိုမျှော်ကြည့်သော ပရောဖက်ပြုသူမဟုတ်ကြောင်း ထပ်မံ၍ မှတ်ချက်ပြုလိုပါသည်။ ဒါပေ မဲ့ ကျွန်တော်လည်း အတူတူပါပဲ။ ကျွန်ုပ်ခြေထောက်ကိုကြည့်ကာ၊ ဥပမာအားဖြင့်၊ ကွန်ပျူတာတွင် Transistor အလုပ်လုပ်ပုံ၊ ရယ်စရာပဲ မဟုတ်လား။ ကျွန်ုပ်တို့သည် CPU တွင် ချို့ယွင်းချက်အချို့ကို ကြုံတွေ့နေရသည်။

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

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

ဆာဗာမရှိသော တစ်လုံးတည်းဖြင့်- အရာသည် အေးဆေးဖြစ်သော်လည်း၊ ၎င်းသည် 2019 ၏ပြဿနာများနှင့်ဝေးသည်။ 2030 နီးလာလေလေ - အဲဒါကို ကြည့်ရအောင်။ ငါတို့အသက်ရှင်မယ်၊ ကျိန်းသေအသက်ရှင်မယ် (အိပ်ရာမဝင်ခင် ထပ်ခါတလဲလဲလုပ်ပါ) ဒါပေမယ့် အခုတော့ တခြားပြဿနာတွေကို ဖြေရှင်းဖို့ လိုအပ်နေပြီလေ။ ဒဏ္ဍာရီပုံပြင် pony Rainbow ကို ယုံကြည်သလိုပါပဲ။ ဟုတ်တယ်၊ ကိစ္စတချို့ရဲ့ ရာခိုင်နှုန်းတချို့ကို ဖြေရှင်းပြီး ပြီးပြည့်စုံစွာ ဖြေရှင်းနိုင်ပေမယ့် ပုဂ္ဂလဓိဋ္ဌာန်အရ ဆာဗာမဲ့ဟာ သက်တံတစ်ခုပါပဲ... ငါ့အတွက်ကတော့ ဒီအကြောင်းအရာဟာ ဝေးကွာလွန်းပြီး နားမလည်နိုင်လောက်အောင်ပါပဲ။ စကားပြောဖို့ အဆင်သင့်မဖြစ်သေးဘူး။ 2019 တွင်၊ serverless ဖြင့် application တစ်ခုတည်းကို ရေးသား၍မရပါ။

Kubernetes မည်ကဲ့သို့ ပြောင်းလဲလာမည်နည်း။

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

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

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

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

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

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

တစ်ချိန်က Urgant ကဲ့သို့ စိတ်ဝင်စားဖွယ်ကောင်းသော အစီအစဉ်တစ်ခုဖြစ်သည့် Saturday Night Live ရှိုးတွင် 80s မှ Isaac Asimov နှင့် YouTube တွင် Isaac Asimov နှင့် အင်တာဗျူးဟောင်းတစ်ခုကို နားထောင်ခဲ့ဖူးသည်။ ကွန်ပြူတာတွေရဲ့ အနာဂတ်အကြောင်း သူ့ကိုမေးတယ်။ အနာဂတ်သည် ရေဒီယိုကဲ့သို့ပင် ရိုးရှင်းသည်ဟု ၎င်းက ဆိုသည်။ ရေဒီယိုလက်ခံကိရိယာသည် မူလက ရှုပ်ထွေးသောအရာတစ်ခုဖြစ်သည်။ လှိုင်းတစ်ခုဖမ်းရန်အတွက် ခလုတ်များကို 15 မိနစ်ကြာလှန်ရမည်ဖြစ်ပြီး တံကျင်များကိုလှန်ကာ ယေဘုယျအားဖြင့် အရာအားလုံးမည်သို့အလုပ်လုပ်သည်ကို သိရန်၊ ရေဒီယိုလှိုင်းထုတ်လွှင့်ခြင်း၏ ရူပဗေဒကို နားလည်နိုင်သည်။ ထို့ကြောင့် ရေဒီယိုတွင် ခလုတ်တစ်ခုသာ ကျန်တော့သည်။

အခု 2019 မှာ ဘယ်ရေဒီယိုလဲ။ ကားထဲမှာ၊ ရေဒီယိုလက်ခံကိရိယာက လှိုင်းလုံးတွေနဲ့ ဘူတာတွေရဲ့ နာမည်တွေကို တွေ့တယ်။ လုပ်ငန်းစဉ်၏ ရူပဗေဒသည် နှစ်ပေါင်း 100 အတွင်း မပြောင်းလဲသေးသော်လည်း အသုံးပြုရလွယ်ကူသည်။ ယခုသာမက ယခုသာမက 1980 တွင် Azimov နှင့် အင်တာဗျူးရှိသောအခါတွင် လူတိုင်းသည် ရေဒီယိုကို အသုံးပြုကြပြီး ၎င်းသည် မည်သို့အလုပ်လုပ်သည်ကို မည်သူမျှ မစဉ်းစားခဲ့ကြပေ။ အမြဲတမ်းအလုပ်လုပ်တယ် - အဲဒါပေးထားတာ။

Azimov က ကွန်ပြူတာတွေနဲ့ အတူတူပဲလို့ ပြောခဲ့တယ်။ အသုံးပြုရလွယ်ကူလာမယ်။. 1980 မှာ ကွန်ပြူတာပေါ်က ခလုတ်တွေကို နှိပ်ဖို့ လေ့ကျင့်ခဲ့ရပေမယ့် နောင်မှာ ဒီလိုမျိုး ဖြစ်လာမှာ မဟုတ်ပါဘူး။

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

အင်ဂျင်နီယာတွေနဲ့ ဘာလုပ်ရမလဲ။

— Kubernetes ကို ပံ့ပိုးပေးသော အင်ဂျင်နီယာများနှင့် စနစ်စီမံခန့်ခွဲသူများသည် မည်သို့ဖြစ်မည်နည်း။

ကို Dmitry: 1C ထွန်းကားပြီးနောက် စာရင်းကိုင်က ဘာဖြစ်သွားတာလဲ။ အတူတူပါပဲ။ အရင်က သူတို့ဟာ စာရွက်ပေါ်မှာ ရေတွက်ခဲ့တယ် - အခု အစီအစဉ်မှာ။ ပမာဏ အမှာစာများဖြင့် လုပ်သားကုန်ထုတ်စွမ်းအား တိုးလာသော်လည်း လုပ်သားကိုယ်တိုင် ပျောက်ကွယ်သွားခြင်း မရှိပေ။ အရင်က မီးသီးတစ်လုံးမှာ အင်ဂျင်နီယာ ၁၀ ယောက်လောက် သွင်းထားရင် အခု တစ်လုံးလောက်တော့ ဖြစ်နေပြီ။

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

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

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

DevOps သို့မဟုတ် စနစ်များ အင်ဂျင်နီယာသည် ပျောက်ကွယ်သွားလိမ့်မည် မဟုတ်ပါ - အဆင့်မြင့် အလုပ်နှင့် စွမ်းဆောင်ရည် တိုးလာမည်။

- အလုပ်တကယ်တိုးလာမယ်ဆိုတာ စိတ်ဝင်စားစရာကောင်းတဲ့ အတွေးတစ်ခုလည်း ကြားခဲ့ရတယ်။

ကို Dmitry: ဟုတ်ပါတယ် ရာနှုန်းပြည့်။ ဘာကြောင့်လဲ ဆိုတော့ ကျွန်တော်တို့ ရေးတဲ့ ဆော့ဖ်ဝဲလ် ပမာဏဟာ အဆက်မပြတ် တိုးပွားနေတာကြောင့်ပါ။ ဆော့ဖ်ဝဲလ်ဖြင့် ကျွန်ုပ်တို့ဖြေရှင်းသည့် ပြဿနာအရေအတွက်သည် အဆက်မပြတ်ကြီးထွားနေပါသည်။ အလုပ်ပမာဏ များလာတယ်။ ယခု DevOps စျေးကွက်သည် အလွန်အမင်း အပူလွန်သွားသည်။ ဒါကို လစာမျှော်မှန်းချက်မှာ မြင်နိုင်ပါတယ်။ ကောင်းသောနည်းဖြင့်၊ အသေးစိတ်မလေ့လာဘဲ X လိုချင်သော အငယ်တန်းများ၊ 1,5X လိုချင်သော အလယ်တန်းများနှင့် 2X လိုချင်သော သက်ကြီးရွယ်အိုများ ရှိသင့်သည်။ ယခုဆိုလျှင်၊ Moscow DevOps လစာစျေးကွက်ကိုကြည့်လျှင် အငယ်တန်းတစ်ဦးသည် X မှ 3X နှင့် အကြီးတန်းမှ X မှ 3X လိုချင်သည်။

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

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

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

ကို Dmitry: ရာနှုန်းပြည့်။ ယေဘူယျအားဖြင့်၊ ကျွန်ုပ်တို့သည် 2019 တွင်နေထိုင်ကြပြီး ဘဝ၏စည်းကမ်းသည် ဤအရာဖြစ်သည်- lifetime learning - ကျွန်ုပ်တို့ ဘဝတစ်လျှောက်လုံး သင်ယူပါ။. ဒါကို အခု လူတိုင်းသိပြီး ခံစားရတယ်လို့ ကျွန်တော်ထင်ပါတယ်၊ ဒါပေမယ့် သိဖို့ မလုံလောက်သေးဘူး - မင်းလုပ်ရမယ်။ နေ့စဉ်နဲ့အမျှ ပြောင်းလဲရမယ်။ ဒါကို မလုပ်ရင် မကြာခင် ဒါမှမဟုတ် နောက်ပိုင်းမှာ ကျွန်တော်တို့ လုပ်ငန်းခွင်ဘေးမှာ ပစ်ချခံရလိမ့်မယ်။

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

ဆန္ဒနဲ့ တစ်မိနစ်ကြော်ငြာပါ။

- မင်းမှာ ဆန္ဒရှိလား။

ကို Dmitry: ဟုတ်တယ်၊ ငါ့မှာ ဆန္ဒများစွာရှိတယ်။

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

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

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

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

- ကျေးဇူးအများကြီးတင်ပါတယ်!

ကို Dmitry: Vitaly၊ အချိန်နဲ့ အင်တာဗျူးအတွက်ရော ကျေးဇူးတင်ပါတယ်။ ချစ်ခင်လေးစားရပါသော စာဖတ်သူများ၊ ဤအချက်ကို ရုတ်တရက် ရောက်ရှိလာပါက ကျေးဇူးအထူးတင်ရှိပါသည်။ ကျွန်ုပ်တို့သည် သင့်အား အနည်းဆုံး အကြံဥာဏ်အချို့ ယူဆောင်လာမည်ဟု မျှော်လင့်ပါသည်။

အင်တာဗျူးတွင်၊ Dmitry သည် werf ကိစ္စနှင့် ပတ်သက်၍ ဆွေးနွေးခဲ့သည်။ ယခု ဤသည်မှာ ပြဿနာအားလုံးနီးပါးကို ဖြေရှင်းပေးသည့် universal Swiss ဓားဖြစ်သည်။ ဒါပေမယ့် အမြဲတမ်းအဲဒီလိုမဟုတ်ဘူး။ ဂရန် DevOpsConf  ပွဲတော်မှာ RIT++ ဒီကိရိယာအကြောင်းကို Dmitry Stolyarov က အသေးစိတ်ပြောပြပါလိမ့်မယ်။ အစီရင်ခံစာထဲမှာ "werf သည် Kubernetes ရှိ CI/CD အတွက် ကျွန်ုပ်တို့၏ကိရိယာဖြစ်သည်" အရာအားလုံးရှိလိမ့်မည်- Kubernetes ၏ပြဿနာများနှင့်လျှို့ဝှက်ကွဲပြားမှုများ၊ ဤအခက်အခဲများကိုဖြေရှင်းရန်ရွေးချယ်မှုများနှင့် werf ၏လက်ရှိအကောင်အထည်ဖော်မှုကိုအသေးစိတ်။ မေလ 27 နှင့် 28 ရက်နေ့တွင်ကျွန်ုပ်တို့နှင့်ပူးပေါင်းပါ၊ ပြီးပြည့်စုံသောကိရိယာများကိုဖန်တီးပါမည်။

source: www.habr.com