Geekly articles weekly

Kubernetes: ما أهمية إعداد إدارة موارد النظام؟

كقاعدة عامة ، هناك حاجة دائمًا إلى توفير مجموعة مخصصة من الموارد لأي تطبيق لتشغيلها الصحيح والمستقر. ولكن ماذا لو تعمل عدة تطبيقات على نفس القدرات في وقت واحد؟ كيفية توفير الحد الأدنى من الموارد اللازمة لكل منهم؟ كيف يمكنني الحد من استهلاك الموارد؟ كيفية توزيع الحمل بشكل صحيح بين العقد؟ كيفية التأكد من آلية القياس الأفقي في حالة زيادة الحمل على التطبيق؟



يجب أن تبدأ مع الأنواع الأساسية للموارد الموجودة في النظام - بالطبع ، وقت المعالج وذاكرة الوصول العشوائي. في عروض k8 ، يتم قياس هذه الأنواع من الموارد بالوحدات التالية:


  • وحدة المعالجة المركزية - في النوى
  • RAM - بالبايت

علاوة على ذلك ، لكل مورد هناك فرصة لتعيين نوعين من المتطلبات - الطلبات والحدود . الطلبات - يصف الحد الأدنى لمتطلبات الموارد المجانية للعقدة لتشغيل الحاوية (والموقد ككل) ، بينما تحدد الحدود قيودًا صارمة على الموارد المتاحة للحاوية.


من المهم أن نفهم أنه في البيان ليس من الضروري تحديد كلا النوعين بشكل صريح ، وسيكون السلوك على النحو التالي:


  • إذا تم تعيين حدود المورد فقط بشكل صريح ، فستتلقى طلبات هذا المورد تلقائيًا قيمة مساوية للحدود (يمكن التحقق من ذلك عن طريق استدعاء كيانات الوصف). أي في الواقع ، سيتم تقييد تشغيل الحاوية بنفس كمية الموارد التي يتطلبها تشغيلها.
  • إذا تم تعيين الطلبات فقط صراحةً لأحد الموارد ، فلن يتم تعيين قيود على هذا المورد - أي الحاوية محدودة فقط بواسطة موارد العقدة نفسها.

من الممكن أيضًا تكوين إدارة الموارد ليس فقط على مستوى حاوية محددة ، ولكن أيضًا على مستوى مساحة الاسم باستخدام الكيانات التالية:


  • LimitRange - يصف سياسة التقييد على مستوى الحاوية / الموقد بالعدد ns وهناك حاجة لوصف القيود الافتراضية على الحاوية / الموقد ، وكذلك لمنع إنشاء حاويات / موقد من الدهون (أو العكس) ، والحد من عددها وتحديد الفرق المحتمل بين الحدود و الطلبات
  • ResourceQuotas - وصف سياسة التقييد عمومًا لجميع الحاويات بالعدد ns ويستخدم ، كقاعدة عامة ، لتحديد الموارد بين البيئات (مفيد عندما لا يتم تحديد البيئات بشكل صارم على مستوى العقد)

فيما يلي أمثلة على البيانات التي تم تعيين حدود الموارد فيها:


  • على مستوى الحاوية المحددة:


    containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200m

    أي في هذه الحالة ، لبدء حاوية مع nginx ، ستحتاج على الأقل إلى وجود 1G OP و 0.2 CPU مجانًا على العقدة ، في حين أن الحاوية القصوى يمكن أن تأكل 0.2 CPU وكل OP المتاحة على العقدة.


  • في عدد صحيح ns:


     apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2Gi

    أي لا يمكن أن يتجاوز مجموع كل حاويات الطلب في ns الافتراضي 300m لوحدة المعالجة المركزية و 1 G لـ OP ، ومجموع الحد الأقصى 700m لوحدة المعالجة المركزية و 2 G لـ OP.


  • القيود الافتراضية للحاويات بالعدد:


     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 لوحدة المعالجة المركزية و 1 G لـ OP ، وحد - 1 CPU و 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

    أي لكل موقد في ns الافتراضي ، سيتم تعيين حد 4 vCPU و 1G.



الآن أود أن أخبرك بالمزايا التي يمكن أن يوفرها لنا تثبيت هذه القيود.


آلية موازنة التحميل بين العقد


