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

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

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

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

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

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

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

Замечание

Вы можете включить метрики управляющей плоскости, чтобы просмотреть журналы и операции автоподготовки узлов с помощью надстройки Azure Monitor Managed Service для 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 az aks update, установив флаг --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 для своего кластера. В этих инструкциях предполагается, что чарт Helm Karpenter уже установлен.

Это важно

Перед началом миграции убедитесь, что у вас установлена последняя версия Karpenter. NAP всегда работает с последней версией.

Это важно

Будьте осторожны, чтобы не удалить CRD Karpenter в ходе этого процесса миграции. Если CRD удаляются, это приводит к удалению базовых объектов NodeClaim, что может нарушить работу ваших рабочих нагрузок.

  1. Чтобы CRD Karpenter не были деинсталлированы на шаге 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, чтобы удалить объект Deployment, Service, Role и другие ресурсы, которые использует открытый код-проект 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, используемые по умолчанию, поскольку у вас уже есть существующие NodePools и вы хотите продолжать использовать их. Если вы хотите включить пулы автоподготовки узлов по умолчанию, вы можете опустить --node-provisioning-default-pools None из команды az aks update.

  4. Проверьте, что миграция завершена: когда az aks update из шага 3 успешно завершится, миграция завершена. Вы также можете подтвердить, что миграция выполняется, проверив заметки на crD Karpenter. Вы должны увидеть:

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

    На этом этапе NAP включен, а автоматическое масштабирование должно возобновиться.

Мониторинг автоматического развертывания узла

Получение журналов и состояния Karpenter

Журналы и обновления состояния можно получить из Karpenter, чтобы помочь в диагностике и отладке событий, связанных с NAP. AKS управляет автоматическим предоставлением узлов от вашего имени и запускает этот процесс в управляемом контрольном уровне. Вы можете включить журналы контрольной плоскости для просмотра журналов и операций Karpenter в ходе автоматического предоставления узлов. Дополнительные сведения о журналах плоскости управления см. в документации по журналам плоскости управления AKS

  1. Настройте правило для журналов ресурсов, чтобы отправлять журналы автозамещения узла в Log Analytics с помощью инструкций инструкции здесь. Убедитесь, что вы отметили флажок node-auto-provisioning при выборе параметров для журналов.

  2. Выберите раздел "Журнал" в кластере.

  3. Введите следующий пример запроса в Log Analytics:

    AKSControlPlane
| where Category == "karpenter-events"

  4. Просмотр событий автоматической подготовки узла в CLI:

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

Метрики автоматической подготовки узла

Вы можете включить метрики плоскости управления (предварительная версия) чтобы просмотреть конкретные метрики и операции Karpenter из node auto-provisioning с помощью управляемой службы Azure Monitor для надстройки Prometheus.

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

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

  • Last updated on