GitLab.com ကို Kubernetes သို့ ပြောင်းရွှေ့ပြီး တစ်နှစ်အတွင်း ကျွန်ုပ်တို့၏ တွေ့ရှိချက်များ

မှတ်ချက်။ ဘာသာပြန်: GitLab တွင် Kubernetes မွေးစားခြင်းကို ကုမ္ပဏီ၏တိုးတက်မှုအတွက် အထောက်အကူဖြစ်စေသော အဓိကအကြောင်းရင်းနှစ်ခုထဲမှ တစ်ခုဟု ယူဆပါသည်။ သို့သော်လည်း မကြာသေးမီအထိ၊ GitLab.com အွန်လိုင်းဝန်ဆောင်မှု၏ အခြေခံအဆောက်အအုံကို virtual machines များပေါ်တွင် တည်ဆောက်ခဲ့ပြီး ပြီးခဲ့သောတစ်နှစ်ခန့်ကမှ K8s သို့ ပြောင်းရွှေ့ခြင်းစတင်ခဲ့ပြီး ယင်းသည် မပြီးပြတ်သေးပါ။ GitLab SRE အင်ဂျင်နီယာတစ်ဦးမှ မကြာသေးမီက ဆောင်းပါးတစ်ပုဒ်၏ ဘာသာပြန်ချက်ကို ကျွန်ုပ်တို့ ကျေနပ်စွာ တင်ဆက်လိုက်ရပါသည်။

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

GitLab.com ၏အစကတည်းက၊ ၎င်း၏ဆာဗာများသည် virtual machines များပေါ်တွင် cloud တွင်လည်ပတ်ခဲ့သည်။ ဤ virtual machines များကို Chef မှ စီမံခန့်ခွဲပြီး ကျွန်ုပ်တို့ကို အသုံးပြု၍ ထည့်သွင်းထားပါသည်။ တရားဝင် Linux အထုပ်. ဖြန့်ကျက်ဗျူဟာ အပလီကေးရှင်းကို အပ်ဒိတ်လုပ်ရန် လိုအပ်ပါက၊ CI ပိုက်လိုင်းကို အသုံးပြု၍ ပေါင်းစပ်ထားသော၊ ဆင့်ကဲပုံစံဖြင့် ဆာဗာတပ်စုကို ရိုးရှင်းစွာ အဆင့်မြှင့်တင်ခြင်း ပါဝင်သည်။ ဤနည်းလမ်း - အနည်းငယ်နှေးကွေးသော်လည်း၊ မှိုင်း - GitLab.com သည် အော့ဖ်လိုင်းအသုံးပြုသူများကဲ့သို့ တူညီသောတပ်ဆင်မှုနှင့် ဖွဲ့စည်းမှုပုံစံများကို အသုံးပြုကြောင်း သေချာစေပါသည်။ (ကိုယ်တိုင် စီမံခန့်ခွဲခြင်း) ဤအတွက် ကျွန်ုပ်တို့၏ Linux ပက်ကေ့ဂျ်များကို အသုံးပြု၍ GitLab တပ်ဆင်မှုများ။

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

Kubernetes နှင့် cloud-native GitLab သို့ ပထမဆုံးခြေလှမ်းများ

အဆိုပါပရောဂျက်ကို 2017 ခုနှစ်တွင်ဖန်တီးခဲ့သည်။ GitLab ဇယားများ cloud ဖြန့်ကျက်မှုအတွက် GitLab ကို ပြင်ဆင်ရန်နှင့် Kubernetes အစုအဝေးများတွင် GitLab ကို ထည့်သွင်းရန် အသုံးပြုသူများကို ဖွင့်ရန်။ GitLab ကို Kubernetes သို့ ရွှေ့ခြင်းသည် SaaS ပလပ်ဖောင်း၏ အရွယ်အစားကို တိုးမြင့်စေမည်ဖြစ်ပြီး၊ အသုံးချမှုများကို ရိုးရှင်းစေပြီး ကွန်ပျူတာအရင်းအမြစ်များ၏ စွမ်းဆောင်ရည်ကို မြှင့်တင်ပေးမည်ကို ကျွန်ုပ်တို့ သိရှိပါသည်။ တစ်ချိန်တည်းမှာပင်၊ ကျွန်ုပ်တို့၏အပလီကေးရှင်း၏လုပ်ဆောင်ချက်အများအပြားသည် virtual machines များမှအကူးအပြောင်းကိုနှေးကွေးစေသည့်တပ်ဆင်ထားသော NFS partitions များပေါ်တွင်မူတည်သည်။

