Tinder သည် Kubernetes သို့ ကူးပြောင်းခြင်း။

မှတ်ချက်။ ဘာသာပြန်- ကမ္ဘာကျော် Tinder ဝန်ဆောင်မှုမှ ဝန်ထမ်းများသည် ၎င်းတို့၏ အခြေခံအဆောက်အဦများကို Kubernetes သို့ ပြောင်းရွှေ့ခြင်းဆိုင်ရာ နည်းပညာအသေးစိတ်အချို့ကို မကြာသေးမီက မျှဝေခဲ့သည်။ လုပ်ငန်းစဉ်သည် နှစ်နှစ်နီးပါးကြာခဲ့ပြီး K8s တွင် ကွန်တိန်နာ ၄၈ဝဝဝ တွင် ဝန်ဆောင်မှု ၂၀၀ ပါ၀င်သော အလွန်ကြီးမားသော ပလပ်ဖောင်းတစ်ခုကို စတင်နိုင်ခဲ့သည်။ Tinder အင်ဂျင်နီယာများသည် မည်သည့်စိတ်ဝင်စားဖွယ်အခက်အခဲများကို ကြုံတွေ့ခဲ့ရပြီး မည်သည့်ရလဒ်များ ရရှိလာသနည်း။ ဤဘာသာပြန်ကို ဖတ်ရှုပါ။

အဘယ်ကြောင့်နည်း

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

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

လုပ်ငန်းစဉ်သည် ခက်ခဲလာပါသည်။ 2019 ခုနှစ်အစောပိုင်းတွင် ကျွန်ုပ်တို့၏ပြောင်းရွှေ့မှုအတွင်း၊ Kubernetes အစုအဝေးသည် အရေးကြီးသောအစုအဝေးသို့ရောက်ရှိခဲ့ပြီး ယာဉ်အသွားအလာပမာဏ၊ အစုအဝေးအရွယ်အစားနှင့် DNS ကြောင့် ပြဿနာအမျိုးမျိုးကို စတင်ကြုံတွေ့လာရသည်။ လမ်းတစ်လျှောက်တွင်၊ ဝန်ဆောင်မှု 200 ကို ရွှေ့ပြောင်းခြင်းနှင့် 1000 node၊ 15000 pods နှင့် 48000 run containers ပါ၀င်သော Kubernetes အစုအဝေးကို ထိန်းသိမ်းခြင်းနှင့် ပတ်သက်သည့် စိတ်ဝင်စားဖွယ်ပြဿနာများစွာကို ကျွန်ုပ်တို့ ဖြေရှင်းခဲ့သည်။

ဘယ်လိုနေသလဲ?

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

Kubernetes အတွက် ပုံများတည်ဆောက်ခြင်း။

Kubernetes အစုအဝေးတွင် လုပ်ဆောင်နေသော မိုက်ခရိုဝန်ဆောင်မှုများအတွက် ရင်းမြစ်ကုဒ် သိုလှောင်ရုံ 30 ကျော်ရှိသည်။ ဤသိုလှောင်ရာနေရာများရှိ ကုဒ်ကို ဘာသာစကားတစ်ခုတည်းအတွက် လုပ်ဆောင်ချိန်ပတ်ဝန်းကျင်များစွာဖြင့် မတူညီသောဘာသာစကားများ (ဥပမာ၊ Node.js၊ Java၊ Scala၊ Go) ဖြင့် ရေးသားထားသည်။

တည်ဆောက်မှုစနစ်သည် မိုက်ခရိုဝန်ဆောင်မှုတစ်ခုစီအတွက် အပြည့်အဝစိတ်ကြိုက်ပြင်ဆင်နိုင်သော “Build context” ကို ပေးဆောင်ရန် ဒီဇိုင်းထုတ်ထားသည်။ ၎င်းတွင် အများအားဖြင့် Dockerfile နှင့် shell commands များပါဝင်ပါသည်။ ၎င်းတို့၏ အကြောင်းအရာကို လုံး၀ စိတ်ကြိုက်ပြင်ဆင်နိုင်ပြီး တစ်ချိန်တည်းတွင် ဤတည်ဆောက်မှုဆိုင်ရာ အကြောင်းအရာများအားလုံးကို စံချိန်စံညွှန်းပုံစံဖြင့် ရေးသားထားသည်။ တည်ဆောက်မှုအခြေအနေများကို စံသတ်မှတ်ခြင်းသည် တစ်ခုတည်းသောတည်ဆောက်မှုစနစ်တစ်ခုသည် အသေးစားဝန်ဆောင်မှုအားလုံးကို ကိုင်တွယ်နိုင်စေပါသည်။

