د K8S ملټي کلستر سفر

اې حبره!

موږ د Exness پلیټ فارم ټیم استازیتوب کوو. مخکې، زموږ همکارانو لا دمخه په اړه یوه مقاله لیکلې وه د k8s لپاره د تولید لپاره چمتو شوي عکسونه. نن ورځ موږ غواړو د مهاجرت خدماتو تجربه زموږ سره شریک کړو Kubernetes.

د پیل کولو لپاره، موږ تاسو ته د ښه پوهیدو لپاره ځینې شمیرې وړاندیز کوو چې څه به پرې بحث وشي:

• زموږ د پراختیا څانګه د 100+ خلکو څخه جوړه ده، په شمول د 10 څخه ډیر مختلف ټیمونه د ځان بسیا QA، DevOps او سکرم پروسې سره. پرمختیایی سټیک - پایتون، پی ایچ پی، C++، جاوا او ګولنګ. 
• د ازموینې او تولید چاپیریال اندازه هر یو شاوخوا 2000 کانټینرونه دي. دوی په خپل مجازی کولو او د VMware لاندې د Rancher v1.6 پرمخ وړي. 

انګیزه

لکه څنګه چې دوی وايي، هیڅ شی د تل لپاره نه پاتې کیږي، او رینچر ډیر وخت دمخه د 1.6 نسخه لپاره د ملاتړ پای اعلان کړ. هو، په تیرو دریو کلونو کې موږ دا زده کړل چې څنګه یې چمتو کړو او هغه ستونزې حل کړو چې رامینځته کیږي، مګر ډیر ځله موږ له ستونزو سره مخ کیږو چې هیڅکله به سم نه شي. Rancher 1.6 د حقونو د صادرولو لپاره یو ossified سیسټم هم لري، چیرې چې تاسو کولی شئ یا تقریبا هرڅه ترسره کړئ یا هیڅ شی.

که څه هم د ملکیت مجازی کول د معلوماتو ذخیره کولو او د هغې امنیت باندې ډیر کنټرول چمتو کړی، دا عملیاتي لګښتونه وضع کړي چې د شرکت دوامداره ودې، د پروژو شمیر او د دوی اړتیاو ته په پام سره د منلو وړ ندي.

موږ غوښتل د IaC معیارونه تعقیب کړو او که اړتیا وي ، په هر جغرافیایی موقعیت کې او د پلورونکي تالاشۍ پرته ظرفیت په چټکۍ سره ترلاسه کړو ، او همدارنګه د دې وړتیا ولرو چې ژر تر ژره یې پریږدو.

لومړي ګامونه

له هرڅه دمخه ، موږ غوښتل په عصري ټیکنالوژیو او حلونو تکیه وکړو چې ټیمونو ته به اجازه ورکړي چې د ګړندي پراختیا دورې ولري او د هغه پلیټ فارم سره متقابل عمل کولو لپاره عملیاتي لګښتونه کم کړي چې بریښنا چمتو کوي. 
 
البته، لومړی شی چې زموږ ذهن ته راغی Kubernetes وو، مګر موږ خوشحاله نه شو او لږ تحقیق مو وکړ ترڅو وګورو چې آیا دا سم انتخاب دی. موږ یوازې د خلاصې سرچینې حلونه ارزولي، او په غیر عادلانه جګړه کې، کوبرنیټس په غیر مشروط ډول وګټله.  

بیا د کلسترونو رامینځته کولو لپاره د یوې وسیلې غوره کولو پوښتنه راغله. موږ خورا مشهور حلونه پرتله کړل: kops، kubespray، kubeadm.

د پیل کولو لپاره، kubeadm موږ ته لاره ډیره پیچلې ښکاري، نه د "بایسکل" د یو ډول اختراع کونکي په څیر، او کوپس کافي انعطاف نه درلود.

او ګټونکی وو:

