نو کبرنیٹس پرفارمنس ٹپس

سب کو سلام! میرا نام Oleg Sidorenkov ہے، میں DomClick میں بنیادی ڈھانچے کی ٹیم کے سربراہ کے طور پر کام کرتا ہوں۔ ہم تین سال سے زیادہ عرصے سے کوبیک کو پروڈکشن میں استعمال کر رہے ہیں، اور اس دوران ہم نے اس کے ساتھ بہت سے مختلف دلچسپ لمحات کا تجربہ کیا ہے۔ آج میں آپ کو بتاؤں گا کہ کس طرح، صحیح نقطہ نظر کے ساتھ، آپ اپنے کلسٹر کے لیے ونیلا کبرنیٹس سے بھی زیادہ کارکردگی کو نچوڑ سکتے ہیں۔ تیار ہو جاؤ!

آپ سب بخوبی جانتے ہیں کہ Kubernetes کنٹینر آرکیسٹریشن کے لیے ایک توسیع پذیر اوپن سورس سسٹم ہے۔ ٹھیک ہے، یا 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، اگر آپس ٹیم پوڈز کو تعینات کرنا چاہتی ہے جو مزید 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. بہترین فائل اسٹوریج کا انتخاب کریں۔

یہاں میں مستقل حجم اور کبرنیٹس ورکر نوڈس کے ڈسک سب سسٹم کے موضوع پر بات کرنا چاہوں گا۔ مجھے امید ہے کہ کوئی بھی پروڈکشن میں ایچ ڈی ڈی پر "کیوب" کا استعمال نہیں کرتا ہے، لیکن بعض اوقات ایک باقاعدہ ایس ایس ڈی کافی نہیں ہوتا ہے۔ ہمیں ایک مسئلہ کا سامنا کرنا پڑا جہاں I/O آپریشنز کی وجہ سے لاگز ڈسک کو ختم کر رہے تھے، اور بہت سے حل نہیں ہیں:

• اعلی کارکردگی والے SSDs کا استعمال کریں یا NVMe پر سوئچ کریں (اگر آپ اپنے ہارڈ ویئر کا انتظام کرتے ہیں)۔

• لاگنگ کی سطح کو کم کریں۔

• پھلیوں کا "سمارٹ" توازن کریں جو ڈسک کو ریپ کرتے ہیں (podAntiAffinity).

اوپر کی سکرین دکھاتی ہے کہ جب ایکسیس لاگنگ کو فعال کیا جاتا ہے تو ڈسک پر nginx-ingress-controller کے تحت کیا ہوتا ہے (~ 12 ہزار لاگز/سیکنڈ)۔ یہ حالت، یقینا، اس نوڈ پر تمام ایپلی کیشنز کے انحطاط کا باعث بن سکتی ہے۔

جہاں تک پی وی کا تعلق ہے، افسوس، میں نے سب کچھ نہیں آزمایا آراء مستقل حجم۔ آپ کے مطابق بہترین آپشن استعمال کریں۔ تاریخی طور پر، یہ ہمارے ملک میں ہوا ہے کہ خدمات کے ایک چھوٹے سے حصے کو RWX والیوم کی ضرورت ہوتی ہے، اور بہت عرصہ پہلے انہوں نے اس کام کے لیے NFS اسٹوریج کا استعمال شروع کیا۔ سستا اور کافی... یقینا، اس نے اور میں نے گندگی کھائی - آپ کو مبارک ہو، لیکن ہم نے اسے ٹیون کرنا سیکھ لیا، اور میرے سر کو مزید درد نہیں ہوتا ہے۔ اور اگر ممکن ہو تو S3 آبجیکٹ اسٹوریج پر جائیں۔

3. آپٹمائزڈ تصاویر جمع کریں۔

کنٹینر کے لیے موزوں تصاویر کا استعمال کرنا بہتر ہے تاکہ Kubernetes انہیں تیزی سے حاصل کر سکیں اور انہیں زیادہ مؤثر طریقے سے انجام دے سکیں۔ 

آپٹمائزڈ کا مطلب ہے کہ تصاویر:

• صرف ایک ایپلی کیشن پر مشتمل ہے یا صرف ایک فنکشن انجام دینا؛

• سائز میں چھوٹا، کیونکہ بڑی تصاویر نیٹ ورک پر بدتر منتقل ہوتی ہیں۔

• صحت اور تیاری کے اختتامی نکات ہیں جو Kubernetes کو بند ہونے کی صورت میں کارروائی کرنے کی اجازت دیتے ہیں۔

• کنٹینر کے موافق آپریٹنگ سسٹمز (جیسے الپائن یا CoreOS) استعمال کریں، جو کنفیگریشن کی غلطیوں کے خلاف زیادہ مزاحم ہیں۔

• ملٹی اسٹیج بلڈز کا استعمال کریں تاکہ آپ صرف مرتب کردہ ایپلیکیشنز کو تعینات کر سکیں نہ کہ ساتھ والے ذرائع۔

بہت سارے ٹولز اور خدمات ہیں جو آپ کو پرواز پر تصاویر کو چیک کرنے اور بہتر بنانے کی اجازت دیتی ہیں۔ ان کو ہمیشہ اپ ٹو ڈیٹ رکھنا اور حفاظت کے لیے جانچنا ضروری ہے۔ نتیجے کے طور پر آپ کو ملتا ہے:

1. پورے کلسٹر پر نیٹ ورک کا بوجھ کم ہو گیا۔

2. کنٹینر کے آغاز کے وقت کو کم کرنا۔

3. آپ کی پوری ڈاکر رجسٹری کا چھوٹا سائز۔

4. DNS کیش استعمال کریں۔

اگر ہم زیادہ بوجھ کے بارے میں بات کرتے ہیں، تو کلسٹر کے ڈی این ایس سسٹم کو ٹیوننگ کیے بغیر زندگی کافی خراب ہے۔ ایک زمانے میں، Kubernetes کے ڈویلپرز نے اپنے kube-dns حل کی حمایت کی۔ اسے یہاں بھی لاگو کیا گیا، لیکن یہ سافٹ ویئر خاص طور پر ٹیون نہیں کیا گیا تھا اور مطلوبہ کارکردگی پیش نہیں کرسکا، حالانکہ یہ ایک آسان کام معلوم ہوتا تھا۔ پھر coredns ظاہر ہوا، جس پر ہم نے سوئچ کیا اور کوئی غم نہیں تھا؛ یہ بعد میں K8s میں ڈیفالٹ ڈی این ایس سروس بن گئی۔ کسی وقت، ہم DNS سسٹم میں 40 ہزار آر پی ایس تک بڑھ گئے، اور یہ حل بھی ناکافی ہو گیا۔ لیکن، قسمت سے، Nodelocaldns باہر آیا، عرف نوڈ لوکل کیش، عرف نوڈ لوکل DNSCache.

ہم اسے کیوں استعمال کرتے ہیں؟ لینکس کے کرنل میں ایک بگ ہے جو UDP پر conntrack NAT کے ذریعے ایک سے زیادہ کال کرنے پر، conntrack ٹیبلز میں اندراجات کے لیے ریس کی حالت کا باعث بنتی ہے، اور 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 سے لی گئی تصویر

Kubernetes میں شیڈولر ہمیشہ درخواستوں پر مبنی ہوتا ہے۔ آپ وہاں جو بھی قیمت ڈالیں گے، شیڈیولر اس کی بنیاد پر ایک مناسب نوڈ تلاش کرے گا۔ کیوبلیٹ کو یہ سمجھنے کے لیے حدود کی اقدار کی ضرورت ہوتی ہے کہ پھلی کو کب گلا گھونٹنا ہے یا مارنا ہے۔ اور چونکہ واحد اہم پیرامیٹر درخواستوں کی قدر ہے، اس لیے 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

جیسا کہ اوپر ذکر کیا گیا ہے، یہ مینی فیسٹ میں درخواستوں/حد کے تناسب کی بنیاد پر متناسب پیمانہ ہے:

• CPU: 200m → 300m: تناسب 1:1.75؛

• میموری: 250Mi → 500Mi: تناسب 1:2۔

کے حوالے کے طور پر HPA، پھر آپریشن کا طریقہ کار زیادہ شفاف ہے۔ میٹرکس جیسے CPU اور میموری کی حد ہوتی ہے، اور اگر تمام ریپلیکس کی اوسط حد سے بڑھ جاتی ہے، تو ایپلیکیشن کو +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 کے بارے میں مت بھولنا

تمام نوڈس ایک ہی ہارڈ ویئر پر نہیں چلتے، اور تمام پوڈز کو کمپیوٹ-انٹینسیو ایپلی کیشنز چلانے کی ضرورت نہیں ہے۔ Kubernetes آپ کو استعمال کرتے ہوئے نوڈس اور پوڈز کی تخصص کو ترتیب دینے کی اجازت دیتا ہے۔ نوڈ وابستگی и پھلی وابستگی.

اگر آپ کے پاس ایسے نوڈس ہیں جو کمپیوٹ-انٹینسیو آپریشنز کے لیے موزوں ہیں، تو زیادہ سے زیادہ کارکردگی کے لیے بہتر ہے کہ ایپلی کیشنز کو متعلقہ نوڈس سے جوڑ دیں۔ ایسا کرنے کے لیے استعمال کریں۔ nodeSelector نوڈ لیبل کے ساتھ۔

ہم کہتے ہیں کہ آپ کے پاس دو نوڈس ہیں: ایک کے ساتھ CPUType=HIGHFREQ اور فاسٹ کور کی ایک بڑی تعداد، دوسرے کے ساتھ MemoryType=HIGHMEMORY زیادہ میموری اور تیز کارکردگی۔ سب سے آسان طریقہ یہ ہے کہ نوڈ پر تعیناتی تفویض کی جائے۔ HIGHFREQسیکشن میں شامل کرکے spec یہ سلیکٹر:

…
nodeSelector:
	CPUType: HIGHFREQ

ایسا کرنے کا ایک زیادہ مہنگا اور مخصوص طریقہ استعمال کرنا ہے۔ nodeAffinity میدان میں affinity سیکشن spec. دو اختیارات ہیں:

• requiredDuringSchedulingIgnoredDuringExecution: سخت ترتیب (شیڈیولر صرف مخصوص نوڈس پر پوڈ تعینات کرے گا (اور کہیں نہیں))؛

• preferredDuringSchedulingIgnoredDuringExecution: نرم ترتیب (شیڈیولر مخصوص نوڈس پر تعینات کرنے کی کوشش کرے گا، اور اگر یہ ناکام ہوجاتا ہے، تو یہ اگلے دستیاب نوڈ پر تعینات کرنے کی کوشش کرے گا)۔

آپ نوڈ لیبل کے انتظام کے لیے ایک مخصوص نحو کی وضاحت کر سکتے ہیں، جیسے In, NotIn, Exists, DoesNotExist, Gt یا Lt. تاہم، یاد رکھیں کہ لیبلز کی لمبی فہرستوں میں پیچیدہ طریقے نازک حالات میں فیصلہ سازی کو سست کر دیں گے۔ دوسرے الفاظ میں، اسے سادہ رکھیں.

جیسا کہ اوپر ذکر کیا گیا ہے، Kubernetes آپ کو موجودہ پوڈز کا تعلق قائم کرنے کی اجازت دیتا ہے۔ یعنی، آپ اس بات کو یقینی بنا سکتے ہیں کہ کچھ پوڈز اسی دستیابی زون (بادلوں کے لیے متعلقہ) یا نوڈس میں دیگر پوڈز کے ساتھ مل کر کام کریں۔

В podAffinity کھیتوں affinity سیکشن spec وہی فیلڈز دستیاب ہیں جیسے کے معاملے میں nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. فرق صرف اتنا ہے۔ matchExpressions پوڈز کو ایک نوڈ سے جوڑ دے گا جو پہلے ہی اس لیبل کے ساتھ پوڈ چلا رہا ہے۔

