Установка патчей и обновление рабочих узлов и версий Kubernetes в Служба Azure Kubernetes

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

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

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

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

• Исправления безопасности ОС для узлов (Linux только): для узлов Linux, Canonical Ubuntu и Azure Linux предоставляют исправления безопасности ОС раз в день. Microsoft тестирует и упаковывает эти исправления в еженедельные обновления образов узлов.

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

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

Соображения перед обновлением

Перед обновлением рабочих узлов AKS и версий Kubernetes рассмотрите следующие эффекты и рекомендации.

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

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

• Стратегии обновления сине-зеленого цвета не влияют на производительность кластера, но повышают затраты и сложность. Подробные зеленые шаблоны на уровнях кластера и пула узлов, включая развертывания, использующие Azure DNS, Диспетчер трафика Azure и Azure Front Door, см. в статье Blue-green deployment of AKS clusters.

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

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

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

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

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

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

• Включите защиту развертывания. Механизмы защиты развертывания обеспечивают соблюдение лучших практик Kubernetes, включая проверку PDB, ограничения ресурсов, проверки состояния и правила антииффинности. Средства защиты развертывания используют элементы управления Политика Azure во время развертывания, чтобы обеспечить правильную настройку рабочих нагрузок до начала обновления.

• Проверьте доступные ограничения вычислительных ресурсов и сети. Проверьте доступные лимиты вычислительных ресурсов и сети в вашей подписке Azure через страницу quota на портале Azure или используя команду az quota. Проверьте вычислительные и сетевые ресурсы, особенно виртуальные процессоры (vCPU) виртуальных машин для узлов, а также число виртуальных машин и число масштабируемых наборов виртуальных машин. Если вы приближаетесь к ограничению, отправьте запрос на увеличение квоты перед обновлением.

• Проверьте доступное пространство IP-адресов в подсетях узла. Во время обновлений в кластере создаются дополнительные узлы для всплеска, а поды перемещаются на эти узлы. Отслеживайте пространство IP-адресов в подсетях узла, чтобы обеспечить достаточное пространство IP-адресов для этих изменений. Разные конфигурации сети Kubernetes имеют разные требования к IP-адресу. Чтобы начать, ознакомьтесь со следующими рекомендациями.

  • Во время обновления число IP-адресов узла увеличивается в соответствии со значением увеличения нагрузки. Минимальное значение всплеска равно 1.

  • Кластеры, основанные на Azure Container Networking Interface (CNI), назначают IP-адреса отдельным подам. Убедитесь, что имеется достаточно пространства IP-адресов для перемещения подов.

  • Кластер продолжает работать во время обновления. Убедитесь, что для масштабирования узлов достаточно адресного пространства IP.

• Настройка нескольких сред. Настройте несколько сред Kubernetes, таких как разработка, промежуточные и рабочие среды. Используйте эти среды для тестирования и проверки изменений перед перемещением их в рабочую среду. Проверка особенно важна при перемещении между несколькими версиями AKS, например с 1.32 по 1.34.

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

• Оптимизируйте кластеры для неуправляемого поведения узлов. По умолчанию, если узел не удается успешно освободить, обновление в вашем кластере также завершается ошибкой. Настройте дренирование узла и установку кордона, чтобы устранить эту проблему. Этот процесс помещает в карантин неотключаемые узлы, чтобы кластер был успешно обновлён, и чтобы вы могли вручную исправить узлы, которые не удалось обновить, применяя патчи или удаляя их. Вы можете настроить параметр --max-blocked-nodes, чтобы указать количество узлов, которые могут не выполниться при разряде перед тем, как обновление завершится сбоем. Например: az aks nodepool update --undrainable-node-behavior Cordon --max-blocked-nodes 2 --drain-timeout 30.

• Используйте принудительное обновление для сценариев аварийного реагирования. Для экстренного корректирования безопасности операторы могут использовать флаг --enable-force-upgrade вместе с --upgrade-override-until для обхода защиты PDB и проверочных мероприятий. При включении принудительного обновления он имеет приоритет над всеми остальными конфигурациями откачки, включая параметры поведения узлов, не подлежащие откачке.

  Внимание

  Используйте эту опцию только для срочных сценариев реагирования на общие уязвимости и воздействия (CVE). Дополнительные сведения см. в разделе "Принудительное обновление кластера AKS".

• Настройка значений усиления импульса. По умолчанию AKS имеет значение 1, что означает, что в процессе обновления создается один дополнительный узел. Увеличьте скорость обновления AKS, увеличив это значение. Рекомендуемое максимальное значение всплеска для рабочих нагрузок, чувствительных к сбоям, равно 33%. Для получения дополнительной информации смотрите Настройка обновления узлового скачка.

