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

В этой статье рассматриваются варианты обновления кластеров AKS и предоставляются рекомендации на основе сценариев для распространенных проблем обновления.

• Сведения об обновлении базовой версии Kubernetes см. в разделе "Обновление кластера AKS".
• Сведения о кластерах с несколькими пулами узлов или узлами Windows Server см. в статье Об обновлении пула узлов в AKS.
• Сведения об обновлении определенного пула узлов без полного обновления кластера см. в статье Об обновлении определенного пула узлов.

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

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

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

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

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

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

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

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

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

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

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

• Запланированное окно обслуживания: Автоматическое обновление в период низкого трафика (рекомендуется минимум четыре часа)
• Максимальный всплеск: более высокие значения ускоряют обновления, но могут нарушить рабочие нагрузки; для производственной среды рекомендуется 33%
• Максимальная недоступность: используйте, если емкость ограничена
• Бюджет прерывания подов: задавать ограничение подов во время процесса обновления; проверять для вашего сервиса
• Время ожидания очистки узлов: настройка длительности ожидания вытеснения pod (по умолчанию 30 минут)
• Время замачивания узла: поэтапное обновление для минимизации времени простоя (по умолчанию 0 минут)

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

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

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

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

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

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

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

Рекомендации по предотвращению или разрешению

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

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

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

• Модули pod медленно завершаются (длительные перехватчики завершения работы или постоянные подключения).
• Строгие Pod Disruption Budgets (PDBs) блокируют эвакуацию pod.

Пример сообщения об ошибке:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... failed with Too Many Requests error. This is often caused by a restrictive Pod Disruption Budget (PDB) policy. See https://aka.ms/aks/debugdrainfailures. Original error: Cannot evict pod as it would violate the pod's disruption budget. PDB debug info: ... blocked by pdb ... with 0 unready pods.

Рекомендации по предотвращению или разрешению

• Установите maxUnavailable в PDB, чтобы разрешить вытеснение по крайней мере одного пода.
• Увеличьте количество реплик pod'а, чтобы бюджет на сбои мог терпеть вытеснения.
• Используйте undrainableNodeBehavior для продолжения обновления, даже если некоторые узлы не могут быть осушены.
  • Расписание (по умолчанию): Замена узлов и всплесков может быть отменена, что уменьшит емкость.
  • Cordon (рекомендуется): Узел оцеплен и помечен как kubernetes.azure.com/upgrade-status=Quarantined.

    • Пример команды:

      az aks nodepool update \
        --resource-group <resource-group-name> \
        --cluster-name <cluster-name> \
        --name <node-pool-name> \
        --undrainable-node-behavior Cordon
      

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

      "upgradeSettings": {
      "drainTimeoutInMinutes": null,
      "maxSurge": "1",
      "nodeSoakDurationInMinutes": null,
      "undrainableNodeBehavior": "Cordon"
      }
      

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

• [Предварительный просмотр] Функция "Максимально допустимое количество заблокированных узлов" позволяет указать, сколько узлов, которые не могут быть отключены (заблокированные узлы), могут быть разрешены во время обновлений или аналогичных операций. Эта функция работает только в том случае, если задано неуправляемое свойство поведения узла; в противном случае команда вернет ошибку.

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

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

  Пример команды:

  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
  

• Продлите время ожидания сброса, если рабочим нагрузкам требуется больше времени (по умолчанию — 30 минут).
• Тестирование PDB в стейджинге, мониторинг событий обновления и использование сине-зеленых развертываний для критически важных нагрузок. Подробнее.

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

• Заблокированные узлы незапланированы для модулей 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> <label-name>
   

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

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

4. После выполнения этого шага можно выполнить согласование состояния кластера, выполнив любую операцию обновления без необязательных полей, как описано здесь. Кроме того, можно масштабировать пул узлов до того же количества узлов, что и количество обновленных узлов. Это действие гарантирует, что пул узлов получает свой исходный размер. 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 значения (ограничивает параллелизм).
• Высокий период ожидания (длительные ожидания между обновлениями узлов).
• Сбои дренажа (см. сбои дренажа узлов).

Рекомендации по предотвращению или разрешению

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

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

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

Рекомендации по предотвращению или разрешению

• Убедитесь, что в подсети достаточно 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 для получения лучших практик и советов по планированию перед началом любого обновления.
• Всегда проверяйте критические изменения API и проверяйте совместимость рабочих нагрузок с целевой версией Kubernetes.
• Проверьте параметры обновления (например maxSurge, maxUnavailableи PDB) в промежуточной среде, чтобы свести к минимуму рабочий риск.
• Отслеживайте события обновления и работоспособности кластера на протяжении всего процесса.