الأسئلة المتداولة عن AKS

توفر هذه المقالة إجابات لبعض الأسئلة الأكثر شيوعا حول خدمة Azure Kubernetes (AKS).

الدعم

هل تقدم AKS اتفاقية على مستوى الخدمة؟

توفر AKS ضمانات اتفاقية مستوى الخدمة (SLA) في مستوى التسعير القياسي مع ميزة اتفاقية مستوى الخدمة في وقت التشغيل.

ما هو دعم النظام الأساسي، وما الذي يتضمنه؟

دعم النظام الأساسي هو خطة دعم مخفضة لمجموعات الإصدار n-3 غير المدعومة. يتضمن دعم النظام الأساسي دعم البنية الأساسية ل Azure فقط.

لمزيد من المعلومات، راجع نهج دعم النظام الأساسي.

هل تقوم AKS تلقائيا بترقية مجموعاتي غير المدعومة؟

نعم، يبدأ AKS الترقيات التلقائية للمجموعات غير المدعومة. عندما يكون نظام مجموعة في إصدار n-3 (حيث n هو أحدث إصدار ثانوي مدعوم من AKS متوفر بشكل عام) على وشك الإفلات إلى n-4، تقوم AKS تلقائيا بترقية نظام المجموعة إلى n-2 للبقاء في نهج دعم AKS.

لمزيد من المعلومات، راجع إصدارات Kubernetes المدعومة ونوافذ الصيانة المخطط لها والترقيات التلقائية.

هل يمكنني تطبيق خصومات حجز Azure على عقد وكيل AKS الخاص بي؟

تتم فوترة عقد عامل AKS كأجهزة Azure الظاهرية القياسية (VMs). إذا قمت بشراء حجوزات Azure لحجم الجهاز الظاهري الذي تستخدمه في AKS، يتم تطبيق هذه الخصومات تلقائيا.

العمليات

هل يمكنني تشغيل حاويات خادم Windows Server على AKS؟

نعم، تدعم AKS حاويات Windows Server. لمزيد من المعلومات، راجع الأسئلة المتداولة حول Windows Server على AKS.

ما هي أنظمة تشغيل لينكس (OS) المدعومة على AKS؟

يدعم AKS أربعة أنظمة تشغيل رئيسية لنظام لينكس، بما في ذلك أوبونتو لينكس، أزور لينكس، أزور لينكس OS Guard، وفلات كار كونتينر لينكس لنظام AKS. عند تحديد --os-type Linux ذلك أثناء إنشاء تجمع العقد أو إنشاء العنقود، يكون نظام التشغيل الافتراضي هو أوبونتو لينكس.

ما هي إصدارات أنظمة التشغيل (OS) المدعومة على AKS؟

عند استخدام --os-sku Ubuntu، يقيم AKS افتراضيا على أوبونتو 22.04 في إصدارات كوبيرنتيز 1.25-1.34. AKS يتبع أوبونتو 24.04 بشكل افتراضي في إصدارات Kubernetes 1.35+. عند استخدام --os-sku AzureLinux، يقوم AKS افتراضيا ب Azure Linux 3.0 في إصدارات Kubernetes 1.32+. في بعض السيناريوهات، مثل تجمعات العقد المفعلة بنظام FIPS، قد يختلف إصدار نظام التشغيل الافتراضي. راجع صور العقد لمزيد من المعلومات.

هل يمكنني نقل نظام المجموعة الخاص بي أو ترحيله بين مستأجري Azure؟

‏‏لا. نقل نظام مجموعة AKS بين المستأجرين غير مدعوم حاليا.

هل يمكنني نقل نظام المجموعة الخاص بي أو ترحيله بين الاشتراكات؟

‏‏لا. نقل نظام مجموعة AKS بين الاشتراكات غير مدعوم حاليا.

هل يمكنني نقل مقطع تخزين AKS الخاص بي أو موارد البنية التحتية لـ AKS إلى مجموعات موارد أخرى أو إعادة تسميتها؟

‏‏لا. لا يتم دعم نقل أو إعادة تسمية نظام مجموعة AKS والموارد المرتبطة بها.

هل يمكنني استعادة نظام المجموعة بعد حذفه؟

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

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

هل يمكنني تغيير سعة مقطع التخزين الخاص بي AKS إلى الصفر؟

يمكنك إيقاف نظام مجموعة AKS قيد التشغيل بالكامل أو User العقد المحددة إلى الصفر.

لا يمكنك تحجيم تجمعات عقدة النظام مباشرة إلى الصفر.

هل يمكنني استخدام واجهات برمجة التطبيقات لمجموعة مقياس الجهاز الظاهري لتوسيع نطاقها يدويا؟

‏‏لا. عمليات التحجيم التي تستخدم واجهات برمجة التطبيقات لمجموعة مقياس الجهاز الظاهري غير مدعومة. يمكنك استخدام واجهات برمجة تطبيقات AKS (az aks scale).

هل يمكنني استخدام مجموعات مقياس الجهاز الظاهري للتحجيم يدويا إلى عقد صفرية؟

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

هل يمكنني إيقاف أو إلغاء تخصيص جميع الأجهزة الظاهرية الخاصة بي؟

‏‏لا. هذا التكوين غير معتمد. قم بإيقاف مقطع التخزين بدلًا من ذلك.

لماذا يتم إنشاء مجموعتي موارد باستخدام AKS؟

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

لتمكين هذه البنية، يمتد كل نشر AKS لمجموعتي موارد:

1. إنشاء مجموعة الموارد الأولى. تحتوي هذه المجموعة على مورد خدمة Kubernetes فقط. يقوم موفر موارد AKS بإنشاء مجموعة الموارد الثانية تلقائيًّا أثناء التوزيع. مثال لمجموعة الموارد الثانية هو MC_myResourceGroup_myAKSCluster_eastus. للحصول على معلومات حول كيفية تحديد اسم مجموعة الموارد الثانية هذه، راجع المقطع التالي.
2. تحتوي مجموعة الموارد الثانية، المعروفة باسم مجموعة موارد العقدة،على كافة موارد البنية الأساسية المقترنة بمقطع التخزين. تتضمن هذه الموارد عقدة Kubernetes VMs والشبكات الظاهرية والتخزين. بشكل افتراضي، مجموعة موارد العقدة اسم مثل MC_myResourceGroup_myAKSCluster_eastus. تحذف AKS تلقائيا مجموعة موارد العقدة كلما حذفت نظام المجموعة. استخدم مجموعة الموارد هذه فقط للموارد التي تشترك في دورة حياة نظام المجموعة.