cloud ဇာတိနှင့် Kubernetes ဆီသို့ တွန်းအားပေးခြင်းဖြင့် ကျွန်ုပ်တို့၏အင်ဂျင်နီယာများအား အသွင်ကူးပြောင်းမှုအစီအစဉ်ကို တဖြည်းဖြည်းချင်း စီစဉ်နိုင်စေခဲ့ပြီး ဝန်ဆောင်မှုအသစ်များကို ဆက်လက်လုပ်ဆောင်နေစဉ်တွင် ကွန်ရက်သိုလှောင်မှုအပေါ် အပလီကေးရှင်း၏မှီခိုမှုအချို့ကို စွန့်လွှတ်ခဲ့သည်။ 2019 ခုနှစ် နွေရာသီတွင် ရွှေ့ပြောင်းခြင်းအား ကျွန်ုပ်တို့ စတင်စီစဉ်ကတည်းက၊ ဤကန့်သတ်ချက်များ အများအပြားကို ဖြေရှင်းပြီးဖြစ်ပြီး၊ GitLab.com သို့ Kubernetes သို့ ပြောင်းရွှေ့ခြင်းလုပ်ငန်းစဉ်သည် ယခုအခါ ကောင်းမွန်စွာ လုပ်ဆောင်နေပြီဖြစ်သည်။

Kubernetes ရှိ GitLab.com ၏အင်္ဂါရပ်များ

GitLab.com အတွက်၊ ကျွန်ုပ်တို့သည် အပလီကေးရှင်းအသွားအလာအားလုံးကို ကိုင်တွယ်ပေးသည့် ဒေသဆိုင်ရာ GKE အစုအဝေးတစ်ခုတည်းကို အသုံးပြုပါသည်။ (ရှုပ်ထွေးပြီးသား) ရွှေ့ပြောင်းခြင်း၏ ရှုပ်ထွေးမှုကို လျှော့ချရန်၊ ကျွန်ုပ်တို့သည် ဒေသတွင်း သိုလှောင်မှု သို့မဟုတ် NFS ကို အားကိုးခြင်းမရှိသော ဝန်ဆောင်မှုများကို အာရုံစိုက်ပါသည်။ GitLab.com သည် အများအားဖြင့် monolithic Rails ကုဒ်ဘေ့စ်ကို အသုံးပြုပြီး ၎င်းတို့ကိုယ်ပိုင် node pool များအတွင်း သီးခြားခွဲထားသော မတူညီသော အဆုံးမှတ်များဆီသို့ အလုပ်ဝန်လက္ခဏာများပေါ်မူတည်၍ လမ်းကြောင်းအသွားအလာကို လမ်းကြောင်းပေးပါသည်။

Frontend ကိစ္စတွင်၊ ဤအမျိုးအစားများကို ဝဘ်၊ API၊ Git SSH/HTTPS နှင့် Registry သို့ တောင်းဆိုမှုများအဖြစ် ပိုင်းခြားထားသည်။ backend ၏အခြေအနေတွင်၊ ကျွန်ုပ်တို့သည် မတူညီသောဝိသေသလက္ခဏာများအလိုက် တန်းစီနေသောအလုပ်များကို ပိုင်းခြားထားသည်။ ကြိုတင်သတ်မှတ်ထားသော အရင်းအမြစ်နယ်နိမိတ်များအလုပ်တာဝန်အမျိုးမျိုးအတွက် Service-Level Objectives (SLOs) ကို သတ်မှတ်ခွင့်ပြုသည်။

