🥇كيفية الوصول إلى موارد Kubernetes Pod

المكافأة من توهاد

عند البدء باستخدام Kubernetes، من الشائع نسيان إعداد موارد الحاوية. في هذه المرحلة، يكفي التأكد من أن صورة Docker تعمل ويمكن نشرها في مجموعة Kubernetes.

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

فريق Kubernetes aaS من Mail.ru ترجمة مقال حول موارد الحاوية (CPU & MEM) والطلبات وقيود الموارد. ستتعرف على فوائد هذه الإعدادات وماذا يحدث إذا لم تقم بتعيينها.

موارد الحوسبة

لدينا نوعان من الموارد مع الوحدات التالية:

وحدة المعالجة المركزية (CPU) - النوى؛
الذاكرة (MEM) - بايت.

يتم تحديد الموارد لكل حاوية. في ملف Pod YAML التالي، سترى قسم الموارد الذي يحتوي على الموارد المطلوبة والحد منها:

موارد الكبسولة المطلوبة = مجموع الموارد المطلوبة لجميع الحاويات؛
حد موارد الكبسولة = مجموع كل حدود موارد الكبسولة.

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

مثال على الموارد المطلوبة والمحدودة

حقل resources.requested من المواصفات Pod هو أحد العناصر المستخدمة للعثور على العقدة المطلوبة. يمكنك بالفعل التخطيط لنشر Pod لذلك. كيف تجد العقدة المناسبة؟

يتكون Kubernetes من عدة مكونات، بما في ذلك العقدة الرئيسية أو العقدة الرئيسية (مستوى تحكم Kubernetes). تحتوي العقدة الرئيسية على عدة عمليات: kube-apserver، وkube-controller-manager، وkube-scheduler.

تعد عملية جدولة kube مسؤولة عن مراجعة البودات المنشأة حديثًا والعثور على العقد العاملة المحتملة التي تطابق جميع طلبات البودات، بما في ذلك عدد الموارد المطلوبة. تم ترتيب قائمة العقد التي عثر عليها بواسطة kube-scheduler. تتم جدولة الكبسولة على العقدة التي حصلت على أعلى الدرجات.

أين سيتم وضع الكبسولة الأرجوانية؟

في الصورة، يمكنك أن ترى أن kube-scheduler يجب أن يقوم بجدولة حاوية أرجوانية جديدة. تحتوي مجموعة Kubernetes على عقدتين: A وB. كما ترى، لا يمكن لـ kube-scheduler جدولة Pod على العقدة A - الموارد المتاحة (غير المطلوبة) لا تتطابق مع طلبات Pod الأرجواني. لذا، فإن الذاكرة التي تبلغ 1 غيغابايت التي تطلبها الكبسولة الأرجوانية لن تتناسب مع العقدة A، نظرًا لأن الذاكرة المتوفرة تبلغ 0,5 غيغابايت. لكن العقدة B لديها موارد كافية. ونتيجة لذلك، يقرر kube-scheduler أن وجهة الكبسولة الأرجوانية هي العقدة B.

الآن نحن نعرف كيف تؤثر الموارد المطلوبة على اختيار العقدة لتشغيل Pod. ولكن ما هو تأثير الموارد الهامشية؟

حد المورد هو الحد الذي لا يمكن لوحدة المعالجة المركزية/وحدة المعالجة المركزية (MEM) تجاوزه. ومع ذلك، فإن مورد وحدة المعالجة المركزية مرن، لذا فإن الحاويات التي تصل إلى حدود وحدة المعالجة المركزية الخاصة بها لن تتسبب في خروج الكبسولة. بدلاً من ذلك، سيبدأ التحكم في وحدة المعالجة المركزية (CPU). إذا تم الوصول إلى حد استخدام MEM، فسيتم إيقاف الحاوية بسبب OOM-Killer وإعادة تشغيلها إذا سمح بذلك إعداد RestartPolicy.

الموارد المطلوبة والحد الأقصى بالتفصيل

اتصالات الموارد بين Docker وKubernetes

أفضل طريقة لشرح كيفية عمل طلبات الموارد وحدود الموارد هي تقديم العلاقة بين Kubernetes وDocker. في الصورة أعلاه، يمكنك رؤية كيفية ارتباط حقول Kubernetes وعلامات بدء تشغيل Docker.

الذاكرة: الطلب والتقييد

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

كما ذكر أعلاه، يتم قياس الذاكرة بالبايت. مرتكز على وثائق Kubernetesيمكننا تحديد الذاكرة كرقم. عادة ما يكون عددًا صحيحًا، على سبيل المثال 2678 - أي 2678 بايت. يمكنك أيضًا استخدام اللواحق G и Giالشيء الرئيسي هو أن نتذكر أنهما ليسا متساويين. الأول عشري والثاني ثنائي. مثل المثال المذكور في وثائق k8s: 128974848, 129e6, 129M, 123Mi - إنهما متساويان عمليا.

خيار كوبيرنيتيس limits.memory يطابق العلم --memory من دوكر. في حالة request.memory لا يوجد سهم لـ Docker لأن Docker لا يستخدم هذا الحقل. قد تسأل، هل هذا ضروري حتى؟ نعم بحاجة. كما قلت من قبل، المجال مهم بالنسبة لـ Kubernetes. واستنادًا إلى المعلومات الواردة منه، يقرر kube-scheduler العقدة التي سيتم جدولة الكبسولة فيها.

ماذا يحدث إذا قمت بتعيين ذاكرة غير كافية للطلب؟

إذا وصلت الحاوية إلى حدود الذاكرة المطلوبة، فسيتم وضع Pod في مجموعة من Pods التي تتوقف عند عدم وجود ذاكرة كافية في العقدة.

ماذا يحدث إذا قمت بتعيين حد الذاكرة منخفضًا جدًا؟

إذا تجاوزت الحاوية حد الذاكرة، فسيتم إنهاؤها بسبب OOM-Killed. وسيتم إعادة التشغيل إن أمكن بناءً على RestartPolicy حيث تكون القيمة الافتراضية Always.

ماذا يحدث إذا لم تحدد الذاكرة المطلوبة؟

سيأخذ Kubernetes القيمة الحدية ويعينها كقيمة افتراضية.

ماذا يمكن أن يحدث إذا لم تحدد حدًا للذاكرة؟

الحاوية ليس لها أي قيود، يمكنها استخدام أي قدر تريده من الذاكرة. إذا بدأ في استخدام كل الذاكرة المتوفرة للعقدة، فسوف يقتله OOM. سيتم بعد ذلك إعادة تشغيل الحاوية إن أمكن بناءً على RestartPolicy.

ماذا يحدث إذا لم تحدد حدود الذاكرة؟

هذا هو السيناريو الأسوأ: لا يعرف المجدول عدد الموارد التي تتطلبها الحاوية، وقد يتسبب ذلك في حدوث مشكلات خطيرة في العقدة. في هذه الحالة، سيكون من الجيد أن يكون لديك حدود افتراضية لمساحة الاسم (يتم تعيينها بواسطة LimitRange). لا توجد حدود افتراضية - لا توجد حدود للكبسولة، ويمكنها استخدام أكبر قدر ممكن من الذاكرة.

إذا كانت الذاكرة المطلوبة أكبر مما يمكن أن تقدمه العقدة، فلن تتم جدولة الكبسولة. من المهم أن تتذكر ذلك Requests.memory - ليس الحد الأدنى للقيمة. هذا وصف لمقدار الذاكرة الكافية للحفاظ على تشغيل الحاوية بشكل مستمر.

يوصى عادةً بتعيين نفس القيمة لـ request.memory и limit.memory. وهذا يضمن أن Kubernetes لن يقوم بجدولة Pod على عقدة بها ذاكرة كافية لتشغيل Pod ولكنها ليست كافية لتشغيله. تذكر: تخطيط Kubernetes Pod يأخذ بعين الاعتبار فقط requests.memoryو limits.memory لا يأخذ بعين الاعتبار.

وحدة المعالجة المركزية: الطلب والحد

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

مع وحدة المعالجة المركزية، كل شيء أكثر تعقيدًا بعض الشيء. بالعودة إلى صورة العلاقة بين Kubernetes وDocker، يمكنك رؤية ذلك request.cpu مباراة --cpu-sharesفي حين limit.cpu يطابق العلم cpus في دوكر.

يتم ضرب وحدة المعالجة المركزية التي يطلبها Kubernetes في 1024، وهي نسبة دورات وحدة المعالجة المركزية. إذا كنت تريد طلب نواة واحدة كاملة، فيجب عليك إضافتها cpu: 1كما هو مبين أعلاه.

إن طلب نواة كاملة (النسبة = 1024) لا يعني أن حاويتك ستستقبلها. إذا كان جهازك المضيف يحتوي على نواة واحدة فقط وكنت تقوم بتشغيل أكثر من حاوية واحدة، فيجب على جميع الحاويات مشاركة وحدة المعالجة المركزية المتاحة فيما بينها. كيف يحدث هذا؟ دعونا ننظر إلى الصورة.

طلب وحدة المعالجة المركزية - نظام أساسي واحد

لنتخيل أن لديك نظام مضيف أحادي النواة يقوم بتشغيل الحاويات. قامت الأم (Kubernetes) بخبز فطيرة (CPU) وتريد تقسيمها بين الأطفال (الحاويات). ثلاثة أطفال يريدون فطيرة كاملة (النسبة = 1024)، طفل آخر يريد نصف فطيرة (512). تريد أمي أن تكون عادلة وتقوم بعملية حسابية بسيطة.

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

بناء على الحساب، سيحصل ثلاثة أطفال على 28٪ من النواة، وليس النواة بأكملها. الطفل الرابع سيحصل على 14% من النواة الكاملة وليس النصف. لكن الأمور ستكون مختلفة إذا كان لديك نظام متعدد النواة.

طلب وحدة المعالجة المركزية - نظام متعدد النواة (4).

في الصورة أعلاه يمكنك أن ترى أن ثلاثة أطفال يريدون فطيرة كاملة، وواحد يريد النصف. وبما أن أمي خبزت أربع فطائر، فإن كل طفل من أطفالها سيحصل على العدد الذي يريده. في النظام متعدد النواة، يتم توزيع موارد المعالج عبر جميع مراكز المعالج المتاحة. إذا كانت الحاوية مقتصرة على أقل من نواة وحدة المعالجة المركزية الكاملة، فلا يزال بإمكانها استخدامها بنسبة 100%.

تم تبسيط الحسابات المذكورة أعلاه لفهم كيفية توزيع وحدة المعالجة المركزية بين الحاويات. بالطبع، إلى جانب الحاويات نفسها، هناك عمليات أخرى تستخدم أيضًا موارد وحدة المعالجة المركزية. عندما تكون العمليات في إحدى الحاويات خاملة، يمكن للآخرين استخدام مواردها. CPU: "200m" مباراة CPU: 0,2وهو ما يعني حوالي 20% من نواة واحدة.

الآن دعنا نتحدث عن limit.cpu. يتم ضرب وحدة المعالجة المركزية التي يحدها Kubernetes بـ 100. والنتيجة هي مقدار الوقت الذي يمكن للحاوية استخدامه كل 100 ميكرو ثانية (cpu-period).

limit.cpu يطابق علم Docker --cpus. هذا مزيج جديد من القديم --cpu-period и --cpu-quota. من خلال تعيينه، نشير إلى عدد موارد وحدة المعالجة المركزية المتاحة التي يمكن للحاوية استخدامها إلى الحد الأقصى قبل بدء التقييد:

وحدات المعالجة المركزية - مزيج cpu-period и cpu-quota. cpus = 1.5 يعادل الإعداد cpu-period = 100000 и cpu-quota = 150000;
فترة وحدة المعالجة المركزية - فترة جدولة وحدة المعالجة المركزية CFS، الافتراضي 100 ميكروثانية؛
حصة وحدة المعالجة المركزية - عدد الميكروثانية بالداخل cpu-period، الذي يحده الحاوية.

ماذا يحدث إذا قمت بتثبيت وحدة المعالجة المركزية المطلوبة غير كافية؟

إذا كانت الحاوية تحتاج إلى أكثر مما تم تثبيته، فسوف تسرق وحدة المعالجة المركزية من العمليات الأخرى.

ماذا يحدث إذا قمت بتعيين حد وحدة المعالجة المركزية منخفضًا جدًا؟

وبما أن مورد وحدة المعالجة المركزية قابل للتعديل، فسيتم تشغيل التقييد.

ماذا يحدث إذا لم تحدد طلب وحدة المعالجة المركزية؟

كما هو الحال مع الذاكرة، قيمة الطلب تساوي الحد.

ماذا يحدث إذا لم تحدد حدًا لوحدة المعالجة المركزية؟

ستستخدم الحاوية القدر الذي تحتاجه من وحدة المعالجة المركزية. إذا تم تعريف سياسة وحدة المعالجة المركزية الافتراضية (LimitRange) في مساحة الاسم، فسيتم استخدام هذا الحد أيضًا للحاوية.

ماذا يحدث إذا لم تحدد طلبًا أو حدًا لوحدة المعالجة المركزية؟

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

تذكر: إذا طلبت وحدة معالجة مركزية أكبر مما يمكن أن توفره العقد، فلن تتم جدولة الكبسولة. Requests.cpu - ليست القيمة الدنيا، ولكنها قيمة كافية لبدء تشغيل الكبسولة والعمل دون أعطال. إذا لم يقم التطبيق بإجراء عمليات حسابية معقدة، فالخيار الأفضل هو التثبيت request.cpu <= 1 وإطلاق أكبر عدد ممكن من النسخ المتماثلة حسب الحاجة.

المبلغ المثالي للموارد المطلوبة أو الحد الأقصى للموارد

لقد تعلمنا عن محدودية موارد الحوسبة. حان الوقت الآن للإجابة على السؤال: "كم عدد الموارد التي يحتاجها جهاز Pod الخاص بي لتشغيل التطبيق دون أي مشاكل؟ ما هو المبلغ المثالي؟

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

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

كمثال انظر هذا لوحة القيادة جرافانا. يعرض الفرق بين الموارد المطلوبة أو حد الموارد واستخدام الموارد الحالي.

اختتام

يساعد طلب الموارد والحد منها في الحفاظ على صحة مجموعة Kubernetes الخاصة بك. يعمل تكوين الحد المناسب على تقليل التكاليف ويحافظ على تشغيل التطبيقات في جميع الأوقات.

باختصار، هناك بعض الأشياء التي يجب وضعها في الاعتبار:

الموارد المطلوبة هي تكوين يتم أخذه في الاعتبار عند بدء التشغيل (عندما يخطط Kubernetes لاستضافة التطبيق). في المقابل، يعد الحد من الموارد أمرًا مهمًا في وقت التشغيل، عندما يكون التطبيق قيد التشغيل بالفعل على العقدة.
بالمقارنة مع الذاكرة، تعتبر وحدة المعالجة المركزية موردًا منظمًا. إذا لم يكن هناك ما يكفي من وحدة المعالجة المركزية، فلن يتم إيقاف تشغيل جهاز Pod الخاص بك وسيتم تشغيل آلية الاختناق.
الموارد المطلوبة والحد الأقصى للموارد ليسا الحد الأدنى والحد الأقصى للقيم! من خلال تحديد الموارد المطلوبة، فإنك تضمن تشغيل التطبيق دون مشاكل.
من الممارسات الجيدة تعيين طلب الذاكرة مساويًا لحد الذاكرة.
طيب طلب التثبيت CPU <=1إذا لم يقم التطبيق بإجراء عمليات حسابية معقدة.
إذا طلبت موارد أكثر مما هو متاح على العقدة، فلن تتم جدولة Pod إلى تلك العقدة أبدًا.
لتحديد المقدار الصحيح للموارد المطلوبة/حدود الموارد، استخدم اختبار الحمل ومراقبته.

آمل أن تساعدك هذه المقالة على فهم المفهوم الأساسي للحد من الموارد. وستكون قادرًا على تطبيق هذه المعرفة في عملك.

حظا سعيدا!

ماذا تقرأ:

المصدر: www.habr.com

كيفية الوصول إلى موارد Kubernetes Pod