Enable or disable node auto-provisioning (NAP) in خدمة Azure Kubernetes ‏(AKS)

تشرح هذه المقالة كيفية تفعيل أو تعطيل التوفير التلقائي للعقد (NAP) في خدمة Azure Kubernetes ‏(AKS) باستخدام قوالب Azure CLI أو Azure Resource Manager (ARM).

إذا كنت ترغب في إنشاء مجموعة AKS ممكنة ل NAP باستخدام شبكة ظاهرية مخصصة (VNet) وشبكات فرعية، فراجع إنشاء مجموعة توفير تلقائي للعقدة (NAP) في شبكة ظاهرية مخصصة.

قبل البدء

قبل البدء، راجع مقالة نظرة عامة على التوفير التلقائي للعقدة (NAP) في AKS ، والتي توضح بالتفصيل كيفية عمل NAPوالمتطلبات الأساسيةوالقيود.

تمكين التوفير التلقائي للعقدة (NAP) على نظام مجموعة AKS

توضح الأقسام التالية كيفية تمكين NAP على مجموعة AKS جديدة أو موجودة:

Note

يمكنك تفعيل control plane metrics لرؤية السجلات والعمليات من node auto-provisioning باستخدام الخدمة المدارة Azure Monitor ل Prometheus add-on.

تمكين NAP على نظام مجموعة جديد

  • قم بتمكين التوفير التلقائي للعقدة على نظام مجموعة جديد باستخدام az aks create الأمر مع --node-provisioning-mode تعيين العلامة على Auto. يقوم الأمر التالي أيضا بتعيين إلى --network-plugin ، إلى ، وإلى azure--network-plugin-mode.overlay--network-dataplanecilium

    az aks create \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --node-provisioning-mode Auto \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --generate-ssh-keys

  1. قم بإنشاء ملف باسم nap.json وإضافة تكوين قالب ARM التالي مع properties.nodeProvisioningProfile.mode تعيين الحقل إلى Auto، مما يتيح NAP. (الإعداد الافتراضي هو Manual.)

    {
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "metadata": {},
  "parameters": {},
  "resources": [
    {
      "type": "Microsoft.ContainerService/managedClusters",
      "apiVersion": "2025-05-01",
      "sku": {
        "name": "Base",
        "tier": "Standard"
      },
      "name": "napcluster",
      "location": "uksouth",
      "identity": {
        "type": "SystemAssigned"
      },
      "properties": {
        "networkProfile": {
            "networkPlugin": "azure",
            "networkPluginMode": "overlay",
            "networkPolicy": "cilium",
            "networkDataplane":"cilium",
            "loadBalancerSku": "Standard"
        },
        "dnsPrefix": "napcluster",
        "agentPoolProfiles": [
          {
            "name": "agentpool",
            "count": 3,
            "vmSize": "standard_d2s_v3",
            "osType": "Linux",
            "mode": "System"
          }
        ],
        "nodeProvisioningProfile": {
          "mode": "Auto"
        }
      }
    }
  ]
}

  2. قم بتمكين التوفير التلقائي للعقدة على نظام مجموعة جديد باستخدام az deployment group create الأمر مع --template-file تعيين العلامة على مسار ملف قالب ARM.

    az deployment group create --resource-group $RESOURCE_GROUP --template-file ./nap.json

تمكين NAP على نظام مجموعة موجود

  • قم بتمكين التوفير التلقائي للعقدة على نظام مجموعة موجود باستخدام az aks update الأمر مع --node-provisioning-mode تعيين العلامة على Auto.

    az aks update --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --node-provisioning-mode Auto

تعطيل التوفير التلقائي للعقدة (NAP) على نظام مجموعة AKS

هام