Kubernetes بھی ایک فیلڈ پیش کرتا ہے۔ 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. پوڈ کی تعیناتی کی ترجیح مقرر کریں۔

صرف اس وجہ سے کہ آپ نے نوڈس کو پوڈز تفویض کیے ہیں اس کا مطلب یہ نہیں ہے کہ تمام پوڈز کو ایک ہی ترجیح کے ساتھ برتا جانا چاہیے۔ مثال کے طور پر، آپ دوسروں سے پہلے کچھ پوڈ لگانا چاہتے ہیں۔

Kubernetes Pod Priority اور Preemption کو ترتیب دینے کے مختلف طریقے پیش کرتا ہے۔ ترتیب کئی حصوں پر مشتمل ہے: آبجیکٹ 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-بٹ انٹیجر ہو سکتی ہے۔ اعلیٰ اقدار مشن-کریٹیکل سسٹم پوڈز کے لیے مخصوص ہیں جنہیں عام طور پر پہلے سے نہیں لگایا جا سکتا۔ نقل مکانی صرف اس صورت میں ہو گی جب ایک اعلیٰ ترجیحی پوڈ کے پاس گھومنے کی جگہ نہ ہو، پھر ایک مخصوص نوڈ سے کچھ پوڈز کو خالی کر دیا جائے گا۔ اگر یہ طریقہ کار آپ کے لیے بہت سخت ہے، تو آپ آپشن شامل کر سکتے ہیں۔ 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 کلسٹر کو ماسٹر نوڈس پر رکھا جائے تاکہ kube-apiserver میں کم سے کم تاخیر ہو۔ اگر آپ ایسا نہیں کر سکتے ہیں، تو شرکاء کے درمیان اچھی بینڈوتھ کے ساتھ ETCD کو جتنا ممکن ہو قریب رکھیں۔ اس بات پر بھی توجہ دیں کہ ETCD سے کتنے نوڈس کلسٹر کو نقصان پہنچائے بغیر گر سکتے ہیں۔

ذہن میں رکھیں کہ کلسٹر میں اراکین کی تعداد میں حد سے زیادہ اضافہ کارکردگی کی قیمت پر غلطی برداشت کو بڑھا سکتا ہے، سب کچھ اعتدال میں ہونا چاہیے۔

اگر ہم سروس کو ترتیب دینے کے بارے میں بات کرتے ہیں، تو چند تجاویز ہیں:

1. کلسٹر کے سائز کی بنیاد پر اچھا ہارڈ ویئر رکھیں (آپ پڑھ سکتے ہیں۔ یہاں).

2. اگر آپ نے ڈی سی کے ایک جوڑے یا اپنے نیٹ ورک کے درمیان کلسٹر پھیلا دیا ہے تو کچھ پیرامیٹرز کو درست کریں اور ڈسکوں کو مطلوبہ بہت کچھ چھوڑ دیا جائے (آپ پڑھ سکتے ہیں یہاں).

حاصل يہ ہوا

یہ مضمون ان نکات کی وضاحت کرتا ہے جن پر ہماری ٹیم عمل کرنے کی کوشش کرتی ہے۔ یہ کارروائیوں کی مرحلہ وار تفصیل نہیں ہے، بلکہ ایسے اختیارات ہیں جو کلسٹر اوور ہیڈ کو بہتر بنانے کے لیے مفید ہو سکتے ہیں۔ یہ واضح ہے کہ ہر کلسٹر اپنے طریقے سے منفرد ہے، اور کنفیگریشن سلوشنز بہت مختلف ہو سکتے ہیں، اس لیے یہ دلچسپ ہوگا کہ آپ اپنے Kubernetes کلسٹر کی نگرانی کیسے کرتے ہیں اور اس کی کارکردگی کو کیسے بہتر بناتے ہیں۔ تبصرے میں اپنا تجربہ شیئر کریں، یہ جاننا دلچسپ ہوگا۔

ماخذ: www.habr.com