استخدام kubenet مع نطاقات عناوين IP الخاصة بك في خدمة Azure Kubernetes Service (AKS)

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

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

توضح هذه المقالة كيفية استخدام شبكات kubenet لإنشاء شبكة فرعية للشبكة الظاهرية بهدف استخدام نظام مجموعة AKS. لمزيد من المعلومات حول خيارات الشبكة واعتباراتها، راجع مفاهيم الشبكة لـ Kubernetes وAKS.

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

• يجب أن تسمح الشبكة الظاهرية لنظام مجموعة AKS بالاتصال بالإنترنت الصادر.
• يجب عدم إنشاء أكثر من نظام مجموعة AKS واحد في الشبكة الفرعية نفسها.
• لا يمكن لمجموعات AKS استخدام 169.254.0.0/16أو 172.30.0.0/16172.31.0.0/16أو أو 192.0.2.0/24 لنطاق عنوان خدمة Kubernetes أو نطاق عناوين الجراب أو نطاق عناوين الشبكة الظاهرية لنظام المجموعة. لا يمكن تحديث النطاق بعد إنشاء نظام المجموعة.
• يجب أن يكون لهوية نظام المجموعة المستخدمة من قبل مجموعة AKS على الأقل دور مساهم الشبكة على الشبكة الفرعية داخل الشبكة الظاهرية. يساعد CLI في تعيين تعيين الدور تلقائيا. إذا كنت تستخدم قالب ARM أو عملاء آخرين، فأنت بحاجة إلى تعيين تعيين الدور يدويا. يجب أن تكون لديك أيضًا الأذونات المناسبة، مثل مالك الاشتراك، لإنشاء هوية نظام مجموعة وتعيين أذونات لها. إذا كنت تريد تعريف دور مخصص بدلا من استخدام دور مساهم الشبكة المضمن، فستحتاج إلى الأذونات التالية:
  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

تحذير

لاستخدام تجمعات عُقَد Windows Server، يجب استخدام Azure CNI. نموذج شبكة kubenet غير متوفر لحاويات Windows Server.

قبل البدء

تحتاج إلى تثبيت الإصدار 2.0.65 من Azure CLI أو إصدار أحدث وتكوينه. قم بتشغيل az --version للعثور على الإصدار. إذا كنت بحاجة إلى التثبيت أو الترقية، فراجع تثبيت Azure CLI.

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

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

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

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

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

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

• يلزم توفر نقلة في تصميم kubenet، الذي يضيف زمن انتقال طفيف لاتصال الفرع.
• يجب استخدام الجداول المسار والمسارات المعرفة من قبل المستخدم، مما يضيف تعقيدًا إلى العمليات.
  • لمزيد من المعلومات، راجع تخصيص خروج نظام المجموعة باستخدام جدول توجيه معرف من قبل المستخدم في AKS وتخصيص خروج نظام المجموعة مع الأنواع الصادرة في AKS.
• التعامل المباشر مع الأفرع غير مدعوم لـ kubenet بسبب تصميمه.
• على عكس مجموعات Azure CNI، لا يمكن لمجموعات kubenet متعددة المشاركة في شبكة فرعية.
• لا تُطبق AKS مجموعات أمان الشبكة (NSGs) على شبكتها الفرعية ولا تعدل أيّاً من مجموعات أمان الشبكة المرتبطة بتلك الشبكة الفرعية. إذا قمت بتوفير الشبكة الفرعية الخاصة بك وإضافة "مجموعات أمان الشبكة" المرتبطة بتلك الشبكة الفرعية، يجب التأكد من أن قواعد الأمان في "مجموعات الأمان الوطنية" تسمح بحركة نقل البيانات بين العقدة وحاوية CIDR. لمزيد من التفاصيل، راجِع مجموعات أمان الشبكة.
• تتضمن الميزات غير المدعومة على kubenet ما يلي:
  • نُهج شبكة Azure
  • تجمعات عقدة Windows
  • المكون الإضافي للعقد الظاهرية

إشعار

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

إشعار

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

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

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

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

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

استخدم kubenet عندما:

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

استخدم Azure CNI عندما:

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

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

إنشاء شبكة ظاهرية وشبكة فرعية

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

   az group create --name myResourceGroup --location eastus
   

2. إذا لم يكن لديك شبكة ظاهرية وشبكة فرعية موجودة لاستخدامها، قم بإنشاء موارد الشبكة هذه باستخدام az network vnet create الأمر . ينشئ الأمر المثال التالي شبكة ظاهرية تسمى myAKSVnet مع بادئة العنوان 192.168.0.0/16 وشبكة فرعية تسمى myAKSSubnet مع بادئة العنوان 192.168.1.0/24:

   az network vnet create \
       --resource-group myResourceGroup \
       --name myAKSVnet \
       --address-prefixes 192.168.0.0/16 \
       --subnet-name myAKSSubnet \
       --subnet-prefix 192.168.1.0/24 \
       --location eastus
   

3. احصل على معرف مورد الشبكة الفرعية az network vnet subnet show باستخدام الأمر وقم بتخزينه كمتغير يسمى SUBNET_ID للاستخدام لاحقا.

   SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)
   

إنشاء نظام مجموعة AKS في الشبكة الظاهرية

قم بإنشاء مجموعة AKS بهويات مُدارة مخصصة من قبل النظام

إشعار

عند استخدام الهوية المعينة من قبل النظام، يمنح Azure CLI دور مساهم الشبكة إلى الهوية المعينة من قبل النظام بعد إنشاء نظام المجموعة. إذا كنت تستخدم قالب ARM أو عملاء آخرين، فأنت بحاجة إلى استخدام الهوية المدارة المعينة من قبل المستخدم بدلا من ذلك.

• إنشاء نظام مجموعة AKS مع الهويات المدارة المعينة من قبل النظام باستخدام az aks create الأمر .

  az aks create \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --network-plugin kubenet \
      --service-cidr 10.0.0.0/16 \
      --dns-service-ip 10.0.0.10 \
      --pod-cidr 10.244.0.0/16 \
      --vnet-subnet-id $SUBNET_ID \
      --generate-ssh-keys 
  

  معلمات التوزيع:

  • --service-cidr اختياري. يستخدم هذا العنوان لتعيين خدمات داخلية في نظام مجموعة AKS عنوان IP. يجب أن يكون نطاق عناوين IP هذا عبارة عن مساحة عنوان غير مستخدمة في أي مكان آخر في بيئة الشبكة الخاصة بك، بما في ذلك أي نطاقات شبكة محلية، وذلك في حال اتصالك أو التخطيط للاتصال بشبكات Azure الظاهرية باستخدام Express Route أو اتصال Site-to-Site VPN. القيمة الافتراضية هي 10.0.0.0/16.
  • --dns-service-ip اختياري. يجب أن يكون العنوان هو عنوان .10 لنطاق عنوان IP للخدمة. القيمة الافتراضية هي 10.0.0.10.
  • --pod-cidr اختياري. يجب أن يكون هذا العنوان مساحة عنوان كبيرة غير مستخدمة في أي مكان آخر في بيئة الشبكة. يتضمن هذا النطاق أي نطاقات شبكة محلية في حال اتصالك أو التخطيط للاتصال بشبكات Azure الظاهرية باستخدام Express Route أو اتصال Site-to-Site VPN. القيمة الافتراضية هي 10.244.0.0/16.
    • يجب أن يكون نطاق العنوان هذا كبيرًا بما يكفي لاستيعاب عدد العُقَد التي تتوقع تغيير حجم نطاقها إليها. لا يمكنك تغيير نطاق العنوان هذا بمجرد نشر نظام المجموعة.
    • يتم استخدام نطاق عناوين IP الخاصة بالحاويات لتعيين مساحة عنوان /24 لكل عقدة في نظام المجموعة. في المثال التالي، يقوم --pod-cidr من 10.244.0.0/16 بتعيين العقدة الأولى 10.244.0.0/24 والعقدة الثانية 10.244.1.0/24 والعقدة الثالثة 10.244.2.0/24.
    • مع تغيير حجم نظام المجموعة أو ترقيته، يستمر النظام الأساسي Azure في تعيين نطاق عناوين IP الخاص بالحاوية لكل عقدة جديدة.

إنشاء نظام مجموعة AKS مع هوية مدارة معينة من قبل المستخدم

إنشاء هوية مدارة

• إنشاء هوية مدارة az identity باستخدام الأمر . إذا كانت لديك هوية مدارة موجودة، فابحث عن المعرف الأساسي باستخدام az identity show --ids <identity-resource-id> الأمر بدلا من ذلك.

  az identity create --name myIdentity --resource-group myResourceGroup
  

  يجب أن يشبه الإخراج الخاص بك إخراج المثال التالي:

  {                                  
    "clientId": "<client-id>",
    "clientSecretUrl": "<clientSecretUrl>",
    "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
    "location": "westus2",
    "name": "myIdentity",
    "principalId": "<principal-id>",
    "resourceGroup": "myResourceGroup",                       
    "tags": {},
    "tenantId": "<tenant-id>",
    "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
  }
  

إضافة تعيين دور للهوية المدارة

إذا كنت تستخدم Azure CLI، تتم إضافة الدور تلقائيا ويمكنك تخطي هذه الخطوة. إذا كنت تستخدم قالب ARM أو عملاء آخرين، فأنت بحاجة إلى استخدام المعرف الأساسي للهوية المدارة لنظام المجموعة لتنفيذ تعيين دور.

• احصل على معرف مورد الشبكة الظاهرية باستخدام الأمر وقم بتخزينه az network vnet show كمتغير يسمى VNET_ID.

  VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)
  

• تعيين الهوية المدارة لأذونات مساهم شبكة نظام مجموعة AKS على الشبكة الظاهرية az role assignment create باستخدام الأمر وتوفير <principalId>.

  az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"
  
  # Example command
  az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"
  

إشعار

قد يستغرق الإذن الممنوح للهوية المُدارة للمجموعة الخاصة بك والمستخدمة بواسطة Azure 60 دقيقة لملء.

إنشاء نظام مجموعة AKS

• إنشاء نظام مجموعة AKS باستخدام az aks create الأمر وتوفير معرف مورد الهوية المدارة لمستوى التحكم للوسيطة assign-identity لتعيين الهوية المدارة المعينة من قبل المستخدم.

  az aks create \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --node-count 3 \
      --network-plugin kubenet \
      --vnet-subnet-id $SUBNET_ID \
      --assign-identity <identity-resource-id> \
      --generate-ssh-keys
  

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

الحصول على الشبكة الفرعية الخاصة بك وجدول التوجيه مع kubenet

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

تحذير

يمكنك إضافة/تحديث القواعد المخصصة على جدول التوجيه المخصص. ومع ذلك، تتم إضافة القواعد بواسطة موفر سحابة Kubernetes التي لا يمكن تحديثها أو إزالتها. يجب أن توجد قواعد مثل 0.0.0.0/0 دائما على جدول توجيه معين وتعيين هدف بوابة الإنترنت الخاصة بك، مثل NVA أو بوابة الخروج الأخرى. كن حذرا عند تحديث القواعد.

تعرف على المزيد من المعلومات حول إعداد جدول توجيه مخصص.

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

• يجب ربط جدول توجيه مخصص بالشبكة الفرعية قبل إنشاء نظام مجموعة AKS.
• لا يمكن تحديث مورد جدول التوجيه المقترن بعد إنشاء نظام المجموعة. ومع ذلك، يمكن تعديل القواعد المخصصة على جدول التوجيه.
• يجب أن تستخدم جميع أنظمة مجموعة AKS جدول توجيه فريد واحد لجميع الشبكات الفرعية المرتبطة بنظام المجموعة. لا يمكنك إعادة استخدام جدول توجيه مع مجموعات متعددة نظرا لامكانية تداخل CIDRs للحجيرة وقواعد التوجيه المتعارضة.
• بالنسبة للهوية المدارة المعينة من قبل النظام، يتم دعمها فقط لتوفير الشبكة الفرعية وجدول التوجيه الخاص بك عبر Azure CLI لأن Azure CLI يضيف تعيين الدور تلقائيا. إذا كنت تستخدم قالب ARM أو عملاء آخرين، فيجب عليك استخدام هوية مدارة معينة من قبل المستخدم، وتعيين أذونات قبل إنشاء نظام المجموعة، والتأكد من أن الهوية المعينة من قبل المستخدم لديها أذونات كتابة إلى الشبكة الفرعية المخصصة وجدول التوجيه المخصص.
• لا يتم دعم إمكانية استخدام جدول التوجيه نفسه مع عدة أنظمة مجموعات AKS.

إشعار

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

يتم دعم كل من الهويات المدارة المعينة من قبل النظام والمخصصة من قبل المستخدم عند إنشاء واستخدام VNet الخاص بك وجدول التوجيه مع المكون الإضافي لشبكة Azure. نوصي بشدة باستخدام هوية مدارة يعينها المستخدم لسيناريوهات BYO.

إضافة جدول توجيه مع هوية مدارة معينة من قبل المستخدم إلى نظام مجموعة AKS

بعد إنشاء جدول توجيه مخصص وربطه بشبكة فرعية في شبكتك الظاهرية، يمكنك إنشاء مجموعة AKS جديدة تحدد جدول التوجيه الخاص بك بهوية مدارة معينة من قبل المستخدم. تحتاج إلى استخدام معرّف الشبكة الفرعية للمكان الذي تخطط لنشر نظام مجموعة AKS فيه. يجب ربط هذه الشبكة الفرعية بجدول التوجيه المخصص.

1. احصل على معرف الشبكة الفرعية az network vnet subnet list باستخدام الأمر .

   az network vnet subnet list --resource-group myResourceGroup --vnet-name myAKSVnet [--subscription]
   

2. إنشاء نظام مجموعة AKS مع شبكة فرعية مخصصة تم تكوينها مسبقا مع جدول توجيه باستخدام az aks create الأمر وتوفير القيم الخاصة بك للمعلمات --vnet-subnet-id--enable-managed-identityو و--assign-identity.

   az aks create \
       --resource-group myResourceGroup \
       --name myManagedCluster \
       --vnet-subnet-id mySubnetIDResourceID \
       --enable-managed-identity \
       --assign-identity controlPlaneIdentityResourceID \
       --generate-ssh-keys
   

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

توضح لك هذه المقالة كيفية نشر نظام مجموعة AKS في الشبكة الفرعية للشبكة الظاهرية الموجودة. الآن، يمكنك البدء في إنشاء تطبيقات جديدة باستخدام Helm أو نشر التطبيقات الموجودة باستخدام Helm.