نو ڪبرنيٽس ڪارڪردگي جا طريقا

هيلو سڀ! منهنجو نالو Oleg Sidorenkov آهي، مان ڪم ڪريان ٿو DomClick ۾ بنيادي ڍانچي جي ٽيم جي سربراهه طور. اسان ٽن سالن کان وڌيڪ عرصي تائين پيداوار ۾ ڪوبڪ استعمال ڪري رهيا آهيون، ۽ ان دوران اسان ان سان گڏ ڪيترائي مختلف دلچسپ لمحات تجربا ڪيا آهن. اڄ مان توهان کي ٻڌايان ٿو ته ڪيئن، صحيح طريقي سان، توهان پنهنجي ڪلستر لاء وينلا ڪبرنيٽس مان اڃا به وڌيڪ ڪارڪردگي نچوض ڪري سگهو ٿا. تيار، مستحڪم وڃڻ!

توهان سڀ چڱيءَ طرح ڄاڻو ٿا ته ڪبرنيٽس ڪنٽينر آرڪيسٽريشن لاءِ هڪ اسپيبلبل اوپن سورس سسٽم آهي. سٺو، يا 5 بائنري جيڪي جادو ڪم ڪن ٿيون توهان جي مائڪرو سروسز جي زندگي جي چڪر کي منظم ڪندي سرور ماحول ۾. ان کان علاوه، اهو هڪ ڪافي لچڪدار اوزار آهي جيڪو مختلف ڪمن لاءِ وڌ ۾ وڌ ڪسٽمائيزيشن لاءِ ليگو وانگر گڏ ڪري سگهجي ٿو.

۽ سڀ ڪجھ ٺيڪ ٿيڻ لڳي ٿو: سرورز کي ڪلستر ۾ اڇليو جيئن باھ جي ڪاٺ ۾ فائر باڪس ۾، ۽ توھان کي ڪو ڏک نه ٿيندو. پر جيڪڏھن توھان ماحول لاءِ آھيو، توھان سوچيندؤ: ”آئون ڪيئن باھ کي ٻرندڙ رکان ۽ ٻيلي کي بچائي سگھان؟ ٻين لفظن ۾، انفراسٹرڪچر کي بهتر ڪرڻ ۽ خرچن کي گهٽائڻ جا طريقا ڪيئن ڳولي سگهجن ٿا.

1. مانيٽر ٽيم ۽ ايپليڪيشن وسيلن

سڀ کان وڌيڪ عام، پر اثرائتي طريقن مان هڪ آهي درخواستن / حدن جو تعارف. ايپليڪيشنن کي ورهايو نالا اسپيسز، ۽ نالن جي اسپيسز پاران ڊولپمينٽ ٽيمن پاران. ترتيب ڏيڻ کان اڳ، پروسيسر جي وقت، ياداشت، ۽ عارضي اسٽوريج جي استعمال لاء ايپليڪيشن جي قيمت مقرر ڪريو.

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

تجربي جي ذريعي، اسان ان نتيجي تي پهتاسين: توهان کي حدن کان درخواستن کي ٻه ڀيرا وڌيڪ نه وڌائڻ گهرجي. ڪلستر جو حجم درخواستن جي بنياد تي ڳڻيو ويندو آهي، ۽ جيڪڏهن توهان ايپليڪيشنن کي وسيلن ۾ فرق ڏيو ٿا، مثال طور، 5-10 ڀيرا، پوء تصور ڪريو ته توهان جي نوڊ جو ڇا ٿيندو جڏهن اهو پوڊن سان ڀريو ويندو آهي ۽ اوچتو لوڊ حاصل ڪري ٿو. ڪجھ به نه سٺو. گھٽ ۾ گھٽ، ٿلهي ۽ وڌ ۾ وڌ، توهان ڪم ڪندڙ کي الوداع چوندا ۽ پوڊ هلڻ شروع ٿيڻ کان پوءِ باقي نوڊس تي هڪ سائيڪل لوڊ حاصل ڪندا.