إشعار

يعد تعديل أي مورد ضمن مجموعة موارد العقدة في مجموعة AKS إجراء غير مدعوم وسيتسبب في فشل عملية نظام المجموعة. يمكنك منع إجراء تغييرات على مجموعة موارد العقدة. منع المستخدمين من تعديل الموارد التي تديرها مجموعة AKS.

هل يمكنني تقديم اسمي الخاص لمجموعة موارد عقدة AKS؟

بشكل افتراضي، تقوم AKS بتسمية مجموعة موارد العقدة MC_resourcegroupname_clustername_location، ولكن يمكنك توفير اسمك الخاص.

لتحديد اسم مجموعة الموارد الخاصة بك، قم بتثبيت الإصدار الملحق واجهة سطر الأوامر Azure CLI من aks-preview0.3.2 أو أحدث. عند إنشاء نظام مجموعة AKS باستخدام az aks create الأمر ، استخدم المعلمة --node-resource-group وحدد اسما لمجموعة الموارد. إذا كنت تستخدم قالب Azure Resource Manager لنشر مجموعة AKS، يمكنك تحديد اسم مجموعة الموارد باستخدام الخاصية nodeResourceGroup .

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

أثناء العمل مع مجموعة موارد العقدة، لا يمكنك:

• تحديد مجموعة موارد موجودة لمجموعة موارد العقدة.
• تحديد اشتراك مختلف لمجموعة موارد العقدة.
• قم بتغيير اسم مجموعة موارد العقدة بعد إنشاء نظام المجموعة.
• تحديد أسماء الموارد المدارة ضمن مجموعة موارد العقدة.
• تعديل أو حذف العلامات Azure المنشأة للموارد المدارة ضمن مجموعة موارد العقدة.

هل يمكنني تعديل العلامات والخصائص الأخرى لموارد AKS في مجموعة موارد العقدة؟

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

يتم إنشاء العلامات التي تم إنشاؤها بواسطة Azure لخدمات Azure الخاصة بها، ويجب أن تسمح بها دائما. بالنسبة إلى AKS، هناك علامات aks-managed و k8s-azure . يعد تعديل أي علامات تم إنشاؤها بواسطة Azure على الموارد ضمن مجموعة موارد العقدة في نظام مجموعة AKS إجراء غير مدعوم، والذي يكسر هدف مستوى الخدمة (SLO).

إشعار

في الماضي، كان اسم Owner العلامة محجوزا ل AKS لإدارة IP العام الذي تم تعيينه على عنوان IP الأمامي لموازن التحميل. الآن، تستخدم الخدمات البادئة aks-managed . بالنسبة للموارد القديمة، لا تستخدم نهج Azure لتطبيق اسم العلامة Owner . وإلا، ستتعطل جميع الموارد على عمليات نشر وتحديث نظام مجموعة AKS. لا ينطبق هذا التقييد على الموارد التي تم إنشاؤها حديثا.

لماذا أرى إصدارات Helm التي تديرها aks بادئة على نظام المجموعة الخاص بي، ولماذا يستمر عدد مراجعتها في الزيادة؟

تستخدم AKS Helm لتسليم المكونات إلى مجموعتك. يمكنك تجاهل aks-managed إصدارات Helm بادئة بأمان. من المتوقع أن تكون المراجعات المتزايدة باستمرار على إصدارات Helm هذه آمنة.

الحصص النسبية والحدود وتوافر المنطقة

ما هي المناطق من Azure التي توفرها حاليًّا AKS؟

للحصول على قائمة كاملة بالمناطق المتاحة، راجع مناطق AKS ومدى توفرها.

هل يمكنني نشر مجموعة AKS عبر المناطق؟

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

هل يمكنني نشر مقطع تخزين AKS عبر مناطق التوفر؟

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

هل يمكنني الحصول على أحجام VM مختلفة في مقطع تخزين واحد؟

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

ما هو حد الحجم على صورة حاوية في AKS؟

لا تقوم AKS بتعيين حد لحجم صورة الحاوية. ولكن كلما كانت الصورة أكبر، زاد الطلب على الذاكرة. قد يتجاوز الحجم الأكبر حدود الموارد أو الذاكرة الإجمالية المتوفرة للعقد العاملة. بشكل افتراضي، تُعيّن الذاكرة لحجم الجهاز الظاهري Standard_DS2_v2 لمجموعة AKS إلى 7 غيغابايت.

عندما تكون صورة الحاوية كبيرة بشكل مفرط، كما هو الحال في نطاق تيرابايت (TB)، قد لا يتمكن kubelet من سحبها من سجل الحاوية إلى عقدة بسبب نقص مساحة القرص.

بالنسبة لعقد Windows Server، لا يتم تشغيل تحديث Windows تلقائيًّا وتطبيق آخر التحديثات. يجب إجراء ترقية على نظام المجموعة وتجمعات عقد Windows Server في نظام مجموعة AKS. اتبع جدولا منتظما استنادا إلى دورة إصدار Windows Update وعملية التحقق من الصحة الخاصة بك. تنشئ عملية الترقية هذه العقد التي تقوم بتشغيل أحدث صورة وتصحيحات Windows Server، ثم تزيل العقد القديمة. لمزيد من المعلومات حول هذه العملية، راجع ترقية تجمع عقدة في AKS.

هل تُطلب صور AKS لتشغيلها كجذر؟

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

• mcr.microsoft.com/oss/kubernetes/coredns
• mcr.microsoft.com/azuremonitor/containerinsights/ciprod
• mcr.microsoft.com/oss/calico/node
• mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

الأمان والوصول والهوية

هل يمكنني تحديد من لديه حق الوصول إلى خادم واجهة برمجة التطبيقات API Kubernetes؟

نعم، هناك خياران للحد من الوصول إلى خادم API:

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

هل يتم تطبيق تحديثات الأمان على عقد وكيل AKS؟

