Udostępnij przez

Włączanie lub wyłączanie automatycznej aprowizacji węzłów (NAP) w usłudze Azure Kubernetes Service (AKS)

W tym artykule wyjaśniono, jak włączyć lub wyłączyć automatyczne aprowizowanie węzłów (NAP) w usłudze Azure Kubernetes Service (AKS) przy użyciu interfejsu wiersza polecenia platformy Azure lub szablonów usługi Azure Resource Manager (ARM).

Jeśli chcesz utworzyć klaster AKS z mechanizmem automatycznego aprowizowania węzłów (NAP) oraz niestandardową siecią wirtualną (VNet) i podsieciami, zobacz Tworzenie klastra z automatycznym aprowizowaniem węzłów w niestandardowej sieci wirtualnej.

Zanim rozpoczniesz

Przed rozpoczęciem zapoznaj się z artykułem Omówienie automatycznej aprowizacji węzłów (NAP) w AKS, który zawiera szczegółowe informacje na temat działania NAP, wymagań wstępnych i ograniczeń.

Włącz automatyczne aprovisionowanie węzłów (NAP) w klastrze usługi AKS

W poniższych sekcjach opisano sposób włączania ochrony dostępu do sieci (NAP) w nowym lub istniejącym klastrze AKS.

Uwaga / Notatka

Metryki płaszczyzny sterowania umożliwiają wyświetlanie dzienników i operacji z automatycznego aprowizowania węzła za pomocą usługi zarządzanej Azure Monitor dla dodatku Prometheus.

Włącz NAP w nowym klastrze

  • Włącz automatyczne aprowizowanie węzłów w nowym klastrze przy użyciu polecenia az aks create z flagą --node-provisioning-mode ustawioną na Auto. Następujące polecenie ustawia również wartość --network-plugin na azure, --network-plugin-mode na overlay, i --network-dataplane na cilium.

    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. Utwórz plik o nazwie nap.json i dodaj następującą konfigurację szablonu ARM z polem properties.nodeProvisioningProfile.mode ustawionym na Auto, co umożliwia NAP. (Ustawieniem domyślnym jest 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. Włącz automatyczne przydzielanie węzłów w nowym klastrze, używając polecenia az deployment group create z flagą --template-file, ustawioną na ścieżkę do pliku szablonu ARM.

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

Włącz NAP w istniejącym klastrze

  • Włącz automatyczne aprowizowanie węzłów w istniejącym klastrze przy użyciu az aks update polecenia z flagą ustawioną na --node-provisioning-modeAuto.

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

Wyłączanie automatycznego prowizjonowania węzłów (NAP) w klastrze usługi AKS

Ważne

Możesz wyłączyć NAP w ramach klastra tylko wtedy, gdy spełnione są następujące warunki:

  • Brak istniejących węzłów NAP. Możesz użyć polecenia kubectl get nodes -l karpenter.sh/nodepool , aby sprawdzić, czy istnieją węzły zarządzane przez NAP.
  • Wszystkie istniejące Karpenter NodePools mają swoje spec.limits.cpu pole ustawione na 0. Ta akcja uniemożliwia tworzenie nowych węzłów, ale nie zakłóca obecnie uruchomionych węzłów.

  1. Ustaw pole spec.limits.cpu na 0 dla każdego istniejącego Karpenter NodePool. Przykład:

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

    Ważne

    Jeśli nie chcesz upewniać się, że każdy pod uruchomiony wcześniej w węźle NAP jest bezpiecznie migrowany do węzła nienależącego do NAP przed jego wyłączeniem, możesz pominąć kroki 2 i 3, a zamiast tego użyć polecenia kubectl delete node dla każdego węzła zarządzanego przez NAP. Nie zalecamy jednak pomijania tych kroków, ponieważ może to spowodować pozostawienie niektórych zasobników oczekujących i nie uwzględnia budżetów zakłóceń zasobników (PDB).

    W przypadku korzystania z polecenia kubectl delete node należy zachować ostrożność, aby usunąć tylko węzły zarządzane przez NAP. Węzły zarządzane przez usługę NAP można zidentyfikować przy użyciu polecenia kubectl get nodes -l karpenter.sh/nodepool.

  2. karpenter.azure.com/disable:NoSchedule Dodaj defekt do każdego KarpenteraNodePool. Przykład:

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

    Ta akcja rozpoczyna proces migracji obciążeń w węzłach zarządzanych przez usługę OCHRONY dostępu do sieci do węzłów innych niż NAP, honorując pliki PDB i limity zakłóceń. Zasobniki są migrowane do węzłów innych niż NAP, jeśli można je dopasować. Jeśli nie ma wystarczającej pojemności o stałym rozmiarze, niektóre węzły zarządzane przez serwer ochrony dostępu do sieci pozostaną.

  3. Zwiększ skalę istniejących stałych rozmiarów ManagedClusterAgentPools lub utwórz nowy stały rozmiar AgentPools, aby przejąć obciążenie z zarządzanych przez NAP węzłów. W miarę dodawania tych węzłów do klastra węzły zarządzane przez moduł ochrony dostępu do sieci są opróżniane i praca jest migrowana do węzłów o stałym rozmiarze.

  4. Usuń wszystkie węzły zarządzane przez NAP przy użyciu polecenia kubectl get nodes -l karpenter.sh/nodepool. Jeśli węzły zarządzane przez NAP nadal istnieją, prawdopodobnie klaster nie ma wystarczającej pojemności stałej wielkości. W takim przypadku należy dodać więcej węzłów, aby można było migrować wszystkie pozostałe zadania.

  1. Zaktualizuj tryb NAP do Manual przy użyciu polecenia Azure CLI az aks update z flagą --node-provisioning-mode ustawioną na Manual.

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

  1. Zaktualizuj pole na Manual w szablonie ARM i wdróż je ponownie.

    {
  "$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"
        }
      }
    }
  ]
}

Dalsze kroki

Aby uzyskać więcej informacji o automatycznym aprowizowaniu węzłów w AKS, zobacz następujące artykuły:

  • Last updated on