ان کان علاوه، مدد سان limitranges شروع ۾، توھان سيٽ ڪري سگھوٿا وسيلا قيمتون ڪنٽينر لاءِ - گھٽ ۾ گھٽ، وڌ ۾ وڌ ۽ ڊفالٽ:

➜  ~ kubectl describe limitranges --namespace ops
Name:       limit-range
Namespace:  ops
Type        Resource           Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------           ---   ---   ---------------  -------------  -----------------------
Container   cpu                50m   10    100m             100m           2
Container   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -
Container   memory             64Mi  40Gi  128Mi            128Mi          2

نالي جي جڳھ جي وسيلن کي محدود ڪرڻ نه وساريو ته جيئن ھڪڙي ٽيم ڪلستر جي سڀني وسيلن تي قبضو نه ڪري سگھي:

➜  ~ kubectl describe resourcequotas --namespace ops
Name:                   resource-quota
Namespace:              ops
Resource                Used          Hard
--------                ----          ----
limits.cpu              77250m        80
limits.memory           124814367488  150Gi
pods                    31            45
requests.cpu            53850m        80
requests.memory         75613234944   150Gi
services                26            50
services.loadbalancers  0             0
services.nodeports      0             0

جيئن ته وضاحت مان ڏسي سگهجي ٿو resourcequotas، جيڪڏهن ops ٽيم پوڊس کي ترتيب ڏيڻ چاهي ٿي جيڪا ٻي 10 سي پي يو کي استعمال ڪندي، شيڊيولر ان جي اجازت نه ڏيندو ۽ هڪ غلطي اڇلائي ڇڏيندو:

Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10

اهڙي مسئلي کي حل ڪرڻ لاء، توهان هڪ اوزار لکي سگهو ٿا، مثال طور، جهڙوڪ هي، ڪمانڊ وسيلن جي حالت کي ذخيرو ڪرڻ ۽ انجام ڏيڻ جي قابل.

2. بهترين فائل اسٽوريج چونڊيو

هتي آئون مسلسل حجم جي موضوع تي رابطو ڪرڻ چاهيندس ۽ ڪبرنيٽس ڪم ڪندڙ نوڊس جي ڊسڪ سبسسٽم. مون کي اميد آهي ته ڪو به استعمال نه ڪندو “ڪيوب” پيداوار ۾ HDD تي، پر ڪڏهن ڪڏهن هڪ باقاعده SSD هاڻي ڪافي نه آهي. اسان هڪ مسئلو پيش ڪيو جتي لاگ ان ڊسڪ کي ختم ڪري رهيا هئا I/O عملن جي ڪري، ۽ اتي ڪيترائي حل نه آهن:

• اعلي ڪارڪردگي SSDs استعمال ڪريو يا NVMe ڏانھن وڃو (جيڪڏھن توھان پنھنجي هارڊويئر کي منظم ڪريو).

• لاگنگ جي سطح کي گھٽايو.

• پوڊس جو "سمارٽ" توازن ڪريو جيڪي ڊسڪ کي ريپ ڪن ٿا (podAntiAffinity).

مٿي ڏنل اسڪرين ڏيکاري ٿي ته ڊسڪ تي nginx-ingress-controller جي تحت ڇا ٿئي ٿو جڏهن access_logs لاگنگ فعال ٿئي ٿي (~ 12 هزار لاگس / سيڪنڊ). اها حالت، يقينا، هن نوڊ تي سڀني ايپليڪيشنن جي تباهي جي ڪري سگھي ٿي.

جيئن ته PV لاء، افسوس، مون هر شيء جي ڪوشش نه ڪئي آهي قسمون مسلسل حجم. بهترين اختيار استعمال ڪريو جيڪو توهان کي مناسب آهي. تاريخي طور تي، اسان جي ملڪ ۾ اهو ٿي چڪو آهي ته خدمتن جو هڪ ننڍڙو حصو RWX حجم جي ضرورت آهي، ۽ هڪ ڊگهو وقت اڳ هن ڪم لاء NFS اسٽوريج استعمال ڪرڻ شروع ڪيو. سستو ۽ ... ڪافي. يقينا، هن ۽ مون گند کائيندا هئا - توهان کي مبارڪ ڏيو، پر اسان ان کي ٽيون ڪرڻ سکيو، ۽ منهنجي مٿي کي وڌيڪ ڏک نه ٿيو. ۽ جيڪڏهن ممڪن هجي، منتقل ڪريو S3 اعتراض اسٽوريج ڏانهن.