• Настройка времени ожидания отключения узла.Время ожидания отключения узла указывает максимальное время, которое кластер ждет, пока рабочая нагрузка пытается перепланировать поды на обновляемом узле. Значение по умолчанию составляет 30 минут. Если у рабочей нагрузки возникли трудности с планированием модулей pod, рассмотрите возможность увеличения этого значения.

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

• Проверьте другие зависимости в кластере. Операторы Kubernetes часто развертывают другие средства в кластере Kubernetes в рамках операций, таких как масштабировщики автомасштабирования на основе событий Kubernetes (KEDA), распределенная среда выполнения приложений (DAPR) и сетки служб. При планировании процессов обновления проверьте заметки о выпуске всех компонентов, используемых для обеспечения совместимости с целевой версией.

• Настройте зонально избыточные конфигурации AKS. Для кластеров AKS с избыточностью между зонами обновление может привести к временно несбалансированному распределению рабочих нагрузок между зонами. Установите значение всплеска как кратное 3, например, 33%, чтобы предотвратить этот дисбаланс.

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

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

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

1. Узел с обновленным изображением добавляется в пул узлов. Значение всплеска определяет, сколько узлов добавляются одновременно.

2. В зависимости от значения всплеска группа существующих узлов изолирована и освобождена. Кордонирование гарантирует, что узел не планирует модули pod. Слив удаляет pods и распределяет их на другие узлы.

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

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

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

Большинство кластеров должны использовать NodeImage канал обновления. Этот канал предоставляет обновленный VHD-образ виртуального жесткого диска узла каждую неделю. Образ узла обновляется в соответствии с окном обслуживания кластера.

Доступные каналы:

• None. Никакие обновления не применяются автоматически.

• Unmanaged. ОС применяет обновления Ubuntu и Azure Linux на ночной основе. Перезагрузки должны управляться отдельно. AKS не может протестировать или контролировать периодичность этих обновлений.

• SecurityPatch. ОС развертывает исправления безопасности, прошедшие тестирование в AKS, и полностью управляемые, используя методы безопасного развертывания. Это исправление не содержит исправлений ошибок ОС. Исправление содержит только обновления системы безопасности. Канал SecurityPatch обычно применяет исправления CVE в течение примерно пяти дней и выполняет повторное создание образа узлов реже, чем NodeImage через привязку исправлений в процессе работы.

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

Дополнительные сведения о частотах по умолчанию без установленного периода обслуживания см. в разделе "Обновление владения" и "Расписание".

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

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

Рекомендуется использовать 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

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

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

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

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

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

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

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

Чтобы отслеживать состояние обновлений автоматически, используйте диспетчер коммуникации AKS для предоставления автоматических оповещений о запланированных действиях по обслуживанию. Кроме того, отслеживайте состояние обновлений с помощью журналов действий Azure Monitor или просмотрите журналы resource logs в кластере с помощью kubectl get events.

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

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

Другие средства мониторинга и наблюдаемости для операций обновления:

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

• Аналитика контейнеров. Настройте пользовательские оповещения о поиске по журналам в таблице KubeEvents для событий обновления из компонента upgrader источника.

• Помощник по Azure. Советник проактивно рекомендует обновления по мере того как кластеры приближаются к окончанию поддержки и предоставляет рекомендации по обновлению и прекращению использования услуг.

• Средство отслеживания выпуска AKS. Используйте средство отслеживания выпуска AKS для мониторинга развертывания версий в регионах Azure и наблюдения за доступностью образа ноды в режиме реального времени.

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

Вы можете использовать команду kubectl describe nodes для того чтобы определить версию ядра ОС и версию образа ОС узлов в вашем кластере.

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:             6.6.87.1-1.azl3
  OS Image:                   Microsoft Azure Linux 3.0
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.7.27
  Kubelet Version:            v1.33.1
  Kube-Proxy Version:         v1.33.1

Используйте команду 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-2404gen2containerd-202604.07.0
usernodepool  AKSUbuntu-2404gen2arm64containerd-202604.07.0

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

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

В следующих выходных данных показаны последние доступные версии образа узла для пула узлов.

Name    NodeImageVersion
------  -------------------------------------
system  AKSAzureLinux-V3gen2-202604.07.0
user    AKSAzureLinux-V3gen2arm64-202604.07.0

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

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

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

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

Если кластеру требуется более длительный цикл обновления, используйте версии AKS, поддерживающие вариант долгосрочной поддержки (LTS). Каждая поддерживаемая версия AKS Kubernetes начиная с версии 1.27 имеет право на 24-месячный LTS через уровень "Премиум". LTS обеспечивает более длительный и контролируемый цикл обновления. Она поддерживает обновления основных версий каждые 24 месяца вместо стандартного 12-месячного цикла. Чтобы включить LTS, используйте --tier premium --k8s-support-plan AKSLongTermSupport.

Дополнительные сведения см. в статье "Поддерживаемые версии Kubernetes" в AKS.

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

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

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

• Учебник AKS для устаревших API: На странице обзора кластера на портале Azure выберите Диагностировать и устранить проблемы, перейдите к категории Create, Upgrade, Delete и Scale, а затем выберите Устаревшие API в Kubernetes. Эта процедура запускает рабочую книгу, которая проверяет наличие устаревших версий API, которые всё ещё используются в вашем кластере. Дополнительные сведения см. в разделе "Удаление использования устаревших API".

• Страница заметок о выпуске AKS: Эта страница содержит подробные сведения о новых версиях и релизах AKS. Просмотрите эти заметки, чтобы оставаться в курсе последних обновлений и изменений.

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

• Критические изменения компонентов AKS по версии: В этой таблице представлен полный обзор критических изменений компонентов AKS по версии. Решайте любые потенциальные проблемы совместимости заранее перед обновлением, обращаясь за помощью к этому руководству.

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

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

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

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

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

В следующих выходных данных показаны доступные версии обновления Kubernetes для кластера.

MasterVersion  Upgrades
-------------  ---------------------------------
1.32.4         1.33.1, 1.33.2, 1.33.3

Чтобы найти пулы, требующие обновления, проверьте версии Kubernetes узлов в этих пулах.

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

В следующих выходных данных показаны версии Kubernetes для каждого пула узлов.

Name          K8version
------------  ------------
systempool    1.32.4
usernodepool  1.32.4

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

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

1. Обновите плоскость управления 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 upgrade , чтобы обновить пулы узлов до целевой версии.

   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 также предоставляет решение для автоматического обновления кластера, чтобы поддерживать ваш кластер в актуальном состоянии. Если вы используете это решение, совместите это с периодом обслуживания для управления временем обновления. Окно обновления должно быть четыре часа или более.

При регистрации кластера в канале выпуска Microsoft автоматически управляет версиями и частотой обновлений кластера и его пулов узлов.

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

Вы можете применять конфигурации канала автоматического обновления и канала автоматического обновления ОС узла во всем вашем окружении рабочей нагрузки с помощью встроенных определений Политика Azure для AKS. Эти политики могут обязывать кластеры использовать определенный канал автоматического обновления, принудительно применять каналы автоматического обновления OS узлов, например, SecurityPatch или NodeImage, и требовать запланированных периодов обслуживания.

AKS Automatic

AKS Automatic — это полностью управляемый интерфейс AKS, где Azure обрабатывает настройку кластера, управление узлами, масштабирование и обновление автоматически. AkS Automatic применяет автоматическое обновление по умолчанию через stable канал кластера и NodeImage канал ОС узла, использует автоматическую подготовку узлов для динамической подготовки узлов и включает средства защиты развертывания. Если для рабочей нагрузки требуется операционная модель, которая автоматически обрабатывает большинство рекомендаций по обновлению вручную в этой статье, попробуйте использовать AKS Automatic в качестве альтернативы.

Обновление нескольких кластеров с помощью диспетчера Azure Kubernetes Fleet Manager

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

• Запуски поэтапного обновления. Определите этапы обновления, такие как разработка, промежуточное развертывание и производство, с настраиваемыми периодами ожидания между этапами.

• Обновление групп и стратегий. Создайте стратегии повторного обновления, определяющие порядок и время обновления между группами кластеров.

• Профили автоматического обновления. Настройте профили автоматического обновления на уровне флота, которые применяют согласованные политики обновления во всех кластерах-членах.

С помощью диспетчера парка можно координировать обновления версий Kubernetes и образов узлов в нескольких кластерах AKS. Дополнительные сведения см. в разделе "Оркестрация обновлений" в нескольких кластерах AKS с помощью диспетчера парка.

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

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

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

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

Соавторы

Microsoft поддерживает эту статью. Следующие авторы написали эту статью.

Главный автор:

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

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

• Сэм Коган | Старший архитектор облачных решений
• Ришаха Саха | Главный архитектор решений
• Paolo Salvatori | Главный инженер клиентов, FastTrack для Azure
• Али Юссефи | Архитектор облачных решений

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

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

• документация по продуктам AKS
• Трекер выпуска AKS
• Стратегия AKS
• Устранение неполадок AKS
• Оптимизация обновлений AKS
• Часто задаваемые вопросы об автоматическом обновлении ОС узла
• Оркестрация обновления для Azure Kubernetes Fleet Manager
• Автоматический обзор AKS
• Стратегии обновления рабочей среды AKS
• Защита развертывания
• Определить операции второго дня
• Рекомендации по устойчивости зоны для AKS

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

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