تقوم AKS بتصحيح CVEs التي تحتوي على تصحيح للمورد كل أسبوع. تنتظر CVEs بدون إصلاح إصلاح مورد قبل أن يمكن معالجتها. يتم تحديث صور AKS تلقائيا في غضون 30 يوما. نوصي بتطبيق صورة عقدة محدثة على إيقاع منتظم للتأكد من تطبيق أحدث الصور المصححة وتصحيحات نظام التشغيل وتحديثها. يمكنك القيام بهذه المهمة:

• يدويًّا، من خلال مدخل Azure أو واجهة سطر الأوامر Azure CLI.
• عن طريق ترقية مقطع تخزين AKS. يقوم نظام المجموعة بترقية الطوق واستنزاف العقد تلقائيا. ثم يجلب عقدة جديدة عبر الإنترنت مع أحدث صورة Ubuntu وإصدار تصحيح جديد أو إصدار Kubernetes ثانوي. لمزيد من المعلومات، راجع الترقية إلى مقطع تخزين AKS.
• باستخدام ترقية صورة عقدة.

هل هناك تهديدات أمنية تستهدف AKS يجب أن أكون على علم بها؟

توفر Microsoft إرشادات للإجراءات الأخرى التي يمكنك اتخاذها لتأمين أحمال العمل الخاصة بك من خلال خدمات مثل Microsoft Defender for Containers. للحصول على معلومات حول تهديد أمني متعلق ب AKS وKubernetes، راجع أهداف حملة جديدة واسعة النطاق ل Kubeflow (8 يونيو 2021).

هل تقوم AKS بتخزين أي بيانات عميل خارج منطقة نظام المجموعة؟

‏‏لا. يتم تخزين جميع البيانات في منطقة نظام المجموعة.

كيف يمكنني تجنب المشكلات البطيئة لإعداد ملكية الأذونات عندما تحتوي وحدة التخزين على العديد من الملفات؟

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

يتمثل التأثير الجانبي للإعداد fsGroup في أنه في كل مرة يتم فيها تحميل وحدة تخزين، يجب على Kubernetes استخدام chown() الأوامر و chmod() بشكل متكرر لجميع الملفات والدلائل داخل وحدة التخزين (مع بعض الاستثناءات). يحدث هذا السيناريو حتى إذا كانت ملكية مجموعة وحدة التخزين تتطابق بالفعل مع المعلمة المطلوبة fsGroup . قد يكون هذا التكوين مكلفا لوحدات التخزين الكبيرة مع الكثير من الملفات الصغيرة، مما قد يتسبب في أن يستغرق بدء تشغيل الجراب وقتا طويلا. كان هذا السيناريو مشكلة معروفة قبل الإصدار 1.20. الحل البديل هو تعيين الجراب لتشغيله كجذر:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

تم حل المشكلة مع Kubernetes الإصدار 1.20. لمزيد من المعلومات، راجع Kubernetes 1.20: التحكم الدقيق في تغييرات أذونات وحدة التخزين.

الشبكات

كيف تتواصل وحدة التحكم المدارة مع العقد الخاصة بي؟

تستخدم AKS اتصال نفق آمن للسماح api-server ل kubelets العقدة الفردية بالاتصال، حتى على شبكات ظاهرية منفصلة. يتم تأمين النفق من خلال تشفير أمان طبقة النقل المتبادل. النفق الرئيسي الحالي الذي تستخدمه AKS هو Konnectivity، المعروف سابقا باسم apiserver-network-proxy. تحقق من أن جميع قواعد الشبكة تتبع قواعد الشبكة المطلوبة من Azure وأسماء المجالات المؤهلة بالكامل (FQDNs).

هل يمكن لوحدات الجراب الخاصة بي استخدام خادم API FQDN بدلا من IP نظام المجموعة؟

نعم، يمكنك إضافة التعليق التوضيحي kubernetes.azure.com/set-kube-service-host-fqdn إلى pods لتعيين KUBERNETES_SERVICE_HOST المتغير إلى اسم المجال لخادم API بدلا من IP خدمة داخل نظام المجموعة. هذا التعديل مفيد في الحالات التي يتم فيها خروج نظام المجموعة الخاص بك عبر جدار حماية الطبقة 7. مثال على ذلك هو عند استخدام Azure Firewall مع قواعد التطبيق.

هل يمكنني تكوين NSGs باستخدام AKS؟

لا تطبق AKS مجموعات أمان الشبكة (NSGs) على شبكتها الفرعية ولا تعدل أيا من مجموعات أمان الشبكة المرتبطة بتلك الشبكة الفرعية. تقوم AKS بتعديل إعدادات NSG لواجهة الشبكة فقط. إذا كنت تستخدم واجهة شبكة الحاوية (CNI)، يجب عليك أيضا التأكد من أن قواعد الأمان في مجموعات أمان الشبكة تسمح بحركة المرور بين العقدة ونطاقات التوجيه بين المجالات دون فئة (CIDR). إذا كنت تستخدم kubenet، يجب عليك أيضا التأكد من أن قواعد الأمان في مجموعات أمان الشبكة تسمح بنسبة استخدام الشبكة بين العقدة والحجيرة CIDR. للحصول على مزيٍد من المعلومات، راجع مجموعة أمان الشبكة.

كيف تعمل مزامنة الوقت في AKS؟

تقوم عقد AKS بتشغيل الخدمة الزمنية، والتي تسحب الوقت من المضيف المحلي. الحاويات التي تعمل على pods تحصل على الوقت من عقد AKS. تستخدم التطبيقات التي تفتح داخل الحاوية الوقت من حاوية الحاوية.

الوظائف الإضافية والملحقات والتكاملات

هل يمكنني استخدام ملحقات VM المخصصة؟

‏‏لا. AKS هي خدمة مدارة. لا يتم دعم التلاعب بالبنية الأساسية كموارد خدمة (IaaS). لتثبيت مكونات مخصصة، استخدم واجهات برمجة التطبيقات Kubernetes APIs وآلياتها. على سبيل المثال، استخدم DaemonSets لتثبيت أي مكونات مطلوبة.

ما هي وحدات تحكم القبول في Kubernetes التي تدعمها AKS؟ هل يمكن إضافة وحدات تحكم القبول أو إزالتها؟

