په کبرنیټس کې د اتوماتیک کولو او سرچینو مدیریت (بیاکتنه او ویډیو راپور)

د اپریل په 27 په کنفرانس کې اعتصاب 2019د "DevOps" برخې برخې په توګه، راپور "په کوبرنیټس کې د اتوماتیک کولو او سرچینو مدیریت" ورکړل شوی. دا پدې اړه خبرې کوي چې تاسو څنګه کولی شئ K8s وکاروئ ترڅو ستاسو د غوښتنلیکونو لوړ شتون ډاډمن کړي او د لوړ فعالیت ډاډ ترلاسه کړي.

د دود له مخې، موږ د وړاندې کولو خوښ یو د راپور ویډیو (44 دقیقې، د مقالې په پرتله ډیر معلوماتي) او اصلي لنډیز د متن بڼه کې. لاړ شه!

راځئ چې د راپور موضوع د کلمې په واسطه تحلیل کړو او له پای څخه پیل وکړو.

کوبنیټس

راځئ چې ووایو موږ په خپل کوربه کې د ډاکر کانټینرونه لرو. د څه لپاره؟ د تکرار وړتیا او انزوا ډاډ ترلاسه کولو لپاره ، کوم چې په پایله کې د ساده او ښه ګمارنې لپاره اجازه ورکوي ، CI/CD. موږ ډیری داسې موټرونه لرو چې کانټینرونه لري.

Kubernetes پدې قضیه کې څه چمتو کوي؟

1. موږ د دې ماشینونو په اړه فکر کول پریږدو او د "بادل" سره کار پیل کوو د کانتینرونو کلستر یا پوډونه (د کانتینرونو ګروپونه).
2. سربیره پردې ، موږ حتی د انفرادي پوډونو په اړه فکر نه کوو ، مګر نور اداره کووоلویې ډلې. داسې د لوړې کچې لومړني موږ ته اجازه راکړئ چې ووایو چې د یو ځانګړي کاري بار چلولو لپاره ټیمپلیټ شتون لري، او دلته د دې چلولو لپاره اړین شمیر مثالونه دي. که موږ وروسته ساننډۍ بدل کړو، ټول مثالونه به بدل شي.
3. د مرستې په مرسته اعلاناتي API د ځانګړو حکمونو د لړۍ د اجرا کولو پر ځای، موږ د "نړۍ جوړښت" (په YAML کې) تشریح کوو، کوم چې د Kubernetes لخوا رامینځته شوی. او بیا: کله چې توضیحات بدل شي ، د هغې اصلي نندارتون به هم بدل شي.

د سرچینو مدیریت

سی پی یو

راځئ چې په سرور کې nginx، php-fpm او mysql چلوو. دا خدمتونه به په حقیقت کې حتی ډیرې پروسې پرمخ وړي، چې هر یو یې کمپیوټري سرچینو ته اړتیا لري:

(په سلایډ کې شمیرې "توتا" دي، د کمپیوټري ځواک لپاره د هرې پروسې خلاصې اړتیا)

د دې سره کار کول اسانه کولو لپاره ، دا منطقي ده چې پروسې په ګروپونو کې سره یوځای کړئ (د مثال په توګه ، ټولې نګینکس پروسې په یوه ګروپ "نګینکس" کې). د دې کولو لپاره یوه ساده او څرګنده لاره دا ده چې هر ګروپ په کانتینر کې واچوئ:

د دوام لپاره، تاسو باید په یاد ولرئ چې کانټینر څه شی دی (په لینکس کې). د دوی ظهور په دانا کې د دریو کلیدي ځانګړتیاو له امله ممکن شوی و، چې ډیر وخت دمخه پلي شوی و: وړتیاوې, نوم ځایونه и ګروپونه. او نور پرمختګ د نورو ټیکنالوژیو لخوا اسانه شوی و (په شمول د مناسب "شیل" لکه ډاکر):

