تكوين شبكات Azure CNI Overlay في خدمة Azure Kubernetes Service (AKS)

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

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

نظرة عامة على تراكب الشبكات

في الشبكات التراكبية، يتم تعيين عناوين IP فقط لعقد نظام مجموعة Kubernetes من الشبكات الفرعية. تتلقى وحدات الجراب عناوين IP من CIDR خاص يتم توفيره في وقت إنشاء نظام المجموعة. يتم تعيين مساحة عنوان /24 لكل عقدة منحوتة من نفس CIDR. تتلقى /24 العقد الإضافية التي تم إنشاؤها عند توسيع نطاق مجموعة تلقائيا مسافات العناوين من نفس CIDR. يقوم Azure CNI بتعيين عناوين IP إلى pods من مساحة /24 هذه.

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

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

يمكنك توفير اتصال صادر (خروج) بالإنترنت لوحدات الجراب التراكبية باستخدام موازن تحميل SKU القياسي أو بوابة NAT المدارة. يمكنك أيضًا التحكم في حركة الخروج عن طريق توجيهها إلى جدار حماية باستخدام التوجيهات المعرفة من قبل المستخدم على الشبكة الفرعية لنظام المجموعة.

يمكنك تكوين اتصال الدخول إلى نظام المجموعة باستخدام وحدة تحكم الدخول، مثل Nginx أو توجيه تطبيق HTTP. لا يمكنك تكوين اتصال الدخول باستخدام Azure App Gateway. للحصول على التفاصيل، راجع القيود مع تراكب Azure CNI.

الاختلافات بين Kubenet وتراكب Azure CNI

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

المنطقة	تراكب Azure CNI	Kubenet
مقياس نظام المجموعة	5000 عقدة و250 pods/node	400 عقدة و250 جراب لكل عقدة
تكوين الشبكة	بسيط - لا توجد تكوينات إضافية مطلوبة لشبكة الجراب	معقد - يتطلب جداول التوجيه وUDRs على الشبكة الفرعية لنظام المجموعة لشبكة الجراب
أداء اتصال الجراب	الأداء على قدم المساواة مع الأجهزة الظاهرية في VNet	الوثبة الإضافية تضيف زمن انتقال
نُهج شبكة Kubernetes	نهج شبكة Azure، Calico، Cilium	Calico
الأنظمة الأساسية لنظام التشغيل المدعومة	Linux وWindows Server 2022، 2019	Linux فقط

تخطيط عنوان IP

• عقد نظام المجموعة: عند إعداد نظام مجموعة AKS، تأكد من أن الشبكات الفرعية للشبكة الظاهرية لديك لديها مساحة كافية للنمو للتحجيم المستقبلي. يمكنك تعيين كل تجمع عقدة إلى شبكة فرعية مخصصة. /24يمكن أن تتناسب الشبكة الفرعية مع ما يصل إلى 251 عقدة نظرا لأن عناوين IP الثلاثة الأولى محجوزة لمهام الإدارة.
• Pods: يقوم حل التراكب بتعيين /24 مساحة عنوان للحجيرات على كل عقدة من CIDR الخاص الذي تحدده أثناء إنشاء نظام المجموعة. حجم /24 ثابت ولا يمكن زيادته أو تصغيره. يمكنك تشغيل ما يصل إلى 250 حاوية على عقدة. عند التخطيط لمساحة عنوان الجراب، تأكد من أن CIDR الخاص كبير بما يكفي لتوفير /24 مساحات عناوين للعقد الجديدة لدعم توسيع نظام المجموعة في المستقبل.
  • عند التخطيط لمساحة عنوان IP للجرابات، ضع في اعتبارك العوامل التالية:
    • يمكن استخدام نفس مساحة جراب CIDR على مجموعات AKS مستقلة متعددة في نفس الشبكة الظاهرية.
    • يجب ألا تتداخل مساحة جراب CIDR مع نطاق الشبكة الفرعية لنظام المجموعة.
    • يجب ألا تتداخل مساحة Pod CIDR مع الشبكات المتصلة مباشرة (مثل تناظر VNet أو ExpressRoute أو VPN). إذا كانت نسبة استخدام الشبكة الخارجية تحتوي على عناوين IP المصدر في نطاق podCIDR، فإنها تحتاج إلى ترجمة إلى عنوان IP غير متداخل عبر SNAT للاتصال بالمجموعة.
• نطاق عنوان خدمة Kubernetes: يعتمد حجم عنوان الخدمة CIDR على عدد خدمات نظام المجموعة التي تخطط لإنشائها. يجب أن يكون أصغر من /12. يجب ألا يتداخل هذا النطاق مع نطاق pod CIDR ونطاق الشبكة الفرعية للمجموعة ونطاق IP المستخدم في الشبكات الظاهرية المتناظرة والشبكات المحلية.
• عنوان IP لخدمة Kubernetes DNS: يقع عنوان IP هذا ضمن نطاق عنوان خدمة Kubernetes الذي يستخدمه اكتشاف خدمة نظام المجموعة. لا تستخدم عنوان IP الأول في نطاق العناوين، حيث يتم استخدام هذا العنوان للعنوان kubernetes.default.svc.cluster.local .

مجموعات أمان الشبكة

لا يتم تغليف حركة مرور Pod to pod مع تراكب Azure CNI، ويتم تطبيق قواعد مجموعة أمان الشبكة الفرعية. إذا كانت الشبكة الفرعية NSG تحتوي على قواعد رفض من شأنها أن تؤثر على حركة مرور pod CIDR، فتأكد من وجود القواعد التالية لضمان وظائف نظام المجموعة المناسبة (بالإضافة إلى جميع متطلبات خروج AKS):

• نسبة استخدام الشبكة من العقدة CIDR إلى العقدة CIDR على جميع المنافذ والبروتوكولات
• نسبة استخدام الشبكة من العقدة CIDR إلى pod CIDR على جميع المنافذ والبروتوكولات (مطلوب لتوجيه نسبة استخدام الشبكة للخدمة)
• نسبة استخدام الشبكة من pod CIDR إلى pod CIDR على جميع المنافذ والبروتوكولات (مطلوب ل pod إلى pod وpod لخدمة نسبة استخدام الشبكة، بما في ذلك DNS)

تستخدم نسبة استخدام الشبكة من جراب إلى أي وجهة خارج كتلة pod CIDR SNAT لتعيين عنوان IP المصدر إلى IP للعقدة حيث يتم تشغيل الجراب.

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

الحد الأقصى لوحدات الجراب لكل عقدة

يمكنك تكوين الحد الأقصى لعدد القرون لكل عقدة في وقت إنشاء نظام المجموعة أو عند إضافة تجمع عقدة جديد. الإعداد الافتراضي لتراكب Azure CNI هو 250. الحد الأقصى للقيمة التي يمكنك تحديدها في تراكب Azure CNI هو 250، والحد الأدنى للقيمة هو 10. ينطبق الحد الأقصى لوحدات الجراب لكل قيمة عقدة تم تكوينها في أثناء إنشاء تجمع عقدة على العقد في تجمع العقدة هذا فقط.

اختيار نموذج شبكة المطلوب استخدامه

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

استخدم الشبكات التراكبية عندما:

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

استخدم خيار VNet التقليدي عندما:

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

القيود مع تراكب Azure CNI

يحتوي تراكب Azure CNI على القيود التالية:

• لا يمكنك استخدام Application Gateway كوحدة تحكم دخول (AGIC) لمجموعة تراكب.
• لا يمكنك استخدام بوابة التطبيق للحاويات لمجموعة تراكب.
• مجموعات توفر الجهاز الظاهري (VMAS) غير مدعومة للتراكب.
• لا يمكنك استخدام الأجهزة الظاهرية من سلسلة DCsv2 في تجمعات العقد. لتلبية متطلبات الحوسبة السرية، ضع في اعتبارك استخدام الأجهزة الظاهرية السرية من سلسلة DCasv5 أو DCadsv5 بدلا من ذلك.
• في حالة استخدام الشبكة الفرعية الخاصة بك لنشر نظام المجموعة، يجب أن تكون أسماء الشبكة الفرعية وVNET ومجموعة الموارد التي تحتوي على VNET 63 حرفا أو أقل. يأتي هذا من حقيقة أن هذه الأسماء سيتم استخدامها كتسميات في عقد عامل AKS، وبالتالي تخضع لقواعد بناء جملة تسمية Kubernetes.

إعداد مجموعات التراكب

إشعار

يجب أن يكون لديك CLI الإصدار 2.48.0 أو أحدث لاستخدام الوسيطة --network-plugin-mode . بالنسبة إلى Windows، يجب أن يكون لديك أحدث ملحق aks-preview Azure CLI مثبتا ويمكنك اتباع الإرشادات أدناه.

إنشاء نظام مجموعة باستخدام تراكب Azure CNI باستخدام az aks create الأمر . تأكد من استخدام الوسيطة --network-plugin-mode لتحديد نظام مجموعة تراكب. إذا لم يتم تحديد pod CIDR، فإن AKS تعين مساحة افتراضية: viz. 10.244.0.0/16.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --pod-cidr 192.168.0.0/16 \
    --generate-ssh-keys

إضافة nodepool جديد إلى شبكة فرعية مخصصة

بعد إنشاء نظام مجموعة باستخدام تراكب Azure CNI، يمكنك إنشاء nodepool آخر وتعيين العقد إلى شبكة فرعية جديدة لنفس الشبكة الظاهرية. يمكن أن يكون هذا الأسلوب مفيدا إذا كنت تريد التحكم في إدخال أو خروج عناوين IP للمضيف من/ نحو الأهداف في نفس VNET أو الشبكات الظاهرية النظيرة.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"
nodepoolName="newpool1"
subscriptionId=$(az account show --query id -o tsv)
vnetName="yourVnetName"
subnetName="yourNewSubnetName"
subnetResourceId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnetName/subnets/$subnetName"
az aks nodepool add --resource-group $resourceGroup --cluster-name $clusterName \
  --name $nodepoolName --node-count 1 \
  --mode system --vnet-subnet-id $subnetResourceId

ترقية نظام مجموعة موجود إلى تراكب CNI

إشعار

يمكنك تحديث مجموعة Azure CNI موجودة إلى تراكب إذا كانت المجموعة تفي بالمعايير التالية:

• نظام المجموعة على Kubernetes الإصدار 1.22+.
• لا يستخدم ميزة تخصيص IP للجراب الديناميكي.
• لم يتم تمكين نهج الشبكة. يمكن إلغاء تثبيت مشغل نهج الشبكة قبل الترقية، راجع إلغاء تثبيت Azure Network Policy Manager أو Calico
• لا يستخدم أي تجمعات عقد Windows مع docker كوقت تشغيل الحاوية.

إشعار

ترقية نظام مجموعة موجود إلى تراكب CNI عملية غير قابلة للعكس.

تحذير

قبل إصدار نظام التشغيل Windows 20348.1668، كان هناك قيود حول مجموعات تراكب Windows بشكل غير صحيح لحزم SNATing من جرابات شبكة المضيف، مما كان له تأثير أكثر ضررا على المجموعات التي تقوم بالترقية إلى التراكب. لتجنب هذه المشكلة، استخدم Windows OS Build أكبر من أو يساوي 20348.1668.

تحذير

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

تؤدي عملية الترقية إلى تشغيل كل تجمع عقدة لإعادة تصويرها في وقت واحد. ترقية كل تجمع عقدة بشكل منفصل إلى تراكب غير مدعوم. أي اضطرابات في شبكة نظام المجموعة مشابهة لترقية صورة العقدة أو ترقية إصدار Kubernetes حيث تتم إعادة تصوير كل عقدة في تجمع عقدة.

ترقية نظام مجموعة Azure CNI

تحديث مجموعة Azure CNI موجودة لاستخدام التراكب باستخدام az aks update الأمر .

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin-mode overlay \
--pod-cidr 192.168.0.0/16

--pod-cidr المعلمة مطلوبة عند الترقية من CNI القديمة لأن الحجيرات تحتاج إلى الحصول على عناوين IP من مساحة تراكب جديدة، والتي لا تتداخل مع الشبكة الفرعية للعقدة الموجودة. لا يمكن أن يتداخل pod CIDR أيضا مع أي عنوان VNet لتجمعات العقدة. على سبيل المثال، إذا كان عنوان VNet هو 10.0.0.0/8، وكانت العقد الخاصة بك في الشبكة الفرعية 10.240.0.0/16، --pod-cidr فلا يمكن أن تتداخل مع 10.0.0.0/8 أو CIDR الخدمة الموجودة على نظام المجموعة.