3. بهتر تصويرون گڏ ڪريو

اھو بھتر آھي ته ڪنٽينر جون تصويرون استعمال ڪيون وڃن ته جيئن ڪبرنيٽس انھن کي تيزيءَ سان حاصل ڪري سگھن ۽ انھن کي وڌيڪ ڪارائتو بڻائي سگھي. 

Optimized مطلب ته تصويرون:

• صرف هڪ ايپليڪيشن تي مشتمل آهي يا صرف هڪ فنڪشن انجام ڏيو؛

• سائيز ۾ ننڍو، ڇاڪاڻ ته وڏيون تصويرون نيٽ ورڪ تي بدتر منتقل ڪيا ويا آهن؛

• صحت ۽ تياري جا آخري نقطا آهن جيڪي ڪبرنيٽس کي ڪم ڪرڻ جي اجازت ڏين ٿا بند ٿيڻ جي صورت ۾؛

• ڪنٽينر-دوست آپريٽنگ سسٽم استعمال ڪريو (جهڙوڪ الپائن يا CoreOS)، جيڪي ترتيب جي غلطين لاءِ وڌيڪ مزاحمتي آهن؛

• ملٽي اسٽيج تعميرات استعمال ڪريو ته جيئن توهان صرف مرتب ٿيل ايپليڪيشنن کي ترتيب ڏئي سگھو ٿا ۽ نه گڏ ڪيل ذريعن کي.

اهڙا ڪيترائي اوزار ۽ خدمتون آهن جيڪي توهان کي پرواز تي تصويرون چيڪ ڪرڻ ۽ بهتر ڪرڻ جي اجازت ڏين ٿيون. اهو ضروري آهي ته انهن کي هميشه تازه ڪاري ۽ حفاظت لاءِ جانچيو وڃي. نتيجي طور، توهان حاصل ڪندا:

1. سڄي ڪلستر تي نيٽ ورڪ لوڊ گھٽايو.

2. ڪنٽينر جي شروعاتي وقت کي گھٽائڻ.

3. توهان جي پوري ڊاکر رجسٽري جو ننڍو سائيز.

4. DNS ڪيش استعمال ڪريو

جيڪڏهن اسان وڏي لوڊ بابت ڳالهايون ٿا، ته ڪلستر جي ڊي اين ايس سسٽم کي ٽيون ڪرڻ کان سواء زندگي تمام خراب آهي. هڪ دفعي هڪ دفعي، Kubernetes ڊولپرز انهن جي kube-dns حل جي حمايت ڪئي. اهو هتي پڻ لاڳو ڪيو ويو، پر اهو سافٽ ويئر خاص طور تي ٽيون نه ڪيو ويو ۽ گهربل ڪارڪردگي پيدا نه ڪيو، جيتوڻيڪ اهو هڪ آسان ڪم نظر اچي ٿو. پوء coredns ظاهر ٿيو، جنهن کي اسان تبديل ڪيو ۽ ڪو به غم نه هو؛ اهو بعد ۾ K8s ۾ ڊفالٽ ڊي اين ايس سروس بڻجي ويو. ڪجهه نقطي تي، اسان DNS سسٽم ڏانهن 40 هزار rps تائين وڌو، ۽ اهو حل پڻ ڪافي نه ٿيو. پر، قسمت سان، Nodelocaldns ٻاهر آيو، اڪا نوڊ مقامي ڪيش، اڪا NodeLocal DNSCache.

