Поделиться через

Включение или отключение автоматической подготовки узла (NAP) в службе Azure Kubernetes (AKS)

В этой статье объясняется, как включить или отключить автоматическую подготовку узлов (NAP) в Службе Azure Kubernetes (AKS) с помощью шаблонов Azure CLI или Azure Resource Manager (ARM).

Если вы хотите создать кластер AKS с поддержкой NAP с пользовательской виртуальной сетью и подсетями, см. статью "Создание кластера автоматической подготовки узла (NAP) в пользовательской виртуальной сети.

Перед тем как начать

Прежде чем приступить к работе, ознакомьтесь с обзором автоматической подготовки узлов (NAP) в статье AKS, в которой описано, как работает NAP, предварительные требования и ограничения.

Включение автоматической подготовки узла (NAP) в кластере AKS

В следующих разделах объясняется, как включить NAP в новом или существующем кластере AKS:

Замечание

Вы можете включить метрики плоскости управления для просмотра журналов и операций из автоматической подготовки узла с использованием управляемой службы Azure Monitor для дополнения Prometheus.

Включение NAP в новом кластере

  • Включите автоподготовку узлов в новом кластере с помощью команды az aks create, у которой установлен флаг --node-provisioning-modeAuto. Следующая команда также задает --network-plugin в azure, --network-plugin-mode в overlay и --network-dataplane в 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. Создайте файл с именем 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.cpu значение 0. Это действие предотвращает создание новых узлов, но не нарушает текущий запуск узлов.

  1. Задайте поле spec.limits.cpu значением 0 для каждого существующего Karpenter NodePool. Рассмотрим пример.

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

    Это важно

    Если вы не хотите убедиться, что каждый модуль pod, ранее запущенный на узле NAP, безопасно переносится на узел, отличный от NAP, перед отключением NAP можно пропустить шаги 2 и 3 и вместо этого использовать kubectl delete node команду для каждого управляемого NAP узла. Тем не менее, мы не рекомендуем пропускать эти шаги, так как это может оставить некоторые pod в состоянии ожидания и не учитывает бюджеты прерываний Pod (PDBs).

    При использовании kubectl delete node команды будьте осторожны, чтобы удалить только узлы, управляемые NAP. Вы можете определить узлы, управляемые NAP, с помощью kubectl get nodes -l karpenter.sh/nodepool команды.

  2. Добавьте karpenter.azure.com/disable:NoSchedule метку на каждый Karpenter NodePool. Рассмотрим пример.

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

    Это действие запускает процесс миграции рабочих нагрузок с узлов, управляемых NAP, на узлы, не управляющиеся NAP, с учетом ПДБ и ограничений на нарушения. Модули Pod переносятся на узлы, отличные от NAP, если они могут соответствовать. Если недостаточно мощностей фиксированного размера, некоторые узлы, управляемые NAP, остаются в сети.

  3. Увеличьте масштаб существующего фиксированного размера ManagedClusterAgentPools или создайте новый фиксированный размер AgentPools, чтобы взять на себя нагрузку с узлов, управляемых системой NAP. Так как эти узлы добавляются в кластер, узлы, управляемые NAP, удаляются, а работа переносится на узлы с фиксированным размером.

  4. Удалите все узлы, управляемые NAP, с помощью kubectl get nodes -l karpenter.sh/nodepool команды. Если узлы, управляемые NAP, по-прежнему существуют, кластер, скорее всего, не имеет емкости фиксированного размера. В этом случае необходимо добавить дополнительные узлы, чтобы остальные рабочие нагрузки могли быть перенесены.

  1. Обновите режим NAP на Manual, используя команду 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"
        }
      }
    }
  ]
}

Дальнейшие шаги

Дополнительные сведения об автоматической подготовке узлов в AKS см. в следующих статьях:

  • Last updated on