ایک اصول کے طور پر، کسی درخواست کو اس کے درست اور مستحکم آپریشن کے لیے وسائل کا ایک وقف شدہ پول فراہم کرنے کی ضرورت ہوتی ہے۔ لیکن کیا ہوگا اگر ایک ہی پاور پر کئی ایپلی کیشنز چل رہی ہوں؟ ان میں سے ہر ایک کو کم از کم ضروری وسائل کیسے فراہم کیے جائیں؟ آپ وسائل کی کھپت کو کیسے محدود کر سکتے ہیں؟ نوڈس کے درمیان بوجھ کو صحیح طریقے سے کیسے تقسیم کیا جائے؟ اگر ایپلیکیشن کا بوجھ بڑھتا ہے تو افقی اسکیلنگ کا طریقہ کار کیسے یقینی بنایا جائے؟
آپ کو اس کے ساتھ شروع کرنے کی ضرورت ہے کہ سسٹم میں کون سے اہم قسم کے وسائل موجود ہیں - یہ، یقینا، پروسیسر کا وقت اور رام ہے۔ k8s میں ان وسائل کی اقسام کو درج ذیل اکائیوں میں ماپا جاتا ہے۔
- سی پی یو - کور میں
- RAM - بائٹس میں
مزید برآں، ہر وسائل کے لیے دو قسم کی ضروریات کا تعین کرنا ممکن ہے۔ درخواستوں и حدود. درخواستیں - کنٹینر (اور مجموعی طور پر پوڈ) چلانے کے لیے نوڈ کے مفت وسائل کے لیے کم از کم تقاضوں کی وضاحت کرتا ہے، جبکہ حدود کنٹینر کے لیے دستیاب وسائل پر سخت حد مقرر کرتی ہے۔
یہ سمجھنا ضروری ہے کہ مینی فیسٹ کو واضح طور پر دونوں اقسام کی وضاحت کرنے کی ضرورت نہیں ہے، لیکن طرز عمل اس طرح ہوگا:
- اگر صرف وسائل کی حدیں واضح طور پر بیان کی گئی ہیں، تو اس وسیلہ کے لیے درخواستیں خود بخود حد کے برابر قدر لیتی ہیں (آپ اس کی توثیق کر سکتے ہیں describe entities کو کال کرکے)۔ وہ. درحقیقت، کنٹینر وسائل کی اسی مقدار تک محدود ہو گا جس کی اسے چلانے کے لیے ضرورت ہے۔
- اگر کسی وسیلہ کے لیے صرف درخواستیں واضح طور پر بیان کی گئی ہیں، تو اس وسیلہ پر کوئی اوپری پابندیاں مقرر نہیں ہیں - یعنی کنٹینر صرف نوڈ کے وسائل سے ہی محدود ہے۔
وسائل کے انتظام کو نہ صرف مخصوص کنٹینر کی سطح پر ترتیب دینا ممکن ہے بلکہ درج ذیل اداروں کا استعمال کرتے ہوئے نام کی جگہ کی سطح پر بھی:
- حد کی حد - ns میں کنٹینر/پوڈ کی سطح پر پابندی کی پالیسی کی وضاحت کرتا ہے اور کنٹینر/پوڈ پر پہلے سے طے شدہ حدود کو بیان کرنے کے ساتھ ساتھ واضح طور پر چربی والے کنٹینرز/پڈز (یا اس کے برعکس) کی تخلیق کو روکنے کے لیے، ان کی تعداد کو محدود کرنے کے لیے اس کی ضرورت ہے۔ اور حدود اور درخواستوں میں اقدار میں ممکنہ فرق کا تعین کریں۔
- وسائل کوٹاس - ns میں موجود تمام کنٹینرز کے لیے عام طور پر پابندی کی پالیسی کی وضاحت کریں اور ایک اصول کے طور پر، ماحول کے درمیان وسائل کو محدود کرنے کے لیے استعمال کیا جاتا ہے (مفید جب ماحول کو نوڈ کی سطح پر سختی سے حد بندی نہ کی گئی ہو)
درج ذیل مینی فیسٹس کی مثالیں ہیں جو وسائل کی حدیں متعین کرتی ہیں:
-
مخصوص کنٹینر کی سطح پر:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mوہ. اس صورت میں، nginx کے ساتھ کنٹینر چلانے کے لیے، آپ کو نوڈ پر کم از کم 1G مفت RAM اور 0.2 CPU کی ضرورت ہوگی، جبکہ زیادہ سے زیادہ کنٹینر 0.2 CPU اور نوڈ پر موجود تمام دستیاب RAM استعمال کر سکتا ہے۔
-
عددی سطح پر ns:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2Giوہ. ڈیفالٹ ns میں تمام درخواست کنٹینرز کا مجموعہ CPU کے لیے 300m اور OP کے لیے 1G سے زیادہ نہیں ہو سکتا، اور تمام حد کا مجموعہ CPU کے لیے 700m اور OP کے لیے 2G ہے۔
-
این ایس میں کنٹینرز کے لیے طے شدہ حدود:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-per-container spec: limits: - type: Container defaultRequest: cpu: 100m memory: 1Gi default: cpu: 1 memory: 2Gi min: cpu: 50m memory: 500Mi max: cpu: 2 memory: 4Giوہ. تمام کنٹینرز کے لیے پہلے سے طے شدہ نام کی جگہ میں، درخواست کو CPU کے لیے 100m اور OP کے لیے 1G، حد - 1 CPU اور 2G پر سیٹ کیا جائے گا۔ ایک ہی وقت میں، CPU (50m <x <2) اور RAM (500M <x <4G) کے لیے درخواست/حد میں ممکنہ قدروں پر بھی ایک حد مقرر کی گئی ہے۔
-
پوڈ کی سطح کی پابندیاں:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1Giوہ. ڈیفالٹ این ایس میں ہر پوڈ کے لیے 4 وی سی پی یو اور 1 جی کی حد ہوگی۔
اب میں آپ کو بتانا چاہوں گا کہ ان پابندیوں کو قائم کرنے سے ہمیں کیا فوائد مل سکتے ہیں۔
نوڈس کے درمیان لوڈ بیلنسنگ میکانزم
جیسا کہ آپ جانتے ہیں، k8s جزو نوڈس کے درمیان پوڈ کی تقسیم کے لیے ذمہ دار ہے، جیسے شیڈیولر۔، جو ایک مخصوص الگورتھم کے مطابق کام کرتا ہے۔ لانچ کرنے کے لیے بہترین نوڈ کا انتخاب کرتے وقت یہ الگورتھم دو مراحل سے گزرتا ہے:
- فلٹرنگ
- رینجنگ
وہ. بیان کردہ پالیسی کے مطابق، ابتدائی طور پر نوڈس کا انتخاب کیا جاتا ہے جس پر سیٹ کی بنیاد پر پوڈ لانچ کرنا ممکن ہوتا ہے۔ پیشن گوئی (بشمول یہ جانچنا کہ آیا نوڈ کے پاس پوڈ چلانے کے لیے کافی وسائل ہیں - PodFitsResources)، اور پھر ان نوڈس میں سے ہر ایک کے لیے، ترجیحات پوائنٹس دیئے جاتے ہیں (بشمول، ایک نوڈ کے جتنے زیادہ مفت وسائل ہوتے ہیں، اسے اتنے ہی زیادہ پوائنٹس تفویض کیے جاتے ہیں - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) اور پوڈ کو نوڈ پر سب سے زیادہ پوائنٹس کے ساتھ لانچ کیا جاتا ہے (اگر کئی نوڈس ایک ساتھ اس شرط کو پورا کرتے ہیں، تو ایک بے ترتیب کو منتخب کیا جاتا ہے)۔
ایک ہی وقت میں، آپ کو یہ سمجھنے کی ضرورت ہے کہ شیڈیولر، جب کسی نوڈ کے دستیاب وسائل کا اندازہ لگاتا ہے، تو اس کی رہنمائی اس ڈیٹا سے ہوتی ہے جو etcd میں محفوظ ہوتا ہے - یعنی اس نوڈ پر چلنے والے ہر پوڈ کے مطلوبہ/حد وسائل کی مقدار کے لیے، لیکن اصل وسائل کے استعمال کے لیے نہیں۔ یہ معلومات کمانڈ آؤٹ پٹ سے حاصل کی جا سکتی ہیں۔ kubectl describe node $NODEمثال کے طور پر:
# kubectl describe nodes nxs-k8s-s1
..
Non-terminated Pods: (9 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
--------- ---- ------------ ---------- --------------- ------------- ---
ingress-nginx nginx-ingress-controller-754b85bf44-qkt2t 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d
kube-system kube-flannel-26bl4 150m (0%) 300m (1%) 64M (0%) 500M (1%) 233d
kube-system kube-proxy-exporter-cb629 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d
kube-system kube-proxy-x9fsc 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d
kube-system nginx-proxy-k8s-worker-s1 25m (0%) 300m (1%) 32M (0%) 512M (1%) 233d
nxs-monitoring alertmanager-main-1 100m (0%) 100m (0%) 425Mi (1%) 25Mi (0%) 233d
nxs-logging filebeat-lmsmp 100m (0%) 0 (0%) 100Mi (0%) 200Mi (0%) 233d
nxs-monitoring node-exporter-v4gdq 112m (0%) 122m (0%) 200Mi (0%) 220Mi (0%) 233d
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 487m (3%) 822m (5%)
memory 15856217600 (2%) 749976320 (3%)
ephemeral-storage 0 (0%) 0 (0%)یہاں ہم تمام پوڈز کو ایک مخصوص نوڈ پر چلتے ہوئے دیکھتے ہیں اور ساتھ ہی وہ وسائل بھی دیکھتے ہیں جن کی ہر پوڈ کی درخواست ہوتی ہے۔ اور یہاں یہ ہے کہ جب cronjob-cron-events-1573793820-xt6q9 پوڈ لانچ کیا جاتا ہے تو شیڈیولر لاگز کیسا نظر آتا ہے (یہ معلومات شیڈیولر لاگ میں اس وقت ظاہر ہوگی جب آپ اسٹارٹ اپ کمانڈ آرگومنٹس میں 10 ویں لاگنگ لیول کو سیٹ کریں گے -v=10):
لاگ
I1115 07:57:21.637791 1 scheduling_queue.go:908] About to try and schedule pod nxs-stage/cronjob-cron-events-1573793820-xt6q9
I1115 07:57:21.637804 1 scheduler.go:453] Attempting to schedule pod: nxs-stage/cronjob-cron-events-1573793820-xt6q9
I1115 07:57:21.638285 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s5 is allowed, Node is running only 16 out of 110 Pods.
I1115 07:57:21.638300 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s6 is allowed, Node is running only 20 out of 110 Pods.
I1115 07:57:21.638322 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s3 is allowed, Node is running only 20 out of 110 Pods.
I1115 07:57:21.638322 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s4 is allowed, Node is running only 17 out of 110 Pods.
I1115 07:57:21.638334 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, Node is running only 16 out of 110 Pods.
I1115 07:57:21.638365 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s12 is allowed, Node is running only 9 out of 110 Pods.
I1115 07:57:21.638334 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s11 is allowed, Node is running only 11 out of 110 Pods.
I1115 07:57:21.638385 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s1 is allowed, Node is running only 19 out of 110 Pods.
I1115 07:57:21.638402 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s2 is allowed, Node is running only 21 out of 110 Pods.
I1115 07:57:21.638383 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, Node is running only 16 out of 110 Pods.
I1115 07:57:21.638335 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, Node is running only 18 out of 110 Pods.
I1115 07:57:21.638408 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s13 is allowed, Node is running only 8 out of 110 Pods.
I1115 07:57:21.638478 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, existing pods anti-affinity terms satisfied.
I1115 07:57:21.638505 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, existing pods anti-affinity terms satisfied.
I1115 07:57:21.638577 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, existing pods anti-affinity terms satisfied.
I1115 07:57:21.638583 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s7 is allowed, Node is running only 25 out of 110 Pods.
I1115 07:57:21.638932 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 9
I1115 07:57:21.638946 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 8
I1115 07:57:21.638961 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: BalancedResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 9
I1115 07:57:21.638971 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7
I1115 07:57:21.638975 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: LeastResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 8
I1115 07:57:21.638990 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7
I1115 07:57:21.639022 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: TaintTolerationPriority, Score: (10)
I1115 07:57:21.639030 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: TaintTolerationPriority, Score: (10)
I1115 07:57:21.639034 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: TaintTolerationPriority, Score: (10)
I1115 07:57:21.639041 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: NodeAffinityPriority, Score: (0)
I1115 07:57:21.639053 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: NodeAffinityPriority, Score: (0)
I1115 07:57:21.639059 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: NodeAffinityPriority, Score: (0)
I1115 07:57:21.639061 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: InterPodAffinityPriority, Score: (0)
I1115 07:57:21.639063 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639073 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: InterPodAffinityPriority, Score: (0)
I1115 07:57:21.639077 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639085 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: InterPodAffinityPriority, Score: (0)
I1115 07:57:21.639088 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639103 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639109 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639114 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639127 1 generic_scheduler.go:781] Host nxs-k8s-s10 => Score 100037
I1115 07:57:21.639150 1 generic_scheduler.go:781] Host nxs-k8s-s8 => Score 100034
I1115 07:57:21.639154 1 generic_scheduler.go:781] Host nxs-k8s-s9 => Score 100037
I1115 07:57:21.639267 1 scheduler_binder.go:269] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10"
I1115 07:57:21.639286 1 scheduler_binder.go:279] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10": all PVCs bound and nothing to do
I1115 07:57:21.639333 1 factory.go:733] Attempting to bind cronjob-cron-events-1573793820-xt6q9 to nxs-k8s-s10یہاں ہم دیکھتے ہیں کہ ابتدائی طور پر شیڈیولر فلٹر کرتا ہے اور 3 نوڈس کی فہرست تیار کرتا ہے جس پر اسے لانچ کیا جا سکتا ہے (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10)۔ پھر یہ سب سے موزوں نوڈ کا تعین کرنے کے لیے ان میں سے ہر ایک نوڈ کے لیے متعدد پیرامیٹرز (بشمول BalancedResourceAllocation، LeastResourceAllocation) کی بنیاد پر اسکور کا حساب لگاتا ہے۔ بالآخر، پوڈ کو نوڈ پر سب سے زیادہ پوائنٹس کے ساتھ شیڈول کیا جاتا ہے (یہاں دو نوڈس میں پوائنٹس کی ایک ہی تعداد 100037 ہے، لہذا ایک بے ترتیب کو منتخب کیا جاتا ہے - nxs-k8s-s10)۔
آؤٹ پٹ: اگر کوئی نوڈ ایسے پوڈ چلاتا ہے جس کے لیے کوئی پابندیاں نہیں لگائی گئی ہیں، تو k8s کے لیے (وسائل کی کھپت کے نقطہ نظر سے) یہ اس طرح کے مترادف ہوگا جیسے اس نوڈ پر ایسی کوئی پوڈ نہیں تھی۔ اس لیے، اگر آپ کے پاس، مشروط طور پر، پیٹو کے عمل کے ساتھ ایک پھلی ہے (مثال کے طور پر، wowza) اور اس کے لیے کوئی پابندیاں مقرر نہیں ہیں، تو ایسی صورت حال پیدا ہو سکتی ہے جب اس پوڈ نے واقعی نوڈ کے تمام وسائل کھا لیے ہوں، لیکن k8s کے لیے یہ نوڈ۔ اسے ان لوڈڈ سمجھا جاتا ہے اور اسے ایک نوڈ کے طور پر درجہ بندی کرتے وقت (دستیاب وسائل کا درست اندازہ لگانے والے پوائنٹس میں) اتنے ہی پوائنٹس سے نوازا جائے گا جس میں کام کرنے والے پوڈ نہیں ہیں، جو بالآخر نوڈس کے درمیان بوجھ کی غیر مساوی تقسیم کا باعث بن سکتے ہیں۔
پھلی کی بے دخلی۔
جیسا کہ آپ جانتے ہیں، ہر پوڈ کو 3 QoS کلاسوں میں سے ایک تفویض کیا گیا ہے:
- ضمانت دی گئی - اس وقت تفویض کیا جاتا ہے جب پوڈ میں ہر کنٹینر کے لیے میموری اور سی پی یو کے لیے ایک درخواست اور حد متعین کی جاتی ہے، اور ان اقدار کو مماثل ہونا چاہیے
- پھٹنے کے قابل - پوڈ میں کم از کم ایک کنٹینر کی ایک درخواست اور ایک حد ہوتی ہے، درخواست کے ساتھ < limit
- بہترین کوشش - جب پوڈ میں ایک بھی کنٹینر وسائل محدود نہ ہو۔
ایک ہی وقت میں، جب کسی نوڈ کو وسائل (ڈسک، میموری) کی کمی کا سامنا ہوتا ہے، تو کیوبلیٹ ایک مخصوص الگورتھم کے مطابق پوڈ کو درجہ بندی اور بے دخل کرنا شروع کر دیتا ہے جو پوڈ کی ترجیح اور اس کی QoS کلاس کو مدنظر رکھتا ہے۔ مثال کے طور پر، اگر ہم RAM کے بارے میں بات کر رہے ہیں، تو QoS کلاس کی بنیاد پر، پوائنٹس درج ذیل اصول کے مطابق دیئے جاتے ہیں:
- ضمانت: -998،XNUMX
- بہترین کوشش: 1000
- پھٹنے والا: min(زیادہ سے زیادہ(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)
وہ. اسی ترجیح کے ساتھ، کیوبلیٹ سب سے پہلے نوڈ سے بہترین کوشش QoS کلاس کے ساتھ پوڈز کو نکالے گا۔
آؤٹ پٹ: اگر آپ مطلوبہ پوڈ کو اس پر وسائل کی کمی کی صورت میں نوڈ سے نکالے جانے کے امکانات کو کم کرنا چاہتے ہیں، تو ترجیح کے ساتھ ساتھ، آپ کو اس کے لیے درخواست/ حد مقرر کرنے کا بھی خیال رکھنا ہوگا۔
ایپلیکیشن پوڈز (HPA) کی افقی آٹو اسکیلنگ کا طریقہ کار
جب کام وسائل کے استعمال (سسٹم - CPU/RAM یا صارف - rps) کے استعمال پر منحصر پوڈز کی تعداد کو خود بخود بڑھانا اور کم کرنا ہوتا ہے، جیسے k8s ہستی HPA (Horizontal Pod Autoscaler)۔ جس کا الگورتھم درج ذیل ہے:
- مشاہدہ شدہ وسائل کی موجودہ ریڈنگز کا تعین کیا جاتا ہے (currentMetricValue)
- وسائل کے لیے مطلوبہ اقدار کا تعین کیا جاتا ہے (desiredMetricValue)، جو سسٹم کے وسائل کے لیے درخواست کا استعمال کرتے ہوئے سیٹ کیے جاتے ہیں
- نقل کی موجودہ تعداد کا تعین کیا جاتا ہے (موجودہ نقلیں)
- درج ذیل فارمولہ نقل کی مطلوبہ تعداد کا حساب لگاتا ہے (مطلوبہ نقلیں)
desiredReplicas = [currentReplicas * (currentMetricValue / desiredMetricValue)]
اس صورت میں، اسکیلنگ اس وقت نہیں ہوگی جب گتانک (currentMetricValue / desiredMetricValue) 1 کے قریب ہو (اس صورت میں، ہم خود قابل اجازت غلطی کو سیٹ کر سکتے ہیں؛ بطور ڈیفالٹ یہ 0.1 ہے)۔
آئیے دیکھتے ہیں کہ ایپ ٹیسٹ ایپلی کیشن (تعیناتی کے طور پر بیان کردہ) کی مثال کا استعمال کرتے ہوئے hpa کیسے کام کرتا ہے، جہاں CPU کی کھپت کے لحاظ سے نقل کی تعداد کو تبدیل کرنا ضروری ہے:
-
ایپلیکیشن مینی فیسٹ
kind: Deployment apiVersion: apps/v1beta2 metadata: name: app-test spec: selector: matchLabels: app: app-test replicas: 2 template: metadata: labels: app: app-test spec: containers: - name: nginx image: registry.nixys.ru/generic-images/nginx imagePullPolicy: Always resources: requests: cpu: 60m ports: - name: http containerPort: 80 - name: nginx-exporter image: nginx/nginx-prometheus-exporter resources: requests: cpu: 30m ports: - name: nginx-exporter containerPort: 9113 args: - -nginx.scrape-uri - http://127.0.0.1:80/nginx-statusوہ. ہم دیکھتے ہیں کہ ایپلیکیشن پوڈ کو ابتدائی طور پر دو مثالوں میں لانچ کیا گیا ہے، جن میں سے ہر ایک میں دو nginx اور nginx-exporter کنٹینرز ہیں، جن میں سے ہر ایک کے لیے ایک مخصوص درخواستوں سی پی یو کے لیے۔
-
HPA منشور
apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: app-test-hpa spec: maxReplicas: 10 minReplicas: 2 scaleTargetRef: apiVersion: extensions/v1beta1 kind: Deployment name: app-test metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 30وہ. ہم نے ایک ایچ پی اے بنایا ہے جو ڈیپلائمنٹ ایپ ٹیسٹ کی نگرانی کرے گا اور سی پی یو اشارے کی بنیاد پر ایپلیکیشن کے ساتھ پوڈز کی تعداد کو ایڈجسٹ کرے گا (ہم توقع کرتے ہیں کہ پوڈ اس کی درخواست کردہ سی پی یو کا 30٪ استعمال کرے گا)، نقل کی تعداد کے ساتھ 2-10 کی حد۔
اب، ایچ پی اے آپریشن کے طریقہ کار کو دیکھتے ہیں اگر ہم کسی ایک چولہا پر بوجھ لگاتے ہیں:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
مجموعی طور پر ہمارے پاس درج ذیل ہیں:
- مطلوبہ قدر (desiredMetricValue) - hpa کی ترتیبات کے مطابق، ہمارے پاس 30% ہے
- موجودہ قدر (currentMetricValue) - حساب کے لیے، کنٹرولر مینیجر % میں وسائل کی کھپت کی اوسط قدر کا حساب لگاتا ہے، یعنی مشروط طور پر مندرجہ ذیل کرتا ہے:
- میٹرک سرور سے پوڈ میٹرکس کی مطلق قدریں وصول کرتا ہے، یعنی 101m اور 4m
- اوسط مطلق قدر کا حساب لگاتا ہے، یعنی (101m + 4m) / 2 = 53m
- مطلوبہ وسائل کی کھپت کے لیے مطلق قدر حاصل کرتا ہے (اس کے لیے، تمام کنٹینرز کی درخواستوں کا خلاصہ کیا جاتا ہے) 60m + 30m = 90m
- درخواست پوڈ کے مقابلے میں CPU کی کھپت کی اوسط فیصد کا حساب لگاتا ہے، یعنی 53m / 90m * 100% = 59%
اب ہمارے پاس وہ سب کچھ ہے جس کی ہمیں یہ تعین کرنے کی ضرورت ہے کہ آیا ہمیں نقلوں کی تعداد کو تبدیل کرنے کی ضرورت ہے؛ ایسا کرنے کے لیے، ہم گتانک کا حساب لگاتے ہیں:
ratio = 59% / 30% = 1.96
وہ. نقل کی تعداد میں ~ 2 گنا اضافہ کیا جانا چاہئے اور رقم [2 * 1.96] = 4 ہونی چاہئے۔
: اختتام جیسا کہ آپ دیکھ سکتے ہیں، اس میکانزم کے کام کرنے کے لیے، ایک ضروری شرط مشاہدہ شدہ پوڈ میں تمام کنٹینرز کے لیے درخواستوں کی موجودگی ہے۔
نوڈس کی افقی آٹو اسکیلنگ کا طریقہ کار (کلسٹر آٹو اسکیلر)
بوجھ میں اضافے کے دوران سسٹم پر منفی اثرات کو بے اثر کرنے کے لیے، ترتیب شدہ hpa ہونا کافی نہیں ہے۔ مثال کے طور پر، hpa کنٹرولر مینیجر کی ترتیبات کے مطابق، یہ فیصلہ کرتا ہے کہ نقل کی تعداد میں 2 گنا اضافہ کرنے کی ضرورت ہے، لیکن نوڈس کے پاس اتنی تعداد میں پوڈز چلانے کے لیے مفت وسائل نہیں ہیں (یعنی نوڈ فراہم نہیں کر سکتا۔ درخواستوں کے پوڈ پر وسائل کی درخواست کی) اور یہ پوڈز زیر التواء حالت میں بدل جاتے ہیں۔
اس صورت میں، اگر فراہم کنندہ کے پاس ایک متعلقہ IaaS/PaaS ہے (مثال کے طور پر، GKE/GCE، AKS، EKS، وغیرہ)، جیسا کہ ایک ٹول نوڈ آٹو اسکیلر. یہ آپ کو کلسٹر میں نوڈس کی زیادہ سے زیادہ اور کم از کم تعداد سیٹ کرنے اور کلسٹر اور پوڈز میں وسائل کی کمی ہونے پر نوڈس کی موجودہ تعداد کو خود بخود ایڈجسٹ کرنے کی اجازت دیتا ہے (کلاؤڈ پرووائیڈر API کو کال کرکے) شیڈول نہیں کیا جا سکتا (زیر التوا حالت میں ہیں)۔
: اختتام نوڈس کو آٹو اسکیل کرنے کے قابل ہونے کے لیے، پوڈ کنٹینرز میں درخواستیں سیٹ کرنا ضروری ہے تاکہ k8s نوڈس پر بوجھ کا صحیح اندازہ لگا سکیں اور اس کے مطابق یہ رپورٹ کریں کہ اگلا پوڈ لانچ کرنے کے لیے کلسٹر میں کوئی وسائل نہیں ہیں۔
حاصل يہ ہوا
واضح رہے کہ ایپلی کیشن کو کامیابی سے چلانے کے لیے کنٹینر کے وسائل کی حدود کا تعین کرنا ضروری نہیں ہے، لیکن پھر بھی درج ذیل وجوہات کی بنا پر ایسا کرنا بہتر ہے۔
- k8s نوڈس کے درمیان بوجھ کے توازن کے لحاظ سے شیڈولر کے زیادہ درست آپریشن کے لیے
- "پوڈ بے دخلی" واقعہ کے پیش آنے کے امکان کو کم کرنے کے لیے
- ایپلیکیشن پوڈز (HPA) کی افقی آٹو اسکیلنگ کام کرنے کے لیے
- کلاؤڈ فراہم کرنے والوں کے لیے نوڈس کی افقی آٹو اسکیلنگ (کلسٹر آٹو اسکیلنگ) کے لیے
ہمارے بلاگ پر دیگر مضامین بھی پڑھیں:
ماخذ: www.habr.com