Варианты обновления и рекомендации для кластеров Службы Azure Kubernetes (AKS)

Область применения: ✔️ AKS Automatic ✔️ AKS Standard

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

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

В этой статье представлена техническая основа для обновлений AKS, охватывая варианты обновления, распространенные сценарии и рекомендации как для AKS Automatic, так и ДЛЯ AKS Standard.

Описание этой статьи

В этом техническом справочнике рассматриваются следующие сведения:

• Почему AKS Automatic является рекомендуемым по умолчанию вариантом, готовым к промышленной эксплуатации, для большинства рабочих нагрузок.
• Чем различается поведение при обновлении в AKS Automatic и AKS Standard.
• Ручные и автоматические способы обновления и когда использовать каждый из них.
• Распространенные сценарии обновления с определенными рекомендациями.
• Методы оптимизации для производительности и минимального сбоя.
• Процессы проверки и проверки перед обновлением.

Связанные рекомендации:

• Общие сведения об AKS Automatic и параметры по умолчанию см. в статье «Введение в Azure Kubernetes Service (AKS) Automatic».
• Сведения о стратегии обновления AKS, ориентированной на рабочую среду, см. в стратегиях обновления рабочей среды AKS.
• Сведения о шаблонах обновления рабочих нагрузок с отслеживанием состояния см. в разделе Шаблоны обновления рабочих нагрузок с отслеживанием состояния.
• Рекомендации по использованию сценариев см. в сценариях обновления AKS. Выберите свой путь.
• Если вы не знакомы с обновлениями AKS, начните с центра сценариев обновления для интерактивной помощи.

Быстрая навигация

Обновление операционных моделей

AKS Автоматический (рекомендуемый вариант по умолчанию для промышленной среды)

AKS Automatic по умолчанию предназначен для эксплуатации в производственной среде. Для обновления AKS Automatic предоставляет:

• Управляемые пулы системных узлов.
• Поведение автоматического обновления кластера со значениями по умолчанию, задаваемыми платформой.
• Поведение автоматического обновления образа ОС узла с частотой, ориентированной на безопасность.
• Встроенные проверки устаревших API Kubernetes.
• Поддержка планового расписания обслуживания.

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

AKS Standard (расширенная модель управления)

AKS Standard обеспечивает прямой контроль над последовательности обновления и настройкой. Вы выбираете и управляете ими:

• Настройка ручного или автоматического обновления.
• Выбор канала обновления.
• Поведение пула узлов и всплеска.
• Регламенты в отношении окон обслуживания и бюджетов допустимых сбоев рабочих нагрузок.

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

Опции обновления

Выполнение обновлений вручную

Применяется в основном к AKS Standard или к специализированным рабочим процессам.

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

• Обновление кластера AKS
• Обновление нескольких кластеров AKS с помощью Диспетчера флотов Azure Kubernetes
• Обновление образа узла
• Настройка обновления узлов при увеличении нагрузки
• Обработка обновлений узловой ОС

Настройка автоматических обновлений

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

• Автоматическое обновление кластера AKS
• Автоматическое обновление нескольких кластеров AKS с помощью Azure Kubernetes Fleet Manager
• Использование планового обслуживания для планирования и контроля обновлений
• Автоматически прекращать обновление кластера AKS при критических изменениях API (предварительная версия)
• Автоматическое обновление образов операционной системы узла кластера AKS
• Автоматическое применение обновлений безопасности к узлам AKS с помощью действий GitHub

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

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

Чтобы поддерживать баланс зон, увеличивайте нагрузку кратно трём узлам. Запросы на постоянный том, использующие диски локально избыточного хранилища Azure, привязаны к определённой зоне и могут привести к простою, если дополнительные узлы находятся в другой зоне. Используйте бюджет прерывания pod (PDB) для обеспечения высокой доступности во время дренажа.

Оптимизация обновлений для повышения производительности и минимизации сбоев

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

AKS Automatic

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

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

AKS Standard

В AKS Standard настройте параметры управления обновлением напрямую:

• Период планового обслуживания: планирование автоматического обновления в периоды низкого трафика. Используйте не менее четырёх часов.
• Максимальный всплеск: более высокие значения ускоряют процесс обновления, но могут нарушить рабочий процесс. Используйте 33% для рабочей среды.
• Максимальная недоступность: используйте, если емкость ограничена.
• Бюджет прерывания pod: Ограничивает количество pod, отключаемых во время обновлений. Проверка для службы.
• Тайм-аут вывода узла из эксплуатации: настройка длительности ожидания выгрузки контейнера. Значение по умолчанию — 30 минут.
• Время выдержки узла: поэтапные обновления помогают свести к минимуму время простоя. Значение по умолчанию — 0 минут.

Проверки, используемые в процессе обновления

AKS выполняет проверку перед обновлением, чтобы обеспечить работоспособность кластера:

• Изменения API, нарушающие совместимость: Обнаруживает устаревшие API.
• Версия обновления Kubernetes: Гарантирует допустимый путь обновления.
• Конфигурация PDB: Проверяет некорректную настройку PDB (например, maxUnavailable=0).
• Квота: Подтверждается, что квоты достаточно для узлов перегрузки.
• Подсеть: Проверяет достаточные IP-адреса.
• Сертификаты/служебные субъекты: Обнаруживает истекшие учетные данные.
• Проверка блокировки управляемых ресурсов: Проверяет наличие блокировок ресурсов, применяемых к группе ресурсов управляемого кластера.

Эти проверки действуют во всей AKS. В AKS Automatic они интегрированы в управляемый путь обновления; в AKS Standard они входят в рабочий процесс.

Распространенные сценарии и рекомендации по обновлению

Сценарий 1. Ограничения емкости

Если кластер ограничен уровнем продукта или региональной емкостью, обновления могут не удаться, если невозможно подготовить дополнительные узлы. Эта ситуация распространена с специализированными уровнями продуктов (например, узлами GPU) или в регионах с ограниченными ресурсами. Такие ошибки, как SKUNotAvailable, AllocationFailedили OverconstrainedAllocationRequest могут возникать, если maxSurge задано слишком большое значение для доступной емкости.

Автоматическое руководство AKS

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

Руководство ПО AKS Standard

• Используйте maxUnavailable для обновления, используя существующие узлы вместо добавления новых. Дополнительные сведения см. в разделе "Настройка недоступных узлов во время обновления".
• Снизьте maxSurge, чтобы уменьшить дополнительные потребности в емкости. Для получения дополнительной информации смотрите Настройка обновления узлового скачка.
• Для обновлений, предназначенных только для обеспечения безопасности, используйте образы обновлений безопасности, которые не требуют наличия дополнительных узлов. Дополнительные сведения см. в разделе "Применение обновлений системы безопасности и ядра" к узлам Linux в службе Azure Kubernetes.

Сценарий 2. Сбои очистки узлов и PDOB-файлы

Обновления требуют очистки узлов (вытеснение контейнеров). Утечки могут завершиться сбоем, если модули pod медленно завершаются или строгие бюджеты нарушений pod (PDBS) блокируют вытеснения pod.

Пример ошибки:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... Cannot evict pod as it would violate the pod's disruption budget.

Автоматическая навигация AKS

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

Руководство по AKS Standard

Вариант 1. Принудительное обновление, обход ограничений PDB

Используйте принудительное обновление только в том случае, если PDB-файлы препятствуют выполнению критически важных обновлений и их невозможно устранить. Это действие переопределяет защиту PDB и может привести к полной недоступности службы во время обновления.

Требования: Azure CLI 2.79.0 или API AKS версии 2025-09-01+

az aks upgrade \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP_NAME \
  --kubernetes-version $KUBERNETES_VERSION \
  --enable-force-upgrade \
  --upgrade-override-until yyyy-mm-ddT13:00:00Z

Вариант 2: Обработка узлов, которые невозможно осушить, с соблюдением PDB

Используйте этот консервативный подход, чтобы уважать PDB при предотвращении сбоев обновления.

Настройте поведение недренируемых узлов:

az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 30

Параметры поведения:

• По расписанию (по умолчанию): удаляет заблокированный узел и с опережением добавляет узел на замену.
• Cordon (рекомендуется): переводит узел в состояние kubernetes.azure.com/upgrade-status=Quarantined.

Максимальное число заблокированных узлов (предварительная версия):

• Указывает, сколько узлов, которые не могут быть очищены, допускается
• Требуется задать undrainable-node-behavior
• Значение по умолчанию — значение maxSurge (обычно 10%), если не указано

Предварительные требования для максимальных заблокированных узлов

Для использования функции максимального числа заблокированных узлов требуется расширение Azure CLI aks-preview версии 18.0.0b9 или более поздней.

# Install or update the aks-preview extension
az extension add --name aks-preview
az extension update --name aks-preview

Пример конфигурации с максимальными заблокированными узлами

az aks nodepool update \
  --cluster-name jizenMC1 \
  --name nodepool1 \
  --resource-group jizenTestMaxBlockedNodesRG \
  --max-surge 1 \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 5

Вариант 3. Автоматическое управление PDB (предварительная версия)

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

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

Рекомендации по предотвращению сбоев в очистке

• Настройте maxUnavailable в PDB для разрешения по крайней мере одного удаления пода.
• Увеличьте репликации подов для соблюдения требований бюджета нарушения
• Увеличьте тайм-аут ожидания завершения, если рабочие нагрузки требуют больше времени. (Значение по умолчанию — 30 минут.)
• Используйте автоматическое управление PDB для автоматизации создания PDB и масштабирования реплик во время операций очистки.
• Тестирование PDB в стейджинге, мониторинг событий обновления и использование сине-зеленых развертываний для критически важных нагрузок. Дополнительные сведения см. в разделе Сине-зеленое развертывание кластеров AKS.

Проверка неуправляемых узлов

• Заблокированные узлы незапланированы для модулей pod и помечены меткой "kubernetes.azure.com/upgrade-status: Quarantined".

• Проверьте метку на любых заблокированных узлах при сбое узла слива при обновлении:

  kubectl get nodes --show-labels=true
  

Устранение неподдающихся разгрузке узлов

1. Удалите ответственный PDB:

   kubectl delete pdb <pdb-name>
   

2. kubernetes.azure.com/upgrade-status: Quarantined Удалите метку:

   kubectl label nodes <node-name> kubernetes.azure.com/upgrade-status-
   

3. При необходимости удалите заблокированный узел:

   az aks nodepool delete-machines --cluster-name <cluster-name> --machine-names <machine-name> --name <node-pool-name> --resource-group <resource-group-name>
   

4. После завершения этого шага можно выполнить согласование состояния кластера, выполнив любую операцию обновления без необязательных полей, как описано в az aksописании. Кроме того, можно масштабировать пул узлов до того же количества узлов, что и количество обновленных узлов. Это действие гарантирует, что пул узлов получает свой исходный размер. AKS уделяет приоритетное внимание удалению заблокированных узлов. Эта команда также восстанавливает состояние подготовки кластера на Succeeded. В следующем примере 2 — общее количество обновленных узлов.

   # Update the cluster to restore the provisioning status
   az aks update --resource-group <resource-group-name> --name <cluster-name>
   
   # Scale the node pool to restore the original size
   az aks nodepool scale --resource-group <resource-group-name> --cluster-name <cluster-name> --name <node-pool-name> --node-count 2
   

Сценарий 3. Медленные обновления

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

Распространенные причины медленных обновлений:

• Низкие maxSurge или maxUnavailable значения (ограничивает параллелизм).
• Высокий период ожидания (длительные ожидания между обновлениями узлов).
• Сбои очистки (см. сбои с очисткой узлов).

Автоматическое управление AKS

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

Руководство по AKS Standard

• maxSurge=33% Используйте maxUnavailable=1 для производственной среды.
• Используйте maxSurge=50% и maxUnavailable=2 для разработки и тестирования.
• Используйте исправление системы безопасности ОС для быстрого и целевого исправления (избегайте повторного создания полного узла).
• Включите --undrainable-node-behavior, чтобы избежать блокировщиков обновления.

Сценарий 4. Исчерпание IP-адресов

Для узлов всплеска требуется больше IP-адресов. Если подсеть почти достигла вместимости, подготовка узла может пройти с ошибкой (например, Error: SubnetIsFull). Этот сценарий является распространенным для Azure Container Networking Interface, высокого уровня maxPods, или большого количества узлов.

Автоматическое наведение AKS

• Перед расширением производственной среды проверьте подсеть и планы по мощностям.
• Мониторинг использования сети в рамках обычных операций.

Руководство по AKS Standard

• Убедитесь, что в вашей подсети достаточно IP-адресов для всех узлов, дополнительных узлов и подов. Формула имеет значение Total IPs = (Number of nodes + maxSurge) * (1 + maxPods).

• Отмените неиспользуемые IP-адреса или разверните подсеть (например, от /24 до /22).

• Уменьшите maxSurge, если расширение подсети невозможно.

  az aks nodepool update \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --name <node-pool-name> \
    --max-surge 10%
  

• Мониторинг использования IP-адресов с помощью Azure Monitor или пользовательских оповещений.

• Уменьшите размер каждого узла, очистите maxPods потерянные IP-адреса подсистемы балансировки нагрузки и запланируйте размер подсети для высокомасштабируемых кластеров.

Часто задаваемые вопросы

Следует ли использовать AKS Automatic или AKS Standard для рабочих обновлений?

Для большинства рабочих нагрузок используйте AKS Automatic. Это решение разработано как готовый к промышленной эксплуатации вариант по умолчанию с управляемым процессом обновления и встроенными защитными механизмами.

Используйте AKS Standard, если требуется расширенный контроль над последовательности обновления, выбором инфраструктуры или операциями пула узлов.

Можно ли использовать средства с открытым кодом для проверки?

Да. Многие средства с открытым кодом интегрируются хорошо с процессами обновления AKS:

• kube-no-trouble (kubent): сканирует устаревшие API до обновления.
• Trivy: сканирование безопасности для образов контейнеров и конфигураций Kubernetes.
• Sonobuoy: проверка соответствия Kubernetes и проверка кластера.
• kube-bench: проверки безопасности на соответствие стандартам Центра интернет-безопасности.
• Polaris: проверка лучших практик Kubernetes.
• kubectl-neat: приведение в порядок манифестов Kubernetes для проверки.

Как проверить совместимость API перед обновлением?

Выполните проверку устаревших функций с помощью таких инструментов, как kubent.

# Install and run API deprecation scanner
kubectl apply -f https://github.com/doitintl/kube-no-trouble/releases/latest/download/knt-full.yaml

# Check for deprecated APIs in your cluster
kubectl run knt --image=doitintl/knt:latest --rm -it --restart=Never -- \
  -c /kubeconfig -o json > api-deprecation-report.json

# Review findings
cat api-deprecation-report.json | jq '.[] | select(.deprecated==true)'

Что отличает обновления AKS от других платформ Kubernetes?

AKS предоставляет несколько уникальных преимуществ:

• Управляемые эксплуатационные сценарии в AKS Automatic для снижения трудозатрат на обновление.
• Встроенная интеграция Azure с Диспетчером трафика Azure, Azure Load Balancer и сетью.
• Диспетчер флота Azure Kubernetes для координации многокластерных обновлений.
• Автоматическое исправление образа узла без ручного управления узлами.
• Встроенная проверка квот, сетей и учетных данных.
• Поддержка Azure для проблем, связанных с обновлением.

Выбор пути обновления

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

Готовы к выполнению?

Все еще думаете?

Используйте центр сценариев обновления для структурированного дерева принятия решений, которое учитывает ваши:

• Допустимое время простоя
• Сложность среды
• Профиль риска
• Ограничения временной шкалы

Окончательные рекомендации

• Используйте AKS Automatic для большинства рабочих нагрузок.
• Ознакомьтесь с руководством по исправлению и обновлению AKS, чтобы получить лучшие практики и советы по планированию перед началом обновления.
• Всегда проверяйте критические изменения API и проверяйте совместимость рабочей нагрузки с целевой версией Kubernetes.
• Проверьте параметры обновления (например maxSurge, maxUnavailableи PDB) в промежуточной среде, чтобы свести к минимуму рабочий риск.
• Отслеживайте события обновления и работоспособности кластера на протяжении всего процесса.