تدعم AKS وحدات التحكم التالية للقبول:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

حاليًّا، لا يمكنك تعديل قائمة وحدات تحكم القبول في AKS.

هل يمكنني استخدام webhooks تحكم القبول في AKS؟

نعم، يمكنك استخدام خطافات الويب لوحدة تحكم القبول على AKS. نوصي باستبعاد مساحات أسماء AKS الداخلية، والتي تم وضع علامة عليها control-plane بالتسمية. على سبيل المثال:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

جدران حماية AKS خروج خادم API بحيث يجب أن تكون خطافات الويب لوحدة تحكم القبول الخاصة بك قابلة للوصول من داخل نظام المجموعة.

هل يمكن أن تؤثر خطافات الويب لوحدة تحكم القبول على نظام kube ومساحات أسماء AKS الداخلية؟

لحماية استقرار النظام ومنع وحدات التحكم المخصصة في القبول من التأثير على الخدمات الداخلية في kube-system مساحة الاسم، لدى AKS منفذ القبول، والذي يستبعد kube-system تلقائيا ومساحات الأسماء الداخلية ل AKS. تضمن هذه الخدمة أن وحدات تحكم القبول المخصصة لا تؤثر على الخدمات التي تعمل في kube-system.

إذا كانت لديك حالة استخدام حرجة لنشر شيء ما على kube-system (غير مستحسن) لدعم خطاف الويب المخصص للقبول، يمكنك إضافة التسمية أو التعليق التوضيحي التالي بحيث يتجاهله منفذ القبول:

• التسمية: "admissions.enforcer/disabled": "true"
• تعليق توضيحي: "admissions.enforcer/disabled": true

هل تم دمج Azure Key Vault مع AKS؟

يوفر موفر Azure Key Vault لبرنامج تشغيل Secrets Store CSI التكامل الأصلي ل Azure Key Vault في AKS.

هل يمكنني استخدام مكتبات تشفير FIPS مع عمليات نشر على AKS؟

يتم الآن دعم العقد التي تم تمكينها باستخدام معايير معالجة المعلومات الفيدرالية (FIPS) على تجمعات العقد المستندة إلى Linux. لمزيد من المعلومات، راجع Add a FIPS-enabled node pool.

كيف يتم تحديث وظائف AKS الإضافية؟

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

ما الغرض من ملحق AKS Linux الذي أراه مثبتا على مثيلات مجموعات مقياس جهاز Linux الظاهري؟

ملحق AKS Linux هو ملحق Azure VM يقوم بتثبيت وتكوين أدوات المراقبة على عقد عامل Kubernetes. يتم تثبيت الملحق على جميع عقد Linux الجديدة والحالية. يقوم بتكوين أدوات المراقبة التالية:

• مصدر العقدة: يجمع بيانات تتبع الاستخدام للأجهزة من الجهاز الظاهري ويجعلها متاحة باستخدام نقطة نهاية المقاييس. بعد ذلك، يمكن لأداة المراقبة، مثل Prometheus، استخراج هذه المقاييس.
• Node-problem-detector: يهدف إلى جعل مشاكل العقد المختلفة مرئية لطبقات المصدر في مكدس إدارة نظام المجموعة. إنها وحدة نظامية تعمل على كل عقدة، وتكتشف مشكلات العقدة، وتقاريرها إلى خادم واجهة برمجة تطبيقات نظام المجموعة باستخدام Events و NodeConditions.
• ig: هو إطار عمل مفتوح المصدر مدعوم من eBPF لتصحيح الأخطاء ومراقبة أنظمة Linux وKubernetes. يوفر مجموعة من الأدوات (أو الأدوات الذكية) التي تجمع المعلومات ذات الصلة التي يمكن للمستخدمين استخدامها لتحديد سبب مشكلات الأداء أو الأعطال أو الحالات الشاذة الأخرى. وتجدر الإشارة إلى أن استقلالها عن Kubernetes يمكن المستخدمين من استخدامها أيضا لتصحيح مشكلات وحدة التحكم.

تساعد هذه الأدوات في توفير إمكانية الملاحظة حول العديد من المشاكل المتعلقة بصحة العقدة، مثل:

• مشكلات البرنامج الخفي للبنية الأساسية: خدمة NTP معطلة
• مشكلات الأجهزة: وحدة المعالجة المركزية أو الذاكرة أو القرص غير الصالح
• مشكلات النواة: حالة توقف تام ل Kernel، نظام ملفات تالف
• مشكلات وقت تشغيل الحاوية: البرنامج الخفي لوقت التشغيل غير المستجيب

لا يتطلب الملحق وصولا خارجيا إضافيا إلى أي عناوين URL أو عناوين IP أو منافذ تتجاوز متطلبات خروج AKS الموثقة. لا يتطلب أي أذونات خاصة تم منحها في Azure. يستخدم kubeconfig للاتصال بخادم API لإرسال بيانات المراقبة التي تم جمعها.

استكشاف مشكلات نظام المجموعة وإصلاحها

لماذا يستغرق حذف نظام المجموعة وقتا طويلا؟

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

لماذا يستغرق إنشاء نظام المجموعة أو تحديثها وقتا طويلا؟

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

إذا كان لدي pods أو عمليات نشر في حالات NodeLost أو Unknown، فهل لا يزال بإمكاني ترقية نظام المجموعة الخاص بي؟

يمكنك ذلك، ولكننا لا نوصي بذلك. إجراء التحديثات عندما تكون حالة نظام المجموعة معروفة وصحية.

إذا كان لدي نظام مجموعة مع عقدة واحدة أو أكثر في حالة غير صحية، أو إذا تم إيقاف تشغيله، هل يمكنني إجراء ترقية؟

‏‏لا. حذف أو إزالة أي عقد في حالة فشل أو غير ذلك من نظام المجموعة قبل الترقية.

حاولت حذف مجموعتي، لكنني أرى الخطأ "[Errno 11001] getaddrinfo failed."

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

قمت بتشغيل ترقية، ولكن الآن بلدي pods في حلقات الأعطال وفشل تحقيقات الاستعداد.

تأكد من أن كيان الخدمة لم تنته صلاحيته. لمزيد من المعلومات، راجع أساس خدمة AKSوبيانات اعتماد تحديث AKS.

كان نظام مجموعتي يعمل، ولكن فجأة لا يمكنني توفير موازنات التحميل أو تحميل مطالبات وحدة التخزين الثابتة.

تأكد من أن كيان الخدمة لم تنته صلاحيته. لمزيد من المعلومات، راجع أساس خدمة AKSوبيانات اعتماد تحديث AKS.

التقاعد والانقطاع

أي إصدارات نظام تشغيل لينكس مهجورة على AKS؟

ابتداء من 17 مارس 2027، لم تعد خدمة Azure Kubernetes Service (AKS) تدعم أو توفر تحديثات الأمان لأوبونتو 20.04. سيتم حذف أي صور عقدة موجودة، ولن تتمكن من توسيع أي مجموعات عقد تعمل بنظام أوبونتو 20.04. انتقل إلى نسخة Ubuntu مدعومة عن طريق ترقية مجموعات العقد إلى إصدار Kubernetes 1.35+. لمزيد من المعلومات حول هذا التقاعد، راجع مشكلة GitHub للتقاعدوإعلان تقاعد تحديثات Azure. للبقاء على اطلاع بالإعلانات والتحديثات، تابع ملاحظات إصدار AKS.

أي إصدارات نظام ويندوز أصبحت مهجورة على AKS؟

ابتداء من 1 مارس 2026، لم تعد Azure Kubernetes Service (AKS) تدعم مجموعات عقد Windows Server 2019. تجمعات العقد التي تعمل بإصدار Kubernetes إصدار 1.33+ لا يمكنها استخدام Windows Server 2019. ابتداء من 1 أبريل 2027، ستقوم AKS بإزالة جميع صور العقد الموجودة لنظام ويندوز سيرفر 2019، مما يعني أن عمليات التوسع ستفشل. لمزيد من المعلومات حول هذا التقاعد، راجع مشكلة GitHub للتقاعدوإعلان تقاعد تحديثات Azure. للبقاء على اطلاع بالإعلانات والتحديثات، تابع ملاحظات إصدار AKS. ابتداء من 15 مارس 2027، لم تعد خدمة Azure Kubernetes Service (AKS) تدعم مجموعات عقد Windows Server 2022. لا يمكن لتجمع العقد التي تعمل كوبيرنتيز إصدار 1.36+ استخدام ويندوز سيرفر 2022. بدءا من 1 أبريل 2028، ستقوم AKS بإزالة جميع صور العقد الموجودة لنظام Windows Server 2022، مما يعني أن عمليات التوسع ستفشل. لمزيد من المعلومات حول هذا التقاعد، راجع مشكلة GitHub للتقاعدوإعلان تقاعد تحديثات Azure. للبقاء على اطلاع بالإعلانات والتحديثات، تابع ملاحظات إصدار AKS.

توفر هذه المقالة إجابات لبعض الأسئلة الأكثر شيوعا حول خدمة Azure Kubernetes (AKS).

توفر AKS ضمانات اتفاقية مستوى الخدمة (SLA) في مستوى التسعير القياسي مع ميزة اتفاقية مستوى الخدمة في وقت التشغيل.

دعم النظام الأساسي هو خطة دعم مخفضة لمجموعات الإصدار n-3 غير المدعومة. يتضمن دعم النظام الأساسي دعم البنية الأساسية ل Azure فقط.

لمزيد من المعلومات، راجع نهج دعم النظام الأساسي.

نعم، يبدأ AKS الترقيات التلقائية للمجموعات غير المدعومة. عندما يكون نظام مجموعة في إصدار n-3 (حيث n هو أحدث إصدار ثانوي مدعوم من AKS متوفر بشكل عام) على وشك الإفلات إلى n-4، تقوم AKS تلقائيا بترقية نظام المجموعة إلى n-2 للبقاء في نهج دعم AKS.

لمزيد من المعلومات، راجع إصدارات Kubernetes المدعومة ونوافذ الصيانة المخطط لها والترقيات التلقائية.

تتم فوترة عقد عامل AKS كأجهزة Azure الظاهرية القياسية (VMs). إذا قمت بشراء حجوزات Azure لحجم الجهاز الظاهري الذي تستخدمه في AKS، يتم تطبيق هذه الخصومات تلقائيا.

نعم، تدعم AKS حاويات Windows Server. لمزيد من المعلومات، راجع الأسئلة المتداولة حول Windows Server على AKS.

يدعم AKS أربعة أنظمة تشغيل رئيسية لنظام لينكس، بما في ذلك أوبونتو لينكس، أزور لينكس، أزور لينكس OS Guard، وفلات كار كونتينر لينكس لنظام AKS. عند تحديد --os-type Linux ذلك أثناء إنشاء تجمع العقد أو إنشاء العنقود، يكون نظام التشغيل الافتراضي هو أوبونتو لينكس.

عند استخدام --os-sku Ubuntu، يقيم AKS افتراضيا على أوبونتو 22.04 في إصدارات كوبيرنتيز 1.25-1.34. AKS يتبع أوبونتو 24.04 بشكل افتراضي في إصدارات Kubernetes 1.35+. عند استخدام --os-sku AzureLinux، يقوم AKS افتراضيا ب Azure Linux 3.0 في إصدارات Kubernetes 1.32+. في بعض السيناريوهات، مثل تجمعات العقد المفعلة بنظام FIPS، قد يختلف إصدار نظام التشغيل الافتراضي. راجع صور العقد لمزيد من المعلومات.

‏‏لا. نقل نظام مجموعة AKS بين المستأجرين غير مدعوم حاليا.

‏‏لا. نقل نظام مجموعة AKS بين الاشتراكات غير مدعوم حاليا.

‏‏لا. لا يتم دعم نقل أو إعادة تسمية نظام مجموعة AKS والموارد المرتبطة بها.

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

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

يمكنك إيقاف نظام مجموعة AKS قيد التشغيل بالكامل أو User العقد المحددة إلى الصفر.

لا يمكنك تحجيم تجمعات عقدة النظام مباشرة إلى الصفر.

‏‏لا. عمليات التحجيم التي تستخدم واجهات برمجة التطبيقات لمجموعة مقياس الجهاز الظاهري غير مدعومة. يمكنك استخدام واجهات برمجة تطبيقات AKS (az aks scale).

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

‏‏لا. هذا التكوين غير معتمد. قم بإيقاف مقطع التخزين بدلًا من ذلك.

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

لتمكين هذه البنية، يمتد كل نشر AKS لمجموعتي موارد:

1. إنشاء مجموعة الموارد الأولى. تحتوي هذه المجموعة على مورد خدمة Kubernetes فقط. يقوم موفر موارد AKS بإنشاء مجموعة الموارد الثانية تلقائيًّا أثناء التوزيع. مثال لمجموعة الموارد الثانية هو MC_myResourceGroup_myAKSCluster_eastus. للحصول على معلومات حول كيفية تحديد اسم مجموعة الموارد الثانية هذه، راجع المقطع التالي.
2. تحتوي مجموعة الموارد الثانية، المعروفة باسم مجموعة موارد العقدة،على كافة موارد البنية الأساسية المقترنة بمقطع التخزين. تتضمن هذه الموارد عقدة Kubernetes VMs والشبكات الظاهرية والتخزين. بشكل افتراضي، مجموعة موارد العقدة اسم مثل MC_myResourceGroup_myAKSCluster_eastus. تحذف AKS تلقائيا مجموعة موارد العقدة كلما حذفت نظام المجموعة. استخدم مجموعة الموارد هذه فقط للموارد التي تشترك في دورة حياة نظام المجموعة.

إشعار

يعد تعديل أي مورد ضمن مجموعة موارد العقدة في مجموعة AKS إجراء غير مدعوم وسيتسبب في فشل عملية نظام المجموعة. يمكنك منع إجراء تغييرات على مجموعة موارد العقدة. منع المستخدمين من تعديل الموارد التي تديرها مجموعة AKS.

بشكل افتراضي، تقوم AKS بتسمية مجموعة موارد العقدة MC_resourcegroupname_clustername_location، ولكن يمكنك توفير اسمك الخاص.

لتحديد اسم مجموعة الموارد الخاصة بك، قم بتثبيت الإصدار الملحق واجهة سطر الأوامر Azure CLI من aks-preview0.3.2 أو أحدث. عند إنشاء نظام مجموعة AKS باستخدام az aks create الأمر ، استخدم المعلمة --node-resource-group وحدد اسما لمجموعة الموارد. إذا كنت تستخدم قالب Azure Resource Manager لنشر مجموعة AKS، يمكنك تحديد اسم مجموعة الموارد باستخدام الخاصية nodeResourceGroup .

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

أثناء العمل مع مجموعة موارد العقدة، لا يمكنك:

• تحديد مجموعة موارد موجودة لمجموعة موارد العقدة.
• تحديد اشتراك مختلف لمجموعة موارد العقدة.
• قم بتغيير اسم مجموعة موارد العقدة بعد إنشاء نظام المجموعة.
• تحديد أسماء الموارد المدارة ضمن مجموعة موارد العقدة.
• تعديل أو حذف العلامات Azure المنشأة للموارد المدارة ضمن مجموعة موارد العقدة.

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

يتم إنشاء العلامات التي تم إنشاؤها بواسطة Azure لخدمات Azure الخاصة بها، ويجب أن تسمح بها دائما. بالنسبة إلى AKS، هناك علامات aks-managed و k8s-azure . يعد تعديل أي علامات تم إنشاؤها بواسطة Azure على الموارد ضمن مجموعة موارد العقدة في نظام مجموعة AKS إجراء غير مدعوم، والذي يكسر هدف مستوى الخدمة (SLO).

إشعار

في الماضي، كان اسم Owner العلامة محجوزا ل AKS لإدارة IP العام الذي تم تعيينه على عنوان IP الأمامي لموازن التحميل. الآن، تستخدم الخدمات البادئة aks-managed . بالنسبة للموارد القديمة، لا تستخدم نهج Azure لتطبيق اسم العلامة Owner . وإلا، ستتعطل جميع الموارد على عمليات نشر وتحديث نظام مجموعة AKS. لا ينطبق هذا التقييد على الموارد التي تم إنشاؤها حديثا.

تستخدم AKS Helm لتسليم المكونات إلى مجموعتك. يمكنك تجاهل aks-managed إصدارات Helm بادئة بأمان. من المتوقع أن تكون المراجعات المتزايدة باستمرار على إصدارات Helm هذه آمنة.

للحصول على قائمة كاملة بالمناطق المتاحة، راجع مناطق AKS ومدى توفرها.

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

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

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

لا تقوم AKS بتعيين حد لحجم صورة الحاوية. ولكن كلما كانت الصورة أكبر، زاد الطلب على الذاكرة. قد يتجاوز الحجم الأكبر حدود الموارد أو الذاكرة الإجمالية المتوفرة للعقد العاملة. بشكل افتراضي، تُعيّن الذاكرة لحجم الجهاز الظاهري Standard_DS2_v2 لمجموعة AKS إلى 7 غيغابايت.

عندما تكون صورة الحاوية كبيرة بشكل مفرط، كما هو الحال في نطاق تيرابايت (TB)، قد لا يتمكن kubelet من سحبها من سجل الحاوية إلى عقدة بسبب نقص مساحة القرص.

بالنسبة لعقد Windows Server، لا يتم تشغيل تحديث Windows تلقائيًّا وتطبيق آخر التحديثات. يجب إجراء ترقية على نظام المجموعة وتجمعات عقد Windows Server في نظام مجموعة AKS. اتبع جدولا منتظما استنادا إلى دورة إصدار Windows Update وعملية التحقق من الصحة الخاصة بك. تنشئ عملية الترقية هذه العقد التي تقوم بتشغيل أحدث صورة وتصحيحات Windows Server، ثم تزيل العقد القديمة. لمزيد من المعلومات حول هذه العملية، راجع ترقية تجمع عقدة في AKS.

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

• mcr.microsoft.com/oss/kubernetes/coredns
• mcr.microsoft.com/azuremonitor/containerinsights/ciprod
• mcr.microsoft.com/oss/calico/node
• mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

نعم، هناك خياران للحد من الوصول إلى خادم API:

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