د راپور په شرایطو کې، موږ یوازې لیوالتیا لرو ګروپونه، ځکه چې د کنټرول ګروپونه د کانټینرونو د فعالیت برخه ده (ډاکر، او داسې نور) چې د سرچینو مدیریت پلي کوي. پروسې په ډلو کې یوځای شوي، لکه څنګه چې موږ غوښتل، د کنټرول ډلې دي.

راځئ چې د دې پروسو لپاره د CPU اړتیاوو ته راستون شو، او اوس د پروسو ګروپونو لپاره:

(زه تکراروم چې ټولې شمیرې د سرچینو د اړتیا خلاصې څرګندونې دي)

په ورته وخت کې، CPU پخپله یوه ځانګړې محدوده سرچینه لري (د مثال په توګه دا 1000 دی)، کوم چې هرڅوک یې نه لري (د ټولو ډلو اړتیاو مجموعه 150+850+460=1460 ده). په دې صورت کې به څه وشي؟

کرنل د سرچینو توزیع پیل کوي او دا "عادلانه" کوي ، هرې ډلې ته ورته مقدار سرچینې ورکوي. مګر په لومړي حالت کې، د اړتیا څخه ډیر شتون لري (333> 150)، نو اضافي (333-150 = 183) په زیرمه کې پاتې کیږي، کوم چې د دوو نورو کانټینرونو ترمنځ په مساوي توګه ویشل کیږي:

د پایلې په توګه: لومړی کانټینر کافي سرچینې درلودې ، دوهم - دا کافي سرچینې نه درلودې ، دریم - دا کافي سرچینې نه درلودې. دا د عملونو پایله ده په لینکس کې "صادق" مهالویش کونکی - CFS. د دې عملیات د دندې په کارولو سره تنظیم کیدی شي وزنونه هر یو کانټینر. د مثال په توګه، دا ډول:

راځئ چې په دویم کانټینر کې د سرچینو نشتوالي قضیه وګورو (php-fpm). ټول کانټینر سرچینې د پروسو ترمنځ په مساوي ډول ویشل شوي. د پایلې په توګه، د ماسټر پروسې ښه کار کوي، مګر ټول کارګران ورو کوي، د اړتیا نیمایي څخه لږ ترلاسه کوي:

دا څنګه د CFS مهالویش کار کوي. موږ به نور هغه وزنونه وایو چې موږ کانټینرونو ته ځانګړي کوو غوښتنې. ولې دا داسې ده - نور وګورئ.

راځئ چې ټول وضعیت له بلې خوا وګورو. لکه څنګه چې تاسو پوهیږئ، ټول سړکونه روم ته ځي، او د کمپیوټر په صورت کې، CPU ته. یو CPU، ډیری دندې - تاسو د ترافیک څراغ ته اړتیا لرئ. د سرچینو اداره کولو لپاره ترټولو ساده لاره د "ټرافيک رڼا" ده: دوی یوې پروسې ته CPU ته د لاسرسي ثابت وخت ورکړ، بیا بل، او داسې نور.

دا طریقه د سختو کوټو په نوم یادیږي (سخت محدودیت). راځئ چې دا په ساده ډول یاد کړو حدود. په هرصورت، که تاسو ټولو کانټینرونو ته محدودیتونه وویشئ، یوه ستونزه رامنځ ته کیږي: mysql د سړک په اوږدو کې موټر چلوي او په یو وخت کې د CPU اړتیا پای ته رسیدلې، مګر نورې ټولې پروسې مجبور دي چې د CPU لپاره انتظار وکړي. بې کاره.

راځئ چې د لینکس کرنل ته راستون شو او د CPU سره یې تعامل - ټولیز انځور په لاندې ډول دی:

cgroup دوه ترتیبات لري - په اصل کې دا دوه ساده "موټرونه" دي چې تاسو ته اجازه درکوي مشخص کړئ:

