مشاركة عبر

خيارات الترقية والتوصيات لمجموعات Azure Kubernetes Service (AKS)

تتناول هذه المقالة خيارات الترقية لمجموعات AKS وتوفر توصيات تستند إلى السيناريو لتحديات الترقية الشائعة.

الخيارات للترقية

إجراء ترقيات يدوية

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

تكوين الترقيات التلقائية

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

اعتبارات خاصة لتجمعات العقد التي تغطي مناطق توفر متعددة

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

تحسين الترقيات لتحسين الأداء وتقليل الاضطرابات

اجمع بين نافذة الصيانة المخطط لها، وMax Surge، وموازنة تعطيل الجراب، ومهلة استنزاف العقدة، ووقت نقع العقدة لزيادة احتمال ترقيات ناجحة منخفضة التعطيل.

إعدادات الترقية كيفية استخدام العقد الإضافية السلوك المتوقع
maxSurge=5، maxUnavailable=0 5 عقد طفرة 5 عقد ارتفعت للترقية
maxSurge=5، maxUnavailable=0 0-4 عقد طفرة فشل الترقية بسبب عدم كفاية عقد الطفرة
maxSurge=0، maxUnavailable=5 غير متوفر 5 عقد موجودة مستنزفة للترقية

إشعار

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

عمليات التحقق من الصحة المستخدمة في عملية الترقية

تقوم AKS بإجراء عمليات التحقق من صحة ما قبل الترقية لضمان صحة نظام المجموعة:

  • تغييرات كسر واجهة برمجة التطبيقات: يكتشف واجهات برمجة التطبيقات المهملة.
  • إصدار ترقية Kubernetes: يضمن مسار ترقية صالحا.
  • تكوين PDB: التحقق من تكوين PDBs بشكل خاطئ (على سبيل المثال، maxUnavailable=0).
  • الحصه النسبيه: يؤكد الحصة النسبية الكافية لعقد الطفرة.
  • الشبكه الفرعيه: التحقق من عناوين IP كافية.
  • الشهادات/أساسيات الخدمة: يكتشف بيانات الاعتماد منتهية الصلاحية.

تساعد هذه الفحوصات على تقليل حالات فشل الترقية وتوفير رؤية مبكرة للمشكلات.

سيناريوهات الترقية الشائعة والتوصيات

السيناريو 1: قيود السعة

إذا كانت مجموعتك محدودة ب SKU أو السعة الإقليمية، فقد تفشل الترقيات عندما لا يمكن توفير عقد الطفرة. هذا شائع مع وحدات SKU المتخصصة (مثل عقد GPU) أو في المناطق ذات الموارد المحدودة. قد تحدث أخطاء مثل SKUNotAvailableأو AllocationFailedأو OverconstrainedAllocationRequest إذا maxSurge تم تعيين عالية جدا للسعة المتوفرة.

توصيات لمنع أو حل

  • يستخدم maxUnavailable للترقية باستخدام العقد الموجودة بدلا من رفع العقد الجديدة. اعرف المزيد.
  • أقل maxSurge لتقليل احتياجات السعة الإضافية. اعرف المزيد.
  • للحصول على تحديثات الأمان فقط، استخدم إعادة تعيين تصحيح الأمان التي لا تتطلب عقد زيادة. اعرف المزيد.

السيناريو 2: فشل استنزاف العقدة وPDBs

تتطلب الترقيات استنزاف العقد (إخلاء الحجيرات). يمكن أن تفشل المصارف إذا:

أمثلة على رسائل الخطأ:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... failed with Too Many Requests error. This is often caused by a restrictive Pod Disruption Budget (PDB) policy. See https://aka.ms/aks/debugdrainfailures. Original error: Cannot evict pod as it would violate the pod's disruption budget. PDB debug info: ... blocked by pdb ... with 0 unready pods.

توصيات لمنع أو حل

  • قم بتعيين maxUnavailable في PDBs للسماح بإخلاء جراب واحد على الأقل.
  • قم بزيادة النسخ المتماثلة للجراب حتى تتسامح ميزانية التعطيل مع عمليات الإخلاء.
  • استخدم undrainableNodeBehavior للسماح بالترقيات للمتابعة حتى إذا تعذر استنزاف بعض العقد:
    • الجدول الزمني (افتراضي): قد يتم حذف استبدال العقدة والطفرة، مما يقلل من السعة.
    • الطوق (مستحسن): العقدة مطوقة ومسماة باسم kubernetes.azure.com/upgrade-status=Quarantined.

      • مثال على الأمر:

        az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon

        يظهر إخراج المثال التالي سلوك العقدة غير القابلة للدراسة المحدثة:

        "upgradeSettings": {
"drainTimeoutInMinutes": null,
"maxSurge": "1",
"nodeSoakDurationInMinutes": null,
"undrainableNodeBehavior": "Cordon"
}

الحد الأقصى المسموح به للعقد المحظورة (معاينة)

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

إشعار

إذا لم تقم بتعيين الحد الأقصى للعقد المحظورة المسموح بها بشكل صريح، تعيينها افتراضيا إلى قيمة Max Surge. إذا لم يتم تعيين Max Surge، يكون الافتراضي عادة 10%، لذلك يتم تعيين الحد الأقصى للعقد المحظورة المسموح بها أيضا إلى 10%.

المتطلبات المسبقه

  • مطلوب إصدار ملحق Azure CLI aks-preview 18.0.0b9 أو أحدث لاستخدام هذه الميزة.

    مثال على الأمر:

    az aks nodepool update \
  --cluster-name jizenMC1 \
  --name nodepool1 \
  --resource-group jizenTestMaxBlockedNodesRG \
  --max-surge 1 \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 5
  • تمديد مهلة الاستنزاف إذا كانت أحمال العمل تحتاج إلى مزيد من الوقت (الافتراضي هو 30 دقيقة).
  • اختبار PDBs في التقسيم المرحلي ومراقبة أحداث الترقية واستخدام عمليات النشر الزرقاء والأخضر لأحمال العمل الهامة. اعرف المزيد.

التحقق من العقد غير القابلة للدراية

  • العقد المحظورة غير مجدولة للقرون وتم وضع علامة عليها بالتسمية "kubernetes.azure.com/upgrade-status: Quarantined".

  • تحقق من التسمية على أي عقد محظورة عند وجود فشل عقدة استنزاف عند الترقية:

    kubectl get nodes --show-labels=true

حل العقد غير القابلة للدراية

  1. إزالة PDB المسؤول:

    kubectl delete pdb <pdb-name>

  2. إزالة التسمية kubernetes.azure.com/upgrade-status: Quarantined :

    kubectl label nodes <node-name> <label-name>

  3. اختياريا، احذف العقدة المحظورة:

    az aks nodepool delete-machines --cluster-name <cluster-name> --machine-names <machine-name> --name <node-pool-name> --resource-group <resource-group-name>

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

    # Update the cluster to restore the provisioning status
az aks update --resource-group <resource-group-name> --name <cluster-name>

# Scale the node pool to restore the original size
az aks nodepool scale --resource-group <resource-group-name> --cluster-name <cluster-name> --name <node-pool-name> --node-count 2

السيناريو 3: الترقيات البطيئة

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

تتضمن الأسباب الشائعة للترقيات البطيئة ما يلي:

توصيات لمنع أو حل

  • للإنتاج: maxSurge=33%، . maxUnavailable=1
  • للتطوير/الاختبار: maxSurge=50%، . maxUnavailable=2
  • استخدم تصحيح أمان نظام التشغيل للتصحيح السريع المستهدف (يتجنب إعادة تعيين العقدة بالكامل).
  • تمكين undrainableNodeBehavior لتجنب حظر الترقية.

السيناريو 4: استنفاد IP

تتطلب عقد الطفرة عناوين IP إضافية. إذا كانت الشبكة الفرعية قريبة من السعة، يمكن أن يفشل توفير العقدة (على سبيل المثال، Error: SubnetIsFull). هذا أمر شائع مع عدد العقدة الكبيرة أو العالية أو الكبيرة maxPodsفي Azure CNI.

توصيات لمنع أو حل

  • تأكد من أن شبكتك الفرعية تحتوي على عناوين IP كافية لجميع العقد وعقد الطفرة والجرابات:

    • صيغة: Total IPs = (Number of nodes + maxSurge) * (1 + maxPods)

  • استعادة عناوين IP غير المستخدمة أو توسيع الشبكة الفرعية (على سبيل المثال، من /24 إلى /22).

  • أقل maxSurge إذا لم يكن توسيع الشبكة الفرعية ممكنا:

    az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --max-surge 10%

  • مراقبة استخدام IP باستخدام Azure Monitor أو التنبيهات المخصصة.

  • تقليل maxPods لكل عقدة، وتنظيف عناوين IP لموازن التحميل المعزول، وتخطيط حجم الشبكة الفرعية للمجموعات عالية النطاق.

الخطوات التالية

  • راجع تصحيح AKS وإرشادات الترقية للحصول على أفضل الممارسات ونصائح التخطيط قبل بدء أي ترقية.
  • تحقق دائما من وجود تغييرات كسر واجهة برمجة التطبيقات والتحقق من توافق أحمال العمل الخاصة بك مع إصدار Kubernetes الهدف.
  • اختبار إعدادات الترقية (مثل maxSurge، maxUnavailableو، و PDBs) في بيئة التقسيم المرحلي لتقليل مخاطر الإنتاج.
  • مراقبة أحداث الترقية وصحة نظام المجموعة طوال العملية.