موږ د خپل مجازی کولو او AWS سره تجربه پیل کړه، هڅه یې کوله چې زموږ د پخوانیو سرچینو مدیریت بڼې ته ورته یو څه بیا جوړ کړو، چیرې چې هرڅوک ورته "کلستر" شریک کړي. او اوس موږ د 10 کوچني مجازی ماشینونو لومړی کلستر لرو، چې یو څو یې په AWS کې موقعیت لري. موږ هلته د ټیمونو د مهاجرت هڅه پیل کړه، هرڅه "ښه" ښکاري، او کیسه پای ته رسیدلی شي، مګر ...

لومړۍ ستونزې

ځواب دا دی چې کوبیسپری په څه باندې جوړ شوی دی، دا هغه وسیله نده چې تاسو ته اجازه درکوي IaC تعقیب کړئ: کله چې د نوډونو کمېشن/کمیشن کول، یو څه په دوامداره توګه غلط شو او یو ډول مداخلې ته اړتیا وه، او کله چې د مختلف OS په کارولو سره، د لوبې کتاب په بل ډول چلند کوي. . لکه څنګه چې په کلستر کې د ټیمونو او نوډونو شمیر ډیر شو، موږ په دې پوهیدل پیل کړل چې د لوبې کتاب بشپړولو لپاره ډیر وخت نیسي، او په پایله کې، زموږ ریکارډ 3,5 ساعته و، ستاسو په اړه څه؟ 🙂

او داسې بریښي چې کوبیسپری یوازې ځواب ویونکی دی ، او هرڅه په لومړي نظر کې روښانه دي ، مګر:

د سفر په پیل کې، دنده یوازې په AWS او مجازی کولو کې ظرفیتونه پیل کول وو، مګر بیا، لکه څنګه چې ډیری وختونه پیښیږي، اړتیاوې بدلې شوې.
 


د دې په رڼا کې، دا څرګنده شوه چې زموږ پخوانۍ بڼه د منابعو یوځای کولو لپاره په یو آرکیسټریشن سیسټم کې مناسبه نه وه - په هغه حالت کې چې کلسترونه خورا لیرې وي او د مختلفو چمتو کونکو لخوا اداره کیږي. 

نور نور. کله چې ټول ټیمونه په ورته کلستر کې کار کوي، مختلف خدمتونه په غلط ډول نصب شوي نوډ سلیکټرز کولی شي د بل ټیم ​​"بهرنۍ" کوربه ته الوتنه وکړي او هلته سرچینې وکاروي، او که داغ ټاکل شوی وي، دوامداره غوښتنې وې چې یو یا بل خدمت کار نه کوي، د انساني فکتور له امله په سمه توګه نه ویشل شوي. بله ستونزه د لګښت محاسبه وه، په ځانګړې توګه د نوډونو په اوږدو کې د خدماتو ویشلو ستونزې په پام کې نیولو سره.

یوه جلا کیسه د کارمندانو د حقونو صادرول وه: هر ټیم غوښتل د کلستر "سر" کې وي او په بشپړ ډول یې اداره کړي، کوم چې کولی شي د بشپړ سقوط لامل شي، ځکه چې ټیمونه اساسا له یو بل څخه خپلواک دي.

څنګه به وي؟

پورتني او د ټیمونو هیلو ته په پام سره چې ډیر خپلواک وي، موږ یو ساده پایله وکړه: یو ټیم - یو کلستر. 

نو موږ دوهم ترلاسه کړ:

او بیا دریم کلستر: 

بیا مو فکر پیل کړ: راځئ ووایو چې په یو کال کې به زموږ ټیمونه له یو څخه ډیر کلستر ولري؟ په بیلابیلو جغرافيائی سیمو کې، د بیلګې په توګه، یا د مختلف چمتو کونکو تر کنټرول لاندې؟ او ځینې به یې وغواړي چې ژر تر ژره د ځینې ازموینو لپاره لنډمهاله کلستر ځای په ځای کړي. 

بشپړ Kubernetes به راشي! دا یو ډول MultiKubernetes دی، دا معلومه شوه. 

په ورته وخت کې، موږ ټول باید په یو ډول دا ټول کلسترونه وساتو، د دې وړتیا ولرو چې په اسانۍ سره دوی ته لاسرسۍ اداره کړو، او همدارنګه نوي جوړ کړو او زاړه یې له لاسي مداخلې پرته له منځه یوسو.

د Kubernetes نړۍ کې زموږ د سفر له پیل څخه یو څه وخت تیر شوی، او موږ پریکړه وکړه چې شته حلونه بیا وڅیړو. دا معلومه شوه چې دا دمخه په بازار کې شتون لري - Rancher 2.2.

زموږ د څیړنې په لومړي مرحله کې، رینچر لابراتوار لا دمخه د 2 نسخه لومړۍ خپرونه جوړه کړې وه، مګر که څه هم دا د یو څو پیرامیټونو سره د بهرني انحصار پرته د کانټینر په لاره اچولو یا د رسمي HELM چارټ په کارولو سره په چټکۍ سره پورته کیدی شي، دا خام ښکاري. موږ ته، او موږ نه پوهیږو چې آیا موږ کولی شو په دې پریکړه تکیه وکړو چې آیا دا به پراختیا ومومي یا په چټکۍ سره پریښودل شي. کلستر = په UI کې د کلیکونو تمثیل هم موږ ته مناسب نه و، او موږ نه غوښتل چې د RKE سره وصل شو، ځکه چې دا یو ډیر محدود تمرکز وسیله ده. 

نسخه رینچر 2.2 لا دمخه ډیر د کار وړ بڼه درلوده او د پخوانیو سره یوځای د بکس څخه بهر په زړه پورې ب featuresو یوه ډله درلوده ، لکه د ډیری بهرني چمتو کونکو سره ادغام ، د حقونو توزیع یو واحد ټکی او د کیوب کنفګ فایلونه ، د کیوبیک ایل پیل کول. په UI کې ستاسو د حقونو سره عکس، د نیست شوي نوم ځایونه عرف پروژې. 

دلته لا دمخه یوه ټولنه هم وه چې د Rancher 2 په شاوخوا کې جوړه شوې وه، او د HashiCorp Terraform په نوم یو چمتو کونکی د دې اداره کولو لپاره رامینځته شوی و، کوم چې موږ سره د هرڅه یوځای کولو کې مرسته وکړه.

څه پیښ شو

د پایلې په توګه، موږ د رینچر چلولو یو کوچني کلستر سره پای ته ورسیدو، نورو ټولو کلسترونو ته د لاسرسي وړ، او همدارنګه ډیری کلسترونه چې ورسره تړلي دي، هر یو ته لاسرسی د ldap ډایرکټر ته د کاروونکي اضافه کولو په توګه ورکول کیدی شي، پرته له دې چې دا چیرته موقعیت لري او کوم چمتو کونکي سرچینې کاروي.

د gitlab-ci او Terraform په کارولو سره ، یو سیسټم رامینځته شوی چې تاسو ته اجازه درکوي د کلاوډ چمتو کونکو یا زموږ په خپل زیربنا کې د هر ډول تشکیلاتو کلستر رامینځته کړئ او د Rancher سره وصل کړئ. دا ټول د IaC سټایل کې ترسره کیږي ، چیرې چې هر کلستر د ذخیره کولو لخوا تشریح شوی ، او د هغې حالت نسخه شوی. په ورته وخت کې ، ډیری ماډلونه د بهرني ذخیره کولو څخه وصل شوي نو ټول هغه څه چې پاتې دي د متغیرونو تیرولو یا د مثالونو لپاره ستاسو دودیز ترتیب تشریح کول دي ، کوم چې د کوډ تکرار سلنه کمولو کې مرسته کوي.

البته ، زموږ سفر پای ته نه دی رسیدلی او لاهم ډیر په زړه پوري دندې په مخ کې دي ، لکه د هر کلسترونو لاګونو او میټریکونو سره د کار یو واحد ټکی ، د خدماتو میش ، په ملټي کلستر کې د بارونو اداره کولو لپاره ګیټاپس او نور ډیر څه. موږ امید لرو چې تاسو زموږ تجربه په زړه پوري ومومئ! 

مقاله د A. Antipov، A. Ganush، د پلیټ فارم انجنیرانو لخوا لیکل شوې وه. 

سرچینه: www.habr.com