مشاركة عبر

الشبكة الفرعية لواجهة شبكة حاويات Azure (CNI) Pod

  • مقالة

تعين الشبكة الفرعية ل Azure CNI Pod عناوين IP إلى pods من شبكة فرعية منفصلة عن عقد نظام المجموعة. تتوفر هذه الميزة في وضعين: تخصيص IP الديناميكي وتخصيص الكتلة الثابتة (معاينة).

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

إشعار

عند استخدام تخصيص كتلة ثابتة من CIDRs، فإن تعريض تطبيق كخدمة ارتباط خاص باستخدام خدمة موازن تحميل Kubernetes غير مدعوم.

  • راجع المتطلبات الأساسية لتكوين شبكات Azure CNI الأساسية في AKS، حيث تنطبق نفس المتطلبات الأساسية على هذه المقالة.

  • راجع معلمات التوزيع لتكوين شبكات Azure CNI الأساسية في AKS، كما تنطبق نفس المعلمات.

  • مجموعات AKS Engine و DIY غير مدعومة.

  • إصدار 2.37.0 Azure CLI أو إصدار أحدث وإصدار 2.0.0b2 الملحق aks-preview أو أحدث.

  • سجل علامة ميزة مستوى الاشتراك لاشتراكك: 'Microsoft.ContainerService/AzureVnetScalePreview'.

  • إذا كان لديك مجموعة موجودة، فأنت بحاجة إلى تمكين Container Insights لمراقبة الوظيفة الإضافية لاستخدام الشبكة الفرعية IP. يمكنك تمكين Container Insights باستخدام az aks enable-addons الأمر ، كما هو موضح في المثال التالي:

    az aks enable-addons --addons monitoring --name <cluster-name> --resource-group <resource-group-name>

وضع تخصيص IP الديناميكي

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

يوفر وضع تخصيص IP الديناميكي المزايا التالية:

  • استخدام أفضل لـ IP:يتم تخصيص IP بشكل حيوي إلى مجموعة وحدات الجراب من الشبكة الفرعية لوحدات الجراب. وهذا يؤدي إلى استخدام أفضل لـ IPs في نظام المجموعة مقارنةً مع حل CNI التقليدي، الذي لا يمتلك تخصيص ثابت من عناوين الإنترنت لكل عقدة.
  • القابلية للتحجيم والمرونة: يمكن تحجيم الشبكات الفرعية للعقدة ووحدة الجراب بشكلٍ مستقل. يمكن مشاركة شبكة فرعية واحدة لوحدة جراب عبر تجمعات عقد متعددة لنظام مجموعة أو عبر أنظمة مجموعات AKS المتعددة المنشورة في نفس الشبكة الظاهرية. يمكنك أيضاً تكوين شبكة فرعية منفصلة لوحدة الجراب وتجمع العقدة.
  • الأداء العالي: نظرا لتعيين وحدات الجراب ل VNet IPs، فإن لديها اتصالا مباشرا بوحدات الجراب والموارد الأخرى لنظام المجموعة في الشبكة الظاهرية. يدعم الحل أنظمة مجموعات كبيرة جداً دون أي تدهور في الأداء.
  • نُهج الشبكة الظاهرية المنفصلة لوحدات الجراب: نظرًا لأن وحدات الجراب لها شبكة فرعية منفصلة، يمكنك تكوين نُهج شبكة ظاهرية منفصلة لهم تختلف عن نُهج العقدة. يتيح هذا العديد من السيناريوهات المفيدة، مثل السماح بالاتصال بالإنترنت فقط للقرون وليس للعقد، وإصلاح IP المصدر للحجيرة في تجمع عقدة باستخدام بوابة Azure NAT، واستخدام مجموعات أمان الشبكة (NSGs) لتصفية نسبة استخدام الشبكة بين تجمعات العقد.
  • نهج شبكة Kubernetes: يعمل كل من نهج شبكة Azure وCalico مع هذا الوضع.

تخطيط عناوين IP

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

خُصصت عناوين IP للعُقد على دفعات من 16. يجب تخطيط تخصيص IP للشبكة الفرعية ل Pod بحد أدنى 16 عنوان IP لكل عقدة في المجموعة، حيث تطلب العقد 16 عنوان IP عند بدء التشغيل وتطلب دفعة أخرى من 16 في أي وقت يكون هناك <8 عناوين IP غير مخصصة في تخصيصها.

يظل تخطيط عنوان IP لخدمات Kubernetes وجسر Docker دون تغيير.

وضع تخصيص الكتلة الثابتة (معاينة)

يساعد تخصيص الكتلة الثابتة على التخفيف من حجم الشبكة الفرعية المحتملة للجراب وحدود تعيين عنوان Azure عن طريق تعيين كتل CIDR للعقد بدلا من عناوين IP الفردية.

يوفر وضع تخصيص الكتلة الثابتة المزايا التالية:

  • قابلية توسع IP أفضل: يتم تخصيص كتل CIDR بشكل ثابت لعقد نظام المجموعة وهي موجودة طوال عمر العقدة، بدلا من التخصيص الديناميكي التقليدي ل IPs الفردية مع CNI التقليدي. وهذا يمكن التوجيه استنادا إلى كتل CIDR ويساعد على توسيع نطاق حد نظام المجموعة حتى 1 مليون جراب من 65 ألف جراب التقليدية لكل نظام مجموعة. يجب أن تكون شبكة Azure الظاهرية كبيرة بما يكفي لاستيعاب مقياس مجموعتك.
  • المرونة: يمكن تحجيم الشبكات الفرعية للعقدة والجراب بشكل مستقل. يمكن مشاركة شبكة فرعية واحدة لوحدة جراب عبر تجمعات عقد متعددة لنظام مجموعة أو عبر أنظمة مجموعات AKS المتعددة المنشورة في نفس الشبكة الظاهرية. يمكنك أيضاً تكوين شبكة فرعية منفصلة لوحدة الجراب وتجمع العقدة.
  • أداء عال: نظرا لأنه يتم تعيين عناوين IP للشبكة الظاهرية لوحدات الجراب، فإن لديها اتصالا مباشرا بقرون نظام المجموعة والموارد الأخرى في الشبكة الظاهرية.
  • نُهج الشبكة الظاهرية المنفصلة لوحدات الجراب: نظرًا لأن وحدات الجراب لها شبكة فرعية منفصلة، يمكنك تكوين نُهج شبكة ظاهرية منفصلة لهم تختلف عن نُهج العقدة. يتيح هذا العديد من السيناريوهات المفيدة مثل السماح بالاتصال بالإنترنت فقط للقرون وليس للعقد، وإصلاح IP المصدر للحجيرة في تجمع عقدة باستخدام بوابة Azure NAT، واستخدام NSGs لتصفية نسبة استخدام الشبكة بين تجمعات العقد.
  • نهج شبكة Kubernetes: تعمل Cilium وAzure NPM وCalico مع هذا الحل.

القيود

فيما يلي بعض القيود المفروضة على استخدام تخصيص كتلة Azure CNI الثابتة:

  • الحد الأدنى لإصدار Kubernetes المطلوب هو 1.28
  • الحد الأقصى لحجم الشبكة الفرعية المدعوم هو x.x.x.x/12 ~ 1 مليون IPs
  • يمكن استخدام وضع تشغيل واحد فقط لكل شبكة فرعية. إذا كانت الشبكة الفرعية تستخدم وضع تخصيص كتلة ثابتة، فلا يمكن استخدام وضع تخصيص IP الديناميكي في مجموعة أو تجمع عقدة مختلف بنفس الشبكة الفرعية والعكس صحيح.
  • مدعوم فقط في مجموعات جديدة أو عند إضافة تجمعات عقدة مع شبكة فرعية مختلفة إلى المجموعات الموجودة. ترحيل أو تحديث المجموعات أو تجمعات العقد الموجودة غير مدعوم.
  • عبر جميع كتل CIDR المعينة لعقدة في تجمع العقدة، سيتم تحديد عنوان IP واحد ك IP أساسي للعقدة. ومن ثم، بالنسبة لمسؤولي الشبكة الذين يختارون --max-pods القيمة، حاول استخدام الحساب أدناه لتلبية احتياجاتك على أفضل نحو واستخدام عناوين IP على النحو الأمثل في الشبكة الفرعية:

max_pods = (N * 16) - 1حيث N هو أي عدد صحيح موجب و0 N>

تخطيط عناوين IP

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

يتم تخصيص كتل CIDR من /28 (16 IPs) للعقد بناء على التكوين الخاص بك --max-pods لتجمع العقدة الخاص بك، والذي يحدد الحد الأقصى لعدد pods لكل عقدة. يتم حجز عنوان IP 1 على كل عقدة من جميع عناوين IP المتوفرة على تلك العقدة لأغراض داخلية.

أثناء تخطيط عناوين IP الخاصة بك، من المهم تحديد التكوين الخاص بك --max-pods باستخدام الحساب التالي: max_pods_per_node = (16 * N) - 1، حيث N يوجد أي عدد صحيح موجب أكبر من 0.

تتطلب القيم المثالية بدون هزاء IP أن تتوافق قيمة pods القصوى مع التعبير أعلاه.

راجع أمثلة الحالات التالية:

حالة المثال max_pods كتل CIDR المخصصة لكل عقدة إجمالي IP المتاح للجرابات هدار IP للعقدة
هدار منخفض (مقبول) 30 2 (16 * 2) - 1 = 32 - 1 = 31 31 - 30 = 1
حالة مثالية 31 2 (16 * 2) - 1 = 32 - 1 = 31 31 - 31 = 0
الهدار العالي (غير مستحسن) 32 3 (16 * 3) - 1 = 48 - 1 = 47 47 - 32 = 15

لا يزال تخطيط عنوان IP لخدمات Kubernetes دون تغيير.

إشعار

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