په 2016 کې بیرته موږ په بفر کې ، او اوس شاوخوا 60 نوډونه (په AWS کې) او 1500 کانټینرونه زموږ د k8s کلستر لخوا اداره کیږي . په هرصورت، موږ د آزموینې او تېروتنې له لارې مایکرو خدماتو ته لاړ، او حتی د k8s سره د څو کلونو کار کولو وروسته موږ لاهم د نوي ستونزو سره مخ یو. پدې پوسټ کې به موږ په اړه خبرې وکړو پروسیسر محدودیتونه: ولې موږ فکر کاوه چې دوی ښه عمل دی او ولې دوی دومره ښه نه دي.
د پروسیسر محدودیتونه او تخته کول
د ډیری نورو Kubernetes کاروونکو په څیر، . د داسې ترتیب پرته، په نوډ کې کانټینرونه کولی شي د پروسیسر ټول ځواک واخلي، کوم چې په پایله کې د مهمو Kubernetes پروسې لامل کیږي (د مثال په توګه kubelet) به غوښتنو ته د ځواب ویلو مخه ونیسي. په دې توګه، د CPU حدود تنظیم کول ستاسو د نوډونو ساتلو لپاره یوه ښه لار ده.
د پروسیسر محدودیتونه یو کانټینر د اعظمي CPU وخت ته ټاکي چې دا د یوې ځانګړې مودې لپاره کارول کیدی شي (ډیفالټ 100ms دی) ، او کانټینر به هیڅکله له دې حد څخه ډیر نشي. په Kubernetes کې د دې لپاره throttling کانټینر او د حد څخه د تیریدو مخه نیسي، یو ځانګړی وسیله کارول کیږي ، مګر دا مصنوعي CPU محدودیتونه پای ته رسوي فعالیت ته زیان رسوي او ستاسو د کانټینرونو غبرګون وخت زیاتوي.
څه پیښ کیدی شي که چیرې موږ د پروسیسر محدودیتونه ونه ټاکلو؟
له بده مرغه، موږ پخپله له دې ستونزې سره مخ وو. هر نوډ یوه پروسه لري چې د کانټینرونو اداره کولو مسؤلیت لري kubelet، او هغه غوښتنو ته ځواب ویل بند کړل. نوډ، کله چې دا پیښ شي، دولت ته ځي NotReady، او له دې څخه کانټینرونه به بل چیرې لیږدول کیږي او په نوي نوډونو کې ورته ستونزې رامینځته کوي. یو مثالی سناریو نه ده، لږترلږه ووایاست.
د فشار او غبرګون د ستونزې څرګندول
د کانټینر تعقیب لپاره کلیدي میټریک دی trottling، دا ښیي چې ستاسو کانټینر څو ځله درول شوی. موږ په علاقه سره په ځینو کانټینرونو کې د تروټلینګ شتون ولیدل ، پرته لدې چې د پروسیسر بار خورا ډیر و یا نه. د مثال په توګه، راځئ چې زموږ یو له اصلي APIs څخه وګورو:
لکه څنګه چې تاسو لاندې لیدلی شئ، موږ حد ټاکلی دی 800m (0.8 یا 80٪ اصلي)، او په غوره رسیدو کې لوړ ارزښتونه 200m (20٪ اصلي). داسې بریښي چې د خدماتو د بندولو دمخه موږ لاهم د پروسیسر ځواک لرو ، په هرصورت ...
تاسو شاید لیدلي وي چې حتی کله چې د پروسیسر بار له ټاکل شوي حد څخه ښکته وي - د پام وړ لاندې - تروټل کول لاهم پیښیږي.
د دې سره مخ شو، موږ ډیر ژر ډیری سرچینې کشف کړې (, , ) د ټراټینګ له امله د خدماتو د فعالیت او غبرګون وخت کمیدو په اړه.
ولې موږ په ټیټ CPU بار کې throttling ګورو؟ لنډه نسخه دا ده: "د لینکس کرنل کې یوه بګ شتون لري چې د ځانګړي پروسیسر محدودیتونو سره د کانټینرونو غیر ضروري فشار لامل کیږي." که تاسو د ستونزې نوعیت سره علاقه لرئ، تاسو کولی شئ پریزنټشن ولولئ ( и اختیارونه) د ډیو چیلک لخوا.
د CPU محدودیتونه لرې کول (د خورا احتیاط سره)
د اوږدو بحثونو وروسته، موږ پریکړه وکړه چې د ټولو خدماتو څخه د پروسیسر محدودیتونه لرې کړو چې په مستقیم یا غیر مستقیم ډول زموږ د کاروونکو لپاره مهم فعالیت اغیزه کوي.
پریکړه اسانه نه وه ځکه چې موږ د خپل کلستر ثبات ته ډیر ارزښت ورکوو. په تیرو کې، موږ دمخه د خپل کلستر د بې ثباتۍ سره تجربه کړې، او بیا خدماتو ډیرې سرچینې مصرف کړې او د دوی ټول نوډ کار سست کړی. اوس هرڅه یو څه توپیر درلود: موږ د خپلو کلسترونو څخه د هغه څه په اړه روښانه پوهه درلوده چې موږ یې تمه درلوده، او همدارنګه د پالن شوي بدلونونو پلي کولو لپاره ښه ستراتیژي.
د یوې مهمې مسلې په اړه سوداګریز لیکونه.
څنګه خپل نوډونه خوندي کړئ کله چې محدودیتونه لرې شي؟
د "غیر محدود" خدماتو جلا کول:
په تیرو کې، موږ دمخه لیدلي چې ځینې نوډونه یو حالت ته راځي notReady، په عمده توګه د خدماتو له امله چې ډیرې سرچینې مصرفوي.
موږ پریکړه وکړه چې دا ډول خدمات په جلا ("لیبل شوي") نوډونو کې ځای په ځای کړو ترڅو دوی په "اړونده" خدماتو کې مداخله ونه کړي. د پایلې په توګه، د ځینو نوډونو په نښه کولو او "غیر اړونده" خدماتو کې د زغم پیرامیټر اضافه کولو سره، موږ په کلستر باندې ډیر کنټرول ترلاسه کړ، او دا زموږ لپاره اسانه شوه چې د نوډونو سره ستونزې وپیژنو. د ورته پروسې د ترسره کولو لپاره، تاسو کولی شئ خپل ځان وپیژنئ .
د سم پروسیسر او حافظې غوښتنه ټاکل:
زموږ ترټولو لوی ویره دا وه چې پروسه به ډیرې سرچینې مصرف کړي او نوډ به غوښتنو ته ځواب ووایی. له اوس راهیسې (د Datadog څخه مننه) موږ کولی شو په روښانه ډول زموږ په کلستر کې ټول خدمات وڅیړو، ما د هغو څو میاشتو عملیات تحلیل کړل چې موږ یې د "غیر اړونده" په توګه ټاکلو پالن درلود. ما په ساده ډول د CPU اعظمي کارول د 20٪ حاشیې سره تنظیم کړل ، او پدې توګه په نوډ کې ځای تخصیص شو په هغه صورت کې چې k8s هڅه کوي نوډ ته نور خدمات وړاندې کړي.
لکه څنګه چې تاسو په ګراف کې لیدلی شئ، په پروسیسر کې اعظمي بار ته رسیدلی 242m د CPU کور (0.242 پروسیسر کورونه). د پروسیسر غوښتنې لپاره، دا د دې ارزښت څخه یو څه لوی شمیر اخیستل کافي دي. مهرباني وکړئ په یاد ولرئ ځکه چې خدمات د کارونکي متمرکز دي، د لوړ بار ارزښتونه د ټرافیک سره سمون لري.
د حافظې کارولو او پوښتنو سره ورته کار وکړئ ، او وایلا - تاسو ټول تنظیم شوي یاست! د ډیر امنیت لپاره، تاسو کولی شئ افقی پوډ اتوماتیک اضافه کړئ. په دې توګه، هرکله چې د سرچینو بار لوړ وي، اتوماتیک کول به نوي پوډونه رامینځته کړي، او کبرنیټس به یې د خالي ځای سره نوډونو ته توزیع کړي. په هغه صورت کې چې پخپله کلستر کې هیڅ ځای پاتې نه وي، تاسو کولی شئ خپل ځان ته خبرتیا ترتیب کړئ یا د نوي نوډونو اضافه کول د دوی د اتوماتیک کولو له لارې تنظیم کړئ.
د نیمګړتیاوو څخه، دا د یادونې وړ ده چې موږ په "کې له لاسه ورکړ."، i.e. د کانټینرونو شمیر چې په یو نوډ کې روان دي. موږ ممکن د ټیټ ترافیک کثافت کې ډیری "آرامونه" هم ولرو، او دا امکان هم شتون لري چې تاسو به د پروسیسر لوړ بار ته ورسیږئ، مګر د اتوماتیک نوډونه باید د وروستي سره مرسته وکړي.
پایلې
زه خوښ یم چې په تیرو څو اونیو کې د تجربو څخه دا غوره پایلې خپروم؛ موږ دمخه د ټولو ترمیم شوي خدماتو په ځواب کې د پام وړ پرمختګونه لیدلي دي:
موږ په خپل کور پاڼه کې غوره پایلې ترلاسه کړې ()، هلته خدمت ګړندی شو دوه دوه ځله!
ایا د لینکس کرنل بګ حل شوی؟
هو، د توزیع نسخه 4.19 او لوړ.
په هرصورت، په لوستلو سره د 2020 کال د سپتمبر دویمه لپاره موږ لاهم د ورته بګ سره د ځینې لینکس پروژو یادونه کوو. زه باور لرم چې د لینکس ځینې توزیعونه لاهم دا بګ لري او یوازې د دې په حل کولو کار کوي.
که ستاسو د توزیع نسخه له 4.19 څخه ټیټه وي ، زه به وروستي ته د تازه کولو وړاندیز وکړم ، مګر په هر حالت کې تاسو باید د پروسیسر محدودیتونو لرې کولو هڅه وکړئ او وګورئ چې فشار دوام لري. لاندې تاسو کولی شئ د Kubernetes مدیریت خدماتو او لینکس توزیع جزوي لیست وګورئ:
- دبیان: فکس د توزیع وروستي نسخه کې مدغم شوی، ، او خورا تازه ښکاري (). ځینې پخوانۍ نسخې ممکن هم ثابتې شي.
- اوبنټو: فکس په وروستي نسخه کې مدغم شوی
- EKS لا تر اوسه حل کړی دی . که ستاسو نسخه له دې څخه ټیټه وي، تاسو باید AMI تازه کړئ.
- کوپس: у
kops 1.18+اصلي کوربه عکس به د اوبنټو 20.04 وي. که ستاسو د کوپس نسخه زوړ وي، تاسو ممکن د حل لپاره انتظار وکړئ. موږ پخپله اوس انتظار کوو. - GKE (ګوګل کلاوډ): فکس مدغم په هرصورت، د throttling سره ستونزې شتون لري .
څه باید وکړو که چیرې فکس د throttling ستونزه حل کړي؟
زه ډاډه نه یم چې ستونزه په بشپړه توګه حل شوې ده. کله چې موږ د فکس سره د کرنل نسخې ته ورسیږو، زه به کلستر ازموینه وکړم او پوسټ به تازه کړم. که چا لا دمخه تازه کړی وي، زه لیواله یم چې ستاسو پایلې ولولم.
پایلې
- که تاسو د لینکس لاندې د ډاکر کانټینرونو سره کار کوئ (هیڅ اهمیت نلري کوبرنیټس، میسوس، سوارم یا نور)، ستاسو کانټینرونه ممکن د ټروټلینګ له امله فعالیت له لاسه ورکړي؛
- هڅه وکړئ د خپل توزیع وروستي نسخه ته تازه کړئ په دې هیله چې بګ لا دمخه حل شوی وي؛
- د پروسیسر محدودیتونه لرې کول به ستونزه حل کړي، مګر دا یو خطرناک تخنیک دی چې باید د خورا احتیاط سره وکارول شي (دا غوره ده چې لومړی د کرنل تازه کړئ او پایلې پرتله کړئ)؛
- که تاسو د CPU محدودیتونه لرې کړي وي، د خپل CPU او حافظې کارول په دقت سره وڅارئ او ډاډ ترلاسه کړئ چې ستاسو د CPU سرچینې ستاسو له مصرف څخه زیاتې دي؛
- یو خوندي اختیار به د پوډونو اتوماتیک کول وي ترڅو د لوړ هارډویر بار په صورت کې نوي پوډونه رامینځته کړي ، نو ځکه چې کبرنیټس دوی وړیا نوډونو ته ګماري.
زه امید لرم چې دا پوسټ تاسو سره ستاسو د کانټینر سیسټمونو فعالیت ښه کولو کې مرسته کوي.
PS لیکوال د لوستونکو او مبصرینو سره مطابقت لري (په انګلیسي کې).
سرچینه: www.habr.com