Обновление кластера Nexus Kubernetes оператора Azure

В этой статье приводятся инструкции по обновлению кластера Operator Nexus Kubernetes для получения последних компонентов и обновлений системы безопасности. Часть жизненного цикла кластера Kubernetes включает периодическое обновление до последней версии Kubernetes. Важно применить последние выпуски системы безопасности или обновить, чтобы получить последние возможности. В этой статье показано, как проверить, настроить и применить обновления к кластеру Kubernetes.

Ограничения

• Процесс обновления кластера по умолчанию — это подход к горизонтальному масштабированию, то есть добавляется по крайней мере один дополнительный узел (или столько узлов, сколько настроено в максимальном всплеске). Если недостаточно емкости, обновление завершается ошибкой.
• Когда новые версии Kubernetes становятся доступными, кластеры клиентов не будут проходить автоматические обновления. Пользователи должны инициировать обновление, когда все сетевые функции в кластере готовы к поддержке новой версии Kubernetes. Дополнительные сведения см. в статье об обновлении кластера.
• Оператор Nexus предлагает обновления на уровне кластера, обеспечивая согласованность во всех пулах узлов. Обновление одного пула узлов не поддерживается. Кроме того, образ узла обновляется как часть обновления кластера при доступности новой версии.
• Настройки, внесенные в узлы агента, будут потеряны во время обновления кластера. Рекомендуется разместить эти настройки DaemonSet вместо внесения вручную изменений в конфигурацию узла, чтобы сохранить их после обновления.
• Изменения, внесенные в конфигурации основных надстроек, восстанавливаются в конфигурации надстройки по умолчанию в рамках процесса обновления кластера. Избегайте настройки конфигурации надстройки (например, Calico и т. д.), чтобы предотвратить потенциальные сбои обновления. Если восстановление конфигурации надстройки сталкивается с проблемами, это может привести к сбоям обновления.
• При обновлении кластера Operator Nexus Kubernetes не удается пропустить дополнительные версии Kubernetes. Необходимо выполнить все обновления последовательно по основному номеру версии. Например, разрешено обновление между 1.14.x ->1.15.x или 1.15.x ->1.16.x, однако 1.14.x ->1.16.x не разрешено. Если ваша версия находится за несколькими основными версиями, следует выполнить несколько последовательных обновлений.
• Максимальный всплеск и (или) максимальное недоступное значение должно быть задано во время создания кластера. Эти значения нельзя изменить после создания кластера. Дополнительные сведения см. в статье upgradeSettings "Создание кластера "Оператор Azure Nexus Kubernetes".

Необходимые компоненты

• Кластер Оператора Azure Nexus Kubernetes, развернутый в группе ресурсов в подписке Azure.
• Если вы используете Azure CLI, эта статья требует, чтобы вы использовали последнюю версию Azure CLI. Если вам необходимо выполнить установку или обновление, ознакомьтесь со статьей Установка Azure CLI.
• Минимальная требуемая версия networkcloud расширения az-cli: 2.0.b3
• Общие сведения о концепциях пакетов версий. Дополнительные сведения см . в пакетах версий Nexus Kubernetes.

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

Проверьте, какие выпуски Kubernetes доступны для кластера, выполнив следующие действия.

Использование Azure CLI

Следующая команда Azure CLI возвращает доступные обновления для кластера:

az networkcloud kubernetescluster show --name <NexusK8sClusterName> --resource-group <ResourceGroup> --output json --query availableUpgrades

Образец вывода:

[
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.4-4"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.6-1"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.26.3-1"
  }
]

Использование портала Azure

1. Войдите на портал Azure.
2. Перейдите к кластеру Operator Nexus Kubernetes.
3. В разделе "Обзор" выберите вкладку "Доступные обновления".

Выбор версии для обновления до

Доступные выходные данные обновления указывают на наличие нескольких версий для обновления. В этом конкретном сценарии текущий кластер работает с версией v1.25.4-3. , в результате доступные варианты обновления включают v1.25.4-4 и последний выпуск v1.25.6-1. исправлений, кроме того, доступна новая дополнительная версия.

У вас есть гибкость для обновления до любой из доступных версий. Однако рекомендуемый курс действий — выполнить обновление до последней доступной major-minor-patch-versionbundle версии.

Примечание.

Входной формат для версии — major.minor.patch или major.minor.patch-versionbundle. Входные данные версии должны быть одной из доступных версий обновления. Например, если текущая версия кластера имеет 1.1.1-1значение, допустимые входные данные версий имеют 1.1.1-2 или 1.1.1-x. Хотя 1.1.1 это допустимый формат, он не будет запускать обновление, так как текущая версия уже 1.1.1включена. Чтобы инициировать обновление, можно указать полную версию пакета версий, например 1.1.1-2. 1.1.2 Однако и 1.2.x являются допустимыми входами и будут использовать последний пакет версий, доступный для 1.1.2 или 1.2.x.

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

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

