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

تمنحك هذه المقالة أساسا تقنيا لترقيات نظام مجموعة Azure Kubernetes Service (AKS) من خلال تغطية خيارات الترقية والسيناريوهات الشائعة. للحصول على إرشادات متعمقة مصممة خصيصا لاحتياجاتك، استخدم مسارات التنقل المستندة إلى السيناريو في نهاية هذه المقالة.

ما تغطيه هذه المقالة

يوفر هذا المرجع الفني أساسيات ترقية AKS شاملة على:

  • خيارات الترقية اليدوية مقابل الترقية التلقائية ووقت استخدام كل منها.
  • سيناريوهات الترقية الشائعة مع توصيات محددة.
  • تقنيات التحسين للأداء والحد الأدنى من التعطيل.
  • إرشادات استكشاف الأخطاء وإصلاحها لمشكلات السعة وفشل التصريف والتوقيت.
  • عمليات التحقق من الصحة وفحوصات ما قبل الترقية.

يعد هذا المركز هو الأفضل لمساعدتك على فهم آليات الترقية واستكشاف المشكلات وإصلاحها وتحسين إعدادات الترقية والتعرف على التنفيذ الفني.

لمزيد من المعلومات، راجع هذه المقالات ذات الصلة:


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

الإنتقال السريع

وضعك المسار الموصى به
تحتاج مجموعة الإنتاج إلى ترقية استراتيجيات ترقية الإنتاج
أحمال عمل قاعدة البيانات/الحالة أنماط حمل العمل ذات الحالة
ترقية لأول مرة أو نظام المجموعة الأساسي ترقية نظام مجموعة AKS الأساسية
بيئات متعددة أو أسطول مركز سيناريوهات الترقية
تجمعات العقد أو عقد Windows ترقيات تجمع العقدة
تجمع عقدة محدد فقط ترقية تجمع العقدة الواحدة

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

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

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

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

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

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

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

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

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

اجمع بين نافذة الصيانة المخطط لها ، والحد الأقصى للزيادة ، و PDB ، ومهلة تصريف العقدة ، ووقت نقع العقدة لزيادة احتمالية الترقيات الناجحة منخفضة الاضطراب:

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

إشعار

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

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

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

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

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

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

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

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

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

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

تتطلب الترقيات استنزاف العقد (إخلاء الحجيرات). يمكن أن تفشل المصارف عندما تكون الكبسولات بطيئة في الإنهاء أو تمنع ميزانيات تعطيل الكبسولات الصارمة (PDBs) عمليات إخلاء الكبسولات.

مثال على الخطأ:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... Cannot evict pod as it would violate the pod's disruption budget.

الخيار 1: فرض الترقية (تجاوز PDB)

Warning

تتجاوز الترقية فرض قيود ميزانية تعطيل Pod (PDB) وقد تتسبب في انقطاع الخدمة عن طريق استنزاف جميع الجرابات في وقت واحد. قبل استخدام هذا الخيار، حاول أولا إصلاح تكوينات PDB الخاطئة (راجع إعدادات PDB minAvailable/maxUnavailable، وتأكد من النسخ المتماثلة الكافية للجراب والتحقق من أن PDBs لا تمنع جميع عمليات الإخلاء).

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

المتطلبات: Azure CLI 2.79.0+ أو إصدار واجهة برمجة تطبيقات AKS 2025-09-01+

az aks upgrade \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP_NAME \
  --kubernetes-version $KUBERNETES_VERSION \
  --enable-force-upgrade \
  --upgrade-override-until 2023-10-01T13:00:00Z

إشعار

  • تحدد المعلمة upgrade-override-until متى ينتهي تجاوز التحقق من الصحة (يجب أن يكون تاريخا/وقتا مستقبليا)
  • إذا لم يتم تحديدها، يتم تحديد النافذة افتراضيا إلى 3 أيام من الوقت الحالي
  • يشير الحرف "Z" إلى المنطقة الزمنية بالتوقيت العالمي المنسق / بتوقيت جرينتش

Warning

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

الخيار 2: التعامل مع العقد غير القابلة للتصريف (Honor PDB)

استخدم هذا النهج المحافظ لتكريم PDBs مع منع فشل الترقية.

تكوين سلوك العقدة غير القابلة للتصريف:

az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 30

خيارات السلوك:

  • الجدول الزمني (افتراضي): يحذف العقدة المحظورة واستبدال الزيادات المفاجئة
  • الطوق (موصى به): عقدة الطوق وتسميتها على أنها kubernetes.azure.com/upgrade-status=Quarantined

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

  • يحدد عدد العقد التي تفشل في التصريف التي يتم تحملها
  • يتطلب ضبطه undrainable-node-behavior
  • يتم تعيينه افتراضيا إلى maxSurge القيمة (عادة 10%) إذا لم يتم تحديده
المتطلبات الأساسية لالحد الأقصى للعقد المحظورة
  • مطلوب الإصدار 18.0.0b9 من ملحق Azure CLI aks-preview أو إصدار أحدث لاستخدام ميزة الحد الأقصى للعقد المحظورة.

    # Install or update the aks-preview extension
    az extension add --name aks-preview
    az extension update --name aks-preview
    
مثال على التكوين مع الحد الأقصى للعقد المحظورة
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

توصيات لمنع فشل الصرف

  • قم بضبطه maxUnavailable في PDBs للسماح بإخلاء جراب واحد على الأقل
  • زيادة النسخ المتماثلة للجراب لتلبية متطلبات ميزانية التعطيل
  • قم بتمديد مهلة التصريف إذا كانت أحمال العمل تحتاج إلى مزيد من الوقت. (الإعداد الافتراضي هو 30 دقيقة.)
  • اختبار PDBs في التقسيم المرحلي ومراقبة أحداث الترقية واستخدام عمليات النشر الزرقاء والأخضر لأحمال العمل الهامة. لمزيد من المعلومات، راجع النشر الأزرق والأخضر لمجموعات AKS.
التحقق من العقد غير القابلة للتصريف
  • العقد المحظورة غير مجدولة للقرون وتم وضع علامة عليها بالتسمية "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. بعد الانتهاء من هذه الخطوة، يمكنك تسوية حالة نظام المجموعة عن طريق تنفيذ أي عملية تحديث بدون الحقول الاختيارية كما هو موضح في az aks. بدلا من ذلك، يمكنك قياس تجمع العقدة إلى نفس عدد العقد مثل عدد العقد التي تمت ترقيتها. يضمن هذا الإجراء وصول تجمع العقدة إلى حجمه الأصلي المقصود. تعطي 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 أو maxUnavailable (تحد من التوازي).
  • أوقات نقع عالية (انتظارات طويلة بين ترقيات العقدة).
  • فشل التصريف (راجع فشل تصريف العقدة).

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

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

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

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

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

  • تأكد من أن شبكتك الفرعية تحتوي على عناوين 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:

  • kube-no-trouble (kubent): يبحث عن واجهات برمجة التطبيقات المهملة قبل الترقيات.
  • Trivy: فحص الأمان لصور الحاويات وتكوينات Kubernetes.
  • Sonobuoy: اختبار مطابقة Kubernetes والتحقق من صحة نظام المجموعة.
  • kube-bench: فحوصات معيارية الأمان مقابل معايير مركز أمن الإنترنت.
  • Polaris: التحقق من صحة أفضل ممارسات Kubernetes.
  • kubectl-neat: تنظيف بيانات Kubernetes للتحقق من الصحة.

كيف يمكنني التحقق من توافق واجهة برمجة التطبيقات قبل الترقية؟

قم بتشغيل فحوصات الإهمال باستخدام أدوات مثل kubent:

# Install and run API deprecation scanner
kubectl apply -f https://github.com/doitintl/kube-no-trouble/releases/latest/download/knt-full.yaml

# Check for deprecated APIs in your cluster
kubectl run knt --image=doitintl/knt:latest --rm -it --restart=Never -- \
  -c /kubeconfig -o json > api-deprecation-report.json

# Review findings
cat api-deprecation-report.json | jq '.[] | select(.deprecated==true)'

ما الذي يجعل ترقيات AKS مختلفة عن منصات Kubernetes الأخرى؟

يوفر AKS العديد من المزايا الفريدة:

  • تكامل Azure الأصلي مع Azure Traffic Manager وAzure Load Balancer والشبكات.
  • Azure Kubernetes Fleet Manager للترقيات المنسقة متعددة المجموعات.
  • تصحيح تلقائي لصورة العقدة بدون إدارة العقدة يدويا.
  • التحقق المضمن من صحة الحصة النسبية والشبكات وبيانات الاعتماد.
  • دعم Azure للمشكلات المتعلقة بالترقية.

اختر مسار الترقية الخاص بك

قدمت لك هذه المقالة أساسا تقنيا. الآن حدد المسار المستند إلى السيناريو.

هل أنت جاهز للتنفيذ؟

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

ما زلت تقرر؟

استخدم مركز سيناريوهات الترقية لشجرة القرارات الموجهة التي تأخذك في الاعتبار:

  • تحمل وقت التوقف عن العمل
  • تعقيد البيئة
  • ملف المخاطر
  • قيود المخطط الزمني

المهام التالية

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