Политика прерывания узлов в Azure Kubernetes Service (AKS) (предварительная версия)

При управлении кластерами AKS и обслуживании некоторые изменения конфигурации требуют повторного создания узлов. Эта операция повторного создания образа активирует последовательное обновление, которое повторно создает узлы. Во время операции переустановки образа AKS помечает узел как недоступный для планирования новых pod, освобождает его от существующих pod (вытесняя их и перепланируя на другие доступные узлы с учетом бюджетов нарушений доступности Pod (Pod Disruption Budgets)), а затем переустанавливает образ узла с обновленной конфигурацией. Этот процесс представляет собой полное пересоздание узла, а не перезагрузку — базовая виртуальная машина переустанавливается из нового образа ОС. В то время как правильно настроенные постоянные тома (с помощью дисков Azure, Файлы Azure или другого внешнего хранилища) не затрагиваются, все данные, хранящиеся в локальном эфемерном хранилище узла (например, томах EmptyDir или локальных путях), окончательно теряются. Эти операции необходимы для применения важных обновлений, но они могут нарушить выполнение рабочих нагрузок и повлиять на доступность приложений. Политика прерывания узлов позволяет точно контролировать, когда эти разрушительные операции могут продолжаться, помогая сбалансировать необходимость обновлений с операционной стабильностью.

Important

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

Что такое политика прерывания узла?

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

  • Планируйте операции, вызывающие сбои, на время окон обслуживания.
  • Блокировать изменения конфигурации во время критически важных бизнес-периодов, сохраняя возможность обновления образа узла и исправлений безопасности.
  • Сохраняйте прогнозируемую работу кластера во время событий с высоким трафиком.

Политика применяется к изменениям конфигурации, инициированным пользователем, для которых требуется повторное использование узлов, например обновление сертификатов доверия пользовательского центра сертификации (ЦС), изменение параметров профиля безопасности или изменение конфигурации ОС узла.

Note

Важно отметить, что эта политика не блокирует обновления версии образа узла (включая каналы обновления SecurityPatch и NodeImage) или обновление версии Kubernetes. Эти операции продолжают продолжаться в соответствии с настроенными расписаниями, даже если политика задана Block. Дополнительные сведения см. в статье об операциях обновления, не контролируемых политикой прерывания узла. Кроме того, некоторые операции восстановления не контролируются этой политикой, чтобы обеспечить работоспособность кластера и доступность. Дополнительные сведения см. в разделе "Операции восстановления", не контролируемые политикой прерывания узла.

Как работает политика прерывания узла

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

  • Оценка политики: AKS оценивает, разрешена ли операция на основе текущей политики.
  • Проверка периода обслуживания (если применимо): при использовании AllowDuringMaintenanceWindowAKS проверяет, входит ли текущее время в настроенное время обслуживания.
  • Выполнение или блокировка операции: операция, нарушающая работу узла, выполняется, если это разрешено, или отклоняется с сообщением об ошибке, если она заблокирована.

Параметры политики

Политика сбоев узлов поддерживает три конфигурации политики:

Policy Description Сценарий использования
Allow Позволяет выполнять операции, требующие повторного создания образа узла в любое время. Это поведение по умолчанию. Используйте, если хотите в первую очередь быстро применять обновления и можете допустить перебои в рабочей нагрузке.
AllowDuringMaintenanceWindow Блокирует операции, требующие переустановки образа узла, если они не выполняются в течение aksManagedNodeOSUpgradeSchedule окна обслуживания. Конфигурация может использовать встроенное расписание или быть связана с общим окном обслуживания. Используйте этот параметр, если хотите ограничить сбои конкретными окнами обслуживания, соответствующими вашему рабочему графику.
Block Блокирует все операции, требующие повторного воспроизведения узла. Используйте, когда необходимо предотвратить любые нарушения работы узла, такие как в критически важные бизнес-периоды или события с высоким трафиком.

Note

При использовании AllowDuringMaintenanceWindow необходимо настроить окно обслуживания aksManagedNodeOSUpgradeSchedule. Конфигурация обслуживания может определить расписание непосредственно в конфигурации или ссылаться на общее окно обслуживания. Дополнительные сведения о настройке периодов обслуживания см. в статье "Использование планового обслуживания для планирования и контроля обновлений для кластера Служба Azure Kubernetes". Если окно обслуживания не настроено, разрешены операции, нарушающие работу узла.

Considerations

При использовании политики прерывания узлов следует учитывать следующие рекомендации.

Операции, охватываемые политикой прерывания узла

Операции на уровне кластера

Включение сетевой политики и обновление Azure CNI Overlay

Чтобы установить необходимые сетевые компоненты и настроить сетевые правила, которые защищают обмен данными pod-to-pod и управляют ими, необходимо повторно использовать узлы.

В следующей таблице описаны обновления политики сети, которые активируют повторное создание образа:

От Кому
Нет (нет политики сети) политика сети Azure
Нет (нет политики сети) Calico
Azure CNI Сетевой слой Azure CNI
политика сети Azure Нет (нет политики сети)
Calico Нет (нет политики сети)

Note

Переключение между сетевыми политиками Azure и Calico после того, как одна из них уже включена, не требует переустановки образа.

Изменения канала обновления ОС узла

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

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

От Кому
Неуправляемые Нет
Не определено Неуправляемые
SecurityPatch Неуправляемые
NodeImage Неуправляемые
Нет Неуправляемые
Не определено Неуправляемые
Неуправляемые SecurityPatch
Неуправляемые NodeImage

Включение двойного стека IPv6

Для поддержки обмена данными с двумя стеками узлы нуждаются в конфигурациях IP-адресов IPv4 и IPv6 и обновлениях сетевого стека (например, правила nftables).

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

От Кому
Только IPv4 IPv4 + IPv6 (двойной стек)

Изменения плоскости данных Cilium

Необходимо установить или удалить программы eBPF, обрабатывающие обработку пакетов на уровне ядра.

В следующей таблице перечислены изменения в плоскости данных Cilium, которые требуют переустановки образа:

От Кому
Нет Cilium
Cilium Нет

Обновления конфигурации прокси-сервера HTTP

Все компоненты узла (контейнеры, kubelet, системные службы) нуждаются в обновленной конфигурации прокси-сервера, применяемой системой. При обновлении конфигурации прокси-сервера HTTP AKS автоматически обновляет все пулы узлов в кластере.

Политика прерывания узла активирует повторное создание образа при изменении любого из следующих свойств конфигурации прокси-сервера HTTP или выполнения любой из следующих операций:

  • httpProxy: URL-адрес прокси-сервера для HTTP-подключений
  • httpsProxy: URL-адрес прокси-сервера для подключений HTTPS
  • noProxy: список адресов, исключённых из проксирования
  • trustedCa: альтернативный сертификат ЦС в кодировке Base64
  • Включить HTTP-прокси в кластере (with --enable-http-proxy)
  • Отключение прокси-сервера HTTP в кластере (с --disable-http-proxy)
  • Повторное использование HTTP-прокси в кластере, который ранее отключил его

Обновления пользовательских сертификатов ЦС

Необходимо установить новые сертификаты ЦС в хранилище доверия ОС, чтобы повлиять на проверку TLS для внутренних служб и частных реестров.

Политика нарушения работы узла запускает переустановку образа при добавлении, удалении или обновлении пользовательских сертификатов центра сертификации.

Изменения идентификационных данных Kubelet

Необходимо применить новые идентификационные учетные данные в конфигурации узла. К ним относятся начальное назначение удостоверений, обновления удостоверений и сброс профиля субъекта-службы.

Политика нарушения работы узлов приводит к переустановке образа при обновлении управляемой идентичности или назначаемой пользователем управляемой идентичности для kubelet.

изменения зоны Частная зона DNS

Необходимо обновить параметры сопоставителя DNS, чтобы разрешить конечную точку сервера частного API с помощью новой зоны DNS.

Политика нарушения работы узлов инициирует переустановку образа при изменении конфигурации частной DNS-зоны в частном кластере.

Включение интеграции сервера API с виртуальной сетью

Необходимо перенастроить узлы для взаимодействия с сервером API с помощью IP-адреса внутренней подсистемы балансировки нагрузки, проецируемого в делегированную подсеть.

Политика нарушения работы узлов инициирует пересоздание образа при включении интеграции API Server с виртуальной сетью (VNet) в существующем кластере, который ранее не использовал эту интеграцию. Это изменение соответствует изменению свойства apiServerAccessProfile.enableVnetIntegration (внутренне — поля privateConnectProfile.enabled) с false (или отсутствующего значения) на true:

От Кому
apiServerAccessProfile.enableVnetIntegration: false или не задано apiServerAccessProfile.enableVnetIntegration: true

Изменения маршрутизации узлов eBPF

Необходимо установить или удалить программы eBPF, обеспечивающие высокопроизводительную пересылку пакетов (режим ускорения BpfVeth).

В следующей таблице приведены изменения маршрутизации на узле eBPF, которые требуют переустановки образа:

От Кому
Стандартная маршрутизация Включена маршрутизация узла eBPF
Включена маршрутизация узла eBPF Стандартная маршрутизация

Операции на уровне пула узлов

Эти операции влияют только на определенные пулы узлов, в которых вы вносите изменения. Они запускают поэтапное пересоздание образов в этих пулах узлов:

Обновления локального профиля DNS

Необходимо применить изменения к управляющей программе кэширования DNS и правилам пересылки DNS на уровне узла.

Политика нарушения работы узла запускает переустановку образа при изменении конфигурации профиля LocalDNS.

Изменения безопасности Trusted Launch

Вы не можете изменить конфигурацию встроенного ПО виртуальной машины и параметры процесса загрузки на работающих виртуальных машинах. Эти изменения требуют повторного создания виртуальных машин.

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

Конфигурация От Кому
vTPM (модуль виртуальной доверенной платформы) Disabled Enabled
vTPM (модуль виртуальной доверенной платформы) Enabled Disabled
Безопасная загрузка Disabled Enabled
Безопасная загрузка Enabled Disabled

Изменения в потоковой передаче артефактов

Чтобы обеспечить более быструю загрузку образов контейнеров за счёт потоковой передачи слоёв образа по запросу, необходимо установить или удалить компоненты потоковой передачи артефактов.

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

От Кому
Disabled Enabled
Enabled Disabled

обновления профиля Windows GMSA (только для пулов узлов Windows)

Необходимо применить новые параметры GMSA, конфигурацию DNS-сервера и учетные данные присоединения к домену для интеграции Active Directory на узлах Windows.

Политика нарушения работы узлов запускает переустановку образа пулов узлов Windows, если изменение GMSA требует применения новой конфигурации узла:

От Кому Запускает повторное создание образа
GMSA отключен GMSA включена Yes
GMSA включена (DNS-сервер или корневой домен задан или изменён) GMSA включен с обновленным DNS-сервером или корневым доменом Yes
GMSA включена (DNS-сервер задан) GMSA отключен Yes
GMSA включен (без набора DNS-сервера) GMSA отключен Нет (конфигурация узла не применяется)

Вложение группы резервирования емкости

Необходимо пересоздать базовые виртуальные машины, чтобы они развертывались с использованием зарезервированной мощности в группе резервирования мощности (CRG). Существующие узлы не были подготовлены для CRG, поэтому AKS должен повторно создать пул узлов, чтобы связать их с резервированием.

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

От Кому Запускает повторное создание образа
Группа резервирования емкости не подключена Присоединенная группа резервирования емкости Yes

Операции, охватываемые политикой прерывания узла в Kubernetes 1.37 и более поздних версиях

В Kubernetes 1.37 и более поздних версиях политика нарушения работы узлов распространяется на следующие изменения конфигурации, которые требуют переустановки образа узла. В Kubernetes 1.36 и более ранних версиях после внесения этих изменений конфигурации необходимо вручную выполнить az aks nodepool upgrade с --node-image-only, чтобы применить их к вашим узлам.

  • Изменения конфигурации SSH: изменение методов доступа SSH (SSH отключен, SSH на основе Entra ID или SSH с локальным пользователем) или обновление публичных ключей SSH в пулах узлов.
  • Изменения ограничений IMDS: включение или отключение ограничения службы метаданных экземпляра (IMDS) для блокировки доступа pod к конечной точке IMDS.
  • Изменения профиля начальной загрузки: изменение профиля начальной загрузки, например переключение artifactSource между Direct и Cache или изменение containerRegistryId (реестра Реестр контейнеров Azure, используемого для кластеров с изолированной сетью).
  • Изменения исходящего типа: изменение исходящего типа подключения кластера (loadBalancer, userDefinedRouting, managedNATGateway или userAssignedNATGateway).

Операции обновления, на которые не распространяется политика прерывания работы узла

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

  • Обновления версий образа узла: обновление до новой версии образа ОС узла (вручную или через каналы автоматического обновления). Эта операция является наиболее распространенной операцией повторного воспроизведения и включает исправления безопасности, обновления ОС и выпуски образов узлов AKS.
  • Обновление версии Kubernetes: обновление версии Kubernetes в пуле узлов, которое включает новые исполняемые файлы Kubernetes, обновленную конфигурацию kubelet и изменения на уровне ОС.

Операции восстановления, не контролируемые политикой прерывания узла

Политика прерывания узлов не управляет следующими автоматическими операциями восстановления. Эти операции могут выполняться независимо от параметра политики, чтобы обеспечить работоспособность кластера и восстановление.

  • Откат конфигурации пула узлов: если операция обновления пула узлов завершается сбоем из-за недопустимой конфигурации или проблем с инфраструктурой, AKS автоматически выполняет откат к последнему работоспособному состоянию и повторно создает образы узлов, чтобы восстановить конфигурацию.
  • Административные операции по восстановлению кластера: когда инженеры службы поддержки Azure выполняют административное восстановление кластера при устранении инцидентов, на узлы повторно устанавливается образ, чтобы обеспечить согласованность между состоянием управляющей плоскости и конфигурацией узлов.
  • Обновление учетных данных идентификатора узла: AKS периодически обновляет учетные данные идентификатора узла в целях безопасности и соответствия требованиям. Эти обновления, инициированные системой, активируют повторное создание образа узла для применения новых учетных данных во всех пулах узлов.

Интеграция с запланированным обслуживанием

Политика прерывания узлов бесшовно интегрируется с окнами планового обслуживания AKS. При установке политики AllowDuringMaintenanceWindow операции, вызывающие сбои, будут выполняться в рамках периода обслуживания aksManagedNodeOSUpgradeSchedule. Расписание может быть встроенным или связанным с общим окном обслуживания. Эта интеграция гарантирует следующее:

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

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

Note

При использовании AllowDuringMaintenanceWindow необходимо настроить окно обслуживания aksManagedNodeOSUpgradeSchedule. Использование default окна обслуживания или aksManagedAutoUpgradeSchedule (автоматического обновления кластера) не соответствует этому требованию. Конфигурация aksManagedNodeOSUpgradeSchedule, связанная с общим периодом обслуживания, действительно удовлетворяет этому требованию. Если вы зададите AllowDuringMaintenanceWindow без настроенного окна aksManagedNodeOSUpgradeSchedule, все деструктивные операции будут разрешены (политике нечем их ограничивать). Дополнительные сведения о настройке периодов обслуживания см. в статье "Использование планового обслуживания для планирования и контроля обновлений для кластера Служба Azure Kubernetes".

Лучшие практики

При реализации политики прерывания узла рассмотрите следующие рекомендации.

  • Используйте AllowDuringMaintenanceWindow в продукционной среде: Комбинируйте с запланированными окнами обслуживания, чтобы контролировать, когда перебои будут происходить в продукционной среде.
  • Установите Block в критические периоды: временно блокируются разрушительные операции во время событий с высоким трафиком, запусков продуктов или реагирования на инциденты. Не используйте Block неограниченное время. Хотя Block это подходит для краткосрочных заморозок (запланированные события, реагирование на инциденты).
  • Обеспечьте гибкость в непроизводственных средах: используйте Allow в средах разработки и тестирования, где быстрая итерация важнее стабильности.
  • Изменение политики обмена данными. Убедитесь, что ваша команда понимает текущую политику и знает, когда операции могут быть заблокированы.
  • Планируйте окна обслуживания надлежащим образом: определяйте длительность окон обслуживания так, чтобы в них можно было выполнить необходимые операции.
  • Проверка поведения политики: проверяйте параметры политики в непроизводственных средах перед их применением к продуктивным кластерам.
  • Мониторинг заблокированных операций: отслеживайте, когда операции блокируются для оптимизации расписания обслуживания.

Связанные материалы

  • Последнее обновление: