Настройка ресурсов AKSNodeClass для автоматической подготовки узла (NAP) в Azure Kubernetes Service (AKS)

В этой статье объясняется, как настроить ресурсы AKSNodeClass для определения настроек, специфичных для Azure, для автоматической подготовки узлов (NAP) в Azure Kubernetes Service (AKS) с помощью Karpenter. AKSNodeClass позволяет настраивать различные аспекты узлов, которые подготавливает Карпентер, например, образ виртуальной машины (VM), размер диска операционной системы (OS), максимальное количество pod на узел и конфигурации kubelet.

Это важно

Начиная с 30 ноября 2025 Azure Kubernetes Service (AKS) больше не поддерживает или не предоставляет обновления системы безопасности для Azure Linux 2.0. Образ узла Linux 2.0 Azure заморожен в выпуске202512.06.0. Начиная с 31 октября 2026 г. образы узлов будут удалены, и вы не сможете масштабировать пулы узлов. Миграция на поддерживаемую версию Azure Linux путем обновления пулов узлов до поддерживаемой версии Kubernetes или путем перехода на osSku AzureLinux3. Дополнительные сведения см. в проблеме на GitHub о выходе из эксплуатации и в объявлении о прекращении обновлений Azure. Чтобы оставаться в курсе объявлений и обновлений, следуйте заметкам о выпуске AKS.

Обзор ресурсов AKSNodeClass

Ресурсы AKSNodeClass позволяют настраивать NAP с использованием параметров Azure. Каждый NodePool ресурс должен ссылаться на AKSNodeClass с использованием spec.template.spec.nodeClassRef. Можно использовать несколько NodePools, указывающих на один и тот же AKSNodeClass, что позволяет совместно использовать общие конфигурации Azure в разных пулах узлов.

Это важно

Изменение параметра для существующего AKSNodeClass не перенастраивает запущенные узлы на месте. NAP помечает узлы, подготовленные из предыдущей конфигурации, как дрейфующие и заменяет их с учетом средств управления прерываниями в ссылающихся ресурсах NodePool. Поле tags — единственное исключение, так как изменения тегов применяются к существующим ресурсам Azure без замены узла. Дополнительные сведения см. в статьях Drift и Бюджеты сбоев. Перед изменением AKSNodeClass, используемого в производственных рабочих нагрузках, ознакомьтесь с этим руководством.

Конфигурация семейства образов

Поле imageFamily задает образ виртуальной машины по умолчанию и логику начальной загрузки для узлов, подготовленных через AKSNodeClass. Если вы не указываете семейство образов, используется версия ОС по умолчанию в соответствии с версией Kubernetes. Графические процессоры поддерживаются в обоих семействах образов в совместимых размерах виртуальных машин. Дополнительные сведения о версии ОС по умолчанию для каждой версии Kubernetes см. в документации по версии ОС AKS.

Поддерживаемые семейства образов

  • Ubuntu: Ubuntu — это дистрибутив Linux по умолчанию для узлов AKS.
    • Версия ОС по умолчанию изменяется на основе версии Kubernetes. Ubuntu 22.04 по умолчанию для Kubernetes версии 1.25– 1.33. Ubuntu 24.04 по умолчанию для Kubernetes версии 1.34 и более поздних версий.
  • AzureLinux: Дистрибутив Azure Linux от Microsoft является альтернативным дистрибутивом Linux для рабочих нагрузок AKS. Дополнительные сведения см. в документации по Azure Linux.
  • AzureContainerLinux: Azure Container Linux поддерживается с AKS 1.34 и более поздними версиями. Используйте виртуальную машину поколения 2 и явно включите оба параметра функции «Доверенный запуск», даже если они вам в остальном не требуются:
    • Установите security.trustedLaunch.vtpm на true.
    • Установите security.trustedLaunch.secureBoot на true.
    • Если задано osDiskSizeGB, используйте значение не менее 60.
    • Не используйте это семейство образов с параметрами, которые этот образ не поддерживает. Дополнительные сведения см. в статье Azure Container Linux в AKS.
  • Windows2022: Windows Server 2022 доступен в предварительной версии. Для этого требуется архитектура AMD64, и это не поддерживается при использовании плоскости данных Cilium. Windows2022 не поддерживает FIPS или Trusted Launch. Не настраивайте linuxOSConfig, не включайте потоковую передачу артефактов и не задавайте LocalDNS режим, отличный от Disabled.
  • Windows2025: Windows Server 2025 доступен в предварительной версии. Для этого требуется архитектура AMD64, и это не поддерживается при использовании плоскости данных Cilium. FIPS является обязательным и фактически включен даже в том случае, если fipsMode опущен. Не настраивайте linuxOSConfig, не включайте потоковую передачу артефактов и не задавайте для LocalDNS режим, отличный от Disabled.

Пример конфигурации семейства образов

В следующем примере конфигурируется AKSNodeClass, чтобы использовать семейство образов AzureLinux.

spec:
  imageFamily: AzureLinux

конфигурация Azure Container Linux

В следующем примере используется Azure Container Linux с необходимыми параметрами доверенного запуска. Он опускает osDiskSizeGB, чтобы платформа выбирала поддерживаемый размер диска.

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: azure-container-linux
spec:
  imageFamily: AzureContainerLinux
  security:
    trustedLaunch:
      vtpm: true
      secureBoot: true

Поддержка ОС Windows (предварительная версия)

Замечание

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

NAP поддерживает Windows2022 и Windows2025 образы.

  • Windows2022: Windows Server 2022 доступен в предварительной версии. Для этого требуется архитектура AMD64, и это не поддерживается при использовании плоскости данных Cilium. Windows2022 не поддерживает FIPS или Trusted Launch. Не настраивайте linuxOSConfig, не включайте потоковую передачу артефактов и не устанавливайте LocalDNS в режим, отличный от Disabled.
  • Windows2025: Windows Server 2025 доступен в предварительной версии. Для этого требуется архитектура AMD64, и это не поддерживается с плоскостью данных Cilium. FIPS является обязательным и фактически включен даже в том случае, если fipsMode опущен. Не настраивайте linuxOSConfig, не включайте потоковую передачу артефактов и не задавайте для LocalDNS режим, отличный от Disabled.

Конфигурация Windows2022

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: windows-2025
spec:
  imageFamily: Windows2025

Конфигурация Windows2025

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: windows-2025
spec:
  imageFamily: Windows2025
  security:
    trustedLaunch:
      vtpm: true
      secureBoot: true

Это важно

Семейства образов Windows доступны в режиме предварительной версии. Используйте конфигурацию Windows NodePool, которая выбирает kubernetes.io/os: windows и kubernetes.io/arch: amd64, и убедитесь, что рабочие нагрузки также выбирают узлы Windows. Дополнительные сведения см. в разделе "Настройка пулов узлов для автоматической подготовки узлов в AKS".

Конфигурация образа узла, совместимого с FIPS

Вы также можете включить образы узлов, совместимые с федеральными стандартами обработки информации (FIPS). Дополнительные сведения о FIPS в AKS см. в документации по FIPS.

Поле fipsMode по умолчанию имеет значение "Отключено" и может иметь следующие параметры:

  • FIPS — выбор образов узлов, совместимых с FIPS
  • Отключен - не используйте образы узлов, соответствующие требованиям FIPS

Следующий пример настраивает AKSNodeClass для выбора образов узлов, совместимых с FIPS, с помощью параметра fipsModeFIPS:

spec:
  fipsMode: FIPS

Конфигурация общедоступного IP-адреса уровня экземпляра

Общедоступный IPv4-адрес можно назначить каждому узлу, подготовленному NAP, установив nodePublicIP.enabled в значение true. При необходимости можно указать ipTags или prefixIDs. Используйте либо одно, либо другое, а не оба.

Использование общедоступного IP-адреса уровня экземпляра с префиксами

При необходимости укажите один префикс общедоступного IP-адреса IPv4 с помощью prefixIDs. Префикс должен находиться в том же регионе, что и кластер. Для зонального префикса ограничьте соответствующий NodePool одной и той же зоной доступности. Нельзя указать ipTags и prefixIDs вместе — используйте только один из них.

Идентичность кластера должна иметь разрешение на использование префикса общедоступного IP-адреса, если он указан, а также на создание ресурсов общедоступного IP-адреса узла и управление ими. Полные инструкции по настройке, безопасности сети и проверке см. в разделе Использование общедоступных IP-адресов узла.

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: public-ip-nodes
spec:
  nodePublicIP:
    enabled: true
    # Optional. Specify at most one IPv4 public IP prefix resource ID.
    prefixIDs:
      - /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/publicIPPrefixes/<prefix-name>

Используйте общедоступный IP-адрес уровня экземпляра с тегами IP и с предпочтением маршрутизации через Интернет

В следующем примере показано, как использовать общедоступный IP-адрес уровня экземпляра с тегом IP:

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: public-ip-nodes
spec:
  nodePublicIP:
    enabled: true
    ipTags:
      - ipTagType: RoutingPreference
        tag: Internet
    # Optional. Specify at most one IPv4 public IP prefix resource ID.
    prefixIDs:
      - /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/publicIPPrefixes/<prefix-name>

Потоковая передача артефактов

Потоковая передача артефактов позволяет передавать образы контейнеров из Реестр контейнеров Azure (ACR) в Azure Kubernetes Service (AKS). AKS извлекает только необходимые слои для начального запуска pod, уменьшая время, необходимое для развертывания рабочих нагрузок.

Необходимые условия

  • Для Artifact Streaming требуется, чтобы реестр контейнеров Azure (ACR) уровня Premium был интегрирован с вашим кластером AKS.
  • В ACR должна быть включена потоковая передача артефактов.

Сведения о том, как включить Artifact Streaming в ACR, см. в документации по Artifact Streaming.

Включение потоковой передачи артефактов в кластерах NAP

Кластеры с включённой функцией автоматического выделения узлов (NAP) могут включить потоковую передачу артефактов с помощью поля spec.artifactStreaming.enabledAKSNodeClass CRD. Установите для этого поля значение true, чтобы включить потоковую передачу артефактов для всех новых или существующих узлов, управляемых NAP, связанных с этим CRD AKSNodeClass.

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: my-node-class
spec:
  # Enables artifact streaming; To use this feature container images must also enable artifact streaming on ACR
  # Valid values: true, false; defaults to false if not specified
  artifactStreaming:
    enabled: 
      true

Замечание

Чтобы использовать потоковую передачу артефактов на управляемых узлах AKS NAP, необходимо также включить потоковую передачу артефактов в Реестр контейнеров Azure (ACR). Если этот параметр не задан в ACR, поле по умолчанию имеет значение false.

Конфигурация подсети виртуальной сети

Поле vnetSubnetID указывает, какая подсеть виртуальной сети Azure VNet должна использоваться для провизии сетевых интерфейсов узла. Это поле необязательно. Если вы не указываете подсеть, NAP использует подсеть по умолчанию, настроенную во время установки Karpenter. Дополнительные сведения см. в разделе "Конфигурации подсети" для NAP.

Пример конфигурации подсети

Идентификатор подсети должен находиться в полном формате Azure Resource Manager (ARM), как показано в следующем примере:

spec:
  vnetSubnetID: "/subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.Network/virtualNetworks/{vnet-name}/subnets/{subnet-name}"

Конфигурация размера диска ОС

Поле osDiskSizeGB указывает размер диска ОС в гигабайтах. Значение по умолчанию — 128 ГБ, а минимальное значение — 30 ГБ.

Рассмотрите более крупные размеры дисков ОС для рабочих нагрузок, которые:

  • Храните значительные данные локально.
  • Требуется дополнительное пространство для образов контейнеров.
  • Имеют высокие требования к вводу-выводу диска

Пример конфигурации размера диска ОС

spec:
  osDiskSizeGB: 256  # 256 GB OS disk

Эфемерная конфигурация диска ОС

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

Критерии выбора эфемерного диска

Система автоматически выбирает временные диски в следующих сценариях:

  • Тип экземпляра виртуальной машины поддерживает диски эфемерной ОС.
  • Эфемерная емкость диска больше или равна запрошеннойosDiskSizeGB.
  • Виртуальная машина имеет достаточную эфемерную емкость хранилища.

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

Эфемерные типы дисков и приоритетность

Azure виртуальные машины могут иметь различные типы эфемерного хранилища. Система использует следующий порядок приоритета:

  • Диски NVMe (высокая производительность)
  • Кэшировать диски (сбалансированная производительность)
  • Диски ресурсов (базовая производительность)

Пример эфемерной конфигурации диска

Требования к пулу узлов можно использовать для обеспечения достаточной эфемерной емкости дисков, как показано в следующем примере:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ephemeral-disk-pool
spec:
  template:
    spec:
      requirements:
        - key: karpenter.azure.com/sku-storage-ephemeralos-maxsize
          operator: Gt
          values: ["128"]  # Require ephemeral disk larger than 128 GB
      nodeClassRef:
        group: karpenter.azure.com
        kind: AKSNodeClass
        name: my-node-class