يمكنك فقط تعطيل NAP على نظام مجموعة إذا تم استيفاء الشروط التالية:

  • لا توجد عقد NAP موجودة. يمكنك استخدام الأمر kubectl get nodes -l karpenter.sh/nodepool للتحقق من العقد المدارة بواسطة NAP الموجودة.
  • تم تعيين حقل كل Karpenter NodePools الحالي إلى spec.limits.cpu0. يمنع هذا الإجراء إنشاء عقد جديدة، ولكنه لا يعطل العقد قيد التشغيل حاليا.

  1. قم بتعيين spec.limits.cpu الحقل إلى 0 كل كاربنتر NodePoolموجود . على سبيل المثال:

    apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  limits:
    cpu: 0

    هام

    إذا كنت لا ترغب في التأكد من أن كل جراب يعمل مسبقا على عقدة NAP يتم ترحيله بأمان إلى عقدة غير NAP قبل تعطيل NAP، فيمكنك تخطي الخطوتين 2 و 3 وبدلا من ذلك استخدام kubectl delete node الأمر لكل عقدة مدارة بواسطة NAP. ومع ذلك، لا نوصي بتخطي هذه الخطوات، لأنها قد تترك بعض الكبسولات معلقة ولا تحترم ميزانيات تعطيل الجراب (PDBs).

    عند استخدام الأمر kubectl delete node ، احرص على حذف العقد المدارة بواسطة NAP فقط. يمكنك تحديد العقد المدارة بواسطة NAP باستخدام الأمر kubectl get nodes -l karpenter.sh/nodepool .

  2. أضف الوصمة karpenter.azure.com/disable:NoSchedule إلى كل كاربنتر NodePool. على سبيل المثال:

    apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      ...
      taints:
        - key: karpenter.azure.com/disable
          effect: NoSchedule

    يبدأ هذا الإجراء عملية ترحيل أحمال العمل على العقد المدارة بواسطة NAP إلى عقد غير تابعة ل NAP، مع احترام PDBs وحدود التعطيل. تنتقل القرون إلى العقد غير NAP إذا كان من الممكن أن تناسبها. إذا لم تكن هناك سعة كافية ثابتة الحجم، تبقى بعض العقد المدارة بواسطة NAP للعقدة.

  3. قم بتوسيع نطاق الحجم ManagedClusterAgentPools الثابت الحالي أو إنشاء حجم AgentPools ثابت جديد لأخذ الحمل من العقد المدارة بواسطة NAP للعقدة. عند إضافة هذه العقد إلى نظام المجموعة، يتم استنزاف العقد المدارة بواسطة NAP للعقدة، ويتم ترحيل العمل إلى العقد ذات الحجم الثابت.

  4. احذف جميع العقد المدارة بواسطة NAP باستخدام الأمر kubectl get nodes -l karpenter.sh/nodepool . إذا كانت العقد المدارة بواسطة NAP لا تزال موجودة، فمن المحتمل أن تفتقر المجموعة إلى سعة ثابتة الحجم. في هذه الحالة، يجب عليك إضافة المزيد من العقد حتى يمكن ترحيل أحمال العمل المتبقية.

  1. قم بتحديث وضع NAP إلى Manual باستخدام أمر az aks update Azure CLI مع تعيين علم --node-provisioning-mode على Manual.

    az aks update \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --node-provisioning-mode Manual

  1. قم بتحديث properties.nodeProvisioningProfile.mode الحقل إلى Manual قالب ARM الخاص بك وأعد توزيعه.

    {
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "metadata": {},
  "parameters": {},
  "resources": [
    {
      "type": "Microsoft.ContainerService/managedClusters",
      "apiVersion": "2025-05-01",
      "sku": {
        "name": "Base",
        "tier": "Standard"
      },
      "name": "napcluster",
      "location": "uksouth",
      "identity": {
        "type": "SystemAssigned"
      },
      "properties": {
        "networkProfile": {
            "networkPlugin": "azure",
            "networkPluginMode": "overlay",
            "networkPolicy": "cilium",
            "networkDataplane":"cilium",
            "loadBalancerSku": "Standard"
        },
        "dnsPrefix": "napcluster",
        "agentPoolProfiles": [
          {
            "name": "agentpool",
            "count": 3,
            "vmSize": "standard_d2s_v3",
            "osType": "Linux",
            "mode": "System"
          }
        ],
        "nodeProvisioningProfile": {
          "mode": "Manual"
        }
      }
    }
  ]
}

الانتقال من Karpenter مفتوح المصدر المستضاف ذاتيا إلى التوفير التلقائي للعقد المدارة (NAP)

إذا تم تثبيت Karpenter من مخطط Helm مصدر مفتوح ، لا يزال بإمكانك تفعيل NAP على العنقود. تفترض هذه الخطوات أن خريطة خوذة كاربنتر قد تم تركيبها.

هام

تأكد من أنك تستخدم أحدث إصدار من Karpenter قبل بدء الترحيل. NAP دائما ما يدعم أحدث إصدار.

هام

كن حذرا من إزالة CRDs الخاصة ب Karpenter عند تنفيذ هذه العملية الترحيلية. إذا تم حذف CRDs، فإنه يحذف المطالبات الأساسية من NodeClaims، مما قد يعطل أعباء عملك.

  1. لضمان عدم إزالة CRDs الخاصة بكاربنتر في الخطوة 2، قم بإزالة التسميات managed-by=Helm والتعليقات التوضيحية.:

    kubectl get crds -l app.kubernetes.io/managed-by=Helm -o name | grep karpenter.azure.com | xargs -I{} kubectl patch {} --type=json -p '
[
  {"op":"remove","path":"/metadata/annotations/meta.helm.sh~1release-name"},
  {"op":"remove","path":"/metadata/annotations/meta.helm.sh~1release-namespace"},
  {"op":"remove","path":"/metadata/labels/app.kubernetes.io~1managed-by"}
]'

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

    helm uninstall karpenter -n kube-system  # If you installed Karpenter into a different namespace than kube-system, specify that here instead of kube-system

  3. تفعيل NAP على مجموعة العناصر:

    az aks update --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --node-provisioning-mode Auto --node-provisioning-default-pools None

    هذا الأمر يعطل مجموعات العقد الافتراضية لأن لديك مجموعات NodePools موجودة وترغب في الاستمرار في استخدامها. إذا كنت ترغب في تفعيل مجموعات الإعداد التلقائي للعقد، يمكنك حذف ذلك --node-provisioning-default-pools None من الأمر az aks update .

  4. تحقق من اكتمال الترحيل: عندما az aks update يكتمل من الخطوة 3 بنجاح، يتم الترحيل. يمكنك أيضا تأكيد أن الترحيل يتم من خلال التحقق من التعليقات على CRDs الخاص ب Karpenter. يجب أن ترى:

        meta.helm.sh/release-name: aks-managed-karpenter-overlay-base
    meta.helm.sh/release-namespace: kube-system

    في هذه المرحلة، يتم تفعيل NAP ويجب أن يستأنف التوسع التلقائي.

مراقبة التوفير التلقائي للعقد

استرجاع سجلات كاربنتر والحالة

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

  1. قم بإعداد قاعدة لسجلات الموارد لدفع سجلات العقد التلقائية إلى Log Analytics باستخدام <تعليمات c0>هنا. تأكد من تحديد المربع عند node-auto-provisioning تحديد خيارات السجلات.

  2. حدد قسم Log على نظام المجموعة الخاص بك.

  3. أدخل المثال التالي في Log Analytics:

    AKSControlPlane
| where Category == "karpenter-events"

  4. عرض أحداث التوفير التلقائي للعقد على CLI:

    kubectl get events --field-selector source=karpenter-events

مقاييس التوفير التلقائي للعقد

يمكنك تفعيل control plane metrics (معاينة) لرؤية مقاييس وعمليات Karpenter المحددة من node auto-provisioning مع الخدمة المدارة Azure Monitor ل Prometheus add-on.

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

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

  • Last updated on