ضابطي جي طور تي، ان جي صحيح ۽ مستحڪم آپريشن لاءِ ائپليڪيشن لاءِ وسيلن جو هڪ وقف پول مهيا ڪرڻ جي ضرورت آهي. پر ڇا جيڪڏهن ڪيترن ئي ايپليڪيشنون ساڳئي طاقت تي هلن ٿيون؟ انهن مان هر هڪ کي گهٽ ۾ گهٽ ضروري وسيلن سان ڪيئن مهيا ڪجي؟ توهان وسيلن جي استعمال کي ڪيئن محدود ڪري سگهو ٿا؟ نوڊس جي وچ ۾ لوڊ کي صحيح طريقي سان ڪيئن ورهايو وڃي؟ افقي اسڪيلنگ ميڪانيزم کي ڪيئن يقيني بڻايو وڃي جيڪڏهن ايپليڪيشن لوڊ وڌائي ٿي؟
توھان کي شروع ڪرڻ جي ضرورت آھي سسٽم ۾ ڪھڙي قسم جا وسيلا موجود آھن - اھو، يقينا، پروسيسر وقت ۽ رام آھي. k8s ۾ ظاهر ٿئي ٿو انهن وسيلن جي قسمن کي هيٺين يونٽن ۾ ماپيو ويو آهي:
- سي پي يو - ڪور ۾
- رام - بائيٽ ۾
ان کان علاوه، هر وسيلن لاء اهو ممڪن آهي ته ٻن قسمن جي گهرجن کي مقرر ڪرڻ لاء. درخواستون и حدن. درخواستون - ڪنٽينر کي هلائڻ لاءِ نوڊ جي مفت وسيلن جي گھٽ ۾ گھٽ ضرورتن کي بيان ڪري ٿو (۽ مجموعي طور تي پوڊ)، جڏهن ته حدون ڪنٽينر وٽ موجود وسيلن تي سخت حد مقرر ڪري ٿي.
اهو سمجهڻ ضروري آهي ته منشور کي واضح طور تي ٻنهي قسمن جي وضاحت ڪرڻ جي ضرورت ناهي، پر عمل هن ريت ٿيندو:
- جيڪڏهن صرف وسيلن جون حدون واضح طور تي بيان ڪيون ويون آهن، ته پوء هن وسيلن لاء درخواستون خودڪار طور تي حدن جي برابر قيمت وٺندي آهي (توهان ان جي تصديق ڪري سگهو ٿا بيان ڪندڙ ادارن کي ڪال ڪندي). اهي. حقيقت ۾، ڪنٽينر وسيلن جي ساڳئي مقدار تائين محدود هوندو جنهن کي هلائڻ جي ضرورت آهي.
- جيڪڏهن صرف درخواستون وسيلا لاءِ واضح طور تي بيان ڪيون ويون آهن، ته پوءِ هن وسيلن تي ڪابه مٿئين پابنديون مقرر نه آهن - يعني ڪنٽينر صرف نوڊ جي وسيلن تائين محدود آهي.
اهو پڻ ممڪن آهي ته وسيلن جي انتظام کي ترتيب ڏيڻ نه رڳو هڪ مخصوص ڪنٽينر جي سطح تي، پر هيٺ ڏنل ادارن کي استعمال ڪندي نالي جي جاء تي پڻ:
- حد جي حد NS ۾ ڪنٽينر/پوڊ جي سطح تي پابندي واري پاليسي کي بيان ڪري ٿو ۽ ڪنٽينر/پڊ تي ڊفالٽ حدون بيان ڪرڻ لاءِ ضروري آهي، انهي سان گڏ واضح طور تي ٿلهي ڪنٽينرز/پڊس (يا ان جي برعڪس) جي تخليق کي روڪڻ لاءِ، انهن جي تعداد کي محدود ڪريو. ۽ حدن ۽ درخواستن ۾ قدرن ۾ ممڪن فرق جو تعين ڪريو
- وسيلن جي کوٽ - بيان ڪريو پابندي واري پاليسي کي عام طور تي سڀني ڪنٽينرز لاءِ اين ايس ۾ ۽ استعمال ڪيو ويندو آهي، ضابطي جي طور تي، وسيلن جي وچ ۾ حد بندي ڪرڻ لاءِ (مفيد جڏهن ماحول کي سختي سان نوڊ جي سطح تي حد بندي نه ڪيو وڃي)
هيٺ ڏنل بيانن جا مثال آهن جيڪي وسيلن جي حد مقرر ڪن ٿا:
-
مخصوص ڪنٽينر جي سطح تي:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mاهي. هن حالت ۾، nginx سان ڪنٽينر کي هلائڻ لاءِ، توهان کي نوڊ تي گهٽ ۾ گهٽ 1G مفت ريم ۽ 0.2 سي پي يو جي ضرورت پوندي، جڏهن ته گهڻو ڪري ڪنٽينر 0.2 سي پي يو استعمال ڪري سگهي ٿو ۽ نوڊ تي موجود سموري ريم.
-
انٽيجر جي سطح تي 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اهي. سڀني ڪنٽينرز لاءِ ڊفالٽ نالي جي جاءِ ۾، درخواست سيٽ ڪئي ويندي 100m لاءِ سي پي يو ۽ 1G لاءِ OP، حد - 1 سي پي يو ۽ 2G. ساڳئي وقت، سي پي يو (50m <x <2) ۽ رام (500M <x <4G) لاءِ درخواست/حد ۾ ممڪن قدرن تي پڻ هڪ حد مقرر ڪئي وئي آهي.
-
پوڊ-سطح جي پابنديون ns:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1Giاهي. ڊفالٽ اين ايس ۾ هر پوڊ لاءِ 4 وي سي پي يو ۽ 1G جي حد هوندي.
هاڻي مان توهان کي ٻڌائڻ چاهيان ٿو ته انهن پابندين کي قائم ڪرڻ سان اسان کي ڪهڙا فائدا ملي سگهن ٿا.
نوڊس جي وچ ۾ لوڊ بيلنس ميڪانيزم
جئين توهان ڄاڻو ٿا، k8s جزو نوڊس جي وچ ۾ پوڊ جي ورڇ لاء ذميوار آهي، جهڙوڪ مقرر ڪندڙ، جيڪو هڪ مخصوص الگورتھم جي مطابق ڪم ڪري ٿو. هي الگورتھم ٻن مرحلن مان گذري ٿو جڏهن لانچ ڪرڻ لاءِ بهترين نوڊ چونڊيو:
- چڪاس
- رينگنگ
اهي. بيان ڪيل پاليسي جي مطابق، نوڊس شروعاتي طور تي چونڊيا ويا آھن جن تي ھڪڙي سيٽ جي بنياد تي پوڊ لانچ ڪرڻ ممڪن آھي اڳڪٿي ڪري ٿو (بشمول چيڪ ڪرڻ ته ڇا نوڊ وٽ ڪافي وسيلا آهن پوڊ کي هلائڻ لاءِ - PodFitsResources) ۽ پوءِ انهن نوڊس مان هر هڪ لاءِ، مطابق ترجيحات پوائنٽس ڏنا ويندا آهن (بشمول، وڌيڪ مفت وسيلا هڪ نوڊ وٽ آهن، وڌيڪ پوائنٽس ان کي تفويض ڪيا ويا آهن - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) ۽ پوڊ نوڊ تي تمام گهڻي پوائنٽن سان شروع ڪيو ويندو آهي (جيڪڏهن ڪيترائي نوڊس هڪ ئي وقت هن شرط کي پورو ڪن ٿا، پوءِ ھڪڙو بي ترتيب چونڊيو ويو آھي).
ساڳئي وقت، توهان کي اهو سمجهڻ جي ضرورت آهي ته شيڊولر، جڏهن نوڊ جي دستياب وسيلن جو جائزو وٺڻ، ڊيٽا طرفان هدايت ڪئي وئي آهي جيڪا وغيره ۾ ذخيرو ٿيل آهي - يعني. هن نوڊ تي هلندڙ هر پوڊ جي گهربل / حد جي وسيلن جي مقدار لاءِ، پر اصل وسيلن جي استعمال لاءِ نه. اها معلومات حاصل ڪري سگهجي ٿي حڪم جي پيداوار مان 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 طبقن مان هڪ مقرر ڪيو ويو آهي:
- ضمانت ٿيل - تفويض ڪيو ويو آهي جڏهن پوڊ ۾ هر ڪنٽينر لاءِ ميموري ۽ سي پي يو لاءِ درخواست ۽ حد بيان ڪئي وئي آهي، ۽ اهي قيمتون ملن گهرجن.
- ڦاٽڻ لائق - پوڊ ۾ گهٽ ۾ گهٽ هڪ ڪنٽينر هڪ درخواست ۽ حد آهي، درخواست سان < حد
- بهترين ڪوشش - جڏهن پوڊ ۾ هڪ واحد ڪنٽينر وسيلن تائين محدود ناهي
ساڳئي وقت، جڏهن هڪ نوڊ وسيلن جي کوٽ جو تجربو ڪري ٿو (ڊسڪ، ياداشت)، ڪوبيليٽ هڪ مخصوص الورورٿم جي مطابق پوڊ کي درجه بندي ۽ بي دخل ڪرڻ شروع ڪري ٿو جيڪو پوڊ ۽ ان جي QoS ڪلاس جي ترجيح کي مدنظر رکي ٿو. مثال طور، جيڪڏهن اسان رام جي باري ۾ ڳالهائي رهيا آهيون، پوء QoS ڪلاس جي بنياد تي، پوائنٽون ڏنل اصولن جي مطابق ڏنا ويا آهن:
- تصديق ٿيل:-998
- بهترين ڪوشش: 1000
- ڦاٽڻ لائق: منٽ (وڌ کان وڌ (2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)
اهي. ساڳي ترجيح سان، ڪوبيليٽ پهريون ڀيرو پوڊز کي نيڪال ڪندو بهترين ڪوشش سان QoS ڪلاس نوڊ مان.
ٿڪل: جيڪڏھن توھان چاھيو ٿا ته مطلوبہ پوڊ کي نوڊ مان ڪڍڻ جي امڪان کي گھٽائڻ جي صورت ۾ ان تي وسيلن جي کوٽ جي صورت ۾، پوءِ ترجيح سان گڏ، توھان کي ان لاءِ درخواست/حد مقرر ڪرڻ جو به خيال رکڻو پوندو.
ايپليڪيشن پوڊس جي افقي خودڪار اسڪيلنگ لاءِ ميڪانيزم (HPA)
جڏهن ڪم اهو آهي ته پوڊ جي تعداد کي خودڪار طريقي سان وڌائڻ ۽ گھٽائڻ جو انحصار وسيلن جي استعمال تي (سسٽم - سي پي يو / رام يا صارف - آر پي ايس)، جهڙوڪ k8s ادارو. هاء (Horizontal Pod Autoscaler). جنهن جو الگورتھم هن ريت آهي:
- مشاهدو ڪيل وسيلن جي موجوده پڙهائي مقرر ڪئي وئي آهي (currentMetricValue)
- وسيلن لاء گهربل قدر مقرر ڪيا ويا آهن (desiredMetricValue)، جيڪي سسٽم وسيلن لاء درخواست استعمال ڪندي مقرر ڪيا ويا آهن
- نقلن جو موجوده تعداد طئي ڪيو ويو آھي (موجوده ريپليڪا)
- هيٺ ڏنل فارمولا ڳڻپيندو آهي گهربل تعداد جي نقلن جو (مطلوب ريپليڪا)
desiredReplicas = [CurrentReplicas * (currentMetricValue / desiredMetricValue)]
انهي صورت ۾، اسڪيلنگ نه ٿيندي جڏهن ڪوفيشيٽ (currentMetricValue / desiredMetricValue) 1 جي ويجهو هوندو (هن صورت ۾، اسان پاڻ کي قابل اجازت غلطي مقرر ڪري سگهون ٿا؛ ڊفالٽ طور اهو 0.1 آهي).
اچو ته ڏسو ته ڪيئن hpa ايپ ٽيسٽ ايپليڪيشن جي مثال کي استعمال ڪندي ڪم ڪري ٿو (تعريف جي طور تي بيان ڪيل)، جتي سي پي يو جي استعمال جي بنياد تي نقلن جو تعداد تبديل ڪرڻ ضروري آهي:
-
ايپليڪيشن پڌرو
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 ڪنٽينر شامل آهن، جن مان هر هڪ لاء مخصوص درخواستون CPU لاء.
-
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