---
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: my-node-class
spec:
  osDiskSizeGB: 128  # This will use ephemeral disk if available and large enough

Эта конфигурация гарантирует, что выбраны только типы экземпляров виртуальных машин с временными дисками размером более 128 ГБ, гарантируя эфемерное использование дисков для указанного размера диска ОС.

Максимальная конфигурация модулей pod

Поле maxPods указывает максимальное количество pod, которые можно разместить на узле. Этот параметр влияет как на плотность кластера, так и на конфигурацию сети.

Минимальное значение maxPods равно 10, а максимальное значение — 250.

Поведение по умолчанию для maxPods

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

Конфигурация сетевого плагина Значение по умолчанию maxPods для каждого узла
Azure CNI со стандартными сетями (версия 1 или NodeSubnet) 30
Azure CNI с оверлейными сетями 250
Нет (нет сетевого подключаемого модуля) 250
Другие конфигурации 110 (стандартная версия Kubernetes по умолчанию)

Пример конфигурации максимального количества подов

spec:
  maxPods: 50  # Allow up to 50 pods per node

Конфигурация LocalDNS

LocalDNS развертывает DNS-прокси уровня узла, который разрешает dns-запросы ближе к рабочим нагрузкам, уменьшая задержку запросов и повышая устойчивость во время временных сбоев DNS. Дополнительные сведения см. в документации по LocalDNS. По умолчанию localDNS имеет значение "Отключено" и может быть настроено на следующие параметры:

  • Disabled (по умолчанию) — отключает функцию LocalDNS. Запросы DNS не разрешаются локально на узле.
  • Preferred — AKS управляет включением LocalDNS в зависимости от версии Kubernetes в пуле узлов. Конфигурация всегда проверяется и включается, но LocalDNS не будет включен, если не используется правильная версия Kubernetes.
  • Required — LocalDNS применяется в пуле узлов, если выполнены все необходимые условия. Если требования не выполнены, развертывание не удается.

Пример конфигурации LocalDNS

Вы можете настроить конфигурации LocalDNS, такие как vnetDNSOverrides и kubeDNSOverrides. Дополнительные сведения о поддерживаемых подключаемых модулях см. в разделе "Настройка LocalDNS".

spec:
  LocalDNS:
    mode: Required
    vnetDNSOverrides:
      - zone: "."
        cacheDuration: "3600s"
        forwardDestination: VnetDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: PreferUDP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
      - zone: "cluster.local"
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: ForceTCP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
    kubeDNSOverrides:
      - zone: "."
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: PreferUDP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
      - zone: "cluster.local"
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: ForceTCP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"

Обновите конфигурацию LocalDNS в существующем AKSNodeClass

Этот localDNS параметр участвует в обнаружении дрейфа, как и другие AKSNodeClass параметры. Когда вы изменяете spec.localDNS в AKSNodeClass, на который уже ссылаются существующие узлы, NAP применяет это изменение через стандартный механизм Drift. NAP не переустанавливает образ на существующие узлы.

Следующее поведение применяется при изменении режима LocalDNS или переопределений, таких как переход mode с Disabled на Required:

  • Новые узлы: каждый узел, который NAP подготавливает после обновления AKSNodeClass, использует новую конфигурацию LocalDNS.
  • Существующие узлы: NAP помечает существующие NodeClaim объекты как изменённые, так как их записанная конфигурация больше не соответствует AKSNodeClass. NAP запускает узел замены, использующий новую конфигурацию LocalDNS, а затем изолирует, освобождает и удаляет отклонившийся узел.
  • Без переустановки образа: Включение LocalDNS в пуле управляемых узлов AKS приводит к переустановке образа каждого узла в пуле. NAP заменяет узел. В любом случае модули pod на затронутых узлах вытесняются и перераспределяются, поэтому планируйте такое же влияние на рабочую нагрузку.

Это важно

Установка значения mode на Preferred или Disabled также изменяет итоговую конфигурацию AKSNodeClass и приводит к дрейфу существующих узлов. Любое изменение в localDNS разделе, включая vnetDNSOverrides значения и kubeDNSOverrides значения, приводит к замене узла.

Когда начинается замена

