Как происходит обновление в открытом и закрытом контурах

Модуль Shturval Updater, каналы обновления, интерфейс кластера и контуры поставки.

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

1. Учтите релизную политику: порядок обновления кластеров, виды версий и поддержка.
2. Проверьте на карте версий, что переход с текущей версии на целевую допустим (при необходимости — через промежуточную).
3. Для минорных обновлений сверьтесь с соответствием версий Штурвал и Kubernetes.
4. Если после подготовки версия не появляется в интерфейсе или процесс идёт с ошибками — см. Траблшутинг обновления.

Модуль обновления (Shturval Updater) #

Модуль Shturval Updater обеспечивает:

• обновление системных компонентов и сервисов кластера;
• управление версиями кластера;
• согласованность версий платформы «Штурвал» и Kubernetes.

Модуль критичен для работы платформы и устанавливается по умолчанию в кластер управления и клиентские кластеры.

Кастомные ресурсы обновления #

• ShturvalUpdate — задаёт версию обновления, отображает статус;
• ShturvalUpdateChannel — канал обновления (в платформе доступен только стабильный канал);
• ShturvalUpdateSchedule — параметры отложенного обновления.

Открытый контур #

Обновление доступно напрямую из репозитория. После выхода новой версии она появляется в интерфейсе. Запустите обновление через раздел «Кластеры» → «Обновление» или через соответствующие кастомные ресурсы.

Закрытый контур #

1. Обновите само зеркало и загрузите бандл новой версии в каждое используемое в закрытом контуре registry или выполните stm bundle load / stm download. Подробнее: Работа с зеркалом после инсталляции.
2. Перезапустите кастомный ресурс ShturvalUpdateChannel (shturval-update) в каждом кластере, который планируете обновлять.
3. Через 5–10 минут новая версия станет доступна для обновления в интерфейсе. Если этого не произошло — см. Траблшутинг обновления.

Перезапуск ShturvalUpdateChannel #

Без перезапуска ShturvalUpdateChannel с именем shturval-update реконсиляция произойдет автоматически, но может занять до 6 часов.

После перезапуска новая версия обычно появляется в интерфейсе через 5–10 минут.

kubectl label ShturvalUpdateChannel shturval-update --namespace shturval-update-system example=

Обновление в графическом интерфейсе #

Платформа выпускается минорными и патч-версиями; патч-релизы выходят по необходимости. График выпуска и политика поддержки описаны в релизной политике. Допустимые переходы между номерами версий — на карте версий.

На дашборде кластера управления или клиентского кластера нажмите Управлять рядом с версией кластера и Kubernetes. В модальном окне обновления можно вручную запустить обновление или настроить автоматический запуск по расписанию; состояние процесса отображается в блоке обновления. Если показано «Обновлений нет», у вас последняя доступная версия (для текущего канала).

Ручной запуск #

Если в списке есть целевая версия, выберите её и нажмите Обновить.

Отложенное обновление по расписанию #

Отложенное обновление задаёт расписание, по которому система может автоматически запускать обновление при появлении подходящей версии. Можно создать несколько конфигураций под разные сценарии (например, для минорных и патч-версий); просмотр всех расписаний — в том же модальном окне, наименование расписания создаётся автоматически.

Чтобы настроить расписание, в окне обновления нажмите + рядом с «Настройка отложенного обновления» и укажите:

• Расписание в формате cron (между значениями — пробелы); расписание интерпретируется в часовом поясе процесса контроллера, обычно UTC;
• Длительность окна обновления (по умолчанию 24 часа) — сколько времени может использоваться для проведения обновления, если к моменту проверки по расписанию доступна подходящая версия; в графическом интерфейсе минимальное значение — 30 минут (меньший интервал может быть недостаточен для корректного обновления);
• Поведение при превышении окна: параметр не влияет на первичный запуск обновления по расписанию, а применяется к уже запущенному обновлению; остановиться — процессы обновления приостанавливаются, в окне отображается состояние UpdatePaused, для возобновления нажмите Продолжить вне расписания; продолжить — обновление идёт до завершения;
• разрешено ли автоматически обновлять до минорных версий; если нет — автоматическое обновление только до патч-версий.

Обратите внимание! расписание задаёт начало окна обновления, а длительность окна — период, в течение которого обновление может быть запущено. При проверке расписания контроллер сначала рассчитывает окно от ближайшего предыдущего запуска по cron. Если текущее время попадает в это окно, обновление запустится сразу, не дожидаясь следующего запуска по расписанию. Например, при расписании 0 20 * * * и длительности окна 24 часа обновление начнётся сразу. Если при таком же расписании в 18:00 UTC задать длительность окна 4 часа, обновление запустится в 20:00 UTC.

Завершите настройку кнопкой Добавить. Конфигурацию расписания можно изменить в любой момент; если правки внесены во время уже идущего обновления, далее применяется новый сценарий. Расписание можно удалить, если обновление по нему ещё не началось.

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

После запуска на дашборде отображаются этапы:

• обновление модуля обновления кластера (shturval-update);
• принудительное удаление устаревших сервисов (этап может быть пропущен при их отсутствии);
• обновление модуля управления конфигурациями узлов (shturval-node-config); этап может быть пропущен, обновление завершится без инициализации этапа;
• обновление версии Kubernetes;
• обновление версий системных сервисов платформы.

Индикация состояния этапов:

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

После завершения обновления кластера #

После обновления кластера обновите шаблоны ВМ в InfraMachineTemplate, чтобы новые узлы создавались с актуальной версией Kubernetes. Пошагово — в разделе Узлы и шаблоны ВМ. Для кластеров с провайдером Shturval v2 отдельная замена шаблонов не требуется.

Обратите внимание! Начиная с релиза 2.14.0 (Kubernetes 1.35) шаблоны ВМ должны быть подготовлены с cgroup v2. Если после обновления не заменить шаблоны, при масштабировании или пересоздании узлов новые ВМ поднимутся из старого шаблона (cgroups v1) и зависнут при обновлении kubelet. Подробнее — Требование cgroup v2.

Обращение в поддержку #

При затруднениях в процессе обновления сначала см. Траблшутинг обновления. При необходимости обратитесь к команде разработки через сервис-деск: вкладка «О системе» графического интерфейса платформы.

Особенности процесса обновления #

Обновление без простоя #

Обновление происходит в фоновом режиме без даунтайма. Кластер продолжает работать во время обновления, приложения остаются доступными.

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

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

1. Cordon — узел помечается как недоступный для новых подов (новые поды не будут размещены на этом узле).
2. Drain — существующие поды аккуратно завершаются или перемещаются на другие узлы (graceful shutdown).
3. Обновление — на узле обновляются компоненты платформы и Kubernetes.
4. Uncordon — узел снова становится доступным для размещения подов.

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

Ограничения #

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

• создать резервную копию кластера (если включён модуль резервного копирования);
• ознакомиться с release notes целевой версии на предмет breaking changes.