مشاركة عبر

واجهات شبكة حاويات AKS القديمة (CNI)

هام

في 31 مارس 2028، سيتم إيقاف شبكة kubenet لخدمة Azure Kubernetes (AKS).

لتجنب انقطاع الخدمة، ستحتاج إلىالترقية إلى تراكب واجهة شبكة حاويات Azure (CNI)قبل ذلك التاريخ، عندما لن يتم دعم أحمال العمل التي تعمل على kubenet ل AKS.

في Azure Kubernetes Service (AKS)، بينما يوصى بتراكب Azure CNI والشبكة الفرعية ل Azure CNI Pod لمعظم السيناريوهات، لا تزال نماذج الشبكات القديمة مثل الشبكة الفرعية لعقدة Azure CNI وkubenet متوفرة ومدعمة. تقدم هذه النماذج القديمة أساليب مختلفة لإدارة عناوين IP الخاصة بالجراب والشبكات، ولكل منها مجموعة خاصة بها من القدرات والاعتبارات. توفر هذه المقالة نظرة عامة على خيارات الشبكات القديمة هذه، وتفاصيل متطلباتها الأساسية، ومعلمات النشر، والخصائص الرئيسية لمساعدتك على فهم أدوارها وكيفية استخدامها بشكل فعال داخل مجموعات AKS الخاصة بك.

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

المتطلبات الأساسية التالية مطلوبة للشبكة الفرعية لعقدة Azure CNI:

  • يجب أن تسمح الشبكة الظاهرية لنظام مجموعة AKS بالاتصال بالإنترنت الصادر.

  • لا يمكن لمجموعات AKS استخدام 169.254.0.0/16أو 172.30.0.0/16172.31.0.0/16أو أو 192.0.2.0/24 لنطاق عنوان خدمة Kubernetes أو نطاق عناوين الجراب أو نطاق عناوين الشبكة الظاهرية لنظام المجموعة.

  • يجب أن يكون لهوية نظام المجموعة المستخدمة من قبل نظام مجموعة AKS أذونات "مساهم الشبكة" على الأقل على الشبكة الفرعية داخل الشبكة الظاهرية. إذا كنت تريد تعريف دور مخصص بدلا من استخدام دور مساهم الشبكة المضمن، فإن الأذونات التالية مطلوبة:

    • Microsoft.Network/virtualNetworks/subnets/join/action
    • Microsoft.Network/virtualNetworks/subnets/read
    • Microsoft.Authorization/roleAssignments/write

  • لا يمكن أن تكون الشبكة الفرعية المعينة إلى تجمع عقدة AKS شبكة فرعية مفوضة.

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

الشبكة الفرعية لعقدة Azure CNI

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

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

معلمات النشر

عند إنشاء نظام مجموعة AKS، تكون المعلمات التالية قابلة للتكوين لشبكة اتصال Azure CNI:

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

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

المكون الإضافي لشبكة Azure: عند استخدام المكون الإضافي لشبكة Azure، لا يمكن الوصول إلى خدمة LoadBalancer الداخلية مع "externalTrafficPolicy=Local" من الأجهزة الظاهرية باستخدام IP في clusterCIDR لا ينتمي إلى مجموعة AKS.

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

  • يجب ألا يكون ضمن نطاق عنوان IP للشبكة الظاهرية لنظام المجموعة.
  • يجب ألا تتداخل مع أي شبكات ظاهرية أخرى تتناظر معها الشبكة الظاهرية لنظام المجموعة.
  • يجب ألا تتداخل مع أي عناوين IP محلية.
  • يجب ألا يكون ضمن النطاقات 169.254.0.0/16أو 172.30.0.0/16172.31.0.0/16.192.0.2.0/24

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

عنوان IP لخدمة Kubernetes DNS: عنوان IP لخدمة DNS الخاصة بنظام المجموعة. يجب أن يكون هذا العنوان ضمن نطاق عنوان خدمة Kubernetes. لا تستخدم عنوان IP الأول في نطاق العناوين. يتم استخدام العنوان الأول في نطاق الشبكة الفرعية للعنوان kubernetes.default.svc.cluster.local.

  • Azure CNI: يمكن أن يدعم نفس نطاق الشبكة الفرعية الأساسي /24 فقط 8 عقد كحد أقصى في نظام المجموعة. يمكن أن يدعم عدد العقد هذا ما يصل إلى 240 حاوية فقط، بحد أقصى افتراضي 30 حاوية لكل عقدة.

إشعار

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

تناظر الشبكة الظاهرية واتصالات ExpressRoute

يمكنك استخدام تناظر شبكة Azure الظاهرية أو اتصالات ExpressRoute مع Azure CNI لتوفير اتصال محلي. تأكد من تخطيط عناوين IP بعناية لمنع التداخل وتوجيه نسبة استخدام الشبكة غير الصحيح. على سبيل المثال، تستخدم العديد من الشبكات المحلية نطاق عناوين 10.0.0.0/8 المعلن عنه عبر اتصال ExpressRoute. نوصي بإنشاء مجموعات AKS في الشبكات الفرعية لشبكة Azure الظاهرية خارج نطاق العناوين هذا، مثل 172.16.0.0/16.

لمزيد من المعلومات، راجع مقارنة نماذج الشبكة ونطاقات الدعم الخاصة بها.

الأسئلة المتداولة حول الشبكة الفرعية ل Azure CNI Pod

  • هل يمكنني نشر الأجهزة الظاهرية في الشبكة الفرعية لنظام المجموعة؟

    نعم بالنسبة للشبكة الفرعية لعقدة Azure CNI، يمكن نشر الأجهزة الظاهرية في نفس الشبكة الفرعية مثل نظام مجموعة AKS.

  • ما هو مصدر IP الذي تراه للأنظمة الخارجية لنسبة استخدام الشبكة التي تنشأ في وحدة جراب تمكين Azure CNI؟

    ترى الأنظمة في نفس الشبكة الافتراضية مثل نظام مجموعة AKS IP كعنوان مصدر لأي نسبة استخدام الشبكة من وحدة الجراب. ترى الأنظمة خارج الشبكة الظاهرية لنظام مجموعة AKS IP لوحدة الجراب كعنوان مصدر لأي نسبة استخدام الشبكة من وحدة الجراب. ولكن بالنسبة لتخصيص IP الديناميكي ل Azure CNI، بغض النظر عن الاتصال داخل نفس الشبكة الظاهرية أو عبر الشبكات الظاهرية، فإن عنوان IP للحجيرة هو دائما عنوان المصدر لأي حركة مرور من الجراب. وذلك لأن Azure CNI لتخصيص IP الديناميكي ينفذ البنية الأساسية لشبكة حاويات Microsoft Azure، ما يعطي تجربة شاملة. ومن ثم، فإنه يلغي استخدام ip-masq-agent، والذي لا يزال يستخدمه Azure CNI التقليدي.

  • هل يمكنني تكوين نُهج الشبكة لكل وحدة جراب؟

    نعم، يتوفر نهج شبكة Kubernetes في AKS. للبدء، راجع نسبة استخدام الشبكة الآمنة بين وحدات الجراب باستخدام نهج الشبكة في AKS.

  • هل الحد الأقصى لعدد وحدات الجراب قابل للنشر إلى عقدة قابلة للتكوين؟

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

  • هل يمكنني نشر الأجهزة الظاهرية في الشبكة الفرعية لنظام المجموعة؟

    نعم. ولكن بالنسبة إلى Azure CNI لتخصيص IP الديناميكي، لا يمكن نشر الأجهزة الظاهرية في الشبكة الفرعية للجراب.

  • ما هو مصدر IP الذي تراه للأنظمة الخارجية لنسبة استخدام الشبكة التي تنشأ في وحدة جراب تمكين Azure CNI؟

    ترى الأنظمة في نفس الشبكة الافتراضية مثل نظام مجموعة AKS IP كعنوان مصدر لأي نسبة استخدام الشبكة من وحدة الجراب. ترى الأنظمة خارج الشبكة الظاهرية لنظام مجموعة AKS IP لوحدة الجراب كعنوان مصدر لأي نسبة استخدام الشبكة من وحدة الجراب.

    ولكن بالنسبة إلى Azure CNI لتخصيص IP الديناميكي، بغض النظر عن الاتصال داخل نفس الشبكة الظاهرية أو عبر الشبكات الظاهرية، فإن عنوان IP للحجيرة هو دائما العنوان المصدر لأي حركة مرور من الجراب. وذلك لأن Azure CNI لتخصيص IP الديناميكي ينفذ البنية الأساسية لشبكة حاويات Microsoft Azure، ما يعطي تجربة شاملة. ومن ثم، فإنه يلغي استخدام ip-masq-agent، والذي لا يزال يستخدمه Azure CNI التقليدي.

  • هل يمكنني استخدام شبكة فرعية مختلفة ضمن شبكة نظام المجموعة الظاهرية لـ نطاق عنوان خدمة Kubernetes؟

    لا يُنصح بذلك، ولكن هذا التكوين ممكن. نطاق عنوان الخدمة هو مجموعة من عناوين IPs الظاهرية (كبار الشخصيات) التي يقوم Kubernetes بتعيينها إلى الخدمات الداخلية في نظام المجموعة. لا يوجد لدى Azure Networking أي رؤية في نطاق IP للخدمة من نظام مجموعة Kubernetes. يمكن أن يؤدي عدم الرؤية في نطاق عنوان خدمة نظام المجموعة إلى حدوث مشكلات. من الممكن لاحقا إنشاء شبكة فرعية جديدة في الشبكة الظاهرية لنظام المجموعة التي تتداخل مع نطاق عنوان الخدمة. في حالة حدوث مثل هذا التداخل، يمكن لـ Kubernetes تعيين خدمة IP قيد الاستخدام بالفعل من قِبل مورد آخر في الشبكة الفرعية، مما يؤدي إلى حدوث سلوك أو فشل لا يمكن التنبؤ به. من خلال التأكد من استخدام نطاق عنوان خارج الشبكة الظاهرية لنظام المجموعة، يمكنك تجنب هذا التداخل الخطر. نعم، عند نشر نظام مجموعة مع Azure CLI أو قالب إدارة الموارد. انظر الحد الأقصى لوحدات الجراب لكل عقدة.

  • هل يمكنني استخدام شبكة فرعية مختلفة ضمن شبكة نظام المجموعة الظاهرية لـ نطاق عنوان خدمة Kubernetes؟

    لا يُنصح بذلك، ولكن هذا التكوين ممكن. نطاق عنوان الخدمة هو مجموعة من عناوين IPs الظاهرية (كبار الشخصيات) التي يقوم Kubernetes بتعيينها إلى الخدمات الداخلية في نظام المجموعة. لا يوجد لدى Azure Networking أي رؤية في نطاق IP للخدمة من نظام مجموعة Kubernetes. يمكن أن يؤدي عدم الرؤية في نطاق عنوان خدمة نظام المجموعة إلى حدوث مشكلات. من الممكن لاحقا إنشاء شبكة فرعية جديدة في الشبكة الظاهرية لنظام المجموعة التي تتداخل مع نطاق عنوان الخدمة. في حالة حدوث مثل هذا التداخل، يمكن لـ Kubernetes تعيين خدمة IP قيد الاستخدام بالفعل من قِبل مورد آخر في الشبكة الفرعية، مما يؤدي إلى حدوث سلوك أو فشل لا يمكن التنبؤ به. من خلال التأكد من استخدام نطاق عنوان خارج الشبكة الظاهرية لنظام المجموعة، يمكنك تجنب هذا التداخل الخطر.