ترقية نظام مجموعة Kubenet

تحديث مجموعة Kubenet موجودة لاستخدام تراكب Azure CNI باستخدام az aks update الأمر .

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin azure \
--network-plugin-mode overlay 

نظرا لأن نظام المجموعة يستخدم بالفعل CIDR خاصا للقرون التي لا تتداخل مع مساحة IP VNet، فلن تحتاج إلى تحديد المعلمة --pod-cidr وسيظل Pod CIDR كما هو إذا لم يتم استخدام المعلمة.

إشعار

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

الشبكات ذات المكدس المزدوج

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

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

• يجب أن يكون لديك Azure CLI 2.48.0 أو أحدث مثبتا.
• Kubernetes الإصدار 1.26.3 أو أحدث.

القيود

الميزات التالية غير مدعومة مع الشبكات ذات المكدس المزدوج:

• نُهج شبكة Azure
• نُهج شبكة Calico
• بوابة NAT
• المكون الإضافي للعقد الظاهرية

نشر نظام مجموعة AKS مزدوج المكدس

يتم توفير السمات التالية لدعم مجموعات المكدس المزدوج:

• --ip-families: يأخذ قائمة مفصولة بفواصل من عائلات IP لتمكينها على نظام المجموعة.
  • فقط ipv4 أو ipv4,ipv6 معتمد.
• --pod-cidrs: يأخذ قائمة مفصولة بفواصل لنطاقات IP لعلامات CIDR لتعيين عناوين IP للجراب منها.
  • يجب أن يتطابق عدد النطاقات وترتيبها في هذه القائمة مع القيمة المقدمة إلى --ip-families.
  • إذا لم يتم توفير أي قيم، يتم استخدام القيمة 10.244.0.0/16,fd12:3456:789a::/64 الافتراضية.
• --service-cidrs: يأخذ قائمة مفصولة بفواصل لنطاقات IP لعلامات CIDR لتعيين عناوين IP للخدمة منها.
  • يجب أن يتطابق عدد النطاقات وترتيبها في هذه القائمة مع القيمة المقدمة إلى --ip-families.
  • إذا لم يتم توفير أي قيم، يتم استخدام القيمة 10.0.0.0/16,fd12:3456:789a:1::/108 الافتراضية.
  • لا يمكن أن تكون الشبكة الفرعية IPv6 المعينة إلى --service-cidrs أكبر من /108.

إنشاء نظام مجموعة AKS مزدوج المكدس

1. إنشاء مجموعة موارد Azure للمجموعة باستخدام الأمر [az group create][az-group-create].

   az group create --location <region> --name <resourceGroupName>
   

2. إنشاء نظام مجموعة AKS مزدوج المكدس باستخدام az aks create الأمر مع تعيين المعلمة --ip-families إلى ipv4,ipv6.

   az aks create \
       --location <region> \
       --resource-group <resourceGroupName> \
       --name <clusterName> \
       --network-plugin azure \
       --network-plugin-mode overlay \
       --ip-families ipv4,ipv6 \
       --generate-ssh-keys
   

إنشاء مثال لحمل العمل

بمجرد إنشاء نظام المجموعة، يمكنك نشر أحمال العمل الخاصة بك. ترشدك هذه المقالة عبر مثال لنشر حمل العمل لخادم ويب NGINX.

نشر خادم ويب NGINX

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

كشف حمل العمل عبر LoadBalancer خدمة النوع

هام

هناك حاليا قيدان يتعلقان بخدمات IPv6 في AKS.

• يرسل Azure Load Balancer تحقيقات السلامة إلى وجهات IPv6 من عنوان ارتباط محلي. في تجمعات عقدة Azure Linux، لا يمكن توجيه حركة المرور هذه إلى جراب، لذا فإن نسبة استخدام الشبكة المتدفقة إلى خدمات IPv6 الموزعة مع externalTrafficPolicy: Cluster فشل. يجب نشر خدمات IPv6 مع externalTrafficPolicy: Local، مما يؤدي kube-proxy إلى الاستجابة للتحقيق على العقدة.
• قبل الإصدار 1.27 من Kubernetes، سيتم توفير عنوان IP الأول فقط للخدمة إلى موازن التحميل، لذلك تتلقى الخدمة ذات المكدس المزدوج عنوان IP عاما فقط لعائلة IP المدرجة الأولى. لتوفير خدمة مزدوجة المكدس لنشر واحد، يرجى إنشاء خدمتين تستهدفان نفس المحدد، واحدة ل IPv4 والأخرى ل IPv6. لم يعد هذا قيدا في kubernetes 1.27 أو أحدث.

kubectl

1. كشف نشر NGINX باستخدام kubectl expose deployment nginx الأمر .

   kubectl expose deployment nginx --name=nginx-ipv4 --port=80 --type=LoadBalancer'
   kubectl expose deployment nginx --name=nginx-ipv6 --port=80 --type=LoadBalancer --overrides='{"spec":{"ipFamilies": ["IPv6"]}}'
   

   تتلقى إخراجا يظهر أن الخدمات قد تم كشفها.

   service/nginx-ipv4 exposed
   service/nginx-ipv6 exposed
   

2. بمجرد الكشف عن النشر وتوفير LoadBalancer الخدمات بالكامل، احصل على عناوين IP للخدمات باستخدام kubectl get services الأمر .

   kubectl get services
   

   NAME         TYPE           CLUSTER-IP               EXTERNAL-IP         PORT(S)        AGE
   nginx-ipv4   LoadBalancer   10.0.88.78               20.46.24.24         80:30652/TCP   97s
   nginx-ipv6   LoadBalancer   fd12:3456:789a:1::981a   2603:1030:8:5::2d   80:32002/TCP   63s
   

3. تحقق من الوظيفة عبر طلب ويب سطر الأوامر من مضيف IPv6 قادر. Azure Cloud Shell غير قادر على IPv6.

   SERVICE_IP=$(kubectl get services nginx-ipv6 -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
   curl -s "http://[${SERVICE_IP}]" | head -n5
   

   <!DOCTYPE html>
   <html>
   <head>
   <title>Welcome to nginx!</title>
   <style>
   

YAML

1. كشف نشر NGINX باستخدام بيان YAML التالي.

   ---
   apiVersion: v1
   kind: Service
   metadata:
     labels:
       app: nginx
     name: nginx-ipv4
   spec:
     externalTrafficPolicy: Cluster
     ports:
    - port: 80
       protocol: TCP
       targetPort: 80
     selector:
       app: nginx
     type: LoadBalancer
   ---
   apiVersion: v1
   kind: Service
   metadata:
     labels:
       app: nginx
     name: nginx-ipv6
   spec:
     externalTrafficPolicy: Cluster
     ipFamilies:
    - IPv6
     ports:
    - port: 80
       protocol: TCP
       targetPort: 80
     selector:
       app: nginx
     type: LoadBalancer
   

2. بمجرد الكشف عن النشر وتوفير LoadBalancer الخدمات بالكامل، احصل على عناوين IP للخدمات باستخدام kubectl get services الأمر .

   kubectl get services
   

   NAME         TYPE           CLUSTER-IP               EXTERNAL-IP         PORT(S)        AGE
   nginx-ipv4   LoadBalancer   10.0.88.78               20.46.24.24         80:30652/TCP   97s
   nginx-ipv6   LoadBalancer   fd12:3456:789a:1::981a   2603:1030:8:5::2d   80:32002/TCP   63s
   

الشبكات ذات المكدس المزدوج مع Azure CNI المشغل بواسطة Cilium - (معاينة)

يمكنك نشر مجموعات AKS مزدوجة المكدس باستخدام Azure CNI المشغل بواسطة Cilium. يسمح لك هذا أيضا بالتحكم في حركة مرور IPv6 باستخدام محرك نهج شبكة Cilium.

هام

تتوفر ميزات معاينة AKS على أساس الخدمة الذاتية والاشتراك. يتم توفير المعاينات "كما هي" و"كما هي متوفرة"، ويتم استبعادها من اتفاقيات مستوى الخدمة والضمان المحدود. تتم تغطية معاينات AKS جزئيًا بواسطة دعم العملاء على أساس بذل أفضل الجهود. على هذا النحو، هذه الميزات ليست مخصصة للاستخدام الإنتاجي. لمزيد من المعلومات، يُرجي الاطلاع على مقالات الدعم الآتية:

• نُهج دعم AKS
• الأسئلة الشائعة حول دعم Azure

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

• يجب أن يكون لديك أحدث إصدار من ملحق معاينة AKS.
• يجب أن يكون لديك Kubernetes الإصدار 1.29 أو أحدث.

تثبيت ملحق aks-preview Azure CLI

• تثبيت ملحق aks-preview باستخدام az extension add الأمر .

  az extension add --name aks-preview
  

• التحديث إلى أحدث إصدار من الملحق الذي تم إصداره باستخدام az extension update الأمر .

  az extension update --name aks-preview
  

تسجيل علامة ميزة "AzureOverlayDualStackPreview"

1. تسجيل علامة الميزة AzureOverlayDualStackPreview باستخدام az feature register الأمر .

   az feature register --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"
   

   يستغرق الأمر بضع دقائق حتى تظهر الحالة مُسجل.

2. تحقق من حالة التسجيل باستخدام az feature show الأمر :

   az feature show --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"
   

3. عندما تعكس الحالة Registered، قم بتحديث تسجيل موفر موارد Microsoft.ContainerService باستخدام az provider register الأمر .

   az provider register --namespace Microsoft.ContainerService
   

إعداد مجموعات التراكب باستخدام Azure CNI المشغل بواسطة Cilium

إنشاء نظام مجموعة باستخدام تراكب Azure CNI باستخدام az aks create الأمر . تأكد من استخدام الوسيطة --network-dataplane cilium لتحديد مخطط بيانات Cilium.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --ip-families ipv4,ipv6 \
    --generate-ssh-keys\

لمزيد من المعلومات حول Azure CNI المشغل بواسطة Cilium، راجع Azure CNI المشغل بواسطة Cilium.

تجمعات عقد Windows للشبكات مزدوجة المكدس - (معاينة)

يمكنك نشر مجموعات AKS مزدوجة المكدس باستخدام مجمعات عقد Windows.

هام

تتوفر ميزات معاينة AKS على أساس الخدمة الذاتية والاشتراك. يتم توفير المعاينات "كما هي" و"كما هي متوفرة"، ويتم استبعادها من اتفاقيات مستوى الخدمة والضمان المحدود. تتم تغطية معاينات AKS جزئيًا بواسطة دعم العملاء على أساس بذل أفضل الجهود. على هذا النحو، هذه الميزات ليست مخصصة للاستخدام الإنتاجي. لمزيد من المعلومات، يُرجي الاطلاع على مقالات الدعم الآتية:

• نُهج دعم AKS
• الأسئلة الشائعة حول دعم Azure

تثبيت ملحق aks-preview Azure CLI

• تثبيت ملحق aks-preview باستخدام az extension add الأمر .

  az extension add --name aks-preview
  

• التحديث إلى أحدث إصدار من الملحق الذي تم إصداره باستخدام az extension update الأمر .

  az extension update --name aks-preview
  

تسجيل علامة ميزة "AzureOverlayDualStackPreview"

1. تسجيل علامة الميزة AzureOverlayDualStackPreview باستخدام az feature register الأمر .

   az feature register --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"
   

   يستغرق الأمر بضع دقائق حتى تظهر الحالة مُسجل.

2. تحقق من حالة التسجيل باستخدام az feature show الأمر :

   az feature show --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"
   

3. عندما تعكس الحالة Registered، قم بتحديث تسجيل موفر موارد Microsoft.ContainerService باستخدام az provider register الأمر .

   az provider register --namespace Microsoft.ContainerService
   

إعداد نظام مجموعة تراكب

إنشاء نظام مجموعة باستخدام تراكب Azure CNI باستخدام az aks create الأمر .

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --ip-families ipv4,ipv6 \
    --generate-ssh-keys\

إضافة عقدة Windows إلى نظام المجموعة

أضف windows nodepool إلى نظام المجموعة باستخدام الأمر [az aks nodepool add][az-aks-nodepool-add].

az aks nodepool add \
    --resource-group $resourceGroup \
    --cluster-name $clusterName \
    --os-type Windows \
    --name winpool1 \
    --node-count 2

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

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