تقوم AKS بتصحيح CVEs التي تحتوي على تصحيح للمورد كل أسبوع. تنتظر CVEs بدون إصلاح إصلاح مورد قبل أن يمكن معالجتها. يتم تحديث صور AKS تلقائيا في غضون 30 يوما. نوصي بتطبيق صورة عقدة محدثة على إيقاع منتظم للتأكد من تطبيق أحدث الصور المصححة وتصحيحات نظام التشغيل وتحديثها. يمكنك القيام بهذه المهمة:

• يدويًّا، من خلال مدخل Azure أو واجهة سطر الأوامر Azure CLI.
• عن طريق ترقية مقطع تخزين AKS. يقوم نظام المجموعة بترقية الطوق واستنزاف العقد تلقائيا. ثم يجلب عقدة جديدة عبر الإنترنت مع أحدث صورة Ubuntu وإصدار تصحيح جديد أو إصدار Kubernetes ثانوي. لمزيد من المعلومات، راجع الترقية إلى مقطع تخزين AKS.
• باستخدام ترقية صورة عقدة.

توفر Microsoft إرشادات للإجراءات الأخرى التي يمكنك اتخاذها لتأمين أحمال العمل الخاصة بك من خلال خدمات مثل Microsoft Defender for Containers. للحصول على معلومات حول تهديد أمني متعلق ب AKS وKubernetes، راجع أهداف حملة جديدة واسعة النطاق ل Kubeflow (8 يونيو 2021).

‏‏لا. يتم تخزين جميع البيانات في منطقة نظام المجموعة.

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

يتمثل التأثير الجانبي للإعداد fsGroup في أنه في كل مرة يتم فيها تحميل وحدة تخزين، يجب على Kubernetes استخدام chown() الأوامر و chmod() بشكل متكرر لجميع الملفات والدلائل داخل وحدة التخزين (مع بعض الاستثناءات). يحدث هذا السيناريو حتى إذا كانت ملكية مجموعة وحدة التخزين تتطابق بالفعل مع المعلمة المطلوبة fsGroup . قد يكون هذا التكوين مكلفا لوحدات التخزين الكبيرة مع الكثير من الملفات الصغيرة، مما قد يتسبب في أن يستغرق بدء تشغيل الجراب وقتا طويلا. كان هذا السيناريو مشكلة معروفة قبل الإصدار 1.20. الحل البديل هو تعيين الجراب لتشغيله كجذر:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

تم حل المشكلة مع Kubernetes الإصدار 1.20. لمزيد من المعلومات، راجع Kubernetes 1.20: التحكم الدقيق في تغييرات أذونات وحدة التخزين.

تستخدم AKS اتصال نفق آمن للسماح api-server ل kubelets العقدة الفردية بالاتصال، حتى على شبكات ظاهرية منفصلة. يتم تأمين النفق من خلال تشفير أمان طبقة النقل المتبادل. النفق الرئيسي الحالي الذي تستخدمه AKS هو Konnectivity، المعروف سابقا باسم apiserver-network-proxy. تحقق من أن جميع قواعد الشبكة تتبع قواعد الشبكة المطلوبة من Azure وأسماء المجالات المؤهلة بالكامل (FQDNs).

نعم، يمكنك إضافة التعليق التوضيحي kubernetes.azure.com/set-kube-service-host-fqdn إلى pods لتعيين KUBERNETES_SERVICE_HOST المتغير إلى اسم المجال لخادم API بدلا من IP خدمة داخل نظام المجموعة. هذا التعديل مفيد في الحالات التي يتم فيها خروج نظام المجموعة الخاص بك عبر جدار حماية الطبقة 7. مثال على ذلك هو عند استخدام Azure Firewall مع قواعد التطبيق.

لا تطبق AKS مجموعات أمان الشبكة (NSGs) على شبكتها الفرعية ولا تعدل أيا من مجموعات أمان الشبكة المرتبطة بتلك الشبكة الفرعية. تقوم AKS بتعديل إعدادات NSG لواجهة الشبكة فقط. إذا كنت تستخدم واجهة شبكة الحاوية (CNI)، يجب عليك أيضا التأكد من أن قواعد الأمان في مجموعات أمان الشبكة تسمح بحركة المرور بين العقدة ونطاقات التوجيه بين المجالات دون فئة (CIDR). إذا كنت تستخدم kubenet، يجب عليك أيضا التأكد من أن قواعد الأمان في مجموعات أمان الشبكة تسمح بنسبة استخدام الشبكة بين العقدة والحجيرة CIDR. للحصول على مزيٍد من المعلومات، راجع مجموعة أمان الشبكة.

تقوم عقد AKS بتشغيل الخدمة الزمنية، والتي تسحب الوقت من المضيف المحلي. الحاويات التي تعمل على pods تحصل على الوقت من عقد AKS. تستخدم التطبيقات التي تفتح داخل الحاوية الوقت من حاوية الحاوية.

‏‏لا. AKS هي خدمة مدارة. لا يتم دعم التلاعب بالبنية الأساسية كموارد خدمة (IaaS). لتثبيت مكونات مخصصة، استخدم واجهات برمجة التطبيقات Kubernetes APIs وآلياتها. على سبيل المثال، استخدم DaemonSets لتثبيت أي مكونات مطلوبة.

تدعم AKS وحدات التحكم التالية للقبول:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

حاليًّا، لا يمكنك تعديل قائمة وحدات تحكم القبول في AKS.

نعم، يمكنك استخدام خطافات الويب لوحدة تحكم القبول على AKS. نوصي باستبعاد مساحات أسماء AKS الداخلية، والتي تم وضع علامة عليها control-plane بالتسمية. على سبيل المثال:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

جدران حماية AKS خروج خادم API بحيث يجب أن تكون خطافات الويب لوحدة تحكم القبول الخاصة بك قابلة للوصول من داخل نظام المجموعة.

لحماية استقرار النظام ومنع وحدات التحكم المخصصة في القبول من التأثير على الخدمات الداخلية في kube-system مساحة الاسم، لدى AKS منفذ القبول، والذي يستبعد kube-system تلقائيا ومساحات الأسماء الداخلية ل AKS. تضمن هذه الخدمة أن وحدات تحكم القبول المخصصة لا تؤثر على الخدمات التي تعمل في kube-system.

إذا كانت لديك حالة استخدام حرجة لنشر شيء ما على kube-system (غير مستحسن) لدعم خطاف الويب المخصص للقبول، يمكنك إضافة التسمية أو التعليق التوضيحي التالي بحيث يتجاهله منفذ القبول:

• التسمية: "admissions.enforcer/disabled": "true"
• تعليق توضيحي: "admissions.enforcer/disabled": true

يوفر موفر Azure Key Vault لبرنامج تشغيل Secrets Store CSI التكامل الأصلي ل Azure Key Vault في AKS.

يتم الآن دعم العقد التي تم تمكينها باستخدام معايير معالجة المعلومات الفيدرالية (FIPS) على تجمعات العقد المستندة إلى Linux. لمزيد من المعلومات، راجع Add a FIPS-enabled node pool.

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

ملحق AKS Linux هو ملحق Azure VM يقوم بتثبيت وتكوين أدوات المراقبة على عقد عامل Kubernetes. يتم تثبيت الملحق على جميع عقد Linux الجديدة والحالية. يقوم بتكوين أدوات المراقبة التالية:

• مصدر العقدة: يجمع بيانات تتبع الاستخدام للأجهزة من الجهاز الظاهري ويجعلها متاحة باستخدام نقطة نهاية المقاييس. بعد ذلك، يمكن لأداة المراقبة، مثل Prometheus، استخراج هذه المقاييس.
• Node-problem-detector: يهدف إلى جعل مشاكل العقد المختلفة مرئية لطبقات المصدر في مكدس إدارة نظام المجموعة. إنها وحدة نظامية تعمل على كل عقدة، وتكتشف مشكلات العقدة، وتقاريرها إلى خادم واجهة برمجة تطبيقات نظام المجموعة باستخدام Events و NodeConditions.
• ig: هو إطار عمل مفتوح المصدر مدعوم من eBPF لتصحيح الأخطاء ومراقبة أنظمة Linux وKubernetes. يوفر مجموعة من الأدوات (أو الأدوات الذكية) التي تجمع المعلومات ذات الصلة التي يمكن للمستخدمين استخدامها لتحديد سبب مشكلات الأداء أو الأعطال أو الحالات الشاذة الأخرى. وتجدر الإشارة إلى أن استقلالها عن Kubernetes يمكن المستخدمين من استخدامها أيضا لتصحيح مشكلات وحدة التحكم.

تساعد هذه الأدوات في توفير إمكانية الملاحظة حول العديد من المشاكل المتعلقة بصحة العقدة، مثل:

• مشكلات البرنامج الخفي للبنية الأساسية: خدمة NTP معطلة
• مشكلات الأجهزة: وحدة المعالجة المركزية أو الذاكرة أو القرص غير الصالح
• مشكلات النواة: حالة توقف تام ل Kernel، نظام ملفات تالف
• مشكلات وقت تشغيل الحاوية: البرنامج الخفي لوقت التشغيل غير المستجيب

لا يتطلب الملحق وصولا خارجيا إضافيا إلى أي عناوين URL أو عناوين IP أو منافذ تتجاوز متطلبات خروج AKS الموثقة. لا يتطلب أي أذونات خاصة تم منحها في Azure. يستخدم kubeconfig للاتصال بخادم API لإرسال بيانات المراقبة التي تم جمعها.

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

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

يمكنك ذلك، ولكننا لا نوصي بذلك. إجراء التحديثات عندما تكون حالة نظام المجموعة معروفة وصحية.

‏‏لا. حذف أو إزالة أي عقد في حالة فشل أو غير ذلك من نظام المجموعة قبل الترقية.

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

تأكد من أن كيان الخدمة لم تنته صلاحيته. لمزيد من المعلومات، راجع أساس خدمة AKSوبيانات اعتماد تحديث AKS.

تأكد من أن كيان الخدمة لم تنته صلاحيته. لمزيد من المعلومات، راجع أساس خدمة AKSوبيانات اعتماد تحديث AKS.

ابتداء من 17 مارس 2027، لم تعد خدمة Azure Kubernetes Service (AKS) تدعم أو توفر تحديثات الأمان لأوبونتو 20.04. سيتم حذف أي صور عقدة موجودة، ولن تتمكن من توسيع أي مجموعات عقد تعمل بنظام أوبونتو 20.04. انتقل إلى نسخة Ubuntu مدعومة عن طريق ترقية مجموعات العقد إلى إصدار Kubernetes 1.35+. لمزيد من المعلومات حول هذا التقاعد، راجع مشكلة GitHub للتقاعدوإعلان تقاعد تحديثات Azure. للبقاء على اطلاع بالإعلانات والتحديثات، تابع ملاحظات إصدار AKS.

ابتداء من 1 مارس 2026، لم تعد Azure Kubernetes Service (AKS) تدعم مجموعات عقد Windows Server 2019. تجمعات العقد التي تعمل بإصدار Kubernetes إصدار 1.33+ لا يمكنها استخدام Windows Server 2019. ابتداء من 1 أبريل 2027، ستقوم AKS بإزالة جميع صور العقد الموجودة لنظام ويندوز سيرفر 2019، مما يعني أن عمليات التوسع ستفشل. لمزيد من المعلومات حول هذا التقاعد، راجع مشكلة GitHub للتقاعدوإعلان تقاعد تحديثات Azure. للبقاء على اطلاع بالإعلانات والتحديثات، تابع ملاحظات إصدار AKS. ابتداء من 15 مارس 2027، لم تعد خدمة Azure Kubernetes Service (AKS) تدعم مجموعات عقد Windows Server 2022. لا يمكن لتجمع العقد التي تعمل كوبيرنتيز إصدار 1.36+ استخدام ويندوز سيرفر 2022. بدءا من 1 أبريل 2028، ستقوم AKS بإزالة جميع صور العقد الموجودة لنظام Windows Server 2022، مما يعني أن عمليات التوسع ستفشل. لمزيد من المعلومات حول هذا التقاعد، راجع مشكلة GitHub للتقاعدوإعلان تقاعد تحديثات Azure. للبقاء على اطلاع بالإعلانات والتحديثات، تابع ملاحظات إصدار AKS.