Обновление образов Kubernetes и узлов в нескольких кластерах-членах

Область применения: ✔️ Менеджер автопарка ✔️ Менеджер автопарка с кластером концентратора

Администраторы платформы, управляющие большим количеством кластеров, часто имеют проблемы с промежуточными обновлениями нескольких кластеров (например, обновление образа ОС узла или версий Kubernetes) безопасным и предсказуемым способом. Чтобы устранить эту проблему, Диспетчер флотов Azure Kubernetes позволяет управлять обновлениями в нескольких кластерах с помощью запусков обновлений.

Запуски обновлений состоят из этапов, групп и стратегий и могут применяться вручную, для однократных обновлений или автоматически для текущих регулярных обновлений с помощью профилей автоматического обновления. Все операции обновления (вручную или автоматические) учитывают окна технического обслуживания кластеров-участников.

Общие сведения о запусках обновлений

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

• Запуск обновления: запуск обновления представляет собой процесс, который применяется к коллекции кластеров AKS и включает в себя цель обновления и последовательность действий. Цель обновления описывает необходимые обновления (например, обновление до Kubernetes версии 1.28.3). Последовательность обновления описывает точный порядок применения обновления к нескольким кластерам-членам, выраженным с помощью этапов и групп. Если не указано, все кластеры-члены обновляются по одному последовательно. Процесс обновления можно остановить и снова запустить.
• Этап обновления: запуски обновления делятся на этапы, которые применяются последовательно. Например, первый этап обновления может обновлять кластеры участников тестовой среды, а второй этап обновления будет позже обновлять кластеры членов рабочей среды. Время ожидания можно указать для задержки между приложением последующих этапов обновления.
• Группа обновлений: каждый этап обновления содержит одну или несколько групп обновлений, которые используются для выбора кластеров-членов, которые необходимо обновить. Группы обновлений также используются для упорядочивания приложения обновлений в кластерах-членах. На этапе обновления обновления применяются ко всем разным группам обновлений параллельно; в каждой группе обновлений кластеры-участники обновляются последовательно. Каждый входящий кластер флота может быть частью только одной группы обновлений.
• Шлюзы утверждения (предварительная версия): можно настроить до или после каждого этапа или группы. Утверждения приостанавливают выполнение обновления, что позволяет вам или настроенным вами автоматизациям проверить, можно ли продолжить. После того как вы или ваша служба автоматизации предоставили утверждение, запуск обновления продолжится.
• Стратегия обновления. Стратегия обновления описывает последовательность обновлений с этапами и группами и позволяет повторно использовать конфигурацию запуска обновления вместо определения последовательности многократно в каждом запуске. Стратегия обновления не включает требуемые версии Kubernetes или образа узла.

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

• Обновите версии Kubernetes для плоскости управления Kubernetes и узлов (включая обновление образов узлов).
• Обновите версии Kubernetes только для уровня управления кластеров.
• Обновите только образы узлов.

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

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

• Latest: Используйте последние образы узлов, доступные в регионе Azure кластера, когда начинается обновление кластера. В результате различные версии образов могут использоваться в зависимости от региона Azure, в котором находится кластер, и при фактическом запуске обновления.
• Consistent: Когда начинается запуск обновления, выбираются общие последние версии образов в регионах Azure для кластеров-участников в этом запуске, чтобы обеспечить использование одинаковых, согласованных версий образов во всех кластерах.

Вы должны выбрать Latest, чтобы использовать более свежие версии образов и свести к минимуму риски безопасности, и выбрать Consistent, чтобы повысить надежность, используя и проверяя эти образы в кластерах на более ранних этапах, прежде чем использовать их в последующих кластерах.

Плановое техническое обслуживание

Обновления выполняются с учетом запланированных окон обслуживания, которые вы установили на уровне кластера Azure Kubernetes Service (AKS).

Кластеры AKS поддерживают два раздельных окна обслуживания — одно для обновлений Kubernetes (плоскости управления) и другое для обновлений образа узла. Периоды обслуживания определяют периоды, когда обновления могут применяться к кластеру, но не являются триггером обновления.

Обновление Fleet Manager учитывает окна обслуживания AKS.

Обновление приоритетно обновляет кластеры на основе планового обслуживания в следующем порядке:

1. Участник с открытым периодом текущего обслуживания.
2. Участник с окном обслуживания, открывающимся в ближайшие четыре часа.
3. Член без периода обслуживания.
4. Участник с закрытым окном обслуживания.

Обновление состояний выполнения

Запуск обновления может находиться в одном из следующих состояний:

• Не запущено: запуск обновления не запущен.
• Ход выполнения: обновление выполняется по крайней мере для одного кластера-член.
• Ожидается:
  • Кластер членов: кластер-член может находиться в Pending состоянии по любым из следующих причин, которые можно просмотреть в поле сообщения.
    • Окно обслуживания не открыто. Сообщение указывает на следующее время открытия.
    • Целевая версия Kubernetes пока недоступна в регионе Azure участника. Сообщение содержит ссылки на средство отслеживания выпуска AKS, чтобы проверить состояние выпуска в разных регионах.
    • Версия образа целевого узла пока недоступна в Azure-регионе участника. Ссылки сообщения на трекер выпуска AKS.
  • Группа обновлений: Группа считается Pending, если все ее члены находятся в состоянии Pending или не начаты, либо если у нее есть Pending шлюз. Когда участник переезжает в Pending, выполнение обновления попытается обновить следующего участника в группе. Если все члены являются Pending, группа перемещается в состояние Pending. Если группа является Pending, запуск обновления ожидает завершения группы, прежде чем перейти к следующему этапу обновления.
  • Этап обновления: этап находится в состоянии Pending , если все группы обновления на этапе находятся в состоянии Pending или не начаты, или если у него есть Pending шлюз.
  • Запуск: запуск находится в Pending состоянии, если текущий этап находится в Pending состоянии.
• Пропущено: можно пропустить все уровни запуска обновления. Пропуск может быть системным или пользовательским.
  • Кластер членов:
    • Пользователь пропустил обновление для члена, группы или этапа.
    • Кластер-член уже находится в целевой версии Kubernetes (если режим выполнения обновления имеет Full или ControlPlaneOnly).
    • Кластер-член уже находится в целевой версии Kubernetes, а все пулы узлов находятся в версии образа целевого узла.
    • Если для выполнения обновления выбран согласованный образ узла, если не удается найти целевую версию образа для одного из пулов узлов, обновление пропускается для этого кластера. Например, это может произойти при добавлении нового пула узлов с новым номером SKU виртуальной машины после запуска обновления.
  • Обновить группу:
    • Пользователь пропустил обновление для группы.
    • Все кластеры-члены системой были обнаружены как Skipped.
  • Этап обновления:
    • Пользователь пропустил обновление для этапа.
    • Все группы обновлений на этапе были обнаружены системой как Skipped.
  • Запуск обновления:
    • Все этапы были обнаружены Skipped системой.
• Остановлено: все уровни запуска обновления можно остановить. Существует два способа ввода остановленного состояния:
  • Пользователь остановил выполнение обновления, после чего процесс обновления перестал отслеживать все операции. Если операция уже была инициирована запуском обновления (например, выполняется обновление кластера), то эта операция не прерывается для этого отдельного кластера.
  • Если во время выполнения обновления возникает сбой (например, сбой обновлений в одном из кластеров), весь запуск обновления вводится в остановленное состояние. Операции не выполняются для последующих кластеров в процессе обновления.
• Сбой: сбой обновления кластера приводит к следующим действиям:
  • Помечает MemberUpdateStatus как Failed в составе кластера.
  • Помечает всех родителей (группа -> стадия -> запуск) как Failed с итоговым сообщением об ошибке.
  • Останавливает выполнение обновления от дальнейшего выполнения.
• Завершено: выполнение обновления успешно завершено.

Общие сведения о профилях автоматического обновления

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

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

• a Channel (стабильный, быстрый, NodeImage, TargetKubernetesVersion (предварительная версия)), который определяет тип автоматического обновления, применяемого к кластерам.
• UpdateStrategy, который настраивает последовательность, в которой обновляются кластеры. Если стратегия не предоставлена, кластеры обновляются по одному последовательно.
• Используйте параметр NodeImageSelectionType (Последнее, Согласованное), чтобы указать, как выбирается образ узла при обновлении версии Kubernetes.

Стабильный канал

Стабильный канал всегда предоставляет последнее исправление Kubernetes, поддерживаемое AKS, для минорной версии N-1, где N является последней поддерживаемой минорной версией.

Примеры:

• Последняя поддерживаемая дополнительная версия Kubernetes — 1.30. Все выпуски исправлений в минорном диапазоне версии 1.29 будут рассматриваться для обновлений стабильного канала.
• Опубликована новая дополнительная версия Kubernetes версии 1.31 . Выпуск любых исправлений в рамках версии 1.30 будет рассматриваться для обновлений стабильного канала. Любой кластер, ранее получая обновления от версии 1.29 , будет обновлен до последнего исправления для версии 1.30.

Быстрый канал

Канал Rapid всегда является самым последним минорным релизом Kubernetes, поддерживаемым AKS.

Примеры:

• Последняя поддерживаемая дополнительная версия — 1.30. Любой выпуск исправлений в минорном диапазоне версии 1.30 будет рассматриваться для обновлений Rapid.
• Опубликована новая дополнительная версия Kubernetes версии 1.31 . 1.30 переходит на стабильный канал. Любой кластер, ранее получающий обновления от версии 1.30 , будет обновлен до последнего исправления для версии 1.31 , который теперь является каналом Rapid.

Канал NodeImage

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

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

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

Пример:

• Кластер имеет узлы с nodeImage AKSWindows-2022-containerd версии 20348.2582.240716. Выпущен новый узел NodeImage версии 20348.2582.240916 , а узлы кластера автоматически обновляются до версии 20348.2582.240916.

Канал TargetKubernetesVersion (предварительный просмотр)

Канал TargetKubernetesVersion позволяет управлять сроками перехода кластера на следующую минорную версию Kubernetes, указывая её в профиле автоматического обновления. Целевая версия Kubernetes должна быть указана в формате "{major}. {minor}" (например, "1.33"). Автоматическое обновление флота автоматически обновляет кластеры-члены до последнего выпуска патча для указанной целевой версии Kubernetes, когда патч доступен. Флот не будет обновляться до следующей дополнительной версии, пока не обновите целевую версию профиля автоматического обновления Kubernetes.

Примеры:

• Вы создадите профиль автоматического обновления с помощью канала TargetKubernetesVersion и укажите целевую версию Kubernetes 1.30. Опубликовано новое исправление версии 1.30.5. Запуск обновления автоматически создается с целевым объектом 1.30.5.
• Вы создаете профиль автоматического обновления с помощью канала TargetKubernetesVersion, укажите целевую версию Kubernetes "1.29" и включите LongTermSupport (LTS) в профиле автоматического обновления. Последняя поддерживаемая сообществом дополнительная версия — 1.33. Опубликовано новое исправление версии 1.29.5. Автоматически создается задача обновления с целью 1.29.5. Примечание. Если созданный запуск обновления включает кластеры без включения LTS, он завершится ошибкой.

Поведение пропуска минорных версий

Автоматическое обновление не перемещает кластеры между минорными версиями Kubernetes, если разница превышает одну минорную версию (например, с 1.28 до 1.30). Если у администраторов есть разнообразный набор версий Kubernetes, рекомендуется сначала выполнить одно или несколько обновлений, чтобы привести кластеры-члены к набору выпущенных версий с последовательными изменениями, и тем самым Stable или Rapid обновление каналов гарантировало бы поддержание согласованности в будущем.

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

• Как обновить несколько кластеров с помощью Azure Kubernetes Fleet Manager: пошаговое руководство по запускам обновлений.
• Практическое руководство. Автоматическое обновление нескольких кластеров с помощью Диспетчера флота Azure Kubernetes.
• Практическое руководство. Мониторинг запусков обновлений для диспетчера флотов Azure Kubernetes.
• Часто задаваемые вопросы об обновлениях кластеров.