نوټ. ژباړه: په GitLab کې د Kubernetes منل یو له دوو اصلي فاکتورونو څخه شمیرل کیږي چې د شرکت وده کې مرسته کوي. په هرصورت، تر دې وروستیو پورې، د GitLab.com آنلاین خدمت زیربنا په مجازی ماشینونو کې جوړه شوې وه، او یوازې یو کال دمخه د K8s ته مهاجرت پیل شو، کوم چې لاهم بشپړ شوی نه دی. موږ خوښ یو چې د GitLab SRE انجینر لخوا د وروستي مقالې ژباړه وړاندې کوو چې دا څنګه پیښیږي او په پروژه کې برخه اخیستونکي انجینران کومې پایلې رامینځته کوي.
د شاوخوا یو کال راهیسې ، زموږ د زیربنا څانګه ټول خدمات په GitLab.com کې Kubernetes ته لیږدول شوي. د دې وخت په جریان کې، موږ نه یوازې کوبرنیټس ته د خدماتو لیږدولو پورې اړوند ننګونو سره مخ شو، بلکې د لیږد په جریان کې د هایبرډ ګمارنې اداره کول هم. هغه ارزښتناک درسونه چې موږ یې زده کړل په دې مقاله کې به بحث وشي.
د GitLab.com له پیل څخه ، د دې سرورونه په مجازی ماشینونو کې په بادل کې روان و. دا مجازی ماشینونه د شیف لخوا اداره کیږي او زموږ په کارولو سره نصب شوي . په هغه صورت کې چې غوښتنلیک تازه کولو ته اړتیا لري، د CI پایپ لاین په کارولو سره په همغږي، ترتیب شوي ډول د سرور بیړۍ تازه کول شامل دي. دا طریقه - که څه هم ورو او لږ څه - ډاډ ترلاسه کوي چې GitLab.com د آفلاین کاروونکو په څیر ورته نصب او ترتیب کولو کړنې کاروي (ځان اداره شوی) د دې لپاره زموږ د لینکس کڅوړو په کارولو سره GitLab تاسیسات.
موږ دا طریقه کاروو ځکه چې دا خورا مهم دي چې ټول هغه غمونه او خوښۍ تجربه کړئ چې د ټولنې عادي غړي یې د GitLab د خپلو کاپيونو نصب او تنظیم کولو په وخت کې تجربه کوي. دې طریقې د یو څه وخت لپاره ښه کار وکړ، مګر کله چې په GitLab کې د پروژو شمیر له 10 ملیون څخه ډیر شو، موږ پوهیږو چې دا نور د پیمانه کولو او ګمارلو لپاره زموږ اړتیاوې نه پوره کوي.
Kubernetes او کلاوډ اصلي GitLab ته لومړي ګامونه
پروژه په 2017 کې جوړه شوې وه د کلاوډ ګمارنې لپاره GitLab چمتو کولو لپاره ، او کاروونکو ته وړتیا ورکول چې ګیټ لیب په Kubernetes کلسترونو کې نصب کړي. موږ بیا پوهیږو چې کوبرنیټس ته د GitLab لیږدول به د SaaS پلیټ فارم اندازه کولو وړتیا لوړه کړي ، ګمارنې ساده کړي ، او د کمپیوټري سرچینو موثریت ته وده ورکړي. په ورته وخت کې ، زموږ د غوښتنلیک ډیری دندې په نصب شوي NFS برخو پورې اړه لري ، کوم چې د مجازی ماشینونو لیږد ورو کړی.
د کلاوډ اصلي او کبرنیټس په لور فشار زموږ انجینرانو ته اجازه ورکړه چې تدریجي لیږد پلان کړي ، په کوم کې چې موږ د نوي ب featuresو رامینځته کولو ته دوام ورکولو په جریان کې د شبکې ذخیره کولو باندې د غوښتنلیک ځینې انحصارونه پریښودل. له هغه وخته چې موږ د 2019 په دوبي کې د مهاجرت پلان کول پیل کړل، ډیری دا محدودیتونه حل شوي، او Kubernetes ته د GitLab.com مهاجرت پروسه اوس ښه روانه ده!
په Kubernetes کې د GitLab.com ځانګړتیاوې
د GitLab.com لپاره، موږ یو واحد سیمه ایز GKE کلستر کاروو چې د غوښتنلیک ټول ټرافیک اداره کوي. د مهاجرت د پیچلتیا د کمولو لپاره، موږ په هغو خدماتو تمرکز کوو چې په محلي ذخیره یا NFS باندې تکیه نه کوي. GitLab.com په عمده ډول د واحد ریل کوډبیس کاروي، او موږ ټرافيک د کاري بار ځانګړتیاو پراساس مختلف پایو ته رسوو چې د دوی په خپلو نوډ حوضونو کې جلا شوي.
د فرنټ اینډ په حالت کې، دا ډولونه د ویب، API، Git SSH/HTTPS او راجستر لپاره په غوښتنو ویشل شوي. د پس منظر په حالت کې، موږ په کتار کې دندې د مختلفو ځانګړتیاوو له مخې تقسیم کوو ، کوم چې موږ ته اجازه راکوي د مختلف کاري بارونو لپاره د خدماتو کچې موخې (SLOs) تنظیم کړو.
دا ټول GitLab.com خدمتونه د نه بدلیدونکي GitLab هیلم چارټ په کارولو سره تنظیم شوي. ترتیب په فرعي چارټونو کې ترسره کیږي، کوم چې په انتخابي ډول فعال کیدی شي ځکه چې موږ په تدریجي ډول کلستر ته خدمتونه لیږدول. که څه هم موږ پریکړه کړې چې زموږ ځینې دولتي خدمات په مهاجرت کې شامل نه کړو، لکه Redis، Postgres، GitLab پاڼې او Gitaly، د Kubernetes کارول موږ ته اجازه راکوي چې د VMs شمیر په بنسټیز ډول کم کړو چې شیف اوس مهال اداره کوي.
د کوبرنیټس ترتیب لید او مدیریت
ټول تنظیمات پخپله د GitLab لخوا اداره کیږي. د دې لپاره، د Terraform او Helm پر بنسټ د ترتیب کولو درې پروژې کارول کیږي. موږ هڅه کوو هرکله چې ممکنه وي د GitLab چلولو لپاره پخپله GitLab وکاروو، مګر د عملیاتي دندو لپاره موږ جلا GitLab نصب لرو. دا د دې لپاره اړین دی چې ډاډ ترلاسه کړئ چې تاسو د GitLab.com په شتون پورې تړلي نه یاست کله چې د GitLab.com ګمارنې او تازه معلومات ترسره کوئ.
که څه هم د Kubernetes کلستر لپاره زموږ پایپ لاینونه په جلا GitLab نصب کې پرمخ ځي، د کوډ ذخیره کولو عکسونه شتون لري چې په عامه توګه په لاندې پتو کې شتون لري:
- - د GitLab هیلم چارټ لپاره د GitLab.com ترتیب کولو چوکاټ؛
- - د خدماتو لپاره تشکیلات لري چې مستقیم د GitLab غوښتنلیک سره تړاو نلري. پدې کې د ننوتلو او کلستر نظارت لپاره تشکیلات شامل دي ، او همدارنګه د پلانټ یو ایم ایل په څیر مدغم شوي وسیلې؛
- - د Kubernetes او میراثي VM زیربنا لپاره د Terraform ترتیب. دلته تاسو ټول هغه سرچینې تنظیم کړئ چې د کلستر چلولو لپاره اړین دي، پشمول د کلستر پخپله، نوډ پول، د خدماتو حسابونه، او د IP پتې ریزرویشنونه.
عامه لید ښودل کیږي کله چې بدلونونه رامینځته کیږي. د مفصل توپیر سره د لینک سره چې SRE په کلستر کې د بدلونونو دمخه تحلیل کوي.
د SRE لپاره، لینک د GitLab نصبولو کې تفصيلي توپیر ته الرښوونه کوي، کوم چې د تولید لپاره کارول کیږي او لاسرسی محدود دی. دا کارمندان او ټولنې ته اجازه ورکوي پرته له دې چې عملیاتي پروژې ته لاسرسی ومومي (کوم چې یوازې د SREs لپاره خلاص دی)، د وړاندیز شوي ترتیب بدلونونه وګوري. د CI پایپ لاینونو لپاره د شخصي مثال سره د کوډ لپاره د عامه GitLab مثال په یوځای کولو سره ، موږ یو واحد کاري فلو ساتو پداسې حال کې چې د تشکیلاتو تازه معلوماتو لپاره د GitLab.com څخه خپلواکي تضمین کوو.
هغه څه چې موږ د مهاجرت په جریان کې وموندل
د حرکت په جریان کې، تجربه ترلاسه شوه چې موږ په کوبرنیټس کې د نوي مهاجرت او ګمارنې لپاره غوښتنه کوو.
1. د شتون زونونو ترمنځ د ترافیک له امله د لګښتونو زیاتوالی
په GitLab.com کې د Git ذخیره کولو بیړۍ لپاره د ورځني وتلو احصایې (هره ورځ بایټس)
ګوګل خپله شبکه په سیمو ویشي. دوی، په بدل کې، د لاسرسي په زونونو (AZ) ویشل شوي دي. د Git کوربه توب د ډیټا لوی مقدار سره تړاو لري، نو دا زموږ لپاره مهمه ده چې د شبکې وتلو کنټرول کړو. د داخلي ترافیک لپاره، وتلو یوازې وړیا دی که چیرې دا د ورته موجودیت زون کې پاتې شي. د دې لیکلو پورې، موږ په عادي کاري ورځ کې نږدې 100 TB ډیټا خدمت کوو (او دا یوازې د Git ذخیره کولو لپاره دی). هغه خدمتونه چې زموږ په زاړه VM میشته ټوپولوژي کې ورته مجازی ماشینونو کې اوسیږي اوس په مختلف کوبرنیټس پوډونو کې پرمخ ځي. دا پدې مانا ده چې ځینې ټرافیک چې مخکې VM ته ځایی و ممکن په احتمالي توګه د شتون زونونو څخه بهر سفر وکړي.
سیمه ایز GKE کلسترونه تاسو ته اجازه درکوي د بې ځایه کیدو لپاره ډیری د شتون زونونه پراخه کړئ. موږ احتمال په پام کې نیسو د خدماتو لپاره چې لوی مقدار ترافیک رامینځته کوي. دا به د اخراج لګښتونه کم کړي پداسې حال کې چې د کلستر کچه بې ځایه ساتل کیږي.
2. محدودیتونه، د سرچینو غوښتنې او اندازه کول
په registry.gitlab.com کې د تولید ټرافيکي پروسس کولو نقلونو شمیر. د ټرافیک لوړوالی په ~15:00 UTC کې.
زموږ د مهاجرت کیسه د اګست په 2019 کې پیل شوه، کله چې موږ خپل لومړی خدمت، د GitLab کانټینر راجستر، Kubernetes ته مهاجرت وکړ. دا ماموریت مهم، د لوړ ټرافیک خدمت د لومړي مهاجرت لپاره ښه انتخاب و ځکه چې دا یو بې ریاسته غوښتنلیک دی چې لږ بهرني انحصارونه لري. لومړۍ ستونزه چې موږ ورسره مخ شوه په نوډونو کې د حافظې نشتوالي له امله د ویستل شوي پوډونو لوی شمیر و. د دې له امله، موږ باید غوښتنې او حدود بدل کړو.
دا وموندل شوه چې د غوښتنلیک په حالت کې چیرې چې د حافظې مصرف د وخت په تیریدو سره ډیریږي ، د غوښتنو لپاره ټیټ ارزښتونه (د هر پوډ لپاره حافظه ساتل) د کارولو په اړه د "سخاوتمند" سخت حد سره یوځای د سنتریت لامل کیږي. (سنترول) نوډونه او د ویستلو لوړه کچه. د دې ستونزې سره د مقابلې لپاره، دا وه . دا د نوډونو فشار لرې کړ او ډاډ ترلاسه کړ چې پوډونه د ژوند دورې لري چې په نوډ باندې ډیر فشار نه راوړي. اوس موږ مهاجرتونه د سخاوتمندانه (او نږدې ورته) غوښتنې سره پیل کوو او د ارزښتونو محدودولو سره د اړتیا سره سم تنظیم کوو.
3. میټریکونه او لاګونه
د زیربنا څانګه د نصب سره په ځنډ، د تېروتنې نرخونو او سنتریت باندې تمرکز کوي (SLO) پورې تړاو لري .
په تیر کال کې، د زیربنا په څانګه کې یو له مهمو پیښو څخه د SLOs سره د څارنې او کار کولو ښه والی دی. SLOs موږ ته اجازه راکړه چې د انفرادي خدماتو لپاره اهداف وټاکو چې موږ د مهاجرت په جریان کې له نږدې څارلي. مګر حتی د دې ښه مشاهدې سره ، دا تل امکان نلري چې سمدلاسه د میټریکونو او خبرتیاو په کارولو سره ستونزې وګورئ. د مثال په توګه، د ځنډ او غلطۍ نرخونو باندې تمرکز کولو سره، موږ د مهاجرت لاندې خدمت لپاره د کارونې ټولې قضیې په بشپړه توګه نه پوښو.
دا مسله نږدې سمدلاسه وروسته وموندل شوه کله چې کلستر ته ځینې کاري بارونه لیږدول. دا په ځانګړي ډول شدید شو کله چې موږ باید هغه دندې وګورو چې د غوښتنو شمیر یې لږ و ، مګر کوم چې خورا ځانګړي ترتیب انحصار درلود. د مهاجرت څخه یو له مهمو درسونو څخه دا وه چې د څارنې پر مهال نه یوازې میټریکونه په پام کې ونیول شي، بلکې لاګونه او "اوږده لکۍ" هم په پام کې ونیول شي. (دا په اړه دی په چارټ کې - نږدې. ژباړه.) تېروتنې اوس د هر مهاجرت لپاره موږ د لاګ پوښتنو تفصيلي لیست شامل کوو (لګول پوښتنې) او روښانه رول بیک طرزالعملونه پلان کړئ چې د ستونزې رامینځته کیدو په صورت کې له یو شفټ څخه بل ته لیږدول کیدی شي.
د زوړ VM زیربنا او نوي کوبرنیټس میشته زیربنا کې موازي ورته غوښتنو خدمت کول یوه ځانګړې ننګونه وړاندې کړه. د لفټ او شفټ مهاجرت برعکس (د غوښتنلیکونو چټک لیږد "لکه څنګه چې دی" نوي زیربنا ته؛ نور توضیحات لوستل کیدی شي، د بیلګې په توګه، - نږدې ژباړه.)په "زاړه" VMs او Kubernetes کې موازي کار ته اړتیا لري چې د څارنې وسیلې د دواړو چاپیریالونو سره مطابقت ولري او د دې وړتیا ولري چې میټریکونه په یو لید کې یوځای کړي. دا مهمه ده چې موږ ورته ډشبورډونه او د ننوتلو پوښتنو څخه کار واخلو ترڅو د لیږد دورې په جریان کې ثابت لید ترلاسه کړو.
4. نوي کلستر ته د ترافیک بدلول
د GitLab.com لپاره، د سرورونو برخه وقف شوې ده . کانري پارک زموږ داخلي پروژې خدمت کوي او هم کولی شي . مګر دا اساسا ډیزاین شوی ترڅو زیربنا او غوښتنلیک کې رامینځته شوي بدلونونه معاینه کړي. لومړی مهاجر شوی خدمت د محدود مقدار داخلي ترافیک په منلو سره پیل شو، او موږ د دې طریقې کارولو ته دوام ورکوو ترڅو ډاډ ترلاسه کړو چې SLOs د کلستر ته د ټولو ټرافیک لیږلو دمخه پوره کیږي.
د مهاجرت په حالت کې، دا پدې مانا ده چې د داخلي پروژو لپاره غوښتنې لومړی Kubernetes ته لیږل کیږي، او بیا موږ په تدریجي ډول د HAProxy له لارې د شالید لپاره وزن بدلولو سره کلستر ته پاتې ټرافیک بدلوو. د VM څخه Kubernetes ته د مهاجرت په جریان کې، دا څرګنده شوه چې دا ډیره ګټوره وه چې د زاړه او نوي زیربنا تر منځ د ټرافیک د بیرته راستنیدو لپاره اسانه لار ولرئ او په وینا، د مهاجرت وروسته په لومړیو څو ورځو کې زاړه زیربنا د رول بیک لپاره چمتو وساتئ.
5. د پوډرو ظرفیتونه او د هغوی کارول
نږدې سمدلاسه لاندې ستونزه وپیژندل شوه: د راجسټری خدماتو لپاره پوډونه په چټکۍ سره پیل شول ، مګر د صدیقیق لپاره د پوډونو پیل کول تر دې وخته پورې و. . د سایډیک پوډونو لپاره د پیل کولو اوږد وخت یوه مسله رامینځته شوه کله چې موږ د کارګرانو لپاره کوبرنیټس ته د کاري بارونو مهاجرت پیل کړ چې د دندو ګړندي پروسس کولو او ګړندي اندازه کولو ته اړتیا لري.
پدې حالت کې، درس دا و چې پداسې حال کې چې د کوبرنیټس افقی پوډ آټوسکلر (HPA) د ترافیک وده په ښه توګه اداره کوي، دا مهمه ده چې د کاري بارونو ځانګړتیاوې په پام کې ونیسئ او پوډونو ته اضافي ظرفیت تخصیص کړئ (په ځانګړې توګه کله چې تقاضا په غیر مساوي ډول ویشل کیږي). زموږ په قضیه کې، په دندو کې ناڅاپه زیاتوالی راغلی، د ګړندۍ اندازه کولو لامل شوی، کوم چې د CPU سرچینو سنتریت لامل شوی مخکې لدې چې موږ د نوډ پول اندازه کولو وخت ولرو.
د کلستر څخه د امکان تر حده د ډیریدو لپاره تل لیوالتیا شتون لري ، په هرصورت ، په پیل کې د فعالیت ستونزو سره مخ شوي ، موږ اوس د سخاوت لرونکي پوډ بودیجې سره پیل کوو او وروسته یې کموو ، په SLOs باندې نږدې نظر ساتو. د سایډیک خدمت لپاره د پوډونو پیل کول د پام وړ ګړندي شوي او اوس په اوسط ډول شاوخوا 40 ثانیې وخت نیسي. دواړه GitLab.com او زموږ د ځان اداره شوي تاسیساتو کارونکي وګټل چې د رسمي ګیټ لیب هیلم چارټ سره کار کوي.
پایلې
د هر خدمت مهاجرت وروسته، موږ په تولید کې د کوبرنیټ کارولو ګټو څخه خوښ یو: ګړندی او خوندي غوښتنلیک ځای په ځای کول، اندازه کول، او د سرچینو ډیر اغیزمن تخصیص. سربیره پردې ، د مهاجرت ګټې د GitLab.com خدمت څخه بهر دي. د رسمي هیلم چارټ کې هر پرمختګ خپلو کاروونکو ته ګټه رسوي.
زه امید لرم چې تاسو زموږ د کبرنیټس مهاجرت سفرونو کیسې څخه خوند اخیستی وي. موږ ټول نوي خدمتونه کلستر ته لیږدولو ته دوام ورکوو. اضافي معلومات په لاندې خپرونو کې موندل کیدی شي:
- «»
- «»
- .
PS د ژباړونکي څخه
زموږ په بلاګ کې هم ولولئ:
- «»
- «»
- «»
- «".
سرچینه: www.habr.com