ဤ GitLab.com ဝန်ဆောင်မှုများအားလုံးသည် မွမ်းမံထားသော GitLab Helm ဇယားကို အသုံးပြု၍ ပြင်ဆင်သတ်မှတ်ထားပါသည်။ ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုများကို အစုအဝေးသို့ ဖြည်းဖြည်းချင်း ပြောင်းရွှေ့ခြင်းဖြင့် ရွေးချယ်လုပ်ဆောင်နိုင်သောကြောင့် ဖွဲ့စည်းမှုပုံစံကို ဇယားကွက်ခွဲများတွင် လုပ်ဆောင်ပါသည်။ Redis၊ Postgres၊ GitLab Pages နှင့် Gitaly ကဲ့သို့သော ရွှေ့ပြောင်းနေထိုင်မှုတွင် ကျွန်ုပ်တို့၏နိုင်ငံပိုင်ဝန်ဆောင်မှုအချို့ကို မထည့်သွင်းရန် ကျွန်ုပ်တို့ ဆုံးဖြတ်ထားသော်လည်း Kubernetes ကိုအသုံးပြုခြင်းဖြင့် ကျွန်ုပ်တို့အား လက်ရှိစားဖိုမှူးစီမံခန့်ခွဲသည့် VM အရေအတွက်ကို သိသိသာသာလျှော့ချနိုင်စေပါသည်။

Kubernetes ဖွဲ့စည်းမှုမြင်နိုင်မှုနှင့် စီမံခန့်ခွဲမှု

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

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

• k8s-workloads/gitlab-com — GitLab Helm ဇယားအတွက် GitLab.com ဖွဲ့စည်းမှုဘောင်၊
• k8s-workloads/gitlab-helmfiles - GitLab အပလီကေးရှင်းနှင့် တိုက်ရိုက်မသက်ဆိုင်သော ဝန်ဆောင်မှုများအတွက် ဖွဲ့စည်းမှုပုံစံများ ပါရှိသည်။ ၎င်းတို့တွင် သစ်ခုတ်ခြင်းနှင့် အစုအဝေးစောင့်ကြည့်ခြင်းအတွက် ဖွဲ့စည်းမှုပုံစံများအပြင် PlantUML ကဲ့သို့ ပေါင်းစပ်ကိရိယာများ ပါဝင်သည်။
• Gitlab-com-အခြေခံအဆောက်အအုံ - Kubernetes နှင့် အမွေအနှစ် VM အခြေခံအဆောက်အဦအတွက် Terraform ဖွဲ့စည်းမှု။ ဤတွင် သင်သည် အစုအဝေးကိုလည်ပတ်ရန် လိုအပ်သောအရင်းအမြစ်များအားလုံးကို အစုအဝေးကိုယ်တိုင်၊ node pools၊ ဝန်ဆောင်မှုအကောင့်များနှင့် IP လိပ်စာကြိုတင်မှာယူမှုများအပါအဝင် အရင်းအမြစ်အားလုံးကို configure လုပ်ပါ။

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

SRE အတွက်၊ လင့်ခ်သည် အကန့်အသတ်ရှိသော ထုတ်လုပ်ခြင်းနှင့် အသုံးပြုခွင့်အတွက် အသုံးပြုသည့် GitLab တပ်ဆင်မှုတွင် အသေးစိတ်ကွဲပြားမှုကို ဦးတည်စေသည်။ ၎င်းသည် ဝန်ထမ်းများနှင့် အသိုက်အဝန်းအား လုပ်ငန်းလည်ပတ်မှုပရောဂျက် (SREs များအတွက်သာဖွင့်ထားသည့်) သို့ဝင်ရောက်ခွင့်မရှိဘဲ အဆိုပြုထားသောဖွဲ့စည်းပုံအပြောင်းအလဲများကိုကြည့်ရှုရန်ခွင့်ပြုသည်။ CI ပိုက်လိုင်းများအတွက် သီးသန့်ဥပမာတစ်ခုနှင့် ကုဒ်အတွက် အများသူငှာ GitLab instance ကို ပေါင်းစပ်ခြင်းဖြင့်၊ configuration updates များအတွက် GitLab.com မှ အမှီအခိုကင်းကြောင်း သေချာစေပြီး၊ ကျွန်ုပ်တို့သည် တစ်ခုတည်းသော အလုပ်အသွားအလာကို ထိန်းသိမ်းထားပါသည်။

ရွှေ့ပြောင်းနေထိုင်စဉ်အတွင်း ကျွန်ုပ်တို့ တွေ့ရှိခဲ့သမျှ

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

1. ရရှိနိုင်မှုဇုန်များကြားတွင် ယာဉ်ကြောပိတ်ဆို့မှုကြောင့် ကုန်ကျစရိတ်များ တိုးလာသည်။

Git သိုလှောင်ရေယာဉ်စုအတွက် GitLab.com ရှိ Git repository fleet အတွက် နေ့စဉ်ထွက်ပေါက်စာရင်းအင်းများ (တစ်နေ့လျှင် bytes)

Google သည် ၎င်း၏ကွန်ရက်ကို ဒေသများအဖြစ် ပိုင်းခြားထားသည်။ တစ်ဖန် ၎င်းတို့ကို သုံးစွဲနိုင်မှုဇုန်များ (AZ) ဟူ၍ ခွဲခြားထားသည်။ Git hosting သည် ဒေတာအမြောက်အမြားနှင့် ဆက်စပ်နေသောကြောင့် ကွန်ရက်မှ ထွက်ခွာမှုကို ထိန်းချုပ်ရန် အရေးကြီးပါသည်။ အတွင်းအသွားအလာအတွက်၊ တူညီသောရရှိနိုင်မှုဇုန်အတွင်းရှိနေပါက egress သည် အခမဲ့ဖြစ်သည်။ ဤရေးသားမှုအရ၊ ကျွန်ုပ်တို့သည် ပုံမှန်အလုပ်နေ့တွင် ဒေတာ 100 TB ခန့်ကို ဝန်ဆောင်မှုပေးနေသည် (၎င်းသည် Git repositories အတွက်သာဖြစ်သည်)။ ကျွန်ုပ်တို့၏ VM-based topology ဟောင်းရှိ တူညီသော virtual machines များတွင် နေထိုင်သည့် ဝန်ဆောင်မှုများသည် ယခု မတူညီသော Kubernetes pods များတွင် လုပ်ဆောင်နေပါသည်။ ဆိုလိုသည်မှာ VM သို့ယခင်ကပြည်တွင်းရှိအသွားအလာအချို့သည်ရရှိနိုင်မှုဇုန်များအပြင်ဘက်သို့သွားလာနိုင်သည်ဟုဆိုလိုသည်။

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

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

registry.gitlab.com တွင် ထုတ်လုပ်မှုလမ်းကြောင်းကို လုပ်ဆောင်နေသည့် ပုံတူအရေအတွက်။ ~ 15:00 UTC တွင် ယာဉ်အသွားအလာ အမြင့်ဆုံး။

ကျွန်ုပ်တို့၏ပထမဆုံးဝန်ဆောင်မှုဖြစ်သော GitLab ကွန်တိန်နာမှတ်ပုံတင်ခြင်းကို Kubernetes သို့ ပြောင်းရွှေ့သောအခါ ကျွန်ုပ်တို့၏ရွှေ့ပြောင်းခြင်းဇာတ်လမ်းသည် 2019 ခုနှစ် သြဂုတ်လတွင် စတင်ခဲ့သည်။ ဤမစ်ရှင်အရေးပါသော၊ အသွားအလာများသောဝန်ဆောင်မှုသည် နိုင်ငံမဲ့အပလီကေးရှင်းဖြစ်သောကြောင့် ပြင်ပမှီခိုမှုအနည်းငယ်ရှိသော နိုင်ငံမဲ့အက်ပလီကေးရှင်းဖြစ်သောကြောင့် ပထမဆုံးရွှေ့ပြောင်းခြင်းအတွက် ကောင်းသောရွေးချယ်မှုဖြစ်သည်။ ကျွန်ုပ်တို့ ပထမဆုံးကြုံတွေ့ရသည့် ပြဿနာမှာ node များတွင် memory မရှိခြင်းကြောင့် နှင်ထုတ်ခံရသော pods အများအပြားဖြစ်သည်။ ထို့အတွက်ကြောင့် ကျွန်ုပ်တို့သည် တောင်းဆိုမှုများနှင့် ကန့်သတ်ချက်များကို ပြောင်းလဲခဲ့ရသည်။

