Автоматическая подготовка узла (предварительная версия)

При развертывании рабочих нагрузок в AKS необходимо принять решение о конфигурации пула узлов относительно необходимого размера виртуальной машины. По мере того как рабочие нагрузки становятся более сложными и требуют различных ресурсов ЦП, памяти и возможностей для выполнения, разработка конфигурации виртуальной машины для многочисленных запросов ресурсов становится затруднительной.

Автоматическая подготовка узла (NAP) (предварительная версия) использует ожидающие требования к ресурсам pod, чтобы решить оптимальную конфигурацию виртуальной машины для выполнения этих рабочих нагрузок наиболее эффективным и экономичным способом.

NAP основан на проекте Karpenter с открытым исходным кодом, а поставщик AKS также является открытым исходным кодом. NAP автоматически развертывает и настраивает и управляет Karpenter в кластерах AKS.

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

• Вам требуется подписка Azure. Если у вас еще нет подписки Azure, вы можете создать бесплатную учетную запись.
• Необходимо установить Azure CLI.
• aks-preview Установите расширение Azure CLI. Минимальная версия 0.5.170.
• Зарегистрируйте флаг возможностей NodeAutoProvisioningPreview.

aks-preview Установка расширения CLI

1. aks-preview Установите расширение CLI с помощью az extension add команды.

   az extension add --name aks-preview
   

2. Обновите расширение, чтобы убедиться, что установлена последняя версия с помощью az extension update команды.

   az extension update --name aks-preview
   

Регистрация флага компонента NodeAutoProvisioningPreview

1. NodeAutoProvisioningPreview Зарегистрируйте флаг компонента с помощью az feature register команды.

   az feature register --namespace "Microsoft.ContainerService" --name "NodeAutoProvisioningPreview"
   

   Через несколько минут отобразится состояние Registered (Зарегистрировано).

2. Проверьте состояние регистрации с помощью az feature show команды.

   az feature show --namespace "Microsoft.ContainerService" --name "NodeAutoProvisioningPreview"
   

3. Когда состояние отражает зарегистрировано, обновите регистрацию поставщика ресурсов Microsoft.ContainerService с помощью az provider register команды.

   az provider register --namespace Microsoft.ContainerService
   

Ограничения

• Невозможно включить в кластере, где пулы узлов имеют автомасштабирование кластера

Неподдерживаемые функции

• пулы узлов Windows;
• Применение пользовательской конфигурации к "kubelet" узла
• Кластеры IPv6
• Объекты сервиса

  Примечание.

  Вы можете использовать управляемое удостоверение, назначаемое системой или назначаемое пользователем.

• Наборы шифрования дисков
• Сертификаты доверия CustomCA
• Режим остановки запуска
• Прокси-сервер HTTP
• Мутация OutboundType . Все исходящие типы поддерживаются, однако их нельзя изменить после создания.
• Частный кластер (и собственный DNS)

Конфигурации сети

Рекомендуемые конфигурации сети для кластеров с настроенной функцией автоматической подготовки узлов следующие.

• Наложение Azure CNI с помощью Cilium
• Наложение Azure CNI
• Azure CNI с поддержкой Cilium
• Azure CNI

Рекомендуемый механизм сетевой политики — Cilium.

В настоящее время следующие конфигурации сети не поддерживаются.

• Политика сети Calico
• Динамическое выделение IP-адресов
• Статическое выделение блоков CIDR

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

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

Активация автоматической подготовки узлов в существующем кластере

• Включите автоматическую подготовку узлов в существующем кластере с помощью команды az aks update и установите для нее --node-provisioning-mode значение Auto. Кроме того, необходимо установить --network-plugin на azure, --network-plugin-mode на overlay, и --network-dataplane на cilium.

  az aks update --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP_NAME --node-provisioning-mode Auto --network-plugin azure --network-plugin-mode overlay --network-dataplane cilium
  

Пулы узлов

Автоматическая подготовка узла использует список SKU виртуальных машин в качестве отправной точки, чтобы решить, какой номер SKU лучше всего подходит для рабочих нагрузок, находящихся в состоянии ожидания. Контроль над тем, какие номера SKU вы хотите в исходном пуле, позволяет вам указывать конкретные семейства SKU или типы виртуальных машин, а также максимальное количество ресурсов, которые использует провайдер ресурсов. Вы также можете ссылаться на различные спецификации в файле пула узлов, например, указывать экземпляры с наведением или по требованию, несколько архитектур и многое другое.

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

В кластере можно использовать несколько определений пула узлов, но AKS развертывает определение пула узлов по умолчанию, которое можно изменить:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: Never
  template:
    spec:
      nodeClassRef:
        name: default

      # Requirements that constrain the parameters of provisioned nodes.
      # These requirements are combined with pod.spec.affinity.nodeAffinity rules.
      # Operators { In, NotIn, Exists, DoesNotExist, Gt, and Lt } are supported.
      # https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#operators
      requirements:
      - key: kubernetes.io/arch
        operator: In
        values:
        - amd64
      - key: kubernetes.io/os
        operator: In
        values:
        - linux
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - on-demand
      - key: karpenter.azure.com/sku-family
        operator: In
        values:
        - D

Поддерживаемые требования к подготовке узлов

Селекторы SKU с известными метками

Чтобы получить список возможностей SKU виртуальной машины и допустимых значений, используйте vm list-skus команду Azure CLI.

az vm list-skus --resource-type virtualMachines --location <location> --query '[].name' --output table

Ограничения пула узлов

По умолчанию автоматическая подготовка узла пытается запланировать рабочие нагрузки в пределах вашей доступной квоты Azure. Можно также указать верхний предел ресурсов, используемых пулом узлов, указав ограничения в спецификации пула узлов.

  # Resource limits constrain the total size of the cluster.
  # Limits prevent Karpenter from creating new instances once the limit is exceeded.
  limits:
    cpu: "1000"
    memory: 1000Gi

Вес пула узлов

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

  # Priority given to the node pool when the scheduler considers which to select. Higher weights indicate higher priority when comparing node pools.
  # Specifying no weight is equivalent to specifying a weight of 0.
  weight: 10

Обновления Kubernetes и образа узла

AKS с автоматической подготовкой узлов управляет обновлениями версий Kubernetes и обновлениями диска ОС виртуальной машины по умолчанию.

Обновления Kubernetes

Обновления Kubernetes для узлов автоматической подготовки узлов соответствуют версии Kubernetes уровня управления. При обновлении кластера узлы, настроенные на автоматическое предоставление, автоматически обновляются для следования той же системе версий.

Обновления образа узла

По умолчанию виртуальные машины пула узлов NAP автоматически обновляются при наличии нового образа. Если вы хотите привязать пул узлов на заданную версию образа узла, можно задать imageVersion в классе узлов:

kubectl edit aksnodeclass default

В определении класса узла задайте параметр "imageVersion" одному из опубликованных выпусков, перечисленных в заметках о выпуске AKS. Вы также можете просмотреть доступность изображений в регионах, ссылаясь на трекер выпуска AKS.

ImageVersion — это дата на образе узла, так как поддерживается только Ubuntu 22.04. Например, "AKSUbuntu-2204-202311.07.0" будет "202311.07.0".

apiVersion: karpenter.azure.com/v1alpha2
kind: AKSNodeClass
metadata:
  annotations:
    kubernetes.io/description: General purpose AKSNodeClass for running Ubuntu2204
      nodes
    meta.helm.sh/release-name: aks-managed-karpenter-overlay
    meta.helm.sh/release-namespace: kube-system
  creationTimestamp: "2023-11-16T23:59:06Z"
  generation: 1
  labels:
    app.kubernetes.io/managed-by: Helm
    helm.toolkit.fluxcd.io/name: karpenter-overlay-main-adapter-helmrelease
    helm.toolkit.fluxcd.io/namespace: 6556abcb92c4ce0001202e78
  name: default
  resourceVersion: "1792"
  uid: 929a5b07-558f-4649-b78b-eb25e9b97076
spec:
  imageFamily: Ubuntu2204
  imageVersion: 202311.07.0
  osDiskSizeGB: 128

Удаление спецификации imageVersion приведет к тому, что пул узлов будет обновлен до последней версии образа узла.

Нарушение работы узла

Когда рабочие нагрузки на узлах снижаются, автоматическое создание узла использует правила прерывания в спецификации пула узлов, чтобы решить, когда и как удалить эти узлы и потенциально перепланировать рабочие нагрузки для повышения эффективности. Это в основном осуществляется путем консолидации, которая удаляет или заменяет узлы для оптимальной компоновки ваших модулей pod. В рамках учета состояния используются ConsolidationPolicy, такие как WhenUnderUtilized, WhenEmpty или WhenEmptyOrUnderUtilized, для инициирования консолидации. consolidateAfter — это условие на основе времени, которое можно задать для разрешения буферного времени между действиями.

Вы можете вручную удалить узел с помощью kubectl delete node, но автоматическая подготовка узлов также может контролировать, когда она должна оптимизировать ваши узлы на основе ваших спецификаций.

  disruption:
    # Describes which types of Nodes NAP should consider for consolidation
    consolidationPolicy: WhenUnderutilized | WhenEmpty
    # 'WhenUnderutilized', NAP will consider all nodes for consolidation and attempt to remove or replace Nodes when it discovers that the Node is underutilized and could be changed to reduce cost

    #  `WhenEmpty`, NAP will only consider nodes for consolidation that contain no workload pods
    
    # The amount of time NAP should wait after discovering a consolidation decision
    # This value can currently only be set when the consolidationPolicy is 'WhenEmpty'
    # You can choose to disable consolidation entirely by setting the string value 'Never'
    consolidateAfter: 30s

Мониторинг событий, связанных с выбором

Автоматическая подготовка узла создает события кластера, которые можно использовать для мониторинга принятия решений по развертыванию и планированию. События можно просматривать в потоке событий Kubernetes.

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

Отключение автоматической подготовки узла

Автоматическая подготовка узла может быть отключена только когда:

• Существующие узлы, управляемые NAP, отсутствуют. Используйте kubectl get nodes -l karpenter.sh/nodepool для просмотра узлов, управляемых NAP.
• Все существующие karpenter.sh/NodePools имеют значение spec.limits.cpu, установленное на 0.

Шаги по отключению автоподготовки узлов

1. Задайте для всех полей karpenter.sh/NodePools spec.limits.cpu значение 0. Это предотвращает создание новых узлов, но не нарушает текущий запуск узлов.

2. Добавьте метку karpenter.azure.com/disable:NoSchedule каждому karpenter.sh/NodePool.

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

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

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

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

5. Измените параметр режима подготовки узла managedCluster на Manual.

   • Azure CLI
   • Шаблон ARM

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