1. د کانټینر وزن (غوښتنې) دی د سهم;
2. د کانټینر په کارونو کې د کار کولو لپاره د CPU ټول وخت سلنه (حدودونه) دي کوټه.

د CPU اندازه کول څنګه؟

مختلفې لارې شتون لري:

1. څه توتونه، هیڅوک نه پوهیږي - تاسو اړتیا لرئ هر وخت خبرې اترې وکړئ.
2. سود روښانه، مګر نسبي: د سرور 50٪ د 4 کورونو سره او 20 کور سره په بشپړ ډول مختلف شیان دي.
3. تاسو کولی شئ هغه څه وکاروئ چې دمخه یې یادونه شوې وزنونه، کوم چې لینکس پیژني، مګر دوی هم خپلوي دي.
4. ترټولو مناسب انتخاب د کمپیوټري سرچینو اندازه کول دي ثانیې. هغوی. د پروسیسر وخت په ثانیو کې د ریښتیني وخت ثانیو په پرتله: د پروسیسر وخت 1 ثانیې په هر 1 ریښتیني ثانیه کې ورکړل شوی - دا یو بشپړ CPU کور دی.

د دې لپاره چې خبرې کول خورا اسانه کړي، دوی په مستقیم ډول اندازه کول پیل کړل دانه، د دوی لخوا معنی د ریښتیني سره ورته CPU وخت. څرنګه چې لینکس په وزن پوهیږي، مګر دومره د CPU وخت / کورونه ندي، یو میکانیزم ته اړتیا وه چې له یو څخه بل ته ژباړل شي.

راځئ چې د 3 CPU کورونو سره د سرور سره یو ساده مثال په پام کې ونیسو ، چیرې چې درې پوډونه به وزن (500، 1000 او 1500) ورکړل شي چې په اسانۍ سره د دوی لپاره تخصیص شوي کور ورته برخو ته بدلیږي (0,5، 1 او 1,5).

که تاسو دویم سرور واخلئ، چیرې چې دوه ځله ډیری کورونه (6) وي، او ورته پوډونه هلته ځای په ځای کړئ، د کور ویش په اسانۍ سره په 2 (1، 2 او 3، په ترتیب سره) په ضرب کولو سره محاسبه کیدی شي. مګر یوه مهمه شیبه هغه وخت رامینځته کیږي کله چې پدې سرور کې څلورم پوډ څرګند شي ، چې وزن به یې د اسانتیا لپاره 3000 وي. دا د CPU سرچینو برخه اخلي (نیم کورونه) ، او د پاتې پوډونو لپاره دوی بیا محاسبه کیږي (نیمه برخه):

Kubernetes او CPU سرچینې

په Kubernetes کې، د CPU سرچینې معمولا اندازه کیږي ملیاډراکس, i.e. 0,001 کور د اساس وزن په توګه اخیستل کیږي. (په لینکس/cgroups اصطلاحاتو کې ورته شی د CPU شریک ویل کیږي، که څه هم، په دقیق ډول، 1000 ملیکورز = 1024 CPU شریکول.) K8s ډاډ ورکوي چې دا په سرور کې د ټولو پوډونو وزنونو مجموعې لپاره د CPU سرچینو په پرتله ډیر پوډونه نه ځای په ځای کوي.

دا څنګه کیږي؟ کله چې تاسو د Kubernetes کلستر ته سرور اضافه کړئ، نو راپور ورکول کیږي چې څومره CPU کورونه شتون لري. او کله چې یو نوی پوډ رامینځته کړئ ، د کوبرنیټس شیډولر پوهیږي چې دا پوډ به څومره کور ته اړتیا ولري. په دې توګه، پوډ به یو سرور ته وټاکل شي چیرې چې کافي کورونه شتون لري.

که څه به پیښ شي نه غوښتنه مشخصه شوې ده (د بیلګې په توګه پوډ د کور ټاکل شوي شمیر نلري چې ورته اړتیا لري)؟ راځئ چې معلومه کړو چې Kubernetes څنګه عموما سرچینې حسابوي.

د پوډ لپاره تاسو کولی شئ دواړه غوښتنې مشخص کړئ (CFS مهالویش کونکي) او حدود (د ترافیک څراغ په یاد ولرئ؟):

• که دوی مساوي مشخص شوي وي، نو پوډ د QoS ټولګي ګمارل کیږي تضمين. د کور دا شمیر تل د دې لپاره شتون لري تضمین شوی.
• که غوښتنه د حد څخه کمه وي - QoS ټولګي د سوځولو وړ. هغوی. موږ د پوډ تمه لرو، د بیلګې په توګه، تل د 1 کور کاروئ، مګر دا ارزښت د دې لپاره محدودیت ندی: ورپسې پوډ کولی شي ډیر کار واخلي (کله چې سرور د دې لپاره وړیا سرچینې ولري).
• د QoS ټولګي هم شتون لري غوره هڅه - پدې کې هغه پوډونه شامل دي چې غوښتنه یې نه ده مشخص شوې. سرچینې دوی ته وروستی ورکول کیږي.

حافظه

د حافظې سره، وضعیت ورته دی، مګر یو څه توپیر لري - وروسته له دې، د دې سرچینو طبیعت توپیر لري. په عموم کې، ورته والی په لاندې ډول دی:

راځئ وګورو چې غوښتنې څنګه په حافظه کې پلي کیږي. پریږدئ چې پوډونه په سرور کې ژوند وکړي، د حافظې مصرف بدل کړي، تر هغه چې یو یې دومره لوی شي چې د حافظې څخه تیریږي. په دې حالت کې، د OOM وژونکی ښکاري او ترټولو لویه پروسه وژني:

دا تل موږ ته مناسب نه دی، نو دا ممکنه ده چې تنظیم کړو چې کومې پروسې زموږ لپاره مهم دي او باید ونه وژل شي. د دې کولو لپاره، پیرامیټر وکاروئ oom_score_adj.

راځئ چې د CPU QoS ټولګیو ته راستون شو او د oom_score_adj ارزښتونو سره ورته والی راوباسئ چې د پوډونو لپاره د حافظې مصرف لومړیتوبونه ټاکي:

• د پوډ لپاره ترټولو ټیټ oom_score_adj ارزښت - -998 - پدې معنی چې دا ډول پوډ باید وروستی وژل شي، دا تضمين.
• تر ټولو لوړ - 1000 - دی غوره هڅهدا ډول پوزې لومړی وژل کیږي.
• د پاتې ارزښتونو محاسبه کولو لپاره (د سوځولو وړ) دلته یو فورمول شتون لري، کوم چې د دې حقیقت حقیقت ته رسوي چې پوډ د ډیرو سرچینو غوښتنه کړې، د وژلو احتمال یې لږ دی.

دوهم "مړ" - limit_in_bytes - د محدودیتونو لپاره. د دې سره ، هرڅه ساده دي: موږ په ساده ډول د جاري شوي حافظې اعظمي اندازه ګمارو ، او دلته (د CPU برعکس) د دې (یاد) اندازه کولو څرنګوالي په اړه هیڅ پوښتنه نشته.

ټول

په Kubernetes کې هر پوډ ورکول کیږي requests и limits - د CPU او حافظې لپاره دواړه پیرامیټونه:

1. د غوښتنو پراساس، د Kubernetes مهالویش کار کوي، کوم چې د سرورونو ترمنځ پوډونه توزیع کوي؛
2. د ټولو پیرامیټونو پراساس، د پوډ QoS ټولګي ټاکل کیږي؛
3. اړوند وزنونه د CPU غوښتنو پراساس محاسبه کیږي؛
4. د CFS مهالویش د CPU غوښتنو پراساس ترتیب شوی؛
5. د OOM قاتل د حافظې غوښتنو پراساس ترتیب شوی؛
6. د "ټرافيک څراغ" د CPU حدودو پراساس ترتیب شوی؛
7. د حافظې د محدودیتونو پراساس، یو حد د cgroup لپاره ترتیب شوی.

په عموم کې، دا انځور ټولو پوښتنو ته ځواب ورکوي چې څنګه د سرچینې مدیریت اصلي برخه په Kubernetes کې واقع کیږي.

اتوماتیک کول

K8s کلستر-آټوسکلر

راځئ تصور وکړو چې ټول کلستر لا دمخه نیول شوی او یو نوی پوډ رامینځته کولو ته اړتیا لري. پداسې حال کې چې پوډ نشي ښکاره کیدی، دا په حالت کې ځړول کیږي په تمه. د دې لپاره چې دا ښکاره شي، موږ کولی شو یو نوی سرور کلستر ته وصل کړو یا د کلستر-آټوسکلر نصب کړو، کوم چې دا به زموږ لپاره وکړي: د کلاوډ چمتو کونکي څخه یو مجازی ماشین امر کړئ (د API غوښتنې په کارولو سره) او دا کلستر سره وصل کړئ. له هغې وروسته به پوډ اضافه شي.

دا د کبرنیټس کلستر اتوماتیک کول دي ، کوم چې عالي کار کوي (زموږ په تجربه کې). په هرصورت، د نورو ځایونو په څیر، دلته ځینې لنډیزونه شتون لري ...

تر هغه چې موږ د کلستر اندازه زیاته کړه، هرڅه سم وو، مګر څه پیښیږي کله چې کلستر خپل ځان خلاصول پیل کړل؟ ستونزه دا ده چې د پوډونو مهاجرت (د کوربه خلاصولو لپاره) د سرچینو په شرایطو کې خورا تخنیکي ستونزمن او ګران دی. Kubernetes یو بشپړ مختلف طریقه کاروي.

د 3 سرورونو کلستر په پام کې ونیسئ چې ځای پرځای کول لري. دا 6 پوډونه لري: اوس د هر سرور لپاره 2 شتون لري. د ځینو دلیلونو لپاره موږ غوښتل یو له سرورونو څخه بند کړو. د دې کولو لپاره موږ به کمانډ وکاروو kubectl drainکوم چې:

• دې سرور ته د نوي پوډونو لیږل منع کوي؛
• په سرور کې موجود پوډونه به حذف کړي.

څرنګه چې Kubernetes د پوډونو شمیر (6) ساتلو مسولیت لري، دا په ساده ډول بیا به جوړ کړي دوی په نورو نوډونو کې، مګر په هغه کې نه چې معیوب شوي وي، ځکه چې دا دمخه د نوي پوډونو کوربه کولو لپاره شتون نلري. دا د Kubernetes لپاره یو بنسټیز میخانیک دی.

په هرصورت، دلته یو اهمیت هم شتون لري. په ورته حالت کې، د StatefulSet لپاره (د ځای پرځای کولو پرځای)، کړنې به توپیر ولري. اوس موږ دمخه یو دولتي غوښتنلیک لرو - د مثال په توګه ، د MongoDB سره درې پوډونه ، چې یو یې یو ډول ستونزه لري (ډیټا فاسد شوې یا بله تېروتنه چې د پوډ په سمه توګه پیل کولو مخه نیسي). او موږ بیا پریکړه کوو چې یو سرور غیر فعال کړو. څه به وشي؟

MongoDB کولای die ځکه چې دا کورم ته اړتیا لري: د دریو نصبونو کلستر لپاره، لږترلږه دوه باید کار وکړي. په هرصورت، دا نه پیښیږي - مننه PodDisruptionBudget. دا پیرامیټر د کاري پوډونو لږترلږه اړین شمیر ټاکي. په دې پوهیدل چې د MongoDB پوډونو څخه یو یې نور کار نه کوي، او وګورئ چې د پوډ ډیسپشن بودیجه د MongoDB لپاره ټاکل شوې ده minAvailable: 2، Kubernetes به تاسو ته اجازه ورنکړي چې یو پوډ حذف کړئ.

لاندینۍ کرښه: د دې لپاره چې د پوډونو حرکت (او په حقیقت کې بیا جوړونه) په سمه توګه کار وکړي کله چې کلستر خوشې شي، دا اړینه ده چې د PodDisruptionBudget تنظیم کړئ.

افقی اندازه کول

راځئ چې یو بل حالت ته پام وکړو. دلته یو غوښتنلیک شتون لري چې په Kubernetes کې د ځای پرځای کولو په توګه روان دی. د کارونکي ترافیک خپلو پوډونو ته راځي (د مثال په توګه ، له دوی څخه درې شتون لري) ، او موږ په دوی کې یو مشخص شاخص اندازه کوو (وایی ، د CPU بار). کله چې بار زیات شي، موږ دا په مهالویش کې ثبت کوو او د غوښتنو توزیع کولو لپاره د پوډونو شمیر ډیروو.

نن ورځ په کوبرنیټس کې دا په لاسي ډول ترسره کولو ته اړتیا نلري: د پوډونو په شمیر کې اتوماتیک زیاتوالی / کمول د اندازه شوي بار شاخصونو ارزښتونو پورې اړه لري.

اصلي پوښتنې دلته دي: دقیقا څه اندازه کول и څنګه تشریح کول ترلاسه شوي ارزښتونه (د پوډونو شمیر بدلولو پریکړه کولو لپاره). تاسو کولی شئ ډیر اندازه اندازه کړئ:

دا څنګه په تخنیکي ډول ترسره کړئ - میټریکونه راټول کړئ، او نور. - ما په راپور کې په تفصیل سره خبرې وکړې څارنه او Kubernetes. او د غوره پیرامیټونو غوره کولو لپاره اصلي مشوره ده تجربه!

موجود دي د کارولو طریقه (استعمال سنتریت او تېروتنې)، چې معنی یې په لاندې ډول ده. په کوم اساس دا اندازه کول معنی لري، د بیلګې په توګه، php-fpm؟ د دې حقیقت پراساس چې کارګران تیریږي ، دا دی کارول. او که کارګران ختم شي او نوې اړیکې ونه منل شي، دا لا دمخه دی سنتری. دا دواړه پیرامیټونه باید اندازه شي، او د ارزښتونو پورې اړه لري، اندازه کول باید ترسره شي.

پر ځای د يو پایلې

راپور دوام لري: د عمودی اندازه کولو په اړه او د سمې سرچینې غوره کولو څرنګوالی. زه به پدې اړه په راتلونکو ویډیوګانو کې خبرې وکړم زموږ یوټیوب - ګډون وکړئ ترڅو تاسو له لاسه ورنکړئ!

ویډیوګانې او سلایډونه

د فعالیت څخه ویډیو (44 دقیقې):

د راپور وړاندې کول:

PS

زموږ په بلاګ کې د کبرنیټس په اړه نور راپورونه:

• «د Kubernetes پراخول او تکمیل کول» (انډری پولوف؛ د اپریل 8، 2019 په سینټ های لوډ++ کې);
• «ډیټابیسونه او کبرنیټس» (دیمیتري سټولیاروف؛ د نومبر 8، 2018 په HighLoad++);
• «څارنه او Kubernetes» (دیمیتري سټولیاروف؛ د می 28، 2018 په RootConf کې);
• «CI/CD د Kubernetes او GitLab سره غوره تمرینونه» (دیمیتري سټولیاروف؛ د نومبر 7، 2017 په HighLoad++);
• «په کوچنیو پروژو کې د کوبرنیټس سره زموږ تجربه» (دیمیتري سټولیاروف؛ د جون 6، 2017 په RootConf کې).

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