အချိန်ကြာလာသည်နှင့်အမျှ မှတ်ဉာဏ်သုံးစွဲမှု တိုးလာနေသည့် အက်ပလီကေးရှင်းတစ်ခုတွင်၊ အသုံးပြုမှုအပေါ် "ရက်ရောသော" ခက်ခဲသောကန့်သတ်ချက်ဖြင့် တွဲလျက် တောင်းဆိုမှုများအတွက် တန်ဖိုးများ (pod တစ်ခုစီအတွက် မှတ်ဉာဏ်ကို သိမ်းဆည်းခြင်း) နည်းပါးသည်ကို ရှာဖွေတွေ့ရှိခဲ့သည်။ (ရွှဲ) nodes များနှင့် နှင်ထုတ်ခြင်း အဆင့်မြင့်မားသည်။ ဒီပြဿနာကို ဖြေရှင်းဖို့၊ တောင်းဆိုမှုများကို တိုးမြှင့်ရန်နှင့် ကန့်သတ်ချက်များကို လျှော့ချရန် ဆုံးဖြတ်ခဲ့သည်။. ၎င်းသည် node များပေါ်မှ ဖိအားများကို ဖယ်ထုတ်ပြီး pods များတွင် node တွင် ဖိအားအလွန်အကျွံမဖြစ်စေသော lifecycle ရှိကြောင်းသေချာစေသည်။ ယခု ကျွန်ုပ်တို့သည် ရက်ရောသော (တူညီလုနီးပါး) တောင်းဆိုချက်နှင့် ကန့်သတ်တန်ဖိုးများဖြင့် ရွှေ့ပြောင်းခြင်းကို စတင်ပြီး ၎င်းတို့ကို လိုအပ်သလို ချိန်ညှိပါ။

3. မက်ထရစ်များနှင့် မှတ်တမ်းများ

အခြေခံအဆောက်အဦဌာနခွဲသည် တပ်ဆင်ထားသည့်အချိန်၊ အမှားအယွင်းနှုန်းများနှင့် ရွှဲရွှဲစိုစွတ်မှုအပေါ် အာရုံစိုက်သည်။ ဝန်ဆောင်မှုအဆင့် ရည်မှန်းချက်များ (SLO) မှ ချိတ်ဆက်ထားသည်။ ကျွန်ုပ်တို့၏စနစ်၏အထွေထွေရရှိနိုင်မှု.

ပြီးခဲ့သောနှစ်တွင်၊ အခြေခံအဆောက်အအုံဌာနခွဲရှိ အဓိကဖြစ်ရပ်များထဲမှတစ်ခုမှာ SLO များစောင့်ကြည့်ခြင်းနှင့် လက်တွဲလုပ်ဆောင်ခြင်းတွင် တိုးတက်မှုများဖြစ်သည်။ SLO များသည် ပြောင်းရွှေ့မှုအတွင်း ကျွန်ုပ်တို့အနီးကပ်စောင့်ကြည့်ခဲ့သည့် တစ်ဦးချင်းဝန်ဆောင်မှုများအတွက် ပန်းတိုင်များချမှတ်နိုင်စေခဲ့သည်။ သို့သော် ဤတိုးတက်လာသော ရှုမြင်နိုင်စွမ်းဖြင့်ပင်၊ မက်ထရစ်များနှင့် သတိပေးချက်များကို အသုံးပြု၍ ပြဿနာများကို ချက်ခြင်းမြင်ရန် အမြဲတမ်းမဖြစ်နိုင်ပါ။ ဥပမာအားဖြင့်၊ ကြာမြင့်ချိန်နှင့် အမှားအယွင်းနှုန်းများကို အာရုံစိုက်ခြင်းဖြင့်၊ ရွှေ့ပြောင်းခြင်းလုပ်ဆောင်နေသည့် ဝန်ဆောင်မှုအတွက် အသုံးပြုမှုကိစ္စအားလုံးကို ကျွန်ုပ်တို့ အပြည့်အဝ အကျုံးမဝင်ပါ။

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

