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

ينطبق على: ✔️ AKS ✔️ Automatic Standard

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

يبقى AKS Standard متاحا للسيناريوهات التي تحتاج فيها إلى تحكم يدوي أعمق في آليات الترقية، خيارات الشبكات، أو سلوك تجمع العقد.

تعطيك هذه المقالة أساسا تقنيا لترقيات AKS من خلال تغطية خيارات الترقية، والسيناريوهات الشائعة، والتوصيات لكل من AKS Automatic وAKS Standard.

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

يغطي هذا المرجع التقني:

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

للحصول على إرشادات ذات صلة:

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

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

نماذج تشغيل الترقية

تم تصميم AKS Automatic بشكل افتراضي للتشغيل الجاهز للإنتاج. بالنسبة للترقيات، توفر AKS Automatic ما يلي:

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

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

معيار AKS (نموذج التحكم المتقدم)

AKS Standard يمنحك تحكما مباشرا في تسلسل الترقية وضبطها. أنت تختار وتدير:

  • تكوين الترقية اليدوي أو التلقائي.
  • ترقية اختيار القناة.
  • تجمع العقد وسلوك التصاعد السريع.
  • الإجراءات التشغيلية المتعلقة بنوافذ الصيانة وميزانيات تعطيل عبء العمل.

استخدم AKS Standard عندما تتطلب بيئتك تخصيصا يتجاوز الإعدادات الافتراضية التلقائية ل AKS.

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

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

ينطبق بشكل أساسي على معيار AKS أو على سير العمل التشغيلي المتخصص.

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

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

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

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

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

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

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

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

AKS تلقائي

في AKS Automatic، يتم ضبط سلوك الترقية على مستوى المنصة مسبقا. ركز ضبطك على مرونة عبء العمل وجاهزية القدرات:

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

معيار AKS

في AKS ستاندرد، قم بضبط ضوابط الترقية مباشرة:

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

إشعار

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

التحقق من صحة LocalDNS وDNS المخصص قبل الترقية إلى Kubernetes 1.37

بدءا من Kubernetes 1.37، تقوم AKS افتراضيا بتجمع عقدة AKS Standard الذي لا يحتوي على ملف تعريف LocalDNS صريح إلى Preferred الوضع، ويمكن LocalDNS عندما يمرر تجمع العقدة عمليات التحقق من التوافق. يؤثر هذا التغيير على مسار DNS لحمل العمل ويمكن أن يعرض تكوينات DNS أو جدار الحماية المخصصة الموجودة التي تدعم منفذ UDP 53 ولكن ليس منفذ TCP 53.

قبل ترقية تجمع عقدة إلى Kubernetes 1.37 أو أحدث:

  1. تحقق مما إذا كان تجمع العقدة يحتوي على ملف تعريف LocalDNS صريح.

  2. اختبر خادم DNS للشبكة الظاهرية المخصصة من عقدة AKS عبر كل من UDP وTCP.

    dig +udp @<custom-dns-ip> <fqdn>
dig +tcp @<custom-dns-ip> <fqdn>

  3. تحقق من أن NSGs وجدران الحماية وNVAs والمسارات تسمح لكل من منفذ UDP وTCP 53.

  4. ترقية تجمع عقدة غير إنتاجية أولا ومراقبة أخطاء CoreDNS و LocalDNS.

  5. إذا لم يكن مسار DNS جاهزا ل LocalDNS، فكون mode بشكل صريح كما هو الحال Disabled قبل الترقية.

للحصول على إرشادات التكوين وإلغاء الاشتراك، راجع تكوين LocalDNS في AKS.

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

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

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

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

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

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

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

التوجيه التلقائي ل AKS

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

إرشادات AKS القياسية

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

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

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

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

التوجيه التلقائي ل AKS

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

إرشادات AKS القياسية

الخيار 1: الترقية القسرية، تجاوز قيود PDB

Warning

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

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

المتطلبات: Azure CLI 2.79.0+ أو AKS API الإصدار 2025-09-01+

az aks upgrade \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP_NAME \
  --kubernetes-version $KUBERNETES_VERSION \
  --enable-force-upgrade \
  --upgrade-override-until yyyy-mm-ddT13:00:00Z

إشعار

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

Warning

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

الخيار الثاني: التعامل مع العقد غير القابلة للاستهلاك مع احترام PDBs

استخدم هذا النهج المحافظ لتكريم 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%) إذا لم يتم تحديده
  • مثل الحد الأقصى للطفرة، إذا كانت القيمة المحسوبة أعلى من عدد العقد المتبقية للترقية في العملية الحالية، يتم استخدام عدد العقد المتبقية التي سيتم ترقيتها بدلا من ذلك
مثال على التكوين مع الحد الأقصى للعقد المحظورة
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
الخيار 3: إدارة بيانات البيانات التلقائية (معاينة)

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

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

توصيات لمنع فشل الصرف
  • قم بضبطه maxUnavailable في PDBs للسماح بإخلاء جراب واحد على الأقل
  • زيادة النسخ المتماثلة للجراب لتلبية متطلبات ميزانية التعطيل
  • قم بتمديد مهلة التصريف إذا كانت أحمال العمل تحتاج إلى مزيد من الوقت. (الإعداد الافتراضي هو 30 دقيقة.)
  • استخدم إدارة PDB التلقائية لأتمتة إنشاء PDB وتكبير النسخ أثناء عمليات التصريف.
  • اختبار 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> kubernetes.azure.com/upgrade-status-

  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 (تحد من التوازي).
  • أوقات نقع عالية (انتظارات طويلة بين ترقيات العقدة).
  • فشل التصريف (راجع فشل تصريف العقدة).

التوجيه التلقائي ل AKS

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

إرشادات AKS القياسية

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

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

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

التوجيه التلقائي ل AKS

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

إرشادات AKS القياسية

  • تأكد من أن شبكتك الفرعية تحتوي على عناوين 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 Automatic أم AKS Standard لترقيات الإنتاج؟

لمعظم أعباء العمل الإنتاجية، استخدم AKS Automatic. تم تصميمه كخيار جاهز للإنتاج مع سلوك ترقية مدمجة ودرابزينات مدمجة.

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

هل يمكنني استخدام أدوات مفتوحة المصدر للتحقق من الصحة؟

نعم. تتكامل العديد من الأدوات مفتوحة المصدر بشكل جيد مع عمليات ترقية AKS:

  • 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 العديد من المزايا الفريدة:

  • تم إدارة المسارات التشغيلية في AKS Automatic لتقليل تكاليف الترقية.
  • تكامل Azure الأصلي مع مدير حركة بيانات Azure وموازن تحميل Azure والشبكات.
  • Azure Kubernetes Fleet Manager للترقيات المنسقة متعددة المجموعات.
  • تصحيح تلقائي لصورة العقدة بدون إدارة العقدة يدويا.
  • التحقق المضمن من صحة الحصة النسبية والشبكات وبيانات الاعتماد.
  • دعم Azure للمشكلات المتعلقة بالترقية.

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

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

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

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

ما زلت تقرر؟

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

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

التوصيات النهائية

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