اسان هي ڇو استعمال ڪندا آهيون؟ لينڪس ڪرنل ۾ هڪ بگ آهي ته، جڏهن يو ڊي پي مٿان ڪنٽريڪ NAT ذريعي هڪ کان وڌيڪ ڪالون ٿين ٿيون، ڪنٽريڪ ٽيبلن ۾ داخلائن لاءِ ريس جي حالت جو سبب بڻجي ٿي، ۽ NAT ذريعي ٽريفڪ جو حصو گم ٿي وڃي ٿو (سروس ذريعي هر سفر NAT آهي). Nodelocaldns هن مسئلي کي حل ڪري ٿو NAT کان نجات حاصل ڪرڻ ۽ TCP سان ڪنيڪشن کي اپ گريڊ DNS ڏانهن اپ گريڊ ڪرڻ سان، انهي سان گڏ مقامي طور تي اپ اسٽريم DNS سوالن کي ڪيش ڪرڻ (بشمول هڪ مختصر 5-سيڪنڊ منفي ڪيش).

5. اسڪيل پوڊ افقي طور تي ۽ عمودي طور تي خودڪار طور تي

ڇا توهان يقين سان چئي سگهو ٿا ته توهان جون سڀئي مائڪرو سروسز لوڊ ۾ ٻه کان ٽي ڀيرا واڌ لاءِ تيار آهن؟ توهان جي ايپليڪيشنن لاء وسيلن کي ڪيئن صحيح طور تي مختص ڪجي؟ ڪم جي لوڊشيڊنگ کان ٻاهر هلندڙ ڪجهه پوڊس کي رکڻ بيڪار ٿي سگهي ٿو، پر انهن کي پوئتي پوئتي رکڻ سان سروس ڏانهن ٽرئفڪ ۾ اوچتو اضافو ٿيڻ کان ڊاؤن ٽائم جو خطرو آهي. خدمتون جهڙوڪ افقي پوڊ آٽو اسڪيلر и عمودي پوڊ آٽو اسڪيلر.

وي پي اي توهان کي اصل استعمال جي لحاظ سان پوڊ ۾ توهان جي ڪنٽينرز جي درخواستن / حدن کي خودڪار طور تي وڌائڻ جي اجازت ڏئي ٿي. اهو ڪيئن مفيد ٿي سگهي ٿو؟ جيڪڏهن توهان وٽ پوڊ آهن جيڪي ڪنهن سبب جي ڪري افقي طور تي اسڪيل نٿا ٿي سگهن (جيڪو مڪمل طور تي قابل اعتماد نه آهي)، پوء توهان ڪوشش ڪري سگهو ٿا تبديلين کي ان جي وسيلن ۾ VPA ڏانهن منتقل ڪرڻ. ان جي خصوصيت ميٽرڪ-سرور جي تاريخي ۽ موجوده ڊيٽا تي ٻڌل هڪ سفارشاتي نظام آهي، تنهن ڪري جيڪڏهن توهان خودڪار طريقي سان درخواستن/حدود کي تبديل ڪرڻ نٿا چاهيو، ته توهان صرف پنهنجي ڪنٽينرز لاءِ تجويز ڪيل وسيلن جي نگراني ڪري سگهو ٿا ۽ سي پي يو کي بچائڻ لاءِ سيٽنگون بهتر ڪري سگهو ٿا. ڪلستر ۾ ياداشت.

تصوير https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 تان ورتل تصوير

ڪبرنيٽس ۾ شيڊولر هميشه درخواستن تي ٻڌل آهي. جيڪا به قيمت توهان اتي رکون ٿا، شيڊولر ان جي بنياد تي هڪ مناسب نوڊ جي ڳولا ڪندو. ڪيبلٽ کي سمجھڻ لاءِ حدن جي قيمتن جي ضرورت آھي جڏھن پوڊ کي ٻوڙي يا مارڻ. ۽ جيئن ته صرف اهم پيٽرولر درخواستن جي قيمت آهي، VPA ان سان گڏ ڪم ڪندو. جڏهن به توهان هڪ ايپليڪيشن کي عمودي طور تي ماپ ڪريو ٿا، توهان وضاحت ڪريو ٿا ته درخواستون ڇا هجڻ گهرجن. پوءِ حدن جو ڇا ٿيندو؟ هي پيٽرول پڻ تناسب سان ماپ ڪيو ويندو.

مثال طور، هتي عام پوڊ سيٽنگون آهن:

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

سفارش انجڻ اهو طئي ڪري ٿو ته توهان جي ايپليڪيشن کي 300m CPU ۽ 500Mi جي ضرورت آهي صحيح طريقي سان هلائڻ لاءِ. توھان ھيٺ ڏنل سيٽنگون حاصل ڪندا:

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

جيئن مٿي ذڪر ڪيو ويو آهي، اهو متناسب اسڪيلنگ آهي جنهن جي بنياد تي منشور ۾ درخواستن/حد جي تناسب تي ٻڌل آهي:

• سي پي يو: 200m → 300m: تناسب 1:1.75؛

• ياداشت: 250Mi → 500Mi: تناسب 1:2.

جي حوالي سان هاء، پوء آپريشن جو ميکانيزم وڌيڪ شفاف آهي. ميٽرڪس جهڙوڪ سي پي يو ۽ ميموري حد تائين رکيل آهن، ۽ جيڪڏهن سڀني نقلن جي اوسط حد کان وڌي وڃي ٿي، ايپليڪيشن کي +1 ذيلي طرفان اسڪيل ڪيو ويندو آهي جيستائين قيمت حد کان هيٺ نه اچي يا جيستائين ريپليڪس جو وڌ ۾ وڌ تعداد پهچي وڃي.

تصوير https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 تان ورتل تصوير

CPU ۽ ميموري وانگر معمولي ميٽرڪس کان علاوه، توهان Prometheus کان پنهنجي ڪسٽم ميٽرڪس تي حدون مقرر ڪري سگهو ٿا ۽ انهن سان ڪم ڪري سگهو ٿا جيڪڏهن توهان سوچيو ته اهو سڀ کان وڌيڪ صحيح اشارو آهي جڏهن توهان جي ايپليڪيشن کي اسڪيل ڪرڻو آهي. هڪ دفعو ايپليڪيشن مخصوص ميٽرڪ حد کان هيٺ مستحڪم ٿئي ٿي، HPA پوڊس کي گھٽ ۾ گھٽ نقلن جي تعداد تائين ماپ ڪرڻ شروع ڪندو يا جيستائين لوڊ مخصوص حد تائين پورو نه ٿئي.

6. Node Affinity ۽ Pod Affinity جي باري ۾ نه وساريو

نه سڀئي نوڊس هڪ ئي هارڊويئر تي هلن ٿا، ۽ نه ئي سڀني پوڊس کي ڪمپيوٽي-گھڻي ايپليڪيشنن کي هلائڻ جي ضرورت آهي. ڪبرنيٽس توهان کي استعمال ڪندي نوڊس ۽ پوڊ جي اسپيشلائيزيشن کي ترتيب ڏيڻ جي اجازت ڏئي ٿو نوڊ لاڳاپو и پوڊ لاڳاپو.

جيڪڏهن توهان وٽ نوڊس آهن جيڪي ڪمپيوٽي-گھڻي آپريشن لاءِ موزون آهن، پوءِ وڌ کان وڌ ڪارڪردگيءَ لاءِ اهو بهتر آهي ته ايپليڪيشنن کي لاڳاپيل نوڊس سان ڳنڍجي. هن استعمال ڪرڻ لاء nodeSelector نوڊ ليبل سان.

اچو ته چئو ته توهان وٽ ٻه نوڊس آهن: هڪ سان CPUType=HIGHFREQ ۽ فاسٽ ڪور جو وڏو تعداد، ٻيو سان گڏ MemoryType=HIGHMEMORY وڌيڪ ياداشت ۽ تيز ڪارڪردگي. نوڊ کي ترتيب ڏيڻ جو آسان طريقو آهي HIGHFREQسيڪشن ۾ شامل ڪرڻ سان spec هي چونڊيندڙ:

…
nodeSelector:
	CPUType: HIGHFREQ

اهو ڪرڻ لاء هڪ وڌيڪ قيمتي ۽ مخصوص طريقو استعمال ڪرڻ آهي nodeAffinity ميدان ۾ affinity حصو spec. اتي ٻه اختيار آهن:

• requiredDuringSchedulingIgnoredDuringExecution: سخت سيٽنگ (شيڊيولر صرف مخصوص نوڊس تي پوڊس کي ترتيب ڏيندو (۽ ٻيو ڪٿي به))؛

• preferredDuringSchedulingIgnoredDuringExecution: نرم سيٽنگ (اسڪولر مخصوص نوڊس کي ترتيب ڏيڻ جي ڪوشش ڪندو، ۽ جيڪڏهن اهو ناڪام ٿيندو، اهو ايندڙ دستياب نوڊ تي لڳائڻ جي ڪوشش ڪندو).

توهان نوڊ ليبلز کي منظم ڪرڻ لاء هڪ مخصوص نحو بيان ڪري سگهو ٿا، جهڙوڪ In, NotIn, Exists, DoesNotExist, Gt يا Lt. بهرحال، ياد رکو ته ليبل جي ڊگھي لسٽن ۾ پيچيده طريقا نازڪ حالتن ۾ فيصلا ڪرڻ کي سست ڪندا. ٻين لفظن ۾، سادو رکو.

جيئن مٿي ذڪر ڪيو ويو آهي، ڪبرنيٽس توهان کي موجوده پوڊ جي لاڳاپي کي ترتيب ڏيڻ جي اجازت ڏئي ٿو. اهو آهي، توهان پڪ ڪري سگهو ٿا ته ڪجهه پوڊ ٻين پوڊ سان گڏ ساڳئي دستيابي زون ۾ ڪم ڪن ٿا (بادل لاءِ لاڳاپيل) يا نوڊس.

В podAffinity شعبا affinity حصو spec ساڳيا شعبا موجود آهن جيئن جي صورت ۾ nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. فرق صرف اهو آهي matchExpressions پوڊس کي هڪ نوڊ تي پابند ڪندو جيڪو اڳ ۾ ئي ان ليبل سان پوڊ هلائي رهيو آهي.

ڪبرنيٽس پڻ هڪ فيلڊ پيش ڪري ٿو podAntiAffinity، جيڪو، ان جي برعڪس، پوڊ کي مخصوص پوڊز سان نوڊ تي پابند نٿو ڪري.

اظهار بابت nodeAffinity ساڳي صلاح ڏني وڃي ٿي: ضابطن کي سادو ۽ منطقي رکڻ جي ڪوشش ڪريو، پوڊ جي وضاحت کي اوورلوڊ ڪرڻ جي ڪوشش نه ڪريو ضابطن جي پيچيده سيٽ سان. اهو هڪ قاعدو ٺاهڻ بلڪل آسان آهي جيڪو ڪلستر جي حالتن سان نه ملندو، شيڊولر تي غير ضروري لوڊ ٺاهڻ ۽ مجموعي ڪارڪردگي کي گهٽائڻ.

7. داغ ۽ رواداري

شيڊولر کي منظم ڪرڻ لاء هڪ ٻيو طريقو آهي. جيڪڏهن توهان وٽ سوين نوڊس ۽ هزارين مائڪرو سروسز سان گڏ هڪ وڏو ڪلستر آهي، ته پوءِ اهو تمام ڏکيو آهي ته ڪجهه پوڊس کي ڪجهه نوڊس تي ميزباني ڪرڻ جي اجازت نه ڏيو.

داغ جو ميکانيزم - پابنديون ضابطا - هن سان مدد ڪري ٿي. مثال طور، ڪجهه حالتن ۾ توهان ڪجهه نوڊس کي هلائڻ کان منع ڪري سگهو ٿا. هڪ مخصوص نوڊ تي داغ لاڳو ڪرڻ لاء توهان کي اختيار استعمال ڪرڻ جي ضرورت آهي taint kubectl ۾. چيڪ ۽ قدر بيان ڪريو ۽ پوءِ داغ وانگر NoSchedule يا NoExecute:

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

اهو پڻ قابل ذڪر آهي ته داغ ميڪانيزم ٽن مکيه اثرات جي حمايت ڪري ٿو: NoSchedule, NoExecute и PreferNoSchedule.

• NoSchedule مطلب ته في الحال پوڊ جي وضاحت ۾ ڪو به لاڳاپيل داخلا نه هوندو tolerations، اهو نوڊ تي ترتيب ڏيڻ جي قابل نه هوندو (هن مثال ۾ node10).

• PreferNoSchedule - آسان نسخو NoSchedule. انهي صورت ۾، شيڊولر ڪوشش ڪندو ته پوڊ مختص نه ڪن جن ۾ ملندڙ داخلا نه آهي tolerations في نوڊ، پر هي هڪ سخت حد ناهي. جيڪڏهن ڪلستر ۾ ڪي وسيلا نه آهن، ته پوڊ هن نوڊ تي ترتيب ڏيڻ شروع ڪندا.

• NoExecute - اهو اثر پوڊز جي فوري طور تي نڪرڻ کي شروع ڪري ٿو جن ۾ لاڳاپيل داخلا نه آهي tolerations.

دلچسپ ڳالهه اها آهي ته هي رويو رواداري ميڪانيزم کي استعمال ڪندي منسوخ ڪري سگهجي ٿو. اهو آسان آهي جڏهن اتي هڪ "حرام" نوڊ آهي ۽ توهان کي صرف ان تي انفراسٽرڪچر سروسز رکڻ جي ضرورت آهي. اهو ڪيئن ڪجي؟ صرف انهن پودن کي اجازت ڏيو جن لاء مناسب رواداري موجود آهي.

هتي اهو آهي ته پوڊ جي وضاحت وانگر نظر ايندي:

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

هن جو مطلب اهو ناهي ته ايندڙ ريپلائي هن خاص نوڊ تي ٿي ويندو، هي نوڊ لاڳاپو ميڪانيزم ناهي ۽ nodeSelector. پر ڪيترن ئي خاصيتن کي گڏ ڪندي، توهان حاصل ڪري سگهو ٿا تمام لچڪدار شيڊولر سيٽنگون.

8. پوڊ جي ترتيب جي ترجيح مقرر ڪريو

صرف ان ڪري ته توهان وٽ نوڊس کي مقرر ڪيل پوڊس جو مطلب اهو ناهي ته سڀني پوڊس کي ساڳئي ترجيح سان علاج ڪيو وڃي. مثال طور، توھان چاھيو ٿا ڪجھ پوڊ ٻين کان پھريائين.

ڪبرنيٽس پيش ڪري ٿو مختلف طريقن سان ترتيب ڏيڻ لاءِ پوڊ ترجيح ۽ اڳڀرائي. سيٽنگ ڪيترن ئي حصن تي مشتمل آهي: اعتراض PriorityClass ۽ فيلڊ جي وضاحت priorityClassName پوڊ جي وضاحت ۾. اچو ته هڪ مثال ڏسو:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"

اسان ٺاهيندا آهيون PriorityClass، ان کي نالو ڏيو، وضاحت ۽ قدر. مٿاهون value، اعليٰ ترجيح. قدر 32 کان گھٽ يا ان جي برابر ڪو به 1-bit انٽيجر ٿي سگھي ٿو. اعليٰ قدرون مشن-نازڪ سسٽم پوڊس لاءِ مخصوص آھن جن کي عام طور تي اڳيئي نه ٿو ڪري سگھجي. بي گھرڻ صرف ان صورت ۾ ٿيندو جڏھن ھڪ اعليٰ اوليت واري پوڊ کي گھمڻ لاءِ ڪا جاءِ نه ھجي، ته پوءِ ھڪ خاص نوڊ مان ڪجھ پوڊ ڪڍيا ويندا. جيڪڏهن هي ميکانيزم توهان لاء تمام سخت آهي، توهان اختيار شامل ڪري سگهو ٿا preemptionPolicy: Never، ۽ پوءِ ڪا به اڳڀرائي نه ٿيندي، پوڊ پهرين قطار ۾ بيٺو ۽ شيڊيولر جو انتظار ڪندو ان لاءِ مفت وسيلا ڳولڻ لاءِ.

اڳيون، اسان هڪ پوڊ ٺاهيندا آهيون جنهن ۾ اسان نالو ظاهر ڪندا آهيون priorityClassName:

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
 spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  priorityClassName: high-priority
          

توھان پنھنجي پسند جيتريون ترجيحي ڪلاس ٺاھي سگھو ٿا، جيتوڻيڪ اھو سفارش آھي ته ان سان پري نه وڃو (چئو، پاڻ کي گھٽ، وچولي ۽ اعليٰ اوليت تائين محدود ڪريو).

اهڙيء طرح، جيڪڏهن ضروري هجي ته، توهان نازڪ خدمتن کي ترتيب ڏيڻ جي ڪارڪردگي کي وڌائي سگهو ٿا جهڙوڪ nginx-ingress-controller، coredns، وغيره.

9. ETCD ڪلستر کي بهتر ڪريو

ETCD کي سڄي ڪلستر جو دماغ سڏيو وڃي ٿو. اهو تمام ضروري آهي ته هن ڊيٽابيس جي آپريشن کي اعلي سطح تي برقرار رکڻ لاء، ڇاڪاڻ ته ڪيوبي ۾ آپريشن جي رفتار ان تي منحصر آهي. هڪ مناسب معيار، ۽ ساڳئي وقت، سٺو حل اهو هوندو ته ETCD ڪلستر کي ماسٽر نوڊس تي رکڻ لاء، ڪوب-اپيسرور کي گهٽ ۾ گهٽ دير ڪرڻ لاء. جيڪڏهن توهان اهو نٿا ڪري سگهو، ته پوءِ ETCD کي جيترو ٿي سگهي ويجھو رکو، شرڪت ڪندڙن جي وچ ۾ سٺي بينڊوڊٿ سان. انهي تي پڻ ڌيان ڏيو ته ETCD مان ڪيترا نوڊس ڪلستر کي نقصان پهچائڻ کان سواء ٻاهر نڪري سگهن ٿيون

ياد رهي ته ڪلسٽر ۾ ميمبرن جي تعداد ۾ گهڻو اضافو ڪارڪردگي جي خرچ تي غلطي رواداري کي وڌائي سگھي ٿو، هر شي کي اعتدال ۾ هجڻ گهرجي.

جيڪڏهن اسان خدمت کي ترتيب ڏيڻ بابت ڳالهايو، اتي ڪجھ سفارشون آهن:

1. سٺي هارڊويئر رکو، ڪلستر جي سائيز جي بنياد تي (توهان پڙهي سگهو ٿا هتي).

2. جيڪڏهن توهان ڊي سي جي هڪ جوڙي يا توهان جي نيٽ ورڪ ۽ ڊسڪ جي وچ ۾ ڪلستر پکڙيل آهي ته ڪجهه پيٽرولر کي ٽوڙيو (توهان پڙهي سگهو ٿا) هتي).

ٿڪل

هي آرٽيڪل انهن نقطن کي بيان ڪري ٿو جيڪي اسان جي ٽيم سان عمل ڪرڻ جي ڪوشش ڪري ٿي. هي عملن جو قدم قدم بيان نه آهي، پر اهي اختيار جيڪي ڪلستر اوور هيڊ کي بهتر ڪرڻ لاءِ ڪارآمد هوندا. اهو واضح آهي ته هر ڪلستر پنهنجي طريقي سان منفرد آهي، ۽ ترتيب ڏيڻ جا حل تمام گهڻو مختلف ٿي سگهن ٿا، تنهنڪري اهو دلچسپ هوندو ته توهان جي راءِ حاصل ڪرڻ ته توهان پنهنجي ڪبرنيٽس ڪلستر جي نگراني ڪيئن ڪندا آهيو ۽ توهان ان جي ڪارڪردگي کي ڪيئن بهتر بڻائيندا آهيو. تبصرن ۾ پنهنجو تجربو حصيداري ڪريو، اهو ڄاڻڻ دلچسپ ٿيندو.

جو ذريعو: www.habr.com