مشاركة عبر

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

  • مقالة

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

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

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

  • يجب أن تسمح الشبكة الظاهرية لنظام مجموعة 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 للعقدة. للحصول على مزيٍد من المعلومات، راجع مجموعة أمان الشبكة.

إشعار

Kubenet غير متوفر لحاويات Windows Server. لاستخدام تجمعات عقد Windows Server، تحتاج إلى استخدام Azure CNI.

الشبكة الفرعية لعقدة 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.

Kubenet

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

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

نظرة عامة على kubenet مع الشبكة الفرعية الخاصة بك

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

من خلال kubenet، تتلقّي العُقَد وحدها عنوان IP في الشبكة الفرعية الخاصة بالشبكة الظاهرية. الأفرع لا تستطيع التواصل مباشرة مع بعضها البعض. بدلا من ذلك، يعالج التوجيه المعرف من قبل المستخدم (UDR) وإعادة توجيه IP الاتصال بين pods عبر العقد. يتم إنشاء UDRs وتكوين إعادة توجيه IP وصيانتها بواسطة خدمة AKS بشكل افتراضي، ولكن يمكنك إحضار جدول التوجيه الخاص بك لإدارة المسار المخصص إذا كنت تريد ذلك. يمكنك أيضا نشر pods خلف خدمة تتلقى عنوان IP معينا وحركة مرور موازنة التحميل للتطبيق. يوضح الرسم التخطيطي التالي كيفية تلقي عقد AKS عنوان IP في الشبكة الفرعية للشبكة الظاهرية، ولكن ليس الأفرع:

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

يدعم Azure 400 مسار كحد أقصى في UDR، لذلك لا يمكنك الحصول على مجموعة AKS أكبر من 400 عقدة. العقد الظاهرية ل AKS ونهج شبكة Azure غير مدعومة مع kubenet. يتم دعم نهج شبكة Calico.

القيود والاعتبارات لـ kubenet

إشعار

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

مدى توفّر عناوين IP ونفادها

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

باستخدام kubenet، يمكنك استخدام نطاق عناوين IP أصغر بكثير ودعم المجموعات الكبيرة ومتطلبات التطبيق. على سبيل المثال، باستخدام نطاق عنوان IP /27 على الشبكة الفرعية، يمكنك تشغيل مجموعة عقدة من 20 إلى 25 مع مساحة كافية لتوسيع نطاقها أو ترقيتها. يمكن أن يدعم حجم نظام المجموعة هذا ما يصل إلى 2200-2750 حاوية (بحد أقصى افتراضي 110 pods لكل عقدة). الحد الأقصى لعدد pods لكل عقدة يمكنك تكوينها باستخدام kubenet في AKS هو 250.

تقارن العمليات الحسابية الأساسية التالية الفرق في نماذج الشبكة:

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

إشعار

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

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

يمكنك استخدام تناظر شبكة Azure الظاهرية أو اتصالات ExpressRoute مع Azure CNI وkubenet لتوفير اتصال محلي. تأكد من تخطيط عناوين 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.

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

    بشكل افتراضي، تستخدم مجموعات AKS kubenet وتنشئ شبكة ظاهرية وشبكة فرعية. من خلال kubenet، تتلقى العُقَد عنوان IP من الشبكة الفرعية الخاصة بشبكة Azure الظاهرية. ترجمة عنوان الشبكة (NAT) ثم تكوينه على العقد، وتتلقى وحدات الجراب عنوان IP "مخفي" خلف عقدة IP. يقلل هذا النهج من عدد عناوين IP التي تحتاج إلى حجزها في مساحة الشبكة لوحدات الجراب لاستخدام الحاويات.

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