• Добавьте новый узел плоскости управления с указанной версией Kubernetes в кластер.
• После добавления нового узла кордон и очистка одного из старых узлов плоскости управления, гарантируя, что рабочие нагрузки, выполняемые на нем, правильно перемещены на другие здоровые узлы плоскости управления.
• После очистки старого узла плоскости управления он удаляется, а новый узел плоскости управления добавляется в кластер.
• Этот процесс повторяется до обновления всех узлов плоскости управления в кластере.
• При обновлении рабочих узлов с помощью всплеска (по умолчанию):
  • Для каждого пула агентов в кластере добавьте новый рабочий узел (или столько узлов, сколько настроено в максимальном всплеске) с указанной версией Kubernetes. Одновременно обновляется несколько пулов агентов.
  • Кордон и очистка одного из старых рабочих узлов, чтобы свести к минимуму нарушения работы приложений. Если вы используете максимальный всплеск, он кордонирует и очищает столько рабочих узлов, сколько рабочих узлов одновременно с числом указанных буферных узлов.
  • После очистки старого рабочего узла он удаляется, а новый рабочий узел с новой версией Kubernetes добавляется в кластер (или столько узлов, сколько настроено в максимальном всплеске).
• При обновлении рабочих узлов без всплеска:
  • Для каждого пула агентов в кластере старый рабочий узел (или столько узлов, сколько настроено в максимальной недоступности), объединяется, очищается, а затем удаляется, прежде чем заменить новый рабочий узел указанным версией Kubernetes. Одновременно обновляется несколько пулов агентов.
  • Во время обновления будет временное сокращение емкости кластера, так как модули pod, исходящие из старого рабочего узла, не будут немедленно переходить к новому узлу. Это может привести к тому, что модули pod вступают в состояние ожидания, если недостаточно емкости. Поэтому важно разработать кластер для удовлетворения требований к емкости приложений, особенно во время обновления без всплеска.
• Этот процесс повторяется до тех пор, пока все рабочие узлы в кластере не будут обновлены.

Примечание.

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

Внимание

Убедитесь, что любая PodDisruptionBudgets (PDB) разрешает перемещение по крайней мере одной реплики pod в любое время в противном случае операция очистки и вытеснения завершится ошибкой. Если операция очистки завершается ошибкой, операция обновления также завершится ошибкой, чтобы убедиться, что приложения не нарушаются. Исправьте причину остановки операции (т. е. неправильные PDB, отсутствие квоты и т. д.) и повторите попытку операции. Также можно настроить время ожидания очистки для пула рабочих узлов, после чего узел будет удален, даже если модули pod еще не завершили очистку. Это может предотвратить блокировку обновлений неправильно настроенными PDF-файлами. Параметр времени ожидания очистки настраивается в секундах и по умолчанию — 1800.

1. Обновите кластер с помощью networkcloud kubernetescluster update команды.

az networkcloud kubernetescluster update --name myNexusK8sCluster --resource-group myResourceGroup --kubernetes-version v1.26.3

2. Убедитесь, что обновление выполнено успешно с помощью show команды.

az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output json --query kubernetesVersion

В следующем примере выходных данных показано, что кластер теперь работает под управлением версии 1.26.3:

"v1.26.3"

3. Убедитесь, что кластер работоспособен.

az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output table

В следующем примере выходных данных показано, что кластер работоспособен:

Name                 ResourceGroup          ProvisioningState    DetailedStatus    DetailedStatusMessage             Location
------------------   ---------------------  -------------------  ----------------  --------------------------------  --------------
myNexusK8sCluster    myResourceGroup        Succeeded            Available         Cluster is operational and ready  southcentralus

Настройка всплеска или недоступности узла

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

Например, максимальное значение всплеска активности, равное 100 %, обеспечивает самый быстрый процесс обновления (удваивая число узлов), но также приводит к тому, что все узлы в пуле узлов будут одновременно остановлены. Может потребоваться использовать более высокое значение, например для сред тестирования. Для рабочих пулов узлов рекомендуется использовать значение max_surge, равное 33 %.

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

API принимает как целочисленные значения, так и процентное значение для максимального всплеска и максимальной недоступности. Целое число, например 5, указывает, что пять узлов могут быть скачны или недоступны. Значение 50 % указывает на значение всплеска или недоступности в половине текущего количества узлов в пуле.

Одно из максимальной нагрузки или максимально недоступное значение должно быть не менее 1 (или 1%), в противном случае не было бы механизма, с помощью которого кластер может быть обновлен. Процентное значение округляется до ближайшего числа узлов. Максимальное увеличение и максимальное недоступное значение могут быть заданы не более 100 %. Если максимальное значение всплеска превышает требуемое количество узлов, которое необходимо обновить, количество узлов, которые необходимо обновить, используется для максимального значения всплеска.

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

Внимание

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

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

• Дополнительные сведения о пакетах версий Nexus Kubernetes.