كما تعلمون ، فإن مكون k8s مثل المجدول ، والذي يعمل وفقًا لخوارزمية معينة ، مسؤول عن توزيع الموقد على العقد. تمر هذه الخوارزمية في عملية اختيار العقدة المثالية للتشغيل عبر مرحلتين:


  1. تصفية
  2. تصنيف

أي وفقًا للسياسة الموضحة ، يتم تحديد العقد مبدئيًا والتي يمكن تشغيلها على أساس مجموعة من المتنبئات (بما في ذلك ما إذا كانت العقدة لديها موارد كافية لتشغيل الموقد - 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, ie, overcommitted.) Resource Requests Limits -------- -------- ------ cpu 487m (3%) 822m (5%) memory 15856217600 (2%) 749976320 (3%) ephemeral-storage 0 (0%) 0 (0%)

هنا نرى جميع القرون تعمل على عقدة معينة ، وكذلك الموارد التي يطلبها كل من القرون. وإليك ما تبدو عليه سجلات المجدول عند بدء تشغيل pod cronjob-cron-events-1573793820-xt6q9 (تظهر هذه المعلومات في سجل المجدول عند تعيين المستوى العاشر من تسجيل الدخول في وسيطات أمر start - 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 فئات جودة الخدمة:


  1. guaranuted - يتم تعيينه عند تعيين طلب وحد لكل حاوية في الموقد للذاكرة ووحدة المعالجة المركزية ، ويجب أن تتطابق هذه القيم
  2. قابل للانفجار - حاوية واحدة على الأقل في الموقد لها طلب وحد ، بينما طلب <حد
  3. أفضل جهد - عندما لا توجد حاوية في الموقد محدودة في الموارد

في الوقت نفسه ، عندما يكون هناك نقص في الموارد (القرص ، الذاكرة) على العقدة ، يبدأ kubelet بترتيب وإخلاء السنفات وفقًا لخوارزمية معينة تأخذ في الاعتبار أولوية pod وفئة جودة الخدمة الخاصة به. على سبيل المثال ، إذا كنا نتحدث عن ذاكرة الوصول العشوائي (RAM) ، فسيتم منح نقاط فئة جودة الخدمة وفقًا للمبدأ التالي:


  • مضمون : -998
  • أحسن تجربة : 1000
  • Burstable : دقيقة (بحد أقصى (2 ، 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes) ، 999)

أي مع نفس الأولوية ، سوف يقوم kubelet أولاً بطرد القرون مع فئة جودة الخدمة الأفضل من العقدة.


الخلاصة : إذا كنت ترغب في تقليل احتمالية إخلاء الحافظة اللازمة من العقدة في حالة عدم وجود موارد كافية عليها ، ثم مع الأولوية ، يجب عليك أيضًا العناية بتحديد الطلب / الحد لذلك.


موقد التطبيق آلية القياس التلقائي الأفقية (HPA)


عندما تكون المهمة هي زيادة وتقليل عدد السنفات تلقائيًا وفقًا لاستخدام الموارد (النظام - وحدة المعالجة المركزية / ذاكرة الوصول العشوائي أو المستخدم - rps) ، يمكن أن تساعد k8s مثل HPA (Horizontal Pod Autoscaler) في حلها. الخوارزمية التي هي كما يلي:


  1. يتم تحديد القراءات الحالية للمورد المرصود (currentMetricValue)
  2. يتم تحديد القيم المطلوبة للمورد (المرجوة MetricValue) ، والتي تم تعيينها لموارد النظام باستخدام الطلب
  3. يتم تحديد عدد النسخ المتماثلة الحالية (currentReplicas)
  4. تحسب الصيغة التالية العدد المطلوب من النسخ المتماثلة (wishReplicas)
    wantReplicas = [currentReplicas * (currentMetricValue / desireMetricValue)]

ومع ذلك ، لن يحدث القياس عندما يكون المعامل (currentMetricValue / wishMetricValue) قريبًا من 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-source ، لكل طلب من طلبات وحدة المعالجة المركزية.


  • 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

    أي أنشأنا hpa الذي سيراقب اختبار التطبيق Deployment وضبط عدد الموقد مع التطبيق بناءً على مؤشر وحدة المعالجة المركزية (نتوقع أن تستهلك الموقد 30٪ من وحدة المعالجة المركزية التي تطلبها) ، بينما يكون عدد النسخ المتماثلة في حدود 2-10.


    الآن ، سننظر في آلية تشغيل HPA إذا قمنا بتطبيق عبء على أحد الموقد:


      # kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi


المجموع لدينا ما يلي:


  • القيمة المطلوبة (wishMetricValue) - وفقًا لإعدادات hpa ، لدينا 30٪
  • القيمة الحالية (currentMetricValue) - للحساب ، يقوم مدير التحكم بحساب متوسط ​​قيمة استهلاك الموارد في٪ ، أي هل مشروط بما يلي:
    1. الحصول على القيم المطلقة لمقاييس الموقد من خادم القياس ، أي 101 م و 4 م
    2. يحسب متوسط ​​القيمة المطلقة ، أي (101 م + 4 م) / 2 = 53 م
    3. الحصول على القيمة المطلقة لاستهلاك المورد المطلوب (لهذا ، يتم تلخيص طلب جميع الحاويات) 60m + 30m = 90m
    4. يحسب متوسط ​​نسبة استهلاك وحدة المعالجة المركزية بالنسبة إلى طلب الموقد 53 م / 90 م * 100 ٪ = 59 ٪

الآن لدينا كل ما هو ضروري لتحديد ما إذا كان من الضروري تغيير عدد النسخ المتماثلة ، لذلك نحسب المعامل:


ratio = 59% / 30% = 1.96


أي يجب زيادة عدد النسخ المتماثلة ~ 2 مرات وتشكل [2 * 1.96] = 4.


الخلاصة: كما ترون ، من أجل أن تعمل هذه الآلية ، هناك شرط مسبق يشمل توافر الطلبات لجميع الحاويات في الموقد المرصود.


آلية القياس التلقائي الأفقي للعقد (Cluster Autoscaler)


من أجل تحييد التأثير السلبي على النظام أثناء رشقات الحمل ، فإن وجود hpa المكوّن لا يكفي. على سبيل المثال ، وفقًا للإعدادات في إدارة وحدة التحكم hpa تقرر أن عدد النسخ المتماثلة يحتاج إلى مضاعفة ، ومع ذلك ، لا توجد موارد مجانية على العقد لتشغيل مثل هذا العدد من القرون (أي ، لا يمكن للعقدة توفير الموارد المطلوبة لطلبات pod) وهذه أدخل حالة الانتظار.


في هذه الحالة ، إذا كان لدى المزود IaaS / PaaS المناسب (على سبيل المثال ، GKE / GCE ، AKS ، EKS ، إلخ) ، يمكن أن تساعدنا أداة مثل Node Autoscaler . يسمح لك بتعيين الحد الأقصى والحد الأدنى لعدد العقد في الكتلة وضبط العدد الحالي للعقد تلقائيًا (عن طريق الوصول إلى واجهة برمجة التطبيقات لمزود الخدمة السحابية لطلب / حذف العقد) عندما يكون هناك نقص في الموارد في المجموعة ولا يمكن جدولة البرامج (في حالة الانتظار).


الخلاصة: من أجل التمكن من قياس العقد تلقائيًا ، من الضروري تحديد الطلبات في حاويات الموقد حتى تتمكن K8s من تقييم حمل العقد بشكل صحيح ، وبالتالي الإبلاغ عن عدم وجود موارد في المجموعة لبدء الموقد التالي.



استنتاج


تجدر الإشارة إلى أن تحديد حدود الموارد للحاوية ليس شرطًا أساسيًا لبدء تشغيل التطبيق بنجاح ، ولكن لا يزال من الأفضل القيام بذلك للأسباب التالية:


  1. لعملية جدولة أكثر دقة من حيث موازنة التحميل بين العقد k8s
  2. لتقليل احتمالية حدوث عملية إخلاء الموقد
  3. بالنسبة لموقد تطبيقات القياس التلقائي الأفقي (HPA)
  4. للتحجيم التلقائي الأفقي للعقد (Cluster Autoscaling) لموفري الخدمات السحابية

اقرأ أيضًا مقالات أخرى على مدونتنا:


Source: https://habr.com/ru/post/ar480072/

More articles:


All Articles