တူညီသောတောင်းဆိုမှုများကို VM အခြေခံအဆောက်အအုံဟောင်းနှင့် Kubernetes အခြေပြုအခြေခံအဆောက်အအုံအသစ်တွင် ပြိုင်တူဆောင်ရွက်ပေးခြင်းသည် ထူးခြားသောစိန်ခေါ်မှုကိုတင်ပြသည်။ lift-and-shift ရွှေ့ပြောင်းခြင်းနှင့် မတူပါ။ (အပလီကေးရှင်းများကို အခြေခံအဆောက်အအုံအသစ်တစ်ခုသို့ “အတိုင်း” အမြန်လွှဲပြောင်းခြင်း၊ အသေးစိတ်အချက်အလက်များကို ဖတ်ရှုနိုင်သည် ဥပမာ၊ ဒီမှာ - ခန့်မှန်းခြေ ဘာသာပြန်။)"အဟောင်း" VM နှင့် Kubernetes တွင် အပြိုင်လုပ်ဆောင်ခြင်းသည် စောင့်ကြည့်ရေးကိရိယာများသည် ပတ်ဝန်းကျင်နှစ်ခုလုံးနှင့် တွဲဖက်အသုံးပြုနိုင်ပြီး မက်ထရစ်များကို မြင်ကွင်းတစ်ခုတည်းအဖြစ် ပေါင်းစပ်နိုင်ရန်လိုအပ်ပါသည်။ အကူးအပြောင်းကာလအတွင်း တသမတ်တည်းကြည့်ရှုနိုင်မှုရရှိရန် တူညီသော ဒက်ရှ်ဘုတ်များနှင့် မှတ်တမ်းမေးခွန်းများကို အသုံးပြုရန် အရေးကြီးပါသည်။

4. ယာဉ်အသွားအလာကို အစုအဝေးအသစ်သို့ ပြောင်းခြင်း။

GitLab.com အတွက်၊ ဆာဗာများ၏ တစ်စိတ်တစ်ပိုင်းကို ရည်ရွယ်ပါသည်။ ကိန္နရီအဆင့်. Canary Park သည် ကျွန်ုပ်တို့၏ အတွင်းပိုင်း ပရောဂျက်များကို ဆောင်ရွက်ပေးပြီး လုပ်ဆောင်နိုင်သည်။ အသုံးပြုသူများမှဖွင့်ထားသည်။. သို့သော် အခြေခံအဆောက်အအုံနှင့် အက်ပ်လီကေးရှင်းတွင် ပြုလုပ်ထားသော အပြောင်းအလဲများကို စမ်းသပ်ရန် အဓိက ဒီဇိုင်းထုတ်ထားသည်။ အကန့်အသတ်ရှိသော အတွင်းအသွားအလာပမာဏကို လက်ခံခြင်းဖြင့် ပထမဆုံး ရွှေ့ပြောင်းခြင်းဝန်ဆောင်မှုကို စတင်ခဲ့ပြီး SLO များကို လမ်းကြောင်းအားလုံးကို အစုအဝေးသို့ မပို့မီ သေချာစေရန် ဤနည်းလမ်းကို ကျွန်ုပ်တို့ ဆက်လက်အသုံးပြုပါသည်။

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

5. အစေ့များ၏ စွမ်းဆောင်ရည်နှင့် ၎င်းတို့၏ အသုံးပြုမှုကို သိမ်းဆည်းပါ။

ချက်ချင်းဆိုသလိုပင် အောက်ပါပြဿနာကို ဖော်ထုတ်တွေ့ရှိခဲ့သည်- Registry ဝန်ဆောင်မှုအတွက် pods များသည် လျင်မြန်စွာစတင်ခဲ့ပြီး၊ သို့သော် Sidekiq အတွက် စတင်သည့် pods များသည် အချိန်ကြာမြင့်ခဲ့သည်။ နှစ်မိနစ်. Sidekiq pods များအတွက် ကြာမြင့်သော စတင်ချိန်သည် အလုပ်အကိုင်များကို လျင်မြန်စွာ စီမံဆောင်ရွက်ပေးရန် လိုအပ်သော အလုပ်သမားများအတွက် Kubernetes သို့ အလုပ်များစတင်ပြောင်းရွှေ့သောအခါ ပြဿနာဖြစ်လာပါသည်။

ဤကိစ္စတွင်၊ သင်ခန်းစာမှာ Kubernetes ၏ Horizontal Pod Autoscaler (HPA) သည် ယာဉ်အသွားအလာတိုးတက်မှုကို ကောင်းမွန်စွာကိုင်တွယ်နိုင်သော်လည်း၊ အလုပ်ဝန်များ၏ဝိသေသလက္ခဏာများကို ထည့်သွင်းစဉ်းစားရန်နှင့် pods များသို့ အားလပ်ချိန်ပမာဏကို ခွဲဝေသတ်မှတ်ရန် အရေးကြီးသည်မှာ (အထူးသဖြင့် ဝယ်လိုအား မညီမညာဖြစ်နေသောအခါ)။ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ အလုပ်များရုတ်တရက်မြင့်တက်လာပြီး လျင်မြန်သောစကေးချဲ့ခြင်းကိုဖြစ်ပေါ်စေပြီး node pool ကိုစကေးချိန်မရမီတွင် CPU ရင်းမြစ်များ ရွှဲလာစေသည်။

အစုအဖွဲ့တစ်ခုမှ တတ်နိုင်သမျှ ညှစ်ထုတ်ရန် သွေးဆောင်မှု အမြဲရှိနေသည်၊ သို့သော် အစပိုင်းတွင် စွမ်းဆောင်ရည် ပြဿနာများ ကြုံတွေ့ခဲ့ရပြီး ယခုအခါ ကျွန်ုပ်တို့သည် ရက်ရောသော ဘတ်ဂျက်ဖြင့် စတင်ကာ နောက်ပိုင်းတွင် ၎င်းကို လျှော့ချကာ SLO များကို အနီးကပ် စောင့်ကြည့်နေပါသည်။ Sidekiq ဝန်ဆောင်မှုအတွက် စတင်အသုံးပြုသည့် pods များသည် သိသိသာသာ အရှိန်မြှင့်ခဲ့ပြီး ယခုအခါ ပျမ်းမျှ စက္ကန့် 40 ခန့် ကြာပါသည်။ pods များ၏ပစ်လွှတ်ချိန်ကိုလျှော့ချမှ GitLab.com နှင့်တရားဝင် GitLab Helm ဇယားဖြင့်လုပ်ဆောင်သော ကျွန်ုပ်တို့၏အသုံးပြုသူများသည် ကိုယ်တိုင်စီမံခန့်ခွဲသည့်တပ်ဆင်မှုများကို ရရှိခဲ့သည်။

ကောက်ချက်

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

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

• «ကျွန်ုပ်တို့သည် Kubernetes သို့ အဘယ်ကြောင့် ပြောင်းရွှေ့နေကြသနည်း။";
• «Kubernetes တွင် GitLab.com";
• GitLab.com ကို Kubernetes သို့ ပြောင်းရွှေ့ခြင်းဆိုင်ရာ Epic.

PS ဘာသာပြန်မှ

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

• «Kubernetes ဖြင့် ၃ နှစ်ကြာ ထုတ်လုပ်ခဲ့သည်- ဤသည်မှာ ကျွန်ုပ်တို့ နားလည်ပါသည်။";
• «အဖြစ်များသော Kubernetes အမှား ၁၀ ခု";
• «Kubernetes ထုတ်လုပ်ရေးတွင် အောင်မြင်မှုဇာတ်လမ်းများ။ အပိုင်း 3- GitHub";
• «Tinder သည် Kubernetes သို့ ကူးပြောင်းခြင်း။"။

source: www.habr.com