ပုံ ၁-၁။ Builder container မှတဆင့် Standardized build process

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

၎င်း၏ကွန်တိန်နာအကောင်အထည်ဖော်မှုအဆင့်မြင့် Docker နည်းပညာများလိုအပ်သည်။ Builder သည် သီးသန့် Tinder သိုလှောင်ရာနေရာများသို့ ဝင်ရောက်ရန် လိုအပ်သော SSH သော့၊ AWS အထောက်အထားများ အစရှိသည်တို့ကဲ့သို့ ပြည်တွင်းအသုံးပြုသူ ID နှင့် လျှို့ဝှက်ချက်များကို အမွေဆက်ခံပါသည်။ ၎င်းသည် တည်ဆောက်ထားသော ရှေးဟောင်းပစ္စည်းများကို သဘာဝအတိုင်း သိမ်းဆည်းရန် ရင်းမြစ်များပါရှိသော ဒေသဆိုင်ရာ လမ်းညွှန်များကို တပ်ဆင်သည်။ ဤချဉ်းကပ်မှုသည် Builder container နှင့် host အကြား တည်ဆောက်ထားသော artifacts များကို ကူးယူရန် လိုအပ်မှုကို ဖယ်ရှားပေးသောကြောင့် စွမ်းဆောင်ရည်ကို မြှင့်တင်ပေးပါသည်။ သိမ်းဆည်းထားသော တည်ဆောက်မှုဆိုင်ရာ ပစ္စည်းများကို ထပ်လောင်းဖွဲ့စည်းမှုမပါဘဲ ပြန်သုံးနိုင်သည်။

ဝန်ဆောင်မှုအချို့အတွက်၊ ကျွန်ုပ်တို့သည် စုစည်းမှုပတ်ဝန်းကျင်ကို runtime ပတ်၀န်းကျင်သို့ မြေပုံပြုလုပ်ရန် အခြားကွန်တိန်နာတစ်ခုကို ဖန်တီးရပါမည် (ဥပမာ၊ Node.js bcrypt စာကြည့်တိုက်သည် ထည့်သွင်းစဉ်တွင် ပလက်ဖောင်းအလိုက် binary artifacts များကို ထုတ်ပေးသည်)။ စုစည်းမှုလုပ်ငန်းစဉ်အတွင်း၊ ဝန်ဆောင်မှုများကြားတွင် လိုအပ်ချက်များ ကွဲပြားနိုင်ပြီး နောက်ဆုံး Dockerfile ကို အလျင်အမြန် စုစည်းပါသည်။

Kubernetes အစုအဝေးတည်ဆောက်မှုနှင့် ရွှေ့ပြောင်းခြင်း။

အစုအဝေးအရွယ်အစားစီမံခန့်ခွဲမှု

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

အဆုံးတွင်၊

• m5.4xlarge - စောင့်ကြည့်ခြင်းအတွက် (Prometheus);
• c5.4xlarge - Node.js workload (single-threaded workload);
• c5.2xlarge - Java နှင့် Go အတွက် (multithreaded workload);
• c5.4xlarge — control panel (3 nodes) အတွက်။

ရွှေ့ပြောင်းခြင်း။

