Обновление Kubernetes: запуск, режимы и переходы между версиями

Где запускать обновление #

Обновление кластера (включая версию Kubernetes) запускается в GUI на дашборде кластера — кластера управления или клиентского кластера или с помощью команд в CLI.

Где посмотреть доступные версии #

В графическом интерфейсе — блок «Обновление» на дашборде кластера. Если доступна хотя бы одна новая версия, об этом сообщается непосредственно в блоке. Полный список стабильных версий, доступных для обновления с текущей версии, открывается по кнопке управления обновлением.

Полная карта — Карта версий обновлений.

В CLI доступные версии можно посмотреть в ресурсе ShturvalUpdateChannel.

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

Рекомендации перед обновлением #

1. Ознакомьтесь с release notes целевой версии — там могут быть breaking changes и миграционные шаги.
2. Создайте резервную копию кластера управления перед обновлением.
3. Проверьте карту версий — убедитесь, что прямой переход поддерживается. Если нет — спланируйте обновление через промежуточную версию.

Обновляйте клиентские кластеры только после обновления кластера управления!

Режимы обновления #

kubectl -n shturval-update-system patch su shturval-update --type=merge -p '{"spec":{"version":"X.Y.Z"}}'

kubectl -n shturval-update-system patch su shturval-update --type=merge -p '{"spec":{"version":"2.14.0"}}'

apiVersion: update.shturval.tech/v1beta1
kind: ShturvalUpdateSchedule
metadata:
  name: update-schedule
  namespace: shturval-update-system
spec:
  allowMinorVersion: true
  pauseIfUpdatePeriodExceed: false
  schedule: "0 8 26 9 *"
  updatePeriod: "10h0m0s"

kubectl -n shturval-update-system patch su shturval-update --type=merge -p '{"spec":{"followSchedule":"update-schedule"}}'

Этапы обновления #

После запуска обновление проходит следующие этапы (отображаются на дашборде):

1. Обновление модуля shturval-update — обновление самого модуля обновления.
2. Принудительное удаление устаревших сервисов — этап может быть пропущен при отсутствии таких сервисов.
3. Обновление shturval-node-config — модуль управления конфигурациями узлов.
4. Обновление версии Kubernetes — обновление компонентов Kubernetes в кластере.
5. Обновление системных сервисов — обновление версий сервисов платформы (мониторинг, логирование и др.).

Статусы этапов #

Цветовая индикация на дашборде:

• Зелёный — этап успешно завершён;
• Жёлтый — этап выполняется;
• Серый — этап не инициализирован.

При использовании отложенного обновления: если обновление не успело завершиться в указанное окно и настроено поведение «остановиться», отображается статус UpdatePaused. Для возобновления нажмите Продолжить вне расписания.

Кастомные ресурсы #

Общий обзор этих и других кастомных ресурсов платформы приведён на странице «Кастомные ресурсы в платформе».

Особые шаги для отдельных переходов #

Некоторые переходы требуют дополнительных действий. Если ручные действия требуются, это указано в release notes целевой версии.

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

В процессе обновления происходит замена версии только на созданных в кластере узлах. Новые создаваемые узлы будут иметь старую версию. Это обусловлено версией, определенной в InfraMachineTemplate. После завершения обновления необходимо создать новый шаблон ВМ на стороне провайдера инфраструктуры и заменить InfraMachineTemplate в группах узлов. Подробнее: Узлы и шаблоны ВМ.

Обновление с версии 2.15 #

Разделы выше — запуск обновления до версии 2.15 включительно: целевая версия задаётся в ShturvalUpdate, доступные версии — в ShturvalUpdateChannel.

Когда кластер обновлен на 2.15, следующее обновление запускается ресурсами группы cluster.shturval.tech в кластере управления. Имя ClusterConfig и ClusterInfo и их неймспейс совпадают с именем кластера. После перехода на 2.15 объекты ShturvalUpdate, ShturvalUpdateChannel и ShturvalUpdateSchedule удаляются.

Шаги в графическом интерфейсе остаются прежними. В CLI меняются ресурсы.

Доступные версии — поле status.update.availableUpdates ресурса ClusterInfo:

kubectl get clusterinfo clustername -n clustername -o jsonpath='{.status.update.availableUpdates}'

Целевая версия — spec.releaseVersion ресурса ClusterConfig. Замените clustername на имя кластера, X.Y.Z — на версию новее 2.15:

kubectl patch clusterconfig clustername -n clustername --type=merge -p '{"spec":{"releaseVersion":"X.Y.Z"}}'

Стратегия обновления узлов — spec.update.updateStrategy. Если поле пустое, применяется InPlace. Допустимые значения: InPlace и RollingUpdate.

RollingUpdate недоступен, если в кластере есть узлы Shturval v2, в том числе в гибридном кластере. Допустимые стратегии — status.update.availableStrategies ресурса ClusterInfo. Пока обновление идёт, spec.releaseVersion и spec.update.updateStrategy менять нельзя.

Чтобы задать стратегию вместе с версией:

kubectl patch clusterconfig clustername -n clustername --type=merge -p '{"spec":{"releaseVersion":"X.Y.Z","update":{"updateStrategy":"RollingUpdate"}}}'

Расписание — ресурс ClusterUpdateSchedule в неймспейсе кластера. Примените манифест в кластере управления:

apiVersion: cluster.shturval.tech/v1beta1
kind: ClusterUpdateSchedule
metadata:
  name: update-schedule
  namespace: clustername
spec:
  schedule: "0 8 26 9 *"
  updatePeriod: "10h0m0s"
  pauseIfUpdatePeriodExceed: false
  allowMinorVersion: true

Дата и время следующего запуска в UTC записываются в поля status.nextUpdateStart и status.nextUpdateEnd ресурса ClusterUpdateSchedule. Если следующий запуск вычислить нельзя, эти поля остаются пустыми.

Когда окно открыто и есть доступная версия, в ClusterConfig записываются spec.releaseVersion и spec.update.followSchedule с именем этого расписания. Удалить расписание нельзя, пока followSchedule на него указывает.