Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье объясняется, как настроить ресурсы 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
Убедитесь, что пользовательские DNS-серверы отвечают на запросы по UDP и TCP через порт 53 из подсети узла. Дополнительные сведения см. в разделе Проверка пользовательского DNS перед включением LocalDNS.
Определите бюджеты нарушений работы Pod для каждого критически важного приложения.
Задайте консервативный бюджет нарушений доступности для затронутых ресурсов
NodePoolперед изменениемAKSNodeClass, как показано в следующем примере:apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: default spec: disruption: budgets: - nodes: "1" # Replace one node at a timelocalDNSСначала примените изменение к непродуктивной средеAKSNodeClass. Кроме того, создайтеAKSNodeClassс включённым LocalDNS и перенесите рабочие нагрузки вNodePool, который ссылается на него.Отслеживайте ход замены, перечисляя запросы узлов. Замена считается завершенной, когда ни один 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>Убедитесь, что 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 см. в следующих статьях: