الأسئلة المتداولة حول خدمة Azure Kubernetes Service (AKS)

تتناول هذه المقالة الأسئلة المتكررة حول خدمة Azure Kubernetes Service (AKS).

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

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

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

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

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

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

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

نعم. هناك خياران لتقييد الوصول إلى الخادم API:

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

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

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

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

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

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

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

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

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

عقد خادم Windows Server

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

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

توفّر Microsoft إرشادات للإجراءات الأخرى التي يمكنك اتخاذها لتأمين أحمال العمل الخاصة بك من خلال خدمات مثل Microsoft Defender for Containers. يرتبط التهديد الأمني التالي ب AKS وKubernetes التي يجب أن تكون على علم بها:

• تستهدف حملة جديدة واسعة النطاق Kubeflow (8 يونيو 2021).

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

يستخدم AKS اتصال نفق آمن للسماح لخادم api وkubelets العقدة الفردية للاتصال حتى على شبكات ظاهرية مُنفصلة. يتم تأمين النفق من خلال تشفير mTLS. النفق الرئيسي الحالي الذي تستخدمه خدمة 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 مع قواعد التطبيق.

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

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

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

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

إشعار

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

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

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

• NamespaceLifecycle
• LimitRanger
• حساب الخدمة
• الفئة الافتراضية
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

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

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

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

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

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

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

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

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

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

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

يوفّر موفر Azure Key Vault لبرنامج تشغيل CSI لمخزن البيانات السرية التكامل الأصلي لـ Azure Key Vault في AKS.

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

نعم، تتوفر حاويات Windows Server على AKS. لتشغيل حاويات Windows Server في AKS، أنشئ تجمع عقدة التي تعمل Windows Server كـنظام التشغيل الضيف OS. يمكن لحاويات Windows Server استخدام Windows Server 2019 فقط. للبدء، راجع إنشاء مقطع تخزين AKS مع تجمع عقدة Windows Server.

يتضمن دعم Windows Server تجمع عقدة بعض القيود التي هي جزء من Windows Server المصدر في مشروع Kubernetes. لمزيد من المعلومات حول هذه القيود، راجع حاويات Windows Server في قيود AKS.

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

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

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

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

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

هل يمكنني نقل/ترحيل مقطع تخزين الخاص بي بين مستأجري Azure؟

نقل مقطع تخزين AKS بين المستأجرين غير مدعوم حاليًّا.

هل يمكنني نقل/ترحيل مقطع التخزين الخاص بي بين الاشتراكات؟

حركة مقاطع التخزين بين الاشتراكات غير معتمدة حاليًّا.

هل يمكنني نقل مجموعات AKS من اشتراك Azure الحالي إلى آخر؟

نقل مقطع التخزين AKS الخاص بك والموارد المقترنة به بين اشتراكات Azure غير مدعومة.

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

نقل أو إعادة تسمية مقطع تخزين AKS والموارد المقترنة بها غير معتمد.

لماذا يستغرق حذف مقطع التخزين الخاص بي وقتًا طويلًا؟

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

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

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

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

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

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

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

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

• وظائف ومكونات Kubernetes
• إنشاء مجموعة أو تجمع عقدة
• الاصلاحات الضروريه
• إصلاح الأخطاء
• التحديثات الأمنية
• المكونات المتوقفة

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

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

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

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

على سبيل المثال، ترقيات kubernetes v1.25 إلى v1.26 أثناء إصدار التوفر العام v1.29. لتقليل الاضطرابات، قم بإعداد نوافذ الصيانة. راجع الترقية التلقائية للحصول على تفاصيل حول قنوات الترقية التلقائية.

إذا كان لدي قرن / توزيع في حالة 'NodeLost' أو 'غير معروف' عندها ألا زال بإمكاني ترقية مقطع التخزين الخاص بي؟

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

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

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

لقد قمت بتشغيل حذف مقطع التخزين، ولكن انظر الخطأ [Errno 11001] getaddrinfo failed

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

قمت بتشغيل ترقية، ولكن الآن القرون الخاصة بي تعاني من فشل لا متناهي، هل ستفشل تحقيقات الاستعداد؟

تأكد من أن أصل الخدمة لم تنته صلاحيته. انظر: خدمة AKS الرئيسية وبيانات اعتماد تحديث AKS.

كان مقطع تخزين يعمل بشكل طبيعي، ولكن فجأة لا يمكنني توفير LoadBalancers، أو تحميل PVCs، وما إلى ذلك؟

تأكد من أن أصل الخدمة لم تنته صلاحيته. انظر: خدمة AKS الرئيسية وبيانات اعتماد تحديث AKS.

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

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

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

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

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

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

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

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

في حين أن AKS لديها آليات مرونة لتحمل مثل هذا التكوين والتعافي منه، فإنه ليس تكوينا مدعوما. قم بإيقاف مقطع التخزين بدلًا من ذلك.

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

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

هل تخزن 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

ما هو الوضع الشفاف لـ Azure CNI مقابل وضع الجسر؟

بدءًا من الإصدار 1.2.0، يُعيّن Azure CNI الوضع الشفاف كوضع افتراضي لتوزيعات Linux CNI أحادية الإيجار. يستبدل الوضع الشفاف وضع الجسر. في أقسام وضع الجسر ووضع شفاف التالية، نناقش المزيد حول الاختلافات بين كلا الوضعين وفوائد وقيود الوضع الشفاف في Azure CNI.

وضع الجسر

ينشئ وضع Azure CNI Bridge جسر L2 يسمى "azure0" بطريقة "في الوقت المناسب". يتم توصيل جميع واجهات زوج الجراب veth من جانب المضيف بهذا الجسر. يمر اتصال Pod-Pod داخل الجهاز الظاهري وحركة المرور المتبقية عبر هذا الجسر. الجسر هو جهاز ظاهري من الطبقة 2 لا يمكنه من تلقاء نفسه تلقي أي شيء أو إرساله إلا إذا قمت بربط جهاز حقيقي واحد أو أكثر به. لهذا السبب، يجب تحويل eth0 من Linux VM إلى جسر تابع ل "azure0"، والذي ينشئ مخطط شبكة معقد داخل جهاز Linux الظاهري. كعرض، كان على CNI معالجة وظائف الشبكات الأخرى، مثل تحديثات خادم DNS.

يوضح المثال التالي كيف يبدو إعداد مسار IP في وضع الجسر. بغض النظر عن عدد القرون التي تحتويها العقدة، هناك مساران فقط. يشير المسار الأول إلى أن نسبة استخدام الشبكة (باستثناء المحلية على azure0) تنتقل إلى البوابة الافتراضية للشبكة الفرعية من خلال الواجهة مع ip "src 10.240.0.4"، وهو عنوان IP الأساسي للعقدة. يقول الثاني "10.20.x.x" مساحة Pod إلى نواة لكي يقررها kernel.

default via 10.240.0.1 dev azure0 proto dhcp src 10.240.0.4 metric 100
10.240.0.0/12 dev azure0 proto kernel scope link src 10.240.0.4
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
root@k8s-agentpool1-20465682-1:/#

وضع شفاف

يأخذ الوضع الشفاف نهجا مباشرا لإعداد شبكات Linux. في هذا الوضع، لا يغير Azure CNI أي خصائص لواجهة eth0 في Linux VM. يساعد هذا النهج لتغيير خصائص شبكة Linux على تقليل مشكلات حالة الزاوية المعقدة التي قد تواجهها المجموعات مع وضع الجسر. في الوضع الشفاف، يقوم Azure CNI بإنشاء وإضافة واجهات زوج جراب veth من جانب المضيف التي تتم إضافتها إلى شبكة المضيف. يتم الاتصال بين Pod-to-Pod داخل الجهاز الظاهري من خلال مسارات ip التي أضافها CNI. بشكل أساسي، اتصال Pod-to-Pod هو أكثر من الطبقة 3 وقواعد التوجيه L3 توجيه حركة مرور الجراب.

يوضح المثال التالي إعداد مسار IP لوضع Transparent. تحصل واجهة كل جراب على مسار ثابت مرفق حتى نسبة استخدام الشبكة مع عنوان IP dest حيث يتم إرسال الجراب مباشرة إلى واجهة الزوج الجانبي veth المضيف ل Pod.

10.240.0.216 dev azv79d05038592 proto static
10.240.0.218 dev azv8184320e2bf proto static
10.240.0.219 dev azvc0339d223b9 proto static
10.240.0.222 dev azv722a6b28449 proto static
10.240.0.223 dev azve7f326f1507 proto static
10.240.0.224 dev azvb3bfccdd75a proto static
168.63.129.16 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
169.254.169.254 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

فوائد الوضع الشفاف

• يوفر التخفيف من conntrack حالة السباق المتوازي DNS وتجنب مشكلات زمن وصول DNS 5 ثوان دون الحاجة إلى إعداد DNS محلي عقدة (قد لا تزال تستخدم DNS المحلية العقدة لأسباب تتعلق بالأداء).
• يلغي زمن انتقال الـ DNS ذو 5 ثوان أولية CNI ويقدم وضع الجسر اليوم بسبب إعداد الجسر "فقط في الوقت المناسب".
• إحدى حالات الزاوية في وضع Bridge هو أن Azure CNI لا يمكنه الاستمرار في تحديث خادم DNS المخصص الذي يضيفه المستخدمون إما إلى VNET أو NIC. ينتج عن هذا السيناريو التقاط CNI للمثيل الأول فقط من قائمة خوادم DNS. تم حل هذه المشكلة في الوضع الشفاف، حيث لا يغير CNI أي خصائص eth0. شاهد المزيد هنا.
• يوفر معالجة أفضل لحركة مرور UDP والتخفيف من حدة عاصفة الفيضانات في UDP عند مهلة ARP. في وضع الجسر، عندما لا يعرف الجسر عنوان MAC ل pod الوجهة في اتصال Pod-to-Pod داخل الجهاز الظاهري، حسب التصميم، فإنه يؤدي إلى عاصفة من الحزمة إلى جميع المنافذ. تم حل هذه المشكلة في الوضع الشفاف، حيث لا توجد أجهزة L2 في المسار. شاهد المزيد هنا.
• يعمل الوضع الشفاف بشكل أفضل في اتصال Intra VM Pod-to-Pod من حيث معدل النقل وزمن الانتقال بالمقارنة مع وضع الجسر.

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

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

يتمثل أحد الآثار الجانبية للإعداد fsGroup في أنه في كل مرة يتم فيها تحميل وحدة تخزين، يجب أن يتكرر chown() Kubernetes وجميع 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: Granular Control of Volume Permission Changes.

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

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

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

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

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

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

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

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

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

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

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

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

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

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