Поделиться через


Использование планового обслуживания для планирования и контроля обновлений для кластера службы Azure Kubernetes

В этой статье показано, как использовать плановое обслуживание для планирования и управления обновлениями образов кластера и узлов в службе Azure Kubernetes (AKS).

Регулярное обслуживание выполняется в кластере AKS автоматически. Существует два типа операций обслуживания:

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

Замечание

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

Перед тем как начать

  • В этой статье предполагается, что у вас есть кластер AKS. Если у вас нет кластера AKS, см. статью "Создание кластера AKS".
  • Если вы используете Azure CLI, обновите ее до последней az upgrade версии с помощью команды.

Соображения

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

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

Планирование типов конфигурации для планового обслуживания

Три типа конфигурации расписания доступны для планового обслуживания:

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

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

  • aksManagedAutoUpgradeSchedule управляет временем выполнения обновлений кластера, запланированных вашим назначенным каналом автоматического обновления. По сравнению с конфигурацией default, вы можете настроить более точно контролируемые параметры каденции и повторения с этой конфигурацией. Дополнительные сведения об автоматическом обновлении кластера см. в статье "Автоматическое обновление кластера службы Azure Kubernetes".

  • aksManagedNodeOSUpgradeSchedule определяет, когда выполняется исправление системы безопасности операционной системы узла, запланированное каналом автоматического обновления ОС узла. Вы можете настроить более точно контролируемые параметры каденции и повторения с этой конфигурацией по сравнению с конфигурацией default. Дополнительные сведения о каналах автоматического обновления ОС узла см. в статье Автоматическое исправление и обновление образов узлов кластера AKS.

Рекомендуется использовать aksManagedAutoUpgradeSchedule для всех сценариев обновления кластера и aksManagedNodeOSUpgradeSchedule для всех сценариев исправления безопасности ос узла.

Этот default вариант предназначен исключительно для еженедельных выпусков AKS. Вы можете переключить конфигурацию default на конфигурацию aksManagedAutoUpgradeSchedule или на конфигурацию aksManagedNodeOSUpgradeSchedule, используя команду az aks maintenanceconfiguration update.

Создание периода обслуживания

Замечание

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

Запланированные периоды обслуживания указываются по Всемирному координированному времени (UTC).

Периодическое окно default обслуживания имеет следующие устаревшие свойства (больше не рекомендуется):

Имя Описание Значение по умолчанию
timeInWeek В конфигурации default это свойство содержит значения day и hourSlots, определяющие период обслуживания. Неприменимо
timeInWeek.day День недели для проведения технического обслуживания в default конфигурации. Неприменимо
timeInWeek.hourSlots Список часовых интервалов времени для выполнения обслуживания в определенный день в default конфигурации. Неприменимо
notAllowedTime Диапазон дат, на которые обслуживание не может выполняться, определяется дочерними свойствами start и end. Это свойство применимо только при создании периода обслуживания, используя файл конфигурации. Неприменимо

Замечание

Начиная с версии API 2023-05-01, используйте указанные ниже свойства для конфигурации default.

Период обслуживания aksManagedAutoUpgradeSchedule или aksManagedNodeOSUpgradeSchedule и конфигурация default, начиная с версии API от 2023-05-01, имеют следующие свойства:

Имя Описание Значение по умолчанию
utcOffset Часовой пояс для обслуживания кластера. +00:00
startDate Дата вступления в силу периода обслуживания. Текущая дата во время создания
startTime Время начала обслуживания в зависимости от часового пояса, определенного utcOffset. Неприменимо
schedule Частота обновления. Доступны три типа: Weekly, AbsoluteMonthlyи RelativeMonthly. Неприменимо
intervalDays Интервал в днях для выполнения обслуживания. Применимо только к aksManagedNodeOSUpgradeSchedule. Неприменимо
intervalWeeks Интервал в неделях для технического обслуживания. Неприменимо
intervalMonths Интервал в месяцах для проведения обслуживания. Неприменимо
dayOfWeek Указанный день недели для начала обслуживания. Неприменимо
durationHours Продолжительность окна проведения обслуживания. Неприменимо
notAllowedDates Диапазон дат, в которых обслуживание не может выполняться, определяется дочерними свойствами start и end. Это применимо только при создании окна обслуживания с помощью файла конфигурации. Неприменимо

Типы расписаний

Поддерживаются четыре типа расписаний :Daily , Weekly, AbsoluteMonthlyи RelativeMonthly.
В таблице ниже показано, какие типы доступны для каждого параметра конфигурации обслуживания.

Примечание.
Начиная с июня 2025 года тип расписания Daily также будет поддерживаться для aksManagedClusterAutoUpgradeSchedule.

Тип расписания default aksManagedClusterAutoUpgradeSchedule aksManagedNodeOSUpgradeSchedule
Ежедневно ✅ (после июня 2025 г.)
Еженедельно
AbsoluteMonthly
Относительный Ежемесячный

Все поля, отображаемые для каждого типа расписания, обязательны.

Расписание Daily может выглядеть следующим образом: "каждые три дня".

"schedule": {
    "daily": {
        "intervalDays": 3
    }
}

Weekly Расписание может выглядеть как "каждые две недели в пятницу":

"schedule": {
    "weekly": {
        "intervalWeeks": 2,
        "dayOfWeek": "Friday"
    }
}

Расписание AbsoluteMonthly может выглядеть как "каждые три месяца в первый день месяца":

"schedule": {
    "absoluteMonthly": {
        "intervalMonths": 3,
        "dayOfMonth": 1
    }
}