Оценка смещения и замена начинаются, как только вы примените обновленный AKSNodeClass. Замена соответствует стандартному жизненному циклу прерываний NAP, поэтому частота и время зависят от параметров управления прерываниями, настроенных для ресурсов NodePool, ссылающихся на AKSNodeClass.

Как NAP координирует замену

Смещение, вызванное изменением LocalDNS, соблюдает стандартные механизмы управления сбоями NAP, описанные в следующей таблице:

CTRL Влияние на замену, вызванную LocalDNS
Бюджеты сбоев (spec.disruption.budgets) Ограничение скорости ограничивает одновременное количество заменяемых узлов NAP. Если вы не определяете бюджеты, NAP по умолчанию использует один бюджет nodes: 10%, поэтому он затрагивает не более 10 процентов узлов пула узлов одновременно.
Бюджет schedule и duration Ограничивает замену окном обслуживания. Установите nodes: "0" за пределами окна, чтобы заблокировать замену.
Бюджеты прерывания Pod (PDB) Применяется во время дренирования узла. NAP ожидает вместо выселения подов, которые нарушают PDB.
karpenter.sh/do-not-disrupt аннотация Исключает аннотированные поды и узлы из добровольных прерываний, включая дрейф.
terminationGracePeriod Время слива колпачков. Этот параметр пропускает PDB-файлы и аннотацию karpenter.sh/do-not-disrupt при истечении периода.

Замена не является ни полностью последовательной, ни полностью параллельной. NAP заранее выделяет мощности для замены перед удалением узла с отклонением, но может одновременно заменить несколько узлов, ссылающихся на один и тот же AKSNodeClass, вплоть до предела, заданного вашими бюджетами нарушений.

Предупреждение

Если вы не задаёте бюджеты прерываний в пулах узлов и не задаёте бюджеты прерываний Pod для рабочих нагрузок, изменение localDNS в загруженном AKSNodeClass может одновременно затронуть до 10 процентов ваших узлов без защиты на уровне приложения, что может привести к простою рабочих нагрузок. Определите PDB для критически важных рабочих нагрузок и задайте консервативный бюджет нарушений доступности перед изменением localDNS в промышленном кластере.

Снижение риска недоступности при включении LocalDNS

  1. Убедитесь, что пользовательские DNS-серверы отвечают на запросы по UDP и TCP через порт 53 из подсети узла. Дополнительные сведения см. в разделе Проверка пользовательского DNS перед включением LocalDNS.

  2. Определите бюджеты нарушений работы Pod для каждого критически важного приложения.

  3. Задайте консервативный бюджет нарушений доступности для затронутых ресурсов NodePool перед изменением AKSNodeClass, как показано в следующем примере:

    apiVersion: karpenter.sh/v1
    kind: NodePool
    metadata:
      name: default
    spec:
      disruption:
        budgets:
        - nodes: "1"   # Replace one node at a time
    
  4. localDNS Сначала примените изменение к непродуктивной средеAKSNodeClass. Кроме того, создайте AKSNodeClass с включённым LocalDNS и перенесите рабочие нагрузки в NodePool, который ссылается на него.

  5. Отслеживайте ход замены, перечисляя запросы узлов. Замена считается завершенной, когда ни один NodeClaim не сообщает об условии состояния Drifted.

    # List node claims and watch replacements appear as drifted nodes are removed
    kubectl get nodeclaims
    
    # Inspect the status conditions on a specific node claim
    kubectl describe nodeclaim <nodeclaim-name>
    
  6. Убедитесь, что localDNS активен на узлах замены. Дополнительные сведения см. в разделе Проверка операции LocalDNS.

Конфигурация Kubelet

В kubelet этом разделе можно настроить различные параметры kubelet, влияющие на поведение узла. Эти параметры являются типичными аргументами kubelet, поэтому поставщик Azure просто передает их в kubelet на узле.

Это важно

Сначала настройте параметры kubelet и проверьте все изменения в непроизводственных средах.

Управление ЦП

Следующие параметры управляют поведением управления ЦП для kubelet:

spec:
  kubelet:
    cpuManagerPolicy: "static"  # or "none"
    cpuCFSQuota: true
    cpuCFSQuotaPeriod: "100ms"
  • cpuManagerPolicy: определяет, как kubelet выделяет ресурсы ЦП. Установите на "static" для закрепления ЦП в нагрузках, чувствительных к задержке.
  • cpuCFSQuota: включает принудительное применение квоты ЦП (CFS) для контейнеров, определяющих ограничения ЦП.
  • cpuCFSQuotaPeriod: задает период квоты ЦП CFS.

