نظرة عامة على شبكات CNI لخدمة Azure Kubernetes (AKS)

يستخدم Kubernetes المكونات الإضافية لواجهة شبكة الحاوية (CNI) لإدارة الشبكات في مجموعات Kubernetes. تعد CNIs مسؤولة عن تعيين عناوين IP إلى pods وتوجيه الشبكة بين pods وتوجيه خدمة Kubernetes والمزيد.

توفر AKS العديد من مكونات CNI الإضافية التي يمكنك استخدامها في مجموعاتك اعتمادا على متطلبات الشبكات الخاصة بك.

نماذج الشبكات في AKS

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

تستخدم AKS نموذجين رئيسيين للشبكات: تراكب الشبكة والشبكة المسطحة.

يحتوي كلا نموذجي الشبكات على العديد من خيارات المكون الإضافي CNI المدعومة. الاختلافات الرئيسية بين النماذج هي كيفية تعيين عناوين IP الخاصة بالجراب وكيفية مغادرة نسبة استخدام الشبكة للمجموعة.

تراكب الشبكات

تراكب الشبكات هو نموذج الشبكات الأكثر شيوعا المستخدم في Kubernetes. في شبكات التراكب، يتم إعطاء الجرابات عنوان IP من CIDR خاص منفصل منطقيا عن الشبكة الفرعية Azure VNet حيث يتم نشر عقد AKS. يسمح هذا بقابلية توسع أبسط وأفضل في كثير من الأحيان من نموذج الشبكة المسطحة.

في شبكات التراكب، يمكن للقرون التواصل مع بعضها البعض مباشرة. نسبة استخدام الشبكة التي تغادر المجموعة هي عنوان شبكة المصدر المترجم (SNAT'd) إلى عنوان IP الخاص بالعقدة، ويتم توجيه نسبة استخدام الشبكة Pod IP الواردة من خلال بعض الخدمة، مثل موازن التحميل. وهذا يعني أن عنوان IP الخاص بالجراب "مخفي" خلف عنوان IP للعقدة. يقلل هذا الأسلوب من عدد عناوين IP للشبكة الظاهرية المطلوبة لمجموعاتك.

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

توفر خدمة Azure Kubernetes المكونات الإضافية CNI التالية لشبكات التراكب:

  • تراكب Azure CNI، المكون الإضافي CNI الموصى به لمعظم السيناريوهات.
  • kubenet، نموذج التراكب القديم CNI.

شبكات مسطحة

على عكس شبكة التراكب، يقوم نموذج شبكة مسطحة في AKS بتعيين عناوين IP إلى pods من شبكة فرعية من نفس Azure VNet مثل عقد AKS. وهذا يعني أن نسبة استخدام الشبكة التي تغادر مجموعاتك ليست SNAT'd، ويتم عرض عنوان IP الخاص بالجراب مباشرة إلى الوجهة. يمكن أن يكون هذا مفيدا لبعض السيناريوهات، مثل عندما تحتاج إلى عرض عناوين IP الخاصة بالجراب للخدمات الخارجية.

رسم تخطيطي يوضح عقدتين مع ثلاث جرابات تعمل كل منهما في نموذج شبكة مسطحة.

توفر خدمة Azure Kubernetes اثنين من مكونات CNI الإضافية للشبكات المسطحة. لا تدخل هذه المقالة في العمق لكل خيار مكون إضافي. لمزيد من المعلومات، راجع الوثائق المرتبطة:

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

اختيار CNI

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

اختيار نموذج شبكة

نموذجا الشبكات الرئيسيان في AKS هما الشبكات التراكبية والمسطحة.

  • تراكب الشبكات:

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

    • تحصل Pods على اتصال VNet كامل ويمكن الوصول إليها مباشرة عبر عنوان IP الخاص بها من الشبكات المتصلة.
    • تتطلب مساحة عنوان IP كبيرة غير مجزأة للشبكة الظاهرية.

مقارنة حالة الاستخدام

عند اختيار نموذج شبكة، ضع في اعتبارك حالات الاستخدام لكل مكون إضافي CNI ونوع نموذج الشبكة الذي يستخدمه:

المكون الإضافي CNI نموذج الشبكات تمييز حالة الاستخدام
تراكب Azure CNI تراكب - الأفضل للحفاظ على VNET IP
- الحد الأقصى لعدد العقد المدعومة من خادم API + 250 جراب لكل عقدة
- تكوين أبسط
-لا يوجد وصول IP خارجي مباشر إلى جراب
الشبكة الفرعية ل Azure CNI Pod (معاينة) مُنْبَسِط - الوصول المباشر إلى الجراب الخارجي
- أوضاع استخدام IP فعال للشبكة الظاهرية أو دعم مقياس نظام المجموعة الكبير
Kubenet (قديم) تراكب - تحديد أولويات الحفاظ على IP
- مقياس محدود
- إدارة المسار اليدوي
الشبكة الفرعية لعقدة Azure CNI (قديم) مُنْبَسِط - الوصول المباشر إلى الجراب الخارجي
- تكوين أبسط
- مقياس محدود
- الاستخدام غير الفعال ل VNet IPs

مقارنة الميزات

قد ترغب أيضا في مقارنة ميزات كل مكون إضافي CNI. يوفر الجدول التالي مقارنة عالية المستوى للميزات التي يدعمها كل مكون إضافي CNI:

ميزة تراكب Azure CNI الشبكة الفرعية ل Azure CNI Pod الشبكة الفرعية لعقدة Azure CNI (قديم) Kubenet
نشر نظام المجموعة في شبكة ظاهرية موجودة أو جديدة مدعوم مدعوم مدعوم مدعوم - أدوات UDRs اليدوية
اتصال Pod-VM مع VM في نفس الشبكة الظاهرية أو نظيرها Pod الذي تم بدؤه الطريقتان الطريقتان Pod الذي تم بدؤه
الوصول المحلي عبر VPN/Express Route Pod الذي تم بدؤه الطريقتان الطريقتان Pod الذي تم بدؤه
الوصول إلى نقاط نهاية الخدمة مدعوم مدعوم مدعوم مدعوم
كشف الخدمات باستخدام موازن التحميل مدعوم مدعوم مدعوم مدعوم
كشف الخدمات باستخدام بوابة التطبيق غير معتمد حاليا مدعوم مدعوم مدعوم
كشف الخدمات باستخدام وحدة تحكم الدخول مدعوم مدعوم مدعوم مدعوم
تجمعات عقدة Windows مدعوم مدعوم مدعوم غير مدعوم
المناطق الخاصة وDNS Azure الافتراضية مدعوم مدعوم مدعوم مدعوم
مشاركة الشبكة الفرعية للشبكة الظاهرية عبر مجموعات متعددة مدعوم مدعوم مدعوم غير مدعوم

نطاق الدعم بين نماذج الشبكة

اعتمادا على CNI الذي تستخدمه، يمكن نشر موارد الشبكة الظاهرية لنظام المجموعة بإحدى الطرق التالية:

  • يمكن للنظام الأساسي لـ Azure إنشاء وتكوين موارد الشبكة الظاهرية تلقائيًا عند إنشاء نظام مجموعة AKS. كما هو الحال في تراكب Azure CNI والشبكة الفرعية لعقدة Azure CNI وKubenet.
  • يمكنك إنشاء وتكوين موارد الشبكة الظاهرية يدويًا والإرفاق لهذه الموارد عند إنشاء نظام مجموعة AKS.

على الرغم من دعم قدرات مثل نقاط نهاية الخدمة أو UDRs، فإن نهج الدعم ل AKS تحدد التغييرات التي يمكنك إجراؤها. على سبيل المثال:

  • إذا قمت بإنشاء موارد الشبكة الظاهرية يدويًا لمجموعة AKS، فأنت مدعوم عند تكوين UDR أو نقاط نهاية الخدمة الخاصة بك.
  • إذا كان النظام الأساسي لـ Azure يقوم تلقائيًا بإنشاء موارد الشبكة الظاهرية لمجموعة AKS، فلا يمكنك تغيير تلك الموارد التي تديرها AKS يدويًا لتكوين UDR الخاصة بك أو نقاط نهاية الخدمة.

المتطلبات الأساسية

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

  • يجب أن تسمح الشبكة الظاهرية لنظام مجموعة AKS بالاتصال بالإنترنت الصادر.
  • لا يمكن لمجموعات AKS استخدام 169.254.0.0/16أو 172.30.0.0/16172.31.0.0/16أو أو 192.0.2.0/24 لنطاق عنوان خدمة Kubernetes أو نطاق عناوين الجراب أو نطاق عناوين الشبكة الظاهرية لنظام المجموعة.
  • في سيناريوهات BYO CNI، يجب أن يكون لهوية نظام المجموعة المستخدمة من قبل مجموعة AKS أذونات مساهم الشبكة على الأقل على الشبكة الفرعية داخل الشبكة الظاهرية. إذا كنت ترغب في تحديد دور مخصص بدلا من استخدام دور مساهم الشبكة المضمن، فإن الأذونات التالية مطلوبة:
    • Microsoft.Network/virtualNetworks/subnets/join/action
    • Microsoft.Network/virtualNetworks/subnets/read
    • Microsoft.Authorization/roleAssignments/write
  • لا يمكن أن تكون الشبكة الفرعية المعينة إلى تجمع عقدة AKS شبكة فرعية مفوضة.
  • لا تُطبق AKS مجموعات أمان الشبكة (NSGs) على شبكتها الفرعية ولا تعدل أيّاً من مجموعات أمان الشبكة المرتبطة بتلك الشبكة الفرعية. إذا قمت بتوفير الشبكة الفرعية الخاصة بك وإضافة "مجموعات أمان الشبكة" المرتبطة بتلك الشبكة الفرعية، يجب التأكد من أن قواعد الأمان في "مجموعات الأمان الوطنية" تسمح بحركة نقل البيانات بين العقدة وحاوية CIDR. للحصول على مزيٍد من المعلومات، راجع مجموعة أمان الشبكة.

الخطوات التالية