руководство по исправлению и обновлению Служба Azure Kubernetes

В этом разделе руководства по операциям Служба Azure Kubernetes (AKS) 2 описаны стратегии исправления и обновления рабочих узлов AKS и версий Kubernetes. В качестве оператора кластера необходимо иметь план для поддержания актуальности кластеров и мониторинга изменений и отмены api Kubernetes с течением времени.

Фон и типы обновлений

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

Тип обновления	Частота обновления	Поддерживаемое плановое обслуживание	Поддерживаемые методы операций	Назначение	Ссылка на документацию
Исправления безопасности ос узла	В ночное время	Да	Автоматический (еженедельно), вручную или неуправляемый (ночью)	Узел	Образы узлов автоматического обновления
Обновления версий образа узла	Linux: еженедельно Windows: Ежемесячно	Да	Автоматический, ручной	Пул узлов	Обновление образа узла AKS
Обновления версии Kubernetes (кластер)	Ежеквартально	Да	Автоматический, ручной	Пул кластеров и узлов	Обновление кластера AKS

Типы обновлений

• Исправления безопасности операционной системы узла (только для Linux). Для узлов Linux как каноническая Ubuntu, так и Azure Linux предоставляют исправления безопасности операционной системы один раз в день. Корпорация Майкрософт тестирует и объединяет эти исправления в еженедельных обновлениях образов узлов.

• Еженедельные обновления образов узлов. AKS предоставляет еженедельные обновления образов узлов. К этим обновлениям относятся последние исправления безопасности ОС и AKS, исправления ошибок и улучшения. Обновления узлов не изменяют версию Kubernetes. Версии форматируются по дате (например, 202311.07.0) для Linux и по дате сборки и ос Windows Server (например, 20348.2113.23115) для Windows. Дополнительные сведения см. в разделе "Состояние выпуска AKS".

• Квартальные выпуски Kubernetes. AKS предоставляет квартальные обновления для выпусков Kubernetes. Эти обновления позволяют пользователям AKS воспользоваться новейшими функциями и усовершенствованиями Kubernetes. Они включают исправления безопасности и обновления образа узла. Дополнительные сведения см. в статье "Поддерживаемые версии Kubernetes" в AKS.

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

Общее влияние кластера

• Обновления на месте (как узел, так и кластер) влияют на производительность среды Kubernetes во время выполнения. Этот эффект можно свести к минимуму с помощью надлежащей настройки бюджетов сбоев pod, конфигурации всплеска узлов и правильного планирования.
• Использование стратегии синих и зеленых обновлений вместо обновления на месте устраняет любое влияние на производительность кластера, но увеличивает затраты и сложность.
• Независимо от стратегии обновления и исправления, необходимо иметь надежный процесс тестирования и проверки для кластера. Сначала исправьте и обновите более низкие среды и выполните проверку после обслуживания, чтобы проверить кластер, узел, развертывание и работоспособность приложений.

Рекомендации по работе с рабочей нагрузкой AKS

Чтобы обеспечить плавную работу кластера AKS во время обслуживания, выполните следующие рекомендации.

• Определите бюджеты нарушений pod (PDB). Настройка бюджетов сбоев pod для развертываний важна. PDB применяют минимальное количество доступных реплик приложений для обеспечения непрерывной функциональности во время событий сбоя. PDB-файлы помогают поддерживать стабильность кластера во время обслуживания или сбоев узлов.

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

  Неправильно настроенные PDF-файлы могут блокировать процесс обновления, так как API Kubernetes предотвращает необходимый кордон и утечку, которая возникает при обновлении образа узла. Кроме того, при одновременном перемещении слишком большого количества модулей pod может произойти сбой приложения. Конфигурация PDB устраняет этот риск.

• Проверьте доступные ограничения вычислительных ресурсов и сети. Проверьте доступные ограничения вычислений и сети в подписке Azure с помощью страницы квоты в портал Azure или с помощью команды az quota. Проверьте вычислительные ресурсы и сетевые ресурсы, особенно виртуальные ЦП виртуальных машин для узлов, а также количество виртуальных машин и масштабируемых наборов виртуальных машин. Если вы приближаетесь к ограничению, отправьте запрос на увеличение квоты перед обновлением.
• Проверьте доступное ПРОСТРАНСТВО IP-адресов в подсетях узлов. Во время обновлений в кластере создаются дополнительные узлы всплеска, а модули pod перемещаются на эти узлы. Важно отслеживать пространство IP-адресов в подсетях узла, чтобы обеспечить достаточное адресное пространство для этих изменений. Разные конфигурации сети Kubernetes имеют разные требования к IP-адресам. В качестве отправной точки ознакомьтесь с этими соображениями:
  • Во время обновления количество IP-адресов узлов увеличивается в соответствии со значением всплеска. (Минимальное значение всплеска равно 1.)
  • Кластеры, основанные на Azure CNI, назначают IP-адреса отдельным модулям pod, поэтому для перемещения pod требуется достаточное пространство IP-адресов.
  • Кластер продолжает работать во время обновления. Убедитесь, что в левом ip-адресе достаточно места, чтобы разрешить масштабирование узлов (если он включен).
• Настройка нескольких сред. Рекомендуется настроить отдельные среды, такие как разработка, промежуточное развертывание и производство, чтобы можно было протестировать и проверить изменения перед их развертыванием в рабочей среде.
• Настройка значений обновления всплеска. По умолчанию AKS имеет значение 1, что означает, что в процессе обновления создается один дополнительный узел. Вы можете увеличить скорость обновления AKS, увеличив это значение. 33% — это рекомендуемое максимальное значение для рабочих нагрузок, чувствительных к нарушениям. Дополнительные сведения см. в разделе "Настройка обновления всплеска узла".
• Настройка времени ожидания очистки узлов. Время ожидания очистки узлов указывает максимальное время ожидания кластера при попытке перепланировать модули pod на узле, обновляемом. Значение по умолчанию для этого составляет 30 минут. Для рабочих нагрузок, которые пытаются перепланировать модули pod, можно настроить это значение по умолчанию.
• Планирование и планирование периодов обслуживания. Процессы обновления могут повлиять на общую производительность кластера Kubernetes. Планирование процессов обновления на месте за пределами окон пикового использования и мониторинг производительности кластера для обеспечения достаточного размера, особенно во время процессов обновления.
• Проверьте другие зависимости в кластере. Операторы Kubernetes часто развертывают другие средства в кластере Kubernetes в рамках операций, таких как масштабировщики KEDA, Dapr и сетки служб. При планировании процессов обновления проверьте заметки о выпуске всех компонентов, которые вы используете, чтобы обеспечить совместимость с целевой версией.

Управление еженедельными обновлениями образов узлов

Корпорация Майкрософт создает новый образ узла для узлов AKS примерно один раз в неделю. Образ узла содержит актуальные исправления системы безопасности ОС, обновления ядра ОС, обновления системы безопасности Kubernetes, обновленные версии двоичных файлов, такие как kubelet, и обновления версий компонентов, перечисленные в заметках о выпуске.

При обновлении образа узла действие кордона и очистки активируется на узлах целевого пула узлов:

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

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

Автоматическое обновление образа узла

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

Доступные каналы включают следующие:

• None. Никакие обновления не применяются автоматически.
• Unmanaged. Обновления Ubuntu и Azure Linux применяются операционной системой на ночной основе. Перезагрузки должны управляться отдельно. AKS не может проверить это и не контролировать периодичность этого.
• SecurityPatch. Исправления системы безопасности, тестируемые AKS, полностью управляемые и применяемые с использованием безопасных методов развертывания. Она не содержит исправлений ошибок ОС только для системы безопасности.
• NodeImage. AKS обновляет узлы с недавно исправленным виртуальным жестким диском, содержащим исправления безопасности и исправления ошибок на еженедельной частоте. Это полностью протестировано и развернуто с помощью безопасных методик развертывания. Сведения о развернутых образах узлов в режиме реального времени см. в статье об обновлениях образов узлов AKS.

