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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• NotStarted: запуск обновления не запущен.
• Выполняется: обновление выполняется по крайней мере для одного из кластеров-членов в запуске обновления.
• Ожидается:
  • Кластер-член: кластер-член может находиться в состоянии ожидания по любым из следующих причин, которые можно просмотреть в поле сообщения.
    • Период обслуживания не открыт. Сообщение указывает на следующее время открытия.
    • Целевая версия Kubernetes пока недоступна в регионе Azure участника. Ссылки на средство отслеживания выпуска, чтобы проверить состояние выпуска в разных регионах.
    • Версия образа целевого узла пока недоступна в регионе Azure члена. Ссылки на средство отслеживания выпуска, чтобы проверить состояние выпуска в разных регионах.
  • Группа: группа находится в состоянии, если все члены группы находятся в 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), определяющий тип автоматического обновления, применяемый к кластерам.
• , 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.

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

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

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

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