Сбор мусора изображений

Следующие параметры определяют поведение сбора мусора образов в kubelet:

spec:
  kubelet:
    imageGCHighThresholdPercent: 85
    imageGCLowThresholdPercent: 80

Эти параметры определяют, когда kubelet выполняет удаление ненужных данных образов контейнеров.

  • imageGCHighThresholdPercent: процент использования диска, при котором активируется очистка ненужных образов.
  • imageGCLowThresholdPercent: целевой процент использования диска после сборки мусора.

Управление топологией

Следующий параметр управляет политикой диспетчера топологий для kubelet:

spec:
  kubelet:
    topologyManagerPolicy: "best-effort"  # none, restricted, best-effort, single-numa-node

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

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

Следующие параметры позволяют настроить дополнительные системные параметры для kubelet:

spec:
  kubelet:
    allowedUnsafeSysctls:
      - "kernel.msg*"
      - "net.ipv4.route.min_pmtu"
    containerLogMaxSize: "50Mi"
    containerLogMaxFiles: 5
    podPidsLimit: 4096
  • allowedUnsafeSysctls: список разрешенных небезопасных системных списков, которые могут использовать модули pod.
  • containerLogMaxSize: Максимальный размер файлов журнала контейнера перед ротацией.
  • containerLogMaxFiles: максимальное количество сохраненных файлов журнала контейнеров.
  • podPidsLimit: максимальное число процессов, разрешённых в любом pod.

Параметры конфигурации пользовательской ОС Linux

В LinuxOSConfig этом разделе можно настроить различные параметры kubelet, влияющие на поведение узла. Эти параметры являются типичными пользовательскими аргументами ОС, поэтому NAP просто передает их в kubelet на узле.

Дополнительные сведения о пользовательских параметрах конфигурации ОС Linux, значениях по умолчанию и рекомендациях см. в справочнике по параметрам конфигурации пользовательского узла.

Это важно

Сначала настройте параметры ОС Linux и проверьте все изменения в непроизводственных средах.

Ограничения параметров дескриптора файлов Linux

Используйте следующие параметры, чтобы задать параметры файловой системы.

spec:
  linuxOSConfig: 
    # Sysctl Settings  
    sysctls:  
      # File System Settings  
      fsFileMax: 2000000               # Range: 8192-12000500  Default: Max of available range
      fsInotifyMaxUserWatches: 1000000 # Range: 781250-2097152 Default: 1048576
      fsAioMaxNr: 1000000              # Range: 65536-6553500  Default: 65536
      fsNrOpen: 1000000                # Range: 8192-20000500  Default: 1048576

Параметры настройки сокета и сети Linux

Используйте следующие параметры, чтобы задать параметр TCP и сети.

spec:
  linuxOSConfig:
      # Network Settings  
      netCoreSomaxconn: 65535          # Range: 4096-3240000  Default: 16384
      netCoreNetdevMaxBacklog: 5000    # Range: 1000-3240000  Default: 1000
      netCoreRmemMax: 134217728        # Range: 212992-134217728  Default: 1048576
      netCoreOptmemMax: 102400         # Range: 20480-4194304     Default: 131072 
      netCoreWmemMax: 134217728        # Range: 212992-134217728  Default: 212992
      netCoreRmemDefault: 212992       # Range: 212992-134217728  
      netCoreWmemDefault: 212992       # Range: 212992-134217728  
      netIPv4IPLocalPortRange: "1024 65535" # Format: "first last", first: 1024-60999, last: 32768-65535  

      # Neighbor Table GC Thresholds  
      netIPv4NeighDefaultGcThresh1: 1024   # Range: 128-80000  Default: 4096
      netIPv4NeighDefaultGcThresh2: 2048   # Range: 512-80000  Default: 8192
      netIPv4NeighDefaultGcThresh3: 4096   # Range: 1024-80000  Default: 16384
      # Note: thresh1 <= thresh2 <= thresh3  

      # Connection Tracking  
      netNetfilterNfConntrackBuckets: 131072  # Range: 65536-524288   Default: dynamically calculated 
      netNetfilterNfConntrackMax: 262144       # Range: 131072-2097152 Default: dynamically calculated 

Параметры ограничения числа рабочих процессов Linux

Используйте следующие параметры, чтобы задать параметр ядра.

spec:
  linuxOSConfig:
      # Kernel Settings  
      kernelThreadsMax: 100000         # Range: 20-513785  Default: Dynamically calculated

Параметры виртуальной памяти Linux

Используйте следующие параметры для настройки работы подсистемы виртуальной памяти ядра Linux и сброса на диск изменённых, но ещё не записанных данных.

spec:
  linuxOSConfig:
      # Memory Management  
      vmMaxMapCount: 262144          # Range: 65530-262144 Default: Max of available range
      vmVfsCachePressure: 100        # Range: 0-100  Default: 100
      vmSwappiness: 60               # Range: 0-100  Default: 60

      # Swap File Configuration  
      swapFileSize: "2Gi"             # Default: (not set) | Pattern: quantity with units Note: Requires kubelet.failSwapOn: false  

      # Transparent Huge Pages  
      transparentHugePageEnabled: "madvise"    # Values: [always, madvise, never]  Default: always
      transparentHugePageDefrag: "defer+madvise" # Values: [always, defer, defer+madvise, madvise, never]  Default: madvise

Параметры GPU

Используйте следующее поле, чтобы включить установку пользовательского драйвера GPU, например с помощью NVIDIA GPU Operator.

spec:
  gpu:
    mode: 
      # acceptable values: [driver, none] default(or if not specified): driver
      # none skips gpu driver installation, driver has NAP manage the GPU driver installation  
      none

Управляемый графический процессор

Поле gpu.mode управляет установкой драйвера GPU. Он принимает Driver или None, и по умолчанию используется Driver. Установите None для пропуска установки драйвера, например при использовании оператора GPU NVIDIA.

Чтобы подключиться к управляемому использованию графических процессоров NVIDIA, используйте mode: Driver и установите nvidia.managementMode: Managed. Управляемый GPU поддерживается для узлов Linux с GPU NVIDIA с помощью режима подготовки ресурсов Machine API в AKS. По умолчанию используется Unmanagedрежим управления NVIDIA.

spec:
  gpu:
    mode: Driver
    nvidia:
      managementMode: Managed

Полный пример GPU под управлением NAP и шаги проверки см. в GPU-узлах под управлением AKS.

Параметры безопасности

Шифрование на узле

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

spec:
  security:
    encryptionatHost: 
      # acceptable values: [true, false] default(or if not specified): false  
      false

Дополнительные сведения о шифровании на основе узлов см. в документации по шифрованию узлов.

Пользовательские ключи и наборы шифрования дисков

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

  • Идентификатор кластера имеет доступ Reader к набору для шифрования дисков.
  • Ресурс Disk Encryption Set имеет Key Vault Crypto Service Encryption User доступ к хранилищу ключей Azure.

Сведения о ключах, управляемых клиентом, и наборах шифрования дисков, включенных при создании кластера, см. в документации по Customer-Managed Keys.

Включите доверенный запуск в кластерах NAP

Кластеры с включенным автоматическим выделением узлов (NAP) могут включить доверенный запуск с помощью поля spec.security.trustedLaunchCRD AKSNodeClass. Задайте для полей secureBoot и vTPM значение true, чтобы включить доверенный запуск для всех новых или существующих узлов, управляемых NAP, связанных с этим CRD AKSNodeClass.

spec:
  security:
  # Enables trusted lunch
  # Valid values: true, false; defaults to false if not specified
     trustedLaunch:
       secureBoot: true
       vTPM: true   

конфигурация тегов ресурсов Azure

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

Ограничения тегов

  • Azure теги ресурсов имеют ограничение в 50 тегов на ресурс.
  • Имена тегов не учитывают регистр, но значения тегов чувствительны к регистру.
  • Azure резервирует некоторые имена тегов, которые нельзя использовать. Дополнительные сведения см. в руководстве по тегам и ограничениях.

Пример конфигурации тегов

spec:
  tags:
    Environment: "production"
    Team: "platform"
    Application: "web-service"
    CostCenter: "engineering"

Полный AKSNodeClass пример конфигурации

В следующем примере показана полная AKSNodeClass конфигурация, которая включает все параметры, описанные в этой статье:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      nodeClassRef:
        group: karpenter.azure.com
        kind: AKSNodeClass
        name: comprehensive-example
---
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: comprehensive-example
spec:
  # Image family configuration
  # Default: Ubuntu
  # Valid values: Ubuntu, AzureLinux, AzureContainerLinux
  imageFamily: Ubuntu

  # FIPS compliant mode - allows support for FIPS-compliant node images
  # Default: Disabled
  # Valid values: FIPS, Disabled
  fipsMode: Disabled

  # Artifact Streaming- allows use of artifact streaming feature; To use this feature container images must also enable artifact streaming on ACR
  # Valid values: true, false; defaults to false if not specified
  artifactStreaming:
    enabled: true

  # LocalDNS mode - allows use of LocalDNS feature
  # Default: Disabled
  # Valid values: Preferred, Required, Disabled
  # vnetDNSOverrides and kubeDNSOverrides are both required, even when mode is Disabled
  # Each list must include the "." and "cluster.local" zones, and each zone must set all nine fields
  localDNS:
    mode: Disabled
    # vnetDNSOverrides apply to DNS traffic from pods with dnsPolicy:default and from kubelet
    vnetDNSOverrides:
      - zone: "."
        cacheDuration: "3600s"
        forwardDestination: VnetDNS   # the "." zone can't forward to ClusterCoreDNS in vnetDNSOverrides
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: PreferUDP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
      - zone: "cluster.local"
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS   # cluster.local can't forward to VnetDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: ForceTCP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
    # kubeDNSOverrides apply to DNS traffic from pods with dnsPolicy:ClusterFirst
    kubeDNSOverrides:
      - zone: "."
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: PreferUDP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
      - zone: "cluster.local"
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: ForceTCP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"

  # Virtual network subnet configuration (optional)
  # If not specified, uses the default --vnet-subnet-id from Karpenter installation
  vnetSubnetID: "/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/my-rg/providers/Microsoft.Network/virtualNetworks/my-vnet/subnets/my-subnet"

  # OS disk size configuration
  # Default: 128 GB
  # Minimum: 30 GB
  osDiskSizeGB: 128

  # Maximum pods per node configuration
  # Default behavior depends on network plugin:
  # - Azure CNI with standard networking: 30 pods
  # - Azure CNI with overlay networking: 250 pods
  # - Other configurations: 110 pods
  # Range: 10-250
  maxPods: 30

  # GPU driver installation (optional)
  # Default: driver - NAP manages gpu driver installation
  # none skips gpu driver installation
  # Valid values: driver, none
  gpu:
    mode: 
      driver

  # Azure resource tags (optional)
  # Applied to all VM instances created with this AKSNodeClass
  tags:
    Environment: "production"
    Team: "platform-team"
    Application: "web-service"
    CostCenter: "engineering"

  # Kubelet configuration (optional)
  # All fields are optional with sensible defaults
  kubelet:
    # CPU management policy
    # Default: "none"
    # Valid values: none, static
    cpuManagerPolicy: "static"

    # CPU CFS quota enforcement
    # Default: true
    cpuCFSQuota: true

    # CPU CFS quota period
    # Default: "100ms"
    cpuCFSQuotaPeriod: "100ms"

    # Image garbage collection thresholds
    # imageGCHighThresholdPercent must be greater than imageGCLowThresholdPercent
    # Range: 0-100
    imageGCHighThresholdPercent: 85
    imageGCLowThresholdPercent: 80

    # Topology manager policy
    # Default: "none"
    # Valid values: none, restricted, best-effort, single-numa-node
    topologyManagerPolicy: "best-effort"

    # Allowed unsafe sysctls (optional)
    # Comma-separated list of unsafe sysctls or patterns
    allowedUnsafeSysctls:
      - "kernel.msg*"
      - "net.ipv4.route.min_pmtu"

    # Container log configuration
    # containerLogMaxSize default: "50Mi"
    containerLogMaxSize: "50Mi"
    
    # containerLogMaxFiles default: 5, minimum: 2
    containerLogMaxFiles: 5

    # Pod process limits
    # Default: -1 (unlimited)
    podPidsLimit: 4096

  security:
  # Enables trusted lunch
  # Valid values: true, false; default(or if not specified): false  
     trustedLaunch:
      secureBoot: true
      vTPM: true
  # Encryption at host
     encryptionatHost: 
      # acceptable values: [true, false] default(or if not specified): false  
      false

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

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