Релизы

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

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

Каналы обновлений

Актуальная информация о версиях DKP на разных каналах обновлений доступна на сайте releases.deckhouse.ru.

Deckhouse Kubernetes Platform использует пять каналов обновлений, обеспечивающих поэтапное развертывание новых версий. Каждая новая версия DKP сначала публикуется в канале Alpha и постепенно продвигается к Rock Solid. Обновления из менее стабильных каналов доступны небольшому числу пользователей, что позволяет выявлять и устранять потенциальные проблемы до того, как они повлияют на production-среды.

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

Процесс переключения на более стабильный канал

При переключении на более стабильный канал (например, с Alpha на EarlyAccess):

  1. DKP загружает данные о релизах из канала EarlyAccess.
  2. Сравнивает их с данными из существующих в кластере кастомных ресурсов DeckhouseRelease.
    • Если в кластере есть более поздние релизы со статусом Pending (ещё не применены), они будут удалены, поскольку они ещё не были опубликованы на новом канале.
    • Если более поздние релизы уже перешли в статус Deployed (успешно установлены), переход на новый релиз произойдёт не сразу. DKP останется на текущем релизе до тех пор, пока на канале EarlyAccess не выйдет более поздняя версия, которую можно будет установить.

Процесс переключения на менее стабильный канал

При переключении на менее стабильный канал (например, с EarlyAccess на Alpha):

  1. DKP скачивает данные о релизах из канала Alpha.
  2. Сравнивает их с данными из существующих в кластере кастомных ресурсов DeckhouseRelease.
  3. Выполняет обновление в соответствии с настроенными параметрами обновления.

Обновление control plane

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

В 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.

d8 system edit cluster-configuration

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

d8 k get nodes

Процесс обновления компонентов control plane

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

При обновлении до новой минорной версии (upgrade):

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

При откате до предыдущей версии (downgrade):

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

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

  1. Bashible API Server меняет версию kubelet в скриптах для всех групп узлов (NodeGroup).
  2. Обновление узлов в разных NodeGroup идёт параллельно, однако внутри каждой NodeGroup узлы обновляются последовательно, по одному.
  3. Для каждой NodeGroup учитываются её настройки:
    • ручной или автоматический режим обновления;
    • наличие окон обновлений;
    • требуется ли удалять поды с узла перед обновлением и др.
  4. Выбирается один (или несколько) узлов-кандидатов, удовлетворяющих всем условиям обновления, после чего выполняется их обновление.
  5. Процесс повторяется, пока не обновятся все узлы во всех группах.
  6. Когда обновлены все узлы во всех группах, процесс обновления завершается.

Получение истории изменений (changelog)

При каждом выпуске новой версии Deckhouse Kubernetes Platform (DKP) формируется changelog — подробный список изменений, включающий новые возможности, исправления ошибок, обновления компонентов, а также важные замечания по совместимости.

Changelog для конкретной версии DKP можно найти в общем списке релизов проекта Deckhouse на GitHub.

Сводная информация о ключевых изменениях, обновлениях версий компонентов, а также о том, какие компоненты в кластере будут перезапущены в процессе обновления, доступна в описании нулевой патч-версии релиза: пример для релиза DKP v1.68.

Содержимое changelog

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

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

Минорные версии и нулевая патч-версия

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

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

Проверка зависимостей при обновлении

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

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