Обновление

Релизом DKP считается любая опубликованная версия платформы. Каждый релиз распространяется по каналам обновлений с заданными задержками.

DKP выпускает два типа релизов:

• Патч-версии (например, с 0.0.1 на 0.0.2) — содержат только исправления ошибок и выпускаются по мере необходимости.
• Минорные версии (например, с 0.0.1 на 0.1.0) — включают новую функциональность и выходят регулярно, каждые 3–4 недели.

Deckhouse Kubernetes Platform использует пять каналов обновлений для поэтапного развёртывания новых версий. Каждый новый релиз последовательно публикуется в каналах: Alpha → Beta → Early Access → Stable → Rock Solid. Благодаря этому менее стабильные версии сначала получают ограниченное число пользователей, что позволяет выявить и исправить проблемы до того, как они затронут production-среды.

Описание каналов (в порядке возрастания стабильности):

• Alpha — наименее стабильный канал с самой высокой частотой появления новых версий. Подходит для небольших кластеров разработки. Релизы публикуются сразу после выхода.
• Beta — также ориентирован на кластеры разработки. Версии попадают сюда после предварительного тестирования в Alpha.
• Early Access — рекомендуемый выбор, если нет особых предпочтений. Подходит для активно развивающихся кластеров (разработка новых приложений, доработки). Обновления задерживаются минимум на 7 дней после релиза.
• Stable — стабильный канал для кластеров в эксплуатации. Обновления публикуются не ранее чем через 14 дней после релиза.
• Rock Solid — максимально стабильный канал. Предназначен для кластеров с повышенными требованиями к надёжности. Обновления выходят с задержкой не менее 30 дней после релиза.

При смене канала, например с Alpha на EarlyAccess, DKP выполняет следующие действия:

1. Загружает информацию о релизах из нового канала (EarlyAccess).
2. Сравнивает эти данные с существующими в кластере ресурсами DeckhouseRelease.
3. Обрабатывает релизы в статусе Pending: Если в кластере есть более поздние релизы, которые ещё не были применены (статус Pending), они удаляются. Причина — эти версии ещё не опубликованы в новом канале.
4. Определяет дальнейшую стратегию: Если более поздние релизы уже были успешно установлены (статус Deployed), переход на новую версию произойдёт не сразу. DKP останется на текущем релизе до тех пор, пока в канале EarlyAccess не появится версия новее текущей, доступная для установки.

При смене канала, например с EarlyAccess на Alpha, DKP выполняет следующие действия:

1. Загружает информацию о релизах из нового канала (Alpha).
2. Сравнивает эти данные с существующими в кластере ресурсами DeckhouseRelease.
3. Выполняет обновление в соответствии с настроенными параметрами (например, автоматически или по расписанию).

В Deckhouse Kubernetes Platform процесс обновления control plane максимально автоматизирован и безопасен как для single-master-, так и для multi-master-кластеров. Возможны лишь кратковременные перерывы в доступности API-сервера, которые не влияют на работу приложений внутри кластера. Дополнительное окно для регламентных работ, как правило, не требуется.

Поддержка версий Kubernetes:

DKP поддерживает последние пять минорных версий Kubernetes. Актуальный список доступен в соответствующей таблице.

Обновление patch-версий компонентов control plane (в рамках одной минорной версии, например, с 1.27.3 на 1.27.5) происходит автоматически вместе с обновлением версии Deckhouse. Пользователь не может управлять установкой patch-версий вручную — процесс полностью автоматизирован внутри платформы.

Для автоматического обновления минорной версии control plane (например, с 1.28.* на 1.30.*) укажите kubernetesVersion: Automatic в ресурсе ClusterConfiguration. Будет выбрана минорная версия Kubernetes, используемая в DKP по умолчанию на момент обновления.

Для ручного обновления минорной версии control plane (например, с 1.28.* до 1.30.*), укажите нужную версию в параметре kubernetesVersion ресурса ClusterConfiguration. Например: kubernetesVersion: 1.30.

Команда запускает обновление до минорной версии Kubernetes, используемой в DKP по умолчанию на момент обновления. Чтобы отследить ход обновления, ориентируйтесь на версию Kubernetes, указанную в выводе команды описания узлов:

Модуль control-plane-manager обновляет манифесты компонентов control plane (apiserver, controller-manager, scheduler и др.). Обновлённые компоненты разворачиваются на всех master-узлах.

При upgrade (переход на новую минорную версию):

• Если нужно перейти на несколько версий вперёд (например, с 1.28 до 1.30), обновление идёт поэтапно: 1.28 → 1.29 → 1.30.
• На каждом этапе сначала обновляется control plane, затем — kubelet на узлах.

При downgrade (откат до предыдущей версии, не поддерживается для редакции CSE):

• Гарантирован откат только на одну минорную версию назад от максимальной версии, когда-либо установленной в кластере.
• Порядок обратный: сначала откатывается kubelet на узлах, затем — компоненты control plane.

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

После обновления control plane начинается обновление узлов:

• Bashible API Server меняет версию kubelet в скриптах для всех групп узлов (NodeGroup).
• Обновление групп узлов:

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

Для каждой группы учитываются настройки: режим (ручной/автоматический), окна обновлений, необходимость дренирования подов и т.д.

• Процесс: выбираются кандидаты, удовлетворяющие условиям, обновляются, и так до тех пор, пока не обновятся все узлы во всех группах.
• Завершение: когда все узлы во всех группах обновлены, процесс обновления считается завершённым.

При каждом выпуске новой версии Deckhouse Kubernetes Platform публикуется changelog — подробный список изменений, который включает:

• новые возможности;
• исправления ошибок;
• обновления компонентов;
• важные замечания по совместимости.

• Полный changelog для конкретной версии DKP доступен в общем списке релизов проекта Deckhouse на GitHub.
• Сводная информация о ключевых изменениях, обновлениях версий компонентов и о том, какие компоненты будут перезапущены в процессе обновления, публикуется в описании нулевой патч-версии релиза (например, для релиза DKP v1.68 — в описании v1.68.0).

Changelog содержит четыре раздела:

• Know before update (важно знать перед обновлением) — важная информация, которую необходимо учесть перед обновлением. Включает сведения о требованиях к совместимости, необходимых действиях перед обновлением и возможных последствиях для кластера.
• Features (новые возможности) — описание ключевых улучшений и новых функций, добавленных в релизе.
• Fixes (исправления) — описание незначительных изменений, обновлений безопасности или улучшения производительности.
• Chore (сервисные изменения) — перечисление технических изменений, которые включают обновления зависимостей, рефакторинг, исправления в процессах сборки и тестирования, а также устранение уязвимостей.

Вся ключевая информация о крупных изменениях публикуется в описании нулевой патч-версии релиза (например, для версии v1.68 — в описании v1.68.0).

Перед обновлением до новой минорной версии (например, до v1.68) рекомендуется:

1. Изучить changelog соответствующей версии.
2. Проверить, затрагивают ли описанные изменения вашу инфраструктуру (конфигурации, компоненты, совместимость).
3. При необходимости внести корректировки в конфигурацию кластера до начала обновления.

Перед применением нового релиза Deckhouse Kubernetes Platform автоматически проверяет состояние кластера. При обнаружении любой из следующих несовместимостей процесс обновления прерывается:

• Неподдерживаемая версия Kubernetes — если текущая версия выходит за пределы поддерживаемых новым релизом.
• Проблемы при kubernetesVersion: Automatic — обновление блокируется, если в новом релизе изменена рекомендуемая версия Kubernetes, включён мониторинг, и в кластере присутствуют ресурсы, объявленные устаревшими (deprecated) в новой версии.
• Несовместимая версия Ingress-контроллера — установленная версия не поддерживается новым релизом.
• Устаревшие ОС на узлах — операционные системы узлов не входят в список поддерживаемых новым релизом.
• Использование удаляемых модулей — в кластере включён модуль, который помечен как deprecated или полностью удалён в новом релизе.