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

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

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

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

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

• تراكب Azure CNI
• تراكب Azure CNI مدعوم من Cilium
• Azure CNI

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

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

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

• سياسة شبكة Calico
• التخصيص الديناميكي لعنوان IP

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

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

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

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

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

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

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

فهم نطاقات توجيه Inter-Domain بدون فئات (CIDR) لنظام مجموعة AKS

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

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

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

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

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

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

# 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 المناسبة للهوية المدارة لنظام المجموعة.

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

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

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

Important

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

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

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

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

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

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

# Get your cluster's managed identity
CLUSTER_IDENTITY=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query identity.principalId -o tsv)

# 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 $CLUSTER_IDENTITY \
  --role "Network Contributor" \
  --scope $VNET_ID

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

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

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

المزايا

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

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

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

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

# Get your cluster's managed identity
CLUSTER_IDENTITY=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query identity.principalId -o tsv)

# 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 $CLUSTER_IDENTITY \
  --role "Karpenter Subnet Access" \
  --scope $SUBNET_ID

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

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

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

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: custom-networking
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$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/$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/$RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$BACKEND_SUBNET_NAME"

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

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

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

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

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

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

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

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