نظرة عامة على تكوينات الشبكات للتوفير التلقائي للعقدة (NAP) في خدمة Azure Kubernetes (AKS)

توفر هذه المقالة نظرة عامة على متطلبات تكوين الشبكات وتوصياتها لمجموعات خدمة Azure Kubernetes ‏(AKS) باستخدام التوفير التلقائي للعقدة (NAP). وهو يغطي التكوينات المدعومة وسلوك الشبكة الفرعية الافتراضي وإعداد التحكم في الوصول المستند إلى الدور (RBAC) واعتبارات التوجيه بين المجالات (CIDR) بدون فئة.

للحصول على نظرة عامة على التوفير التلقائي للعقدة في AKS، راجع نظرة عامة على التوفير التلقائي للعقدة (NAP) في خدمة Azure Kubernetes ‏(AKS).

تكوينات الشبكات المدعومة ل NAP

عند تقييم دعم الشبكات ل NAP، ضع في اعتبارك وضع إدارة عناوين IP (IPAM) والمكون الإضافي للشبكة و مستوى بيانات الشبكة ونهج الشبكة. يصف الجدول التالي الخيارات التي يدعمها NAP:

طبقة التكوين	خيار	دعم NAP
IPAM	تراكب Azure CNI	مدعوم
IPAM	الشبكة الفرعية Azure CNI Node	مدعوم
IPAM	Azure الشبكة الفرعية CNI Pod مع تخصيص IP الديناميكي	غير مدعوم
المكون الإضافي للشبكة	Kubenet	غير مدعوم
مستوى البيانات	Azure CNI المشغل بواسطة Cilium	مدعوم مع وضع IPAM Azure CNI معتمد
نهج الشبكة	كاليكو	غير مدعوم

استخدم Azure تراكب CNI مع Azure CNI المشغل بواسطة وحدة بيانات Cilium. يوفر Cilium إمكانات شبكات متقدمة ويتم تحسينه للأداء باستخدام NAP.

تكوينات الشبكة الفرعية ل NAP

تعيين الحقل الاختياري vnetSubnetID في AKSNodeClass مورد لتكوين الشبكة الفرعية المخصصة التي يستخدمها Karpenter لتوفير عقد NAP. إذا لم تحدد vnetSubnetID، يستخدم Karpenter الشبكة الفرعية الافتراضية التي تم تكوينها أثناء التثبيت، وهي عادة الشبكة الفرعية المحددة بواسطة المعلمة --vnet-subnet-id عند إنشاء نظام مجموعة AKS.

تقوم NAP تلقائيا بنشر وتكوين وإدارة Karpenter على نظام مجموعة AKS الخاص بك، ويستند إلى مشاريع Karpenterوموفر AKS Karpenter مفتوحة المصدر.

AKSNodeClass يمكن أن تحدد كل من الموارد الموجودة على نظام مجموعة AKS الخاص بك تكوينات مختلفة vnetSubnetID، والتي تمكن تكوينات الشبكة الفرعية المختلطة عبر تجمعات العقد. تستخدم فئات العقدة التي لا تحدد vnetSubnetID تكوين الشبكة الفرعية الافتراضي لنظام المجموعة.

سلوك انحراف الشبكة الفرعية

يراقب Karpenter تغييرات تكوين الشبكة الفرعية ويكتشف الانجراف عند vnetSubnetID تعديل in AKSNodeClass . يعد فهم هذا السلوك أمرا بالغ الأهمية عند إدارة تكوينات الشبكات المخصصة.

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

قبل تغيير vnetSubnetID، تأكد من أن هوية نظام المجموعة لديها الأذونات المطلوبة على الشبكة الفرعية الجديدة وأن الشبكة الفرعية لديها ما يكفي من عناوين IP المتاحة لعقد الاستبدال. يمكن أن تؤدي ميزانيات تعطيل الجراب والتعليقات karpenter.sh/do-not-disrupt التوضيحية إلى تأخير الاستبدال الطوعي للانحراف.

Important

لا تدعم الشبكات الظاهرية المدارة بواسطة AKS الشبكات الفرعية المخصصة. استخدم vnetSubnetID فقط مع شبكة ظاهرية مخصصة تديرها.

نطاقات CIDR لمجموعة AKS ل NAP

عند تكوين شبكة مخصصة باستخدام vnetSubnetID، تحتاج إلى فهم نطاقات CIDR الخاصة بمؤسستك وإدارتها لتجنب تعارضات الشبكة. على عكس تجمعات عقد AKS التقليدية التي تقوم بإنشائها من خلال قوالب Azure Resource Manager (ARM)، يطبق Karpenter تعريفات الموارد المخصصة (CRDs) التي توفر العقد على الفور دون التحقق الموسع الذي يوفره ARM.

اعتبارات CIDR لتكوينات الشبكة الفرعية المخصصة ل NAP

عند التكوين vnetSubnetID، يجب عليك:

• التحقق من توافق CIDR: تأكد من أن الشبكات الفرعية المخصصة لا تتعارض مع نطاقات CIDR الحالية.
• سعة IP للخطة: احسب عناوين IP المطلوبة للتوسع المتوقع.
• التحقق من صحة الاتصال: اختبار مسارات الشبكة وقواعد مجموعة الأمان.
• مراقبة الاستخدام: تتبع استخدام الشبكة الفرعية والتخطيط للنمو.
• تكوين المستند: الاحتفاظ بسجلات قرارات تصميم الشبكة.

النزاعات الشائعة في CIDR

كن على دراية بسيناريوهات تعارض CIDR الشائعة التالية عند استخدام الشبكات الفرعية المخصصة مع NAP:

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

# Example conflict scenarios:
# Cluster Pod CIDR: 10.244.0.0/16  
# Custom Subnet:   10.244.1.0/24  ❌ CONFLICT

# Service CIDR:    10.0.0.0/16
# Custom Subnet:   10.0.10.0/24   ❌ CONFLICT

# Safe configuration:
# Cluster Pod CIDR: 10.244.0.0/16
# Service CIDR:     10.0.0.0/16  
# Custom Subnet:    10.1.0.0/24   ✅ NO CONFLICT

إعداد RBAC لتكوينات الشبكة الفرعية المخصصة

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

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

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

الهوية المعينة من قبل النظام

CLUSTER_IDENTITY=$(az aks show \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --query identity.principalId \
  --output tsv)

الهوية التي تم تعيينها من قبل المستخدم

CLUSTER_IDENTITY=$(az identity show \
  --resource-group $IDENTITY_RESOURCE_GROUP \
  --name $IDENTITY_NAME \
  --query principalId \
  --output tsv)

هناك طريقتان رئيسيتان لإعداد هذه الأذونات: تعيين أذونات الشبكة الظاهرية الواسعة (VNet) أو تعيين أذونات الشبكة الفرعية ذات النطاق.

تعيين أذونات الشبكة الظاهرية (VNet) الواسعة

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

Important

يمنح Microsoft.Network/*دور مساهم الشبكة ، والذي يسمح لهوية نظام المجموعة بإنشاء موارد الشبكة وتعديلها وحذفها ضمن نطاق VNet المعين. راجع هذا الوصول قبل استخدام الدور في الإنتاج لأن NAP يتطلب فقط أذونات قراءة وضم الشبكة الفرعية لهذا السيناريو.

الميزات والاعتبارات

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

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

الأذونات المطلوبة

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

# Get your VNet resource ID
VNET_ID="/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME"

# Assign Network Contributor role for subnet read/join operations
az role assignment create \
  --assignee-object-id $CLUSTER_IDENTITY \
  --assignee-principal-type ServicePrincipal \
  --role "Network Contributor" \
  --scope $VNET_ID

للحصول على مثال كامل لإعداد شبكة مخصصة وتعيين أذونات شبكة ظاهرية واسعة، راجع إعداد الشبكة الظاهرية المخصصة - نموذج البرنامج النصي RBAC الأكثر تساهلا.

تعيين أذونات الشبكة الفرعية ذات النطاق

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

المزايا

يوفر تعيين أذونات الشبكة الفرعية ذات النطاق المزايا التالية:

• يتبع مبدأ الامتياز الأقل.
• يوفر التحكم في الوصول الدقيق.
• يضمن امتثالا أفضل لسياسات الأمان.

الأذونات المطلوبة

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

# For each subnet, assign specific subnet permissions
SUBNET_ID="/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME"

# Create custom role definition for subnet access
cat > subnet-access-role.json << EOF
{
  "Name": "Karpenter Subnet Access",
  "IsCustom": true,
  "Description": "Allows reading subnet information and joining VMs to subnets",
  "Actions": [
    "Microsoft.Network/virtualNetworks/subnets/read",
    "Microsoft.Network/virtualNetworks/subnets/join/action"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/<subscription-id>"
  ]
}
EOF

# Create the custom role (only needed once per subscription)
az role definition create --role-definition subnet-access-role.json

# Assign the custom role to each subnet
az role assignment create \
  --assignee-object-id $CLUSTER_IDENTITY \
  --assignee-principal-type ServicePrincipal \
  --role "Karpenter Subnet Access" \
  --scope $SUBNET_ID

للحصول على مثال كامل لإعداد الشبكات المخصصة وتعيين أذونات الشبكة الفرعية ذات النطاق، راجع نموذج البرنامج النصي لأذونات الشبكة الفرعية ذات النطاق.

مثال على تكوينات الشبكة الفرعية المخصصة

يوضح المثال التالي كيفية تكوين شبكة فرعية مخصصة لعقد NAP باستخدام vnetSubnetID الحقل في مورد AKSNodeClass :

spec.vnetSubnetID تعيين الحقل إلى معرف مورد Azure الكامل للشبكة الفرعية الهدف باستخدام التنسيق /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Network/virtualNetworks/{vnetName}/subnets/{subnetName}.

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: custom-networking
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME"

يوضح المثال التالي كيفية استخدام فئات عقد متعددة مع تكوينات شبكة فرعية مختلفة:

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: frontend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$FRONTEND_SUBNET_NAME"
---
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: backend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$BACKEND_SUBNET_NAME"

إحضار سياسة دعم CNI (BYO CNI) الخاصة بك

يسمح Karpenter for Azure بإحضار تكوينات واجهة شبكة الحاويات (BYO CNI)، ويتبع نفس نهج الدعم مثل AKS. لا يقوم BYO CNI بإجراء تكوين يسرده NAP على أنه غير مدعوم، مثل kubenet أو Calico، مدعوما. عند استخدام CNI مخصص، يكون دعم استكشاف الأخطاء وإصلاحها المتعلق بالشبكات خارج نطاق أي اتفاقيات أو ضمانات على مستوى الخدمة.

تفاصيل نطاق الدعم

يوضح ما يلي ما هو مدعوم وما لا يتم دعمه عند استخدام BYO CNI مع Karpenter:

• مدعوم: مشكلات الوظائف والتكامل الخاصة ب Karpenter عند استخدام تكوينات CNI الخاصة بك (BYO).
• غير مدعوم: مشكلات الشبكات الخاصة ب CNI أو مشكلات التكوين أو استكشاف الأخطاء وإصلاحها عند استخدام مكونات CNI الإضافية التابعة لجهات خارجية.

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

لمزيد من المعلومات حول التوفير التلقائي للعقدة في AKS، راجع المقالات التالية:

• استخدام التوفير التلقائي للعقدة في شبكة ظاهرية مخصصة
• تكوين تجمعات العقد للتوفير التلقائي للعقدة على AKS
• تكوين نهج التعطيل للتوفير التلقائي للعقدة على AKS