Сведения о частотах по умолчанию без установленного периода обслуживания см. в разделе "Владение обновлениями" и "Частота".

При выборе Unmanaged канала обновления необходимо управлять процессом перезагрузки с помощью средства, например курированного. Unmanaged не предоставляет безопасные методики развертывания, предоставляемые AKS, и не будет работать в период обслуживания. Если вы выберете SecurityPatch канал обновления, обновления можно применять так же часто, как еженедельно. Для этого уровня исправлений требуется, чтобы виртуальные жесткие диски хранились в вашей группе ресурсов, которая взимает номинальную плату. SecurityPatch Управление применением путем задания соответствующего aksManagedNodeOSUpgradeSchedule значения, соответствующего курсу, который лучше всего подходит для рабочей нагрузки. Дополнительные сведения см. в разделе "Создание периода обслуживания". Если вам также нужны исправления ошибок, которые обычно приходят с новыми образами узлов (VHD), то вместо этого SecurityPatchнужно выбрать NodeImage канал.

Рекомендуется использовать NodeImage канал обновления и настроить aksManagedNodeOSUpgradeSchedule период обслуживания до времени, когда кластер находится за пределами пиковых окон использования. См. раздел "Создание периода обслуживания" для атрибутов, которые можно использовать для настройки периода обслуживания кластера. Основные атрибуты:

• name. Используется aksManagedNodeOSUpgradeSchedule для обновлений ОС узла.
• utcOffset. Настроить часовой пояс.
• startTime. Задайте время начала периода обслуживания.
• dayofWeek. Задайте дни недели для окна. Например, Saturday.
• schedule. Задайте частоту окна. Для NodeImage обновлений рекомендуется weekly.
• durationHours. Задайте для этого атрибута по крайней мере четыре часа.

В этом примере устанавливается еженедельное время обслуживания до 8:00 восточного времени в субботу:

az aks maintenanceconfiguration add -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule --utc-offset=-05:00 --start-time 20:00 --day-of-week Saturday --schedule-type weekly --duration 4

Дополнительные примеры см. в статье "Добавление конфигурации периода обслуживания" с помощью Azure CLI.

В идеале эта конфигурация будет развернута в рамках развертывания кластера в виде инфраструктуры как кода.

Вы можете проверить настроенные периоды обслуживания с помощью Azure CLI:

az aks maintenanceconfiguration list -g <ResourceGroupName> --cluster-name <AKSClusterName>

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

az aks maintenanceconfiguration show -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule

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

Внимание

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

В этой ситуации можно рассмотреть одно из следующих вариантов:

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

Вы можете проверить состояние событий обновления с помощью журналов действий Azure или просмотреть журналы ресурсов в кластере.

Вы можете подписаться на события Служба Azure Kubernetes (AKS) с Сетка событий Azure, включая события обновления AKS. Эти события могут оповещать вас, когда доступна новая версия Kubernetes, и помочь отслеживать изменения состояния узла во время процессов обновления.

Вы также можете управлять процессом еженедельного обновления с помощью GitHub Actions. Этот метод обеспечивает более детализированный контроль процесса обновления.

Процесс обновления узла вручную

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

kubectl describe nodes <NodeName>

Пример выходных данных (фрагмент):

System Info:
  Machine ID:                 bb2e85e682ae475289f2e2ca4ed6c579
  System UUID:                6f80de9d-91ba-490c-8e14-9e68b7b82a76
  Boot ID:                    3aed0fd5-5d1d-4e43-b7d6-4e840c8ee3cf
  Kernel Version:             5.15.0-1041-azure
  OS Image:                   Ubuntu 22.04.2 LTS
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.7.1+azure-1
  Kubelet Version:            v1.26.6
  Kube-Proxy Version:         v1.26.6

Используйте команду azure CLI az aks nodepool list , чтобы определить версии образов узлов в кластере:

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,NodeImageVersion:nodeImageVersion}" --output table

Пример результата:

Name       NodeImageVersion
---------  ---------------------------------------------
systempool  AKSUbuntu-2204gen2containerd-202307.12.0
usernodepool  AKSUbuntu-2204gen2arm64containerd-202307.12.0