အခြေခံအဆောက်အဦဟောင်းမှ Kubernetes သို့ ပြောင်းရွှေ့ခြင်းအတွက် ကြိုတင်ပြင်ဆင်သည့်အဆင့်များထဲမှတစ်ခုမှာ ဝန်ဆောင်မှုများကြားရှိ လက်ရှိတိုက်ရိုက်ဆက်သွယ်ရေးကို ဝန်ချိန်ခွင်လျှာအသစ်များ (Elastic Load Balancers (ELB)) သို့ ပြန်လည်ညွှန်းရန်ဖြစ်သည်။ ၎င်းတို့ကို virtual private cloud (VPC) ၏ သီးခြား subnet တစ်ခုပေါ်တွင် ဖန်တီးထားသည်။ ဤကွန်ရက်ခွဲအား Kubernetes VPC နှင့် ချိတ်ဆက်ထားသည်။ ၎င်းသည် ကျွန်ုပ်တို့အား ဝန်ဆောင်မှုမှီခိုမှုဆိုင်ရာ သီးခြားအစီအစဥ်ကို ထည့်သွင်းစဉ်းစားခြင်းမရှိဘဲ မော်ဂျူးများကို ဖြည်းဖြည်းချင်း ပြောင်းရွှေ့နိုင်စေခဲ့သည်။

ဤအဆုံးမှတ်များကို ELB အသစ်တစ်ခုစီသို့ ညွှန်ပြသော CNAME များပါရှိသော အလေးချိန်ရှိသော DNS မှတ်တမ်းများကို အသုံးပြု၍ ဖန်တီးထားသည်။ ကူးပြောင်းရန်အတွက် 0 အလေးချိန်ရှိသော Kubernetes ဝန်ဆောင်မှု ELB အသစ်ကို ညွှန်ပြသော ဝင်ခွင့်အသစ်တစ်ခု ထပ်ထည့်လိုက်ပါသည်။ ထို့နောက် ဝင်ရောက်မှု၏ Time To Live (TTL) ကို 0 ဟု သတ်မှတ်ထားသည်။ ယင်းပြီးနောက်၊ အဟောင်းနှင့် အသစ်များကို ဖြည်းဖြည်းချင်း ချိန်ညှိပေးခဲ့သည်။ နှင့် နောက်ဆုံးတွင် ဝန်ထုပ်ဝန်ပိုး၏ 100% ကို ဆာဗာအသစ်သို့ ပေးပို့ခဲ့သည်။ ကူးပြောင်းခြင်းပြီးဆုံးပြီးနောက်၊ TTL တန်ဖိုးသည် ပိုမိုလုံလောက်သောအဆင့်သို့ ပြန်သွားခဲ့သည်။

ကျွန်ုပ်တို့ရှိထားသော Java module များသည် TTL DNS နိမ့်ပါးမှုကို ရင်ဆိုင်နိုင်သော်လည်း Node အပလီကေးရှင်းများက မလုပ်ဆောင်နိုင်ပါ။ အင်ဂျင်နီယာတစ်ဦးသည် ချိတ်ဆက်မှုပေါင်းကူးကန်ကုဒ်၏ အစိတ်အပိုင်းကို ပြန်လည်ရေးသားပြီး စက္ကန့် 60 တိုင်း ရေကူးကန်များကို အပ်ဒိတ်လုပ်သော မန်နေဂျာတွင် ထည့်သွင်းထားသည်။ ရွေးချယ်ထားသောနည်းလမ်းသည် အလွန်ကောင်းမွန်ပြီး သိသာထင်ရှားသော စွမ်းဆောင်ရည်ကျဆင်းခြင်းမရှိပါ။

သင်ခန်းစာ

Network Fabric ၏ ကန့်သတ်ချက်များ

8 ခုနှစ် ဇန်နဝါရီလ 2019 ရက်နေ့ နံနက်အစောပိုင်းတွင် Tinder ပလပ်ဖောင်းသည် မမျှော်လင့်ဘဲ ပျက်ကျသွားခဲ့သည်။ ထိုနေ့နံနက်အစောပိုင်းတွင် ပလပ်ဖောင်း တုံ့ပြန်နေချိန်တိုးလာမှုကို တုံ့ပြန်သည့်အနေဖြင့်၊ အစုအဝေးရှိ pods နှင့် node အရေအတွက် တိုးလာခဲ့သည်။ ၎င်းသည် ကျွန်ုပ်တို့၏ node များအားလုံးတွင် ARP cache ကို ကုန်ဆုံးသွားစေခဲ့သည်။

ARP cache နှင့်ဆက်စပ်သော Linux ရွေးစရာသုံးမျိုးရှိသည်။

(အရင်းအမြစ်)

