مفاهيم قابلية التوسع

5 دقائق

قبل العثور على حل التحجيم، تحتاج إلى فهم قابلية التوسع وكيفية تطبيقها على تطبيقات Kubernetes.

في هذه الوحدة، نراجع بعض مفاهيم قابلية التوسع.

قابلية التوسع

تصف قابلية التوسع قدرة التطبيق أو النظام على التعامل مع كمية متزايدة من العمل عن طريق إضافة المزيد من الموارد إليه.

في السيناريو المثال، مقدار العمل الذي يواجه زيادة هو عدد طلبات العملاء. يمكن تمثيل مقدار الموارد المضافة بطريقتين: قابلية التوسع الرأسي وقابلية التوسع الأفقي.

قابلية التوسع الرأسي

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

Vertical scaling diagram.

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

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

قابلية التوسع الأفقي

تشير قابلية التوسع الأفقي أو التوسع إلى تحجيم نظام عن طريق تكرار التطبيق وموازنة الحمل عبر مثيلات التطبيق.

Horizontal scaling diagram.

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

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

قابلية التوسع اليدوي على نظام Kubernetes

قبل أن نغطي HPA، دعنا نراجع كيفية توسيع نطاق تطبيق Kubernetes يدويا.

كل عملية نشر مرتبطة بمورد آخر يسمى ReplicaSet. مجموعة النسخ المتماثلة مسؤولة عن الحفاظ على "حالة النسخة المتماثلة المطلوبة" وتوسيع نطاق التطبيق الحقيقي داخل أو خارج للحفاظ على الحالة المطلوبة بنفس الحالة الحقيقية. يمكنك التحكم في عدد النسخ المتماثلة في التوزيع من خلال spec.replicas المفتاح في مواصفات التوزيع. يعين هذا المفتاح عدد النسخ المتماثلة المطلوبة في ReplicaSet الأساسية ويجبر وحدة التحكم في النسخ المتماثل على الاحتفاظ بهذا العدد من النسخ المتماثلة في أي وقت.

يمكنك أيضا التحكم في عدد النسخ المتماثلة في عملية نشر باستخدام kubectl scale deploy/contoso-website --replicas <number> الأمر . يغير هذا الأمر بشكل ديناميكي عدد النسخ المتماثلة المطلوبة في التوزيع ويغير حجم التطبيق أو يتدرج.

HorizontalPodAutoscaler (HPA)

يُعد مورد HPA المورد الأصلي لنظام Kubernetes 1.8+ الذي يوفر قابلية التوسع الأفقي للحجيرات الموجودة في نظام المجموعة. ويراقب مقاييس واجهة برمجة التطبيقات (API) كل 30 ثانية لاكتشاف أي تغييرات في عدد النسخ المتماثلة المطلوبة. إذا كان عدد النسخ المتماثلة المطلوب مختلفا عن عدد النسخ المتماثلة الحالية، فإن مدير وحدة التحكم، الذي يدير كائنات HPA، يقوم بتغيير حجم النشر داخل أو خارج.

HorizontalPodAutoscaling design diagram.

تعمل موارد HPA مع مجموعة واجهة برمجة التطبيقات autoscaling في نظام Kubernetes. هناك إصداران لمجموعة واجهة برمجة التطبيقات هذه: v1 و v2. v1 يسمح الإصدار للنشر بالتحجيم استنادا إلى مقاييس وحدة المعالجة المركزية فقط. v2 يسمح الإصدار بالمراقبة الأصلية لكل من وحدة المعالجة المركزية والذاكرة. في هذه الوحدة النمطية v2 ، نستخدم الإصدار .

يرتبط كل مورد من موارد HPA بمرجع للتوسع، ويتم تحديده في مفتاح spec.scaleTargetRef لبيان مورد HPA. يجب أن يحتوي مرجع المقياس هذا على جرابات أساسية ليتم تحجيمها، وإلا فلن يعمل HPA، حيث لا يمكن تطبيق التحجيم على الكائنات التي لا يمكن تحجيمها، مثل DaemonSets.

من المهم أن يكون لكل جراب طلب مورد معين في مواصفاته. لا يمكن لخوارزمية HPA حساب المقاييس بشكل صحيح وتحديد استخدام الموارد دون هذا الإعداد. يمكنك تعيين هذا الحد من خلال spec.template.spec.containers[].resources المفتاح في بيان التوزيع، كما هو موضح في المثال التالي:

spec:
  template:
    spec:
      containers:
        - resources:
            requests:
              cpu: 250m
              memory: 256M
            limits:
              cpu: 500m
              memory: 512M

مثال على بيان HPA

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

‏‫اختبر معلوماتك

ما هو التحجيم الأفقي؟

عندما يتم نسخ تطبيق من أجل الحفاظ على تحميل أثقل.

إضافة المزيد من ذاكرة RAM إلى الجهاز الظاهري.

عرض التطبيق عديم الحالة كي يمكن استخدامه دون تخزين دائم.

لماذا من المهم وجود مجموعة من طلبات المورد على الحجيرات المرتبطة بمورد HPA؟

لأنها الطريقة الوحيدة لحساب استخدام الموارد.

يستحسن إجراء ذلك حتى لا يضعف التطبيق، وإن كان ذلك غير مهم.

لذا يعرف مورد HPA متى يتم إيقاف توسع مورد ما استناداً إلى الموارد المتوفرة في نظام المجموعة.

لماذا لا يستحسن التوسع الرأسي للتطبيقات عديمة الحالة؟

التحجيم العمودي يكرر التطبيقات ويصعب على التطبيقات عديمة الحالة.

يتطلب تطبيقا ذو حالة ليتم تحجيمه عموديا.

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

عليك الإجابة على كل الأسئلة قبل مراجعة عملك.

متابعة