Используйте az aks nodepool get-upgrades , чтобы определить последнюю доступную версию образа узла для определенного пула узлов:

az aks nodepool get-upgrades \
   --resource-group <ResourceGroupName> \
   --cluster-name <AKSClusterName> \
   --nodepool-name <NodePoolName> --output table

Пример результата:

KubernetesVersion    LatestNodeImageVersion                         Name     OsType
-------------------  ---------------------------------------------  -------  --------
1.26.6               AKSUbuntu-2204gen2arm64containerd-202308.10.0  default  Linux

Обновления кластера

Сообщество Kubernetes выпускает дополнительные версии Kubernetes примерно каждые три месяца. Чтобы сообщить о новых версиях и выпусках AKS, страница заметок о выпуске AKS обновляется регулярно. Вы также можете подписаться на RSS-канал GitHub AKS, который предоставляет обновления в режиме реального времени об изменениях и улучшениях.

AKS следует политике поддержки N - 2 , что означает, что полная поддержка предоставляется для последнего выпуска (N) и двух предыдущих дополнительных версий. Поддержка ограниченной платформы предлагается для третьей предыдущей дополнительной версии. Дополнительные сведения см . в политике поддержки AKS.

Чтобы обеспечить поддержку кластеров AKS, необходимо установить процесс непрерывного обновления кластера. Этот процесс включает тестирование новых версий в более низких средах и планирование обновления до рабочей до новой версии по умолчанию. Такой подход может поддерживать прогнозируемость в процессе обновления и свести к минимуму нарушения работы приложений. Дополнительные сведения см. в статье Обновление кластера службы Azure Kubernetes (AKS).

Если кластеру требуется более длительный цикл обновления, используйте версии AKS, поддерживающие параметр долгосрочной поддержки (LTS). Если включить параметр LTS, корпорация Майкрософт предоставляет расширенную поддержку версий Kubernetes в течение двух лет, что обеспечивает более длительный и контролируемый цикл обновления. Дополнительные сведения см. в статье "Поддерживаемые версии Kubernetes" в AKS.

Обновление кластера включает обновление узла и использует аналогичный процесс кордона и очистки.

Перед обновлением

Рекомендуется всегда обновлять и тестировать в более низких средах, чтобы свести к минимуму риск нарушения работы в рабочей среде. Обновления кластера требуют дополнительного тестирования, так как они включают изменения API, которые могут повлиять на развертывания Kubernetes. Следующие ресурсы могут помочь вам в процессе обновления:

• Книга AKS для устаревших API. На странице обзора кластера в портал Azure можно выбрать команду "Диагностика и решение проблем", перейти в категорию "Создание", "Обновить", "Удалить" и "Масштабировать", а затем выбрать устаревшие api Kubernetes. Для этого выполняется книга, которая проверяет наличие устаревших версий API, используемых в кластере. Дополнительные сведения см. в разделе "Удаление использования устаревших API".
• Страница заметок о выпуске AKS. Эта страница содержит подробные сведения о новых версиях и выпусках AKS. Просмотрите эти заметки, чтобы оставаться в курсе последних обновлений и изменений.
• Страница заметок о выпуске Kubernetes. Эта страница содержит подробные сведения о последних версиях Kubernetes. Обратите особое внимание на заметки о срочном обновлении, которые содержат критически важные сведения, которые могут повлиять на кластер AKS.
• Компоненты AKS критически изменяются по версии. В этой таблице представлен полный обзор критических изменений компонентов AKS по версии. Ссылаясь на это руководство, вы можете заранее решить любые потенциальные проблемы совместимости перед процессом обновления.

Помимо этих ресурсов Майкрософт, рассмотрите возможность использования средств с открытым исходным кодом для оптимизации процесса обновления кластера. Одним из таких инструментов является Fairwinds pluto, который может сканировать развертывания и диаграммы Helm для устаревших API Kubernetes. Эти средства помогут обеспечить совместимость приложений с последними версиями Kubernetes.

Процесс обновления