gc_thresh3 - ဒါက ခက်ခဲတဲ့ ကန့်သတ်ချက်ပါ။ မှတ်တမ်းရှိ "neighbor table overflow" entries များ၏ အသွင်အပြင်သည် synchronous garbage collection (GC) ပြီးနောက်တွင်ပင် အိမ်နီးချင်း entry ကို သိမ်းဆည်းရန် ARP cache တွင် နေရာအလုံအလောက်မရှိဟု ဆိုလိုပါသည်။ ဤကိစ္စတွင်၊ kernel သည် packet ကိုလုံးဝစွန့်ပစ်ခဲ့သည်။

ငါတို့သုံးတယ် Flannel Kubernetes ရှိ ကွန်ရက်ထည်အဖြစ်။ ပက်ကေ့ခ်ျများကို VXLAN မှတဆင့် ကူးစက်သည်။ VXLAN သည် L2 ကွန်ရက်၏ထိပ်တွင် တပ်ဆင်ထားသော L3 လိုဏ်ခေါင်းတစ်ခုဖြစ်သည်။ နည်းပညာသည် MAC-in-UDP (MAC Address-in-User Datagram Protocol) encapsulation ကိုအသုံးပြုပြီး Layer 2 ကွန်ရက်အပိုင်းများကို ချဲ့ထွင်ခွင့်ပြုသည်။ ရုပ်ပိုင်းဆိုင်ရာဒေတာစင်တာကွန်ရက်ရှိ သယ်ယူပို့ဆောင်ရေးပရိုတိုကောသည် IP နှင့် UDP ဖြစ်သည်။

ပုံ ၂-၁။ ဖလန်နယ်ပုံ (အရင်းအမြစ်)

ပုံ ၂-၂။ VXLAN ပက်ကေ့ဂျ် (အရင်းအမြစ်)

Kubernetes လုပ်သား node တစ်ခုစီသည် ကြီးမားသော /24 ပိတ်ဆို့ခြင်းမှ /9 mask တစ်ခုဖြင့် virtual address space ကို ခွဲဝေပေးပါသည်။ node တစ်ခုစီအတွက် ဒါက နည်းလမ်း လမ်းကြောင်းဇယားရှိ တစ်ခု၊ ARP ဇယား ( flannel.1 အင်တာဖေ့စ်ပေါ်ရှိ ) နှင့် switching table (FDB) တွင် တစ်ခု။ အလုပ်သမား node တစ်ခုကို ပထမဆုံးစတင်သည့်အချိန် သို့မဟုတ် node အသစ်တစ်ခုကို တွေ့ရှိတိုင်း ၎င်းတို့ကို ပေါင်းထည့်သည်။

ထို့အပြင်၊ node-pod (သို့မဟုတ် pod-pod) ဆက်သွယ်ရေးသည် နောက်ဆုံးတွင် အင်တာဖေ့စ်မှတဆင့် ဖြတ်သန်းသွားပါသည်။ ကျင့်ဝတ် (အပေါ်က Flannel ပုံတွင်ပြထားသည့်အတိုင်း)။ ၎င်းသည် သက်ဆိုင်ရာရင်းမြစ်နှင့် ဦးတည်ရာနေရာတစ်ခုစီအတွက် ARP ဇယားတွင် ထပ်လောင်းထည့်သွင်းမှုကို ဖြစ်ပေါ်စေသည်။

ကျွန်ုပ်တို့၏ပတ်ဝန်းကျင်တွင် ဤဆက်သွယ်ရေးအမျိုးအစားသည် အလွန်အသုံးများသည်။ Kubernetes ရှိ ဝန်ဆောင်မှုအရာဝတ္ထုများအတွက် ELB တစ်ခုကို ဖန်တီးပြီး Kubernetes သည် node တစ်ခုစီကို ELB ဖြင့် စာရင်းသွင်းပါသည်။ ELB သည် pods များအကြောင်း ဘာမျှမသိပါ၊ ရွေးချယ်ထားသော node သည် packet ၏နောက်ဆုံးဦးတည်ချက်မဟုတ်ပေ။ အဓိကအချက်မှာ node သည် ELB မှ packet တစ်ခုကို လက်ခံရရှိသောအခါ၊ ၎င်းသည် စည်းမျဉ်းများကို ထည့်သွင်းစဉ်းစားသည် iptables သီးခြားဝန်ဆောင်မှုတစ်ခုအတွက် အခြား node တစ်ခုပေါ်ရှိ pod တစ်ခုကို ကျပန်းရွေးချယ်သည်။

ရှုံးနိမ့်ချိန်တွင်၊ အစုအဝေးတွင် 605 node များရှိသည်။ အထက်ဖော်ပြပါ အကြောင်းပြချက်များအတွက် ဤအချက်သည် အဓိပ္ပါယ်ကို ကျော်လွှားရန် လုံလောက်ပါသည်။ gc_thresh3ပုံသေဖြစ်သည့်။ ဒီလိုဖြစ်လာတဲ့အခါ၊ packets တွေကို စတင်ကျဆင်းသွားရုံသာမကဘဲ /24 mask ပါတဲ့ Flannel virtual address space တစ်ခုလုံး ARP ဇယားကနေ ပျောက်သွားပါတယ်။ Node-pod ဆက်သွယ်ရေးနှင့် DNS မေးမြန်းမှုများ ရပ်တန့်နေသည် (DNS ကို အစုအဝေးတစ်ခုတွင် လက်ခံထားပါသည်၊ အသေးစိတ်အတွက် ဤဆောင်းပါးတွင် နောက်မှဖတ်ပါ)။

ဤပြဿနာကိုဖြေရှင်းရန်, သင်သည်တန်ဖိုးများကိုတိုးမြှင့်ရန်လိုအပ်သည်။ gc_thresh1, gc_thresh2 и gc_thresh3 ပျောက်ဆုံးနေသောကွန်ရက်များကို ပြန်လည်မှတ်ပုံတင်ရန် Flannel ကို ပြန်လည်စတင်ပါ။

မျှော်လင့်မထားသော DNS အတိုင်းအတာ

ရွှေ့ပြောင်းခြင်းလုပ်ငန်းစဉ်အတွင်း၊ ကျွန်ုပ်တို့သည် အသွားအလာကို စီမံခန့်ခွဲရန် DNS ကို တက်ကြွစွာအသုံးပြုပြီး အခြေခံအဆောက်အအုံဟောင်းမှ ဝန်ဆောင်မှုများကို Kubernetes သို့ တဖြည်းဖြည်းလွှဲပြောင်းပေးပါသည်။ ကျွန်ုပ်တို့သည် Route53 တွင် ဆက်စပ် RecordSets အတွက် အတော်လေးနိမ့်သော TTL တန်ဖိုးများကို သတ်မှတ်ပေးပါသည်။ အခြေခံအဆောက်အဦဟောင်းသည် EC2 ဖြစ်ရပ်များတွင် လုပ်ဆောင်နေချိန်တွင်၊ ကျွန်ုပ်တို့၏ ဖြေရှင်းသူ ဖွဲ့စည်းမှုပုံစံသည် Amazon DNS ကို ညွှန်ပြခဲ့သည်။ ဒါကို ကျွန်ုပ်တို့ လက်ခံထားပြီး ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုများနှင့် Amazon ဝန်ဆောင်မှုများ (ဥပမာ DynamoDB) ပေါ်တွင် TTL နိမ့်ကျမှု၏ သက်ရောက်မှုကို လုံး၀သတိမထားမိပါ။

ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုများကို Kubernetes သို့ ပြောင်းရွှေ့ထားစဉ်၊ DNS သည် တစ်စက္ကန့်လျှင် တောင်းဆိုချက်ပေါင်း 250 ကို လုပ်ဆောင်နေကြောင်း တွေ့ရှိရပါသည်။ ရလဒ်အနေဖြင့်၊ အပလီကေးရှင်းများသည် DNS စုံစမ်းမှုများအတွက် အဆက်မပြတ်နှင့် လေးနက်သော အချိန်ကုန်ခြင်းကို စတင်ခံစားလာရသည်။ DNS ဝန်ဆောင်မှုပေးသူကို CoreDNS သို့ ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ရန်နှင့် ပြောင်းလဲရန် မယုံနိုင်လောက်အောင် ကြိုးပမ်းခဲ့သော်လည်း (အမြင့်မားဆုံးသောဝန်တွင် 1000 pods တွင် cores 120 တွင်လည်ပတ်နေသည်) သို့ဖြစ်ခဲ့သည်။

အခြားဖြစ်နိုင်သော အကြောင်းရင်းများနှင့် ဖြေရှင်းနည်းများကို သုတေသနပြုနေစဉ်တွင် ကျွန်ုပ်တို့ ရှာဖွေတွေ့ရှိခဲ့သည်။ ဆောင်းပါးpacket filtering framework ကို ထိခိုက်စေသော ပြိုင်ပွဲအခြေအနေများကို ဖော်ပြခြင်း။ နေပြည် Linux တွင် ကျွန်ုပ်တို့ သတိပြုမိသော အချိန်ကုန်ဆုံးမှုများသည် တိုးလာနေသော ကောင်တာတစ်ခုနှင့် တွဲလျက် ထည့်သွင်း_မအောင်မြင်ပါ။ Flannel interface တွင် ဆောင်းပါး၏ တွေ့ရှိချက်များနှင့် ကိုက်ညီပါသည်။

ပြဿနာသည် Source and Destination Network Address Translation (SNAT နှင့် DNAT) အဆင့်တွင် ဖြစ်ပေါ်ပြီး ဇယားထဲသို့ နောက်ဆက်တွဲ ဝင်ရောက်မှု ဆန့်ကျင်သည်။. ပြည်တွင်း၌ ဆွေးနွေးခဲ့ပြီး အသိုင်းအဝိုင်းမှ အကြံပြုထားသော ဖြေရှင်းချက်တစ်ခုမှာ DNS ကို အလုပ်သမား ခုံသို့ ကိုယ်တိုင်ရွှေ့ရန် ဖြစ်သည်။ ဒါဆိုရင်:

• အသွားအလာသည် node အတွင်းတွင်ရှိနေသောကြောင့် SNAT မလိုအပ်ပါ။ ၎င်းသည် interface ကိုဖြတ်သန်းရန်မလိုအပ်ပါ။ ကျင့်ဝတ်.
• ဦးတည်ရာ IP သည် node ၏ဒေသခံဖြစ်ပြီး စည်းမျဉ်းများနှင့်အညီ ကျပန်းရွေးချယ်ထားသော pod ဖြစ်သောကြောင့် DNAT မလိုအပ်ပါ။ iptables.

ဒီနည်းလမ်းကို လိုက်နာဖို့ ဆုံးဖြတ်ခဲ့ပါတယ်။ CoreDNS ကို Kubernetes တွင် DaemonSet အဖြစ် အသုံးပြုထားပြီး၊ ကျွန်ုပ်တို့သည် ဒေသန္တရ node DNS ဆာဗာကို အကောင်အထည်ဖော်ခဲ့သည် ဆုံးဖြတ်ချက်ချ pod တစ်ခုစီကို အလံတစ်ခုသတ်မှတ်၍ --cluster-dns ပညတ်တော်တို့ကို kubelet . ဤဖြေရှင်းချက်သည် DNS အချိန်ကုန်ခြင်းများအတွက် ထိရောက်မှုရှိလာခဲ့သည်။

သို့သော်၊ ထုပ်ပိုးဆုံးရှုံးမှုနှင့် ကောင်တာတွင် တိုးလာနေသည်ကို ကျွန်ုပ်တို့တွေ့မြင်နေရဆဲဖြစ်သည်။ ထည့်သွင်း_မအောင်မြင်ပါ။ Flannel interface တွင်။ ကျွန်ုပ်တို့သည် DNS အသွားအလာအတွက် SNAT နှင့်/သို့မဟုတ် DNAT ကို ဖယ်ရှားနိုင်သောကြောင့် ပြေလည်မှုရပြီးနောက် ဆက်လက်လုပ်ဆောင်သွားပါသည်။ အခြားအသွားအလာ အမျိုးအစားများအတွက် ပြိုင်ပွဲအခြေအနေများကို ထိန်းသိမ်းထားသည်။ ကံကောင်းထောက်မစွာ၊ ကျွန်ုပ်တို့၏ packet အများစုသည် TCP ဖြစ်ကြပြီး ပြဿနာတစ်ခုဖြစ်ပွားပါက ၎င်းတို့ကို ရိုးရိုးပြန်ပို့ပေးပါသည်။ ယာဉ်အသွားအလာ အမျိုးအစားအားလုံးအတွက် သင့်လျော်သော အဖြေကို ကျွန်ုပ်တို့ ရှာဖွေနေဆဲဖြစ်သည်။

ပိုမိုကောင်းမွန်သော Load Balancing အတွက် Envoy ကို အသုံးပြုခြင်း။

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

ကျွန်ုပ်တို့အသုံးပြုခဲ့သည့် နောက်ထပ်ဖြေရှင်းချက်တစ်ခုမှာ အရေးကြီးသောဝန်ဆောင်မှုများအတွက် အရင်းအမြစ်တောင်းဆိုမှုများကို အတုအယောင် တိုးမြှင့်ရန်ဖြစ်သည်။ ဤအခြေအနေတွင်၊ အနီးအနားတွင် ချထားသော အစေ့များသည် အခြားသော လေးလံသော အစေ့များနှင့် နှိုင်းယှဉ်ရန် နေရာပိုရပေလိမ့်မည်။ အရင်းအမြစ်များ ဖြုန်းတီးခြင်းကြောင့်လည်း ရေရှည်တွင် အလုပ်မဖြစ်နိုင်ပါ။ ထို့အပြင်၊ ကျွန်ုပ်တို့၏ Node အပလီကေးရှင်းများသည် single-threaded ဖြစ်သောကြောင့် core တစ်ခုသာ အသုံးပြုနိုင်သည်။ တစ်ခုတည်းသော အဖြေမှာ ပိုမိုကောင်းမွန်သော ဝန်ချိန်ခွင်လျှာကို အသုံးပြုရန်ဖြစ်သည်။

အပြည့်အဝတန်ဖိုးထားချင်ခဲ့တာ ကြာပါပြီ။ အထူးသံတမန်. လက်ရှိအခြေအနေသည် ကျွန်ုပ်တို့အား အလွန်အကန့်အသတ်ဖြင့် အသုံးချနိုင်စေပြီး ချက်ချင်းရလဒ်များကို ရရှိစေပါသည်။ Envoy သည် ကြီးမားသော SOA အပလီကေးရှင်းများအတွက် ဒီဇိုင်းထုတ်ထားသော စွမ်းဆောင်ရည်မြင့်၊ ပွင့်လင်းအရင်းအမြစ်၊ အလွှာ-၇ ပရောက်စီဖြစ်သည်။ အလိုအလျောက်ပြန်စမ်းခြင်း၊ circuit breakers နှင့် global rate limiting အပါအဝင် အဆင့်မြင့် ဝန်ချိန်ညှိခြင်းနည်းပညာများကို အကောင်အထည်ဖော်နိုင်သည်။ (မှတ်ချက်။ ဘာသာပြန်: ဤအကြောင်းပိုမိုဖတ်ရှုနိုင်ပါသည်။ ဤဆောင်းပါးတွင် Envoy ကိုအခြေခံထားတဲ့ Istio အကြောင်း။)

ကျွန်ုပ်တို့သည် အောက်ပါဖွဲ့စည်းမှုပုံစံကို အကောင်အထည်ဖော်ဆောင်လာသည်- pod တစ်ခုစီအတွက် Envoy sidecar တစ်ခုရှိပြီး လမ်းကြောင်းတစ်ခုစီရှိကာ၊ အစုအဝေးကို ဆိပ်ကမ်းမှတစ်ဆင့် စက်တွင်းရှိ ကွန်တိန်နာသို့ ချိတ်ဆက်ပါ။ ဖြစ်နိုင်ခြေရှိသော ကက်စကတ်များကို လျှော့ချရန်နှင့် သေးငယ်သော အချင်းဝက်ကို ထိန်းသိမ်းရန်အတွက်၊ ဝန်ဆောင်မှုတစ်ခုစီအတွက် Envoy ရှေ့-ပရောက်စီ အကွက်များ၊ ဝန်ဆောင်မှုတစ်ခုစီအတွက် Availability Zone (AZ) တစ်ခုစီကို အသုံးပြုထားပါသည်။ ၎င်းတို့သည် ပေးထားသောဝန်ဆောင်မှုအတွက် AZ တစ်ခုစီရှိ pods စာရင်းများကို ရိုးရိုးပြန်ပေးသည့် ကျွန်ုပ်တို့၏အင်ဂျင်နီယာတစ်ဦးမှ ရေးသားထားသော ရိုးရှင်းသောဝန်ဆောင်မှုရှာဖွေရေးအင်ဂျင်ကို အားကိုးအားထားပြုပါသည်။

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

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

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

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

ပုံ ၃-၁။ Envoy သို့ကူးပြောင်းစဉ်တွင် ဝန်ဆောင်မှုတစ်ခု၏ CPU ပေါင်းစည်းခြင်း

နောက်ဆုံးရလဒ်

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

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

ရွှေ့ပြောင်းခြင်းမှာ နှစ်နှစ်နီးပါးကြာခဲ့သော်လည်း၊ ၂၀၁၉ ခုနှစ် မတ်လတွင် ပြီးမြောက်ခဲ့သည်။ လက်ရှိတွင် Tinder ပလပ်ဖောင်းသည် ဝန်ဆောင်မှု 2019၊ node 200၊ pods 1000 နှင့် 15 run containers များပါရှိသော Kubernetes အစုအဝေးတစ်ခုပေါ်တွင် သီးသန့်လည်ပတ်နေသည်။ အခြေခံအဆောက်အအုံသည် လုပ်ငန်းဆောင်ရွက်မှုအဖွဲ့များ၏ တစ်ခုတည်းသော နယ်ပယ်မဟုတ်တော့ပါ။ ကျွန်ုပ်တို့၏ အင်ဂျင်နီယာများအားလုံးသည် ဤတာဝန်ကို ခွဲဝေခံစားပြီး ၎င်းတို့၏ အပလီကေးရှင်းများ တည်ဆောက်ခြင်းနှင့် အသုံးပြုခြင်းလုပ်ငန်းစဉ်ကို ကုဒ်ကိုသာ အသုံးပြု၍ ထိန်းချုပ်ပါသည်။

PS ဘာသာပြန်မှ

ကျွန်ုပ်တို့၏ဘလော့ဂ်ရှိ ဆောင်းပါးများကို ဆက်တိုက်ဖတ်ပါ-

• «Kubernetes ထုတ်လုပ်ရေးတွင် အောင်မြင်မှုဇာတ်လမ်းများ။ အပိုင်း 1: eBay မှ မီးဖို 4200 နှင့် TessMaster"။
• «Kubernetes ထုတ်လုပ်ရေးတွင် အောင်မြင်မှုဇာတ်လမ်းများ။ အပိုင်း 2: Concur နှင့် SAP"။
• «Kubernetes ထုတ်လုပ်ရေးတွင် အောင်မြင်မှုဇာတ်လမ်းများ။ အပိုင်း 3: GitHub"။
• «Kubernetes ထုတ်လုပ်ရေးတွင် အောင်မြင်မှုဇာတ်လမ်းများ။ အပိုင်း 4: SoundCloud (Prometheus မှ)"။
• «Kubernetes ထုတ်လုပ်ရေးတွင် အောင်မြင်မှုဇာတ်လမ်းများ။ အပိုင်း 5: ဒစ်ဂျစ်တယ်ဘဏ် Monzo"။
• «Kubernetes ထုတ်လုပ်ရေးတွင် အောင်မြင်မှုဇာတ်လမ်းများ။ အပိုင်း 6: BlaBlaCar"။
• «Kubernetes ထုတ်လုပ်ရေးတွင် အောင်မြင်မှုဇာတ်လမ်းများ။ အပိုင်း 7: BlackRock"။
• «Kubernetes ထုတ်လုပ်ရေးတွင် အောင်မြင်မှုဇာတ်လမ်းများ။ အပိုင်း 8: Huawei"။
• «Kubernetes ထုတ်လုပ်ရေးတွင် အောင်မြင်မှုဇာတ်လမ်းများ။ အပိုင်း 9: CERN နှင့် 210 K8s အစုအဝေးများ"။
• «Kubernetes ထုတ်လုပ်ရေးတွင် အောင်မြင်မှုဇာတ်လမ်းများ။ အပိုင်း 10: Reddit"။

source: www.habr.com