إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
تمنحك هذه المقالة أساسا تقنيا لترقيات نظام مجموعة Azure Kubernetes Service (AKS) من خلال تغطية خيارات الترقية والسيناريوهات الشائعة. للحصول على إرشادات متعمقة مصممة خصيصا لاحتياجاتك، استخدم مسارات التنقل المستندة إلى السيناريو في نهاية هذه المقالة.
ما تغطيه هذه المقالة
يوفر هذا المرجع الفني أساسيات ترقية AKS شاملة على:
- خيارات الترقية اليدوية مقابل الترقية التلقائية ووقت استخدام كل منها.
- سيناريوهات الترقية الشائعة مع توصيات محددة.
- تقنيات التحسين للأداء والحد الأدنى من التعطيل.
- إرشادات استكشاف الأخطاء وإصلاحها لمشكلات السعة وفشل التصريف والتوقيت.
- عمليات التحقق من الصحة وفحوصات ما قبل الترقية.
يعد هذا المركز هو الأفضل لمساعدتك على فهم آليات الترقية واستكشاف المشكلات وإصلاحها وتحسين إعدادات الترقية والتعرف على التنفيذ الفني.
لمزيد من المعلومات، راجع هذه المقالات ذات الصلة:
- لترقية مجموعات AKS للإنتاج، راجع استراتيجيات ترقية إنتاج AKS.
- للحصول على أنماط ترقية لمجموعات AKS ذات أحمال عمل ذات حالة، راجع أنماط ترقية حمل العمل ذي الحالة.
- لاستخدام مركز السيناريو لمساعدتك في اختيار نهج ترقية AKS الصحيح، راجع سيناريوهات ترقية AKS: اختر المسار الخاص بك.
إذا كنت جديدا على ترقيات AKS، فابدأ بمركز سيناريوهات الترقية للحصول على المساعدة الموجهة المستندة إلى السيناريو.
الإنتقال السريع
| وضعك | المسار الموصى به |
|---|---|
| تحتاج مجموعة الإنتاج إلى ترقية | استراتيجيات ترقية الإنتاج |
| أحمال عمل قاعدة البيانات/الحالة | أنماط حمل العمل ذات الحالة |
| ترقية لأول مرة أو نظام المجموعة الأساسي | ترقية نظام مجموعة AKS الأساسية |
| بيئات متعددة أو أسطول | مركز سيناريوهات الترقية |
| تجمعات العقد أو عقد Windows | ترقيات تجمع العقدة |
| تجمع عقدة محدد فقط | ترقية تجمع العقدة الواحدة |
الخيارات للترقية
إجراء ترقيات يدوية
تتيح لك الترقيات اليدوية التحكم عند ترقية نظام المجموعة إلى إصدار Kubernetes جديد. هذه الترقيات مفيدة لاختبار إصدار معين أو استهدافه:
- ترقية نظام مجموعة AKS
- ترقية مجموعات AKS متعددة عبر Azure Kubernetes Fleet Manager
- ترقية صورة العقدة
- تخصيص ترقية طفرة العقدة
- معالجة تحديثات نظام التشغيل للعقدة
تكوين الترقيات التلقائية
تحافظ الترقيات التلقائية على نظام المجموعة الخاص بك على إصدار مدعوم ومحدث. استخدم هذه الترقيات عندما تريد أتمتة الإعدادات:
- ترقية نظام مجموعة AKS تلقائيا
- ترقية مجموعات AKS متعددة تلقائيا عبر Azure Kubernetes Fleet Manager
- استخدام الصيانة المخططة لجدولة الترقيات والتحكم فيها
- إيقاف ترقيات نظام مجموعة AKS تلقائيا عند تغييرات كسر واجهة برمجة التطبيقات (معاينة)
- ترقية صور نظام تشغيل عقدة نظام مجموعة AKS تلقائيا
- تطبيق تحديثات الأمان على عقد AKS تلقائيا باستخدام إجراءات GitHub
اعتبارات خاصة لتجمعات العقد التي تمتد عبر مناطق توفر متعددة
يستخدم AKS موازنة منطقة جهد أفضل في مجموعات العقد. أثناء زيادة الترقية، تكون مناطق عقد زيادة التيار في مجموعات مقياس الجهاز الظاهري غير معروفة مسبقا، مما قد يتسبب مؤقتا في تكوين منطقة غير متوازن. تحذف AKS عقد الزيادة المفاجئة بعد الترقية وتستعيد توازن المنطقة الأصلية.
للحفاظ على توازن المناطق، قم بتعيين الارتفاع المفاجئ إلى مضاعف من ثلاث عقد. مطالبات وحدة التخزين الثابتة التي تستخدم أقراص التخزين الزائدة عن الحاجة محليا في Azure مرتبطة بالمنطقة وقد تتسبب في تعطل إذا كانت عقد زيادة التيار في منطقة مختلفة. استخدم ميزانية تعطيل الجراب (PDB) للحفاظ على التوافر العالي أثناء المصارف.
تحسين الترقيات لتحسين الأداء وتقليل الاضطرابات
اجمع بين نافذة الصيانة المخطط لها ، والحد الأقصى للزيادة ، و PDB ، ومهلة تصريف العقدة ، ووقت نقع العقدة لزيادة احتمالية الترقيات الناجحة منخفضة الاضطراب:
- نافذة الصيانة المخططة: جدولة الترقية التلقائية خلال فترات حركة المرور المنخفضة. نوصي بأربع ساعات على الأقل.
- الحد الأقصى للارتفاع: تعمل القيم الأعلى على تسريع الترقيات ولكنها قد تعطل أحمال العمل. نوصي ب 33% للإنتاج.
- الحد الأقصى غير المتاح: يستخدم عندما تكون السعة محدودة.
- ميزانية تعطيل الجراب: اضبط لتقييد القرون أثناء الترقيات. التحقق من صحة خدمتك.
- مهلة استنزاف العقدة: تكوين مدة انتظار إخلاء الجراب. الإعداد الافتراضي هو 30 دقيقة.
- وقت نقع العقدة: ترقيات Stagger لتقليل وقت التوقف عن العمل. الإعداد الافتراضي هو 0 دقيقة.
| إعدادات الترقية | كيفية استخدام العقد الإضافية | السلوك المتوقع |
|---|---|---|
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 تم تعيين عالية جدا للسعة المتوفرة.
توصيات لمنع أو حل
- استخدمه
maxUnavailableللترقية باستخدام العقد الموجودة بدلا من زيادة العقد الجديدة. لمزيد من المعلومات، راجع تخصيص العقد غير المتوفرة أثناء الترقية. - أقل
maxSurgeلتقليل احتياجات السعة الإضافية. لمزيد من المعلومات، راجع تخصيص ترقية طفرة العقدة. - للحصول على تحديثات الأمان فقط، استخدم إعادة تعيين تصحيح الأمان التي لا تتطلب عقد زيادة. لمزيد من المعلومات، راجع تطبيق تحديثات الأمان والنواة على عقد Linux في خدمة Azure Kubernetes.
السيناريو 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
حل العقد غير القابلة للدراية
إزالة PDB المسؤول:
kubectl delete pdb <pdb-name>إزالة التسمية
kubernetes.azure.com/upgrade-status: Quarantined:kubectl label nodes <node-name> <label-name>اختياريا، احذف العقدة المحظورة:
az aks nodepool delete-machines --cluster-name <cluster-name> --machine-names <machine-name> --name <node-pool-name> --resource-group <resource-group-name>بعد الانتهاء من هذه الخطوة، يمكنك تسوية حالة نظام المجموعة عن طريق تنفيذ أي عملية تحديث بدون الحقول الاختيارية كما هو موضح في 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) في بيئة التقسيم المرحلي لتقليل مخاطر الإنتاج. - مراقبة أحداث الترقية وصحة نظام المجموعة طوال العملية.