Расписание RelativeMonthly может выглядеть как "каждые два месяца в последний понедельник":

"schedule": {
    "relativeMonthly": {
        "intervalMonths": 2,
        "dayOfWeek": "Monday",
        "weekIndex": "Last"
    }
}

Допустимые значения для weekIndex включают First, Second, Third, Fourth и Last.

Настройка окна обслуживания

Добавьте конфигурацию периода обслуживания в кластер AKS с помощью az aks maintenanceconfiguration add команды.

Первый пример добавляет новую default конфигурацию, которая планирует обслуживание с 1:00 до 2:00 каждый понедельник. Второй пример добавляет новую aksManagedAutoUpgradeSchedule конфигурацию, которая планирует выполнение обслуживания в каждую третью пятницу в период с 12:00 ночи до 8:00 утра в часовом поясе UTC+5:30.

# Add a new default configuration
az aks maintenanceconfiguration add --resource-group myResourceGroup --cluster-name myAKSCluster --name default --weekday Monday --start-hour 1

# Add a new aksManagedAutoUpgradeSchedule configuration
az aks maintenanceconfiguration add --resource-group myResourceGroup --cluster-name myAKSCluster --name aksManagedAutoUpgradeSchedule --schedule-type Weekly --day-of-week Friday --interval-weeks 3 --duration 8 --utc-offset +05:30 --start-time 00:00

Замечание

При использовании default типа конфигурации можно опустить --start-time параметр, чтобы разрешить обслуживание в любое время в течение дня.

Обновление существующего окна обслуживания

Обновите существующую конфигурацию обслуживания с помощью az aks maintenanceconfiguration update команды.

Во следующем примере конфигурация default обновляется для планирования проведения технического обслуживания с 2:00 до 3:00 утра каждый понедельник.

az aks maintenanceconfiguration update --resource-group myResourceGroup --cluster-name myAKSCluster --name default --weekday Monday --start-hour 2

Перечислите все окна обслуживания в существующем кластере

Перечислите текущие окна обслуживания конфигурации в вашем кластере AKS с помощью команды az aks maintenanceconfiguration list:

az aks maintenanceconfiguration list --resource-group myResourceGroup --cluster-name myAKSCluster

Показать конкретное окно конфигурации обслуживания в существующем кластере

Посмотрите конкретное окно конфигурации обслуживания в вашем кластере AKS, используя команду az aks maintenanceconfiguration show с параметром --name:

az aks maintenanceconfiguration show --resource-group myResourceGroup --cluster-name myAKSCluster --name aksManagedAutoUpgradeSchedule

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

{
  "id": "/subscriptions/<subscription>/resourceGroups/myResourceGroup/providers/Microsoft.ContainerService/managedClusters/myAKSCluster/maintenanceConfigurations/aksManagedAutoUpgradeSchedule",
  "maintenanceWindow": {
    "durationHours": 4,
    "notAllowedDates": [
      {
        "end": "2024-01-05",
        "start": "2023-12-23"
      }
    ],
    "schedule": {
      "absoluteMonthly": {
        "dayOfMonth": 1,
        "intervalMonths": 3
      },
      "daily": null,
      "relativeMonthly": null,
      "weekly": null
    },
    "startDate": "2023-01-20",
    "startTime": "09:00",
    "utcOffset": "-08:00"
  },
  "name": "aksManagedAutoUpgradeSchedule",
  "notAllowedTime": null,
  "resourceGroup": "myResourceGroup",
  "systemData": null,
  "timeInWeek": null,
  "type": null
}

Удаление окна конфигурации обслуживания в существующем кластере

Удалите окно настройки обслуживания в вашем кластере AKS с помощью команды az aks maintenanceconfiguration delete.

В следующем примере удаляется конфигурация обслуживания autoUpgradeSchedule.

az aks maintenanceconfiguration delete --resource-group myResourceGroup --cluster-name myAKSCluster --name autoUpgradeSchedule

Вопросы и ответы

  • Как проверить существующие конфигурации обслуживания в кластере?

    Используйте команду az aks maintenanceconfiguration show.

  • Может ли реактивное, незапланированное обслуживание происходить в периоды notAllowedTime или notAllowedDates?

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

  • Как узнать, произошло ли событие обслуживания?

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

    AKS также эмитирует события Azure Event Grid, связанные с обновлением. Дополнительные сведения см. в статье AKS как источник сетки событий.

  • Можно ли одновременно использовать несколько конфигураций обслуживания?

    Да, можно одновременно запускать все три конфигурации: default, aksManagedAutoUpgradeScheduleи aksManagedNodeOSUpgradeSchedule. Если окна перекрываются, AKS решает порядок выполнения.

  • Я настроил период обслуживания, но обновление не произошло. Почему?

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

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

  • Почему один из пулов агентов был обновлён вне периода обслуживания?

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

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

  • Существуют ли рекомендации по настройке обслуживания?

    Мы рекомендуем задать расписание обновлений безопасности операционной системы узла на еженедельную периодичность, если вы используете NodeImage канал, так как новый образ узла поставляется каждую неделю. Вы также можете принять участие в канале SecurityPatch для получения ежедневных обновлений системы безопасности.

    Задайте для расписания автоматического обновления ежемесячное значение, чтобы оставаться в курсе политики поддержки Kubernetes N-2.

    Подробное обсуждение лучших практик обновления и других аспектов смотрите в руководстве по исправлению и обновлению AKS.

  • Можно ли настроить все кластеры в одной подписке для использования одной конфигурации обслуживания?

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

Дальнейшие шаги