Чтобы проверить, требуется ли обновление кластера, используйте az aks get-upgrades , чтобы получить список доступных версий обновления для кластера AKS. Определите целевую версию кластера из результатов.

Приведем пример:

az aks get-upgrades \
   --resource-group <ResourceGroupName> --name <AKSClusterName> --output table

Пример результата:

MasterVersion  Upgrades
-------------  ---------------------------------
1.26.6         1.27.1, 1.27.3

Проверьте версии узлов в пулах узлов Kubernetes, чтобы определить пулы, которые необходимо обновить:

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,k8version:orchestratorVersion}" --output table

Пример результата:

Name          K8version
------------  ------------
systempool    1.26.6
usernodepool  1.26.6

Обновление вручную

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

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

Следуя этому подходу, можно свести к минимуму нарушения во время процесса обновления и обеспечить доступность приложений. Ниже приведены подробные действия.

1. Выполните команду az aks upgrade с флагом--control-plane-only, чтобы обновить только плоскость управления кластером, а не пулы узлов кластера:

   az aks upgrade \
      --resource-group <ResourceGroupName> --name <AKSClusterName> \
      --control-plane-only \
      --kubernetes-version <KubernetesVersion>
   

2. Выполните обновление az aks nodepool, чтобы обновить пулы узлов до целевой версии:

   az aks nodepool upgrade \
      --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> --name <NodePoolName> \
      --no-wait --kubernetes-version <KubernetesVersion>
   

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

Вы можете проверить состояние процесса обновления, выполнив команду kubectl get events. Сведения об устранении неполадок обновления кластера см . в документации по устранению неполадок AKS.

Регистрация кластеров в каналах выпуска автоматического обновления

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

Автоматическое обновление кластера предлагает различные варианты канала выпуска. Ниже приведена рекомендуемая конфигурация среды и канала выпуска:

Среда	Канал обновления	Description
Рабочая версия	stable	Для стабильности и зрелости версий используйте стабильный или обычный канал для рабочих нагрузок.
Промежуточное, тестирование, разработка	То же, что и в рабочей среде	Чтобы убедиться, что тесты указывают на версию, на которую вы будете обновлять рабочую среду, используйте тот же канал выпуска, что и в рабочей среде.
Ранее	rapid	Чтобы протестировать последние выпуски Kubernetes и новые функции AKS или API, используйте rapid канал. Вы можете улучшить свое время на рынок, когда версия rapid в ней повышена до канала, который вы используете для рабочей среды.

Рекомендации

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

Сценарий	Инициировано пользователем	Обновление Kubernetes	Обновление ядра ОС	Обновление образа узла
Установка обновлений для системы безопасности	No	No	Да, после перезагрузки	Да
Создание кластера	Да	Возможно	Да, если обновленный образ узла использует обновленное ядро	Да, относительно существующего кластера, если доступен новый выпуск
Обновление Kubernetes уровня управления	Да	Да	No	No
Обновление Kubernetes пула узлов	Да	Да	Да, если обновленный образ узла использует обновленное ядро	Да, если новый выпуск доступен
Масштабирование пула узлов	Да	No	No	No
Обновление образа узла	Да	Нет	Да, если обновленный образ узла использует обновленное ядро	Да
Автоматическое обновление кластера	No	Да	Да, если обновленный образ узла использует обновленное ядро	Да, если новый выпуск доступен

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Автор субъекта:

• Энтони Невико | Главный архитектор облачных решений

Другие участники:

• Ришаха Саха | Главный архитектор решений
• Паоло Сальватори | Главный инженер клиента, FastTrack для Azure
• Али Юссефи | Архитектор облачных решений

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.

Следующие шаги

• Документация по продукту AKS
• Средство отслеживания выпуска AKS
• Стратегия AKS
• Акселератор целевой зоны AKS
• Устранение неполадок AKS
• Оптимизация обновлений AKS
• Вопросы об обновлении ОС узла
• Строительный набор AKS
• Базовая автоматизация AKS
• Определение операций day-2

Связанные ресурсы

• Руководство по операциям AKS-2
• Методики триажа AKS