С 26 ноября 2024 года на канале обновлений Stable сменились три версии Deckhouse Kubernetes Platform (DKP) — c 1.65 по 1.67. В этом дайджесте мы пройдёмся по самым важным изменениям в платформе и расскажем, как это скажется на работе её пользователей. Полный список изменений можно найти по ссылкам в описании каждого релиза.

Содержание:

Deckhouse Kubernetes Platform 1.65: автоматическое масштабирование master-узлов и поддержка МОС ОС и OpenSuse

Версия DKP 1.65 на канале обновлений Stable появилась 26 ноября 2024 года. Из ключевых особенностей можно выделить поддержку операционных систем МОС ОС и OpenSuse, новые возможности настройки режима обновлений DKP, автоматическое создание резервных копий базы etcd раз в сутки, проверку проекта на соответствие шаблону и автоматическую миграцию master-узлов при выполнении команды dhctl converge.

Рассмотрим изменения подробнее.

Добавлена поддержка операционных систем МОС ОС и OpenSuse

Это обновление обеспечивает совместимость с версиями МОС ОС 15.4 и 15.5 и OpenSuse 15.4, 15.5, 15.6. Теперь пользователи могут работать в более разнообразной инфраструктуре и использовать преимущества этих систем.

Добавлен новый режим обновлений DKP

Теперь для обновлений в режиме Manual (ручной режим) требуется подтверждение не только минорных версий, но и патч-версий. Это означает, что пользователи должны вручную подтверждать каждое обновление, что повышает контроль над процессом обновления.

Если нужно автоматически применять патч-версии (например, исправления безопасности или небольшие обновления), но при этом подтверждать обновления минорных версий, можно использовать режим AutoPatch. Он позволяет автоматизировать процесс обновления патч-версий, сохраняя контроль над более значительными обновлениями.

Подробности — в документации.

Добавлено автоматическое создание резервных копий базы etcd раз в сутки

Часто пользователи забывают заранее настроить резервное копирование. И если в таком случае удалить объекты из кластера, восстановить их невозможно. Поэтому мы добавили в DKP автоматическое создание резервных копий базы etcd раз в сутки в 00:00 по UTC. Результат сохраняется в директорию /var/lib/etcd/etcd-backup.tar.gz на всех master-узлах.

Добавлена проверка проекта на его соответствие шаблону проекта

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

Теперь невалидные проекты блокируются на этапе создания, что предотвращает появление проблем после развёртывания. Проекты создаются только в том случае, если они соответствуют шаблонам и не содержат ошибок, что гарантирует, что они будут функционировать правильно.

Процесс проверки проектов автоматизирован с помощью dry run рендеринга.

Масштабирование и изменение конфигурации master-узлов теперь требует меньше ручных действий

Миграция, обновление и масштабирование master-узлов при выполнении dhctl converge теперь полностью автоматические, даже при переходе к кластеру с одним master-узлом. Ранее это нужно было делать вручную.

Добавлена поддержка сканирования образов, размещённых в хранилищах, работающих по незащищённым протоколам или с использованием самоподписанных сертификатов

Ранее мы могли сканировать образы контейнеров только в реестрах, доступных по защищённому протоколу HTTPS. Это ограничивало возможность работать с хранилищами, использующими незащищённые протоколы (например, HTTP) или самоподписанные сертификаты. Теперь мы добавили поддержку сканирования образов, размещённых в таких хранилищах.

Эта новая функция позволяет нам сканировать образы из реестров, доступных по HTTP, убеждаться в отсутствии уязвимостей CVE, а затем безопасно перемещать эти образы в наш защищённый внутренний реестр.  

Полный список изменений версии 1.65.

Deckhouse Kubernetes Platform 1.66: поддержка Kubernetes 1.31 и добавление модуля multitenancy-manager в DKP Community Edition

Версия DKP 1.66 на канале обновлений Stable появилась 10 декабря 2024 года. Из ключевых особенностей можно выделить поддержку Kubernetes 1.31 и изменение версии по умолчанию, поддержку облачного провайдера Базис.DynamiX, ускорение процесса добавления облачных узлов с типом CloudPermanent, автоматическое назначение StorageClass на основе глобального параметра.

Рассмотрим изменения подробнее.

Добавлена поддержка Kubernetes 1.31 и прекращена поддержка Kubernetes 1.26 

Это обновление предоставит пользователям возможность воспользоваться последними функциями и улучшениями, доступными в Kubernetes 1.31. 

В каждом релизе DKP поддерживается не менее четырёх последних версий Kubernetes. Перейти на новую можно в любой момент. Минимальная поддерживаемая версия изменена на Kubernetes 1.27. В будущих релизах DKP поддержка Kubernetes 1.27 будет прекращена.

При этом версия Kubernetes, используемая по умолчанию, изменена на 1.29. Если для параметра kubernetesVersion установлено значение Automatic, при обновлении DKP версия Kubernetes обновится автоматически.

Однако для обновления до новой версии важно убедиться, что приложения готовы к изменениям. Но не переживайте, мы подумали обо всём за вас. Мы автоматически проверим на наличие блокировок, таких как использование устаревших API, и сгенерируем алерты о необходимости их исправления перед обновлением версии Kubernetes. Так вы можете обновиться без риска что-то сломать.

Модуль multitenancy-manager стал доступен в DKP Community Edition

Раньше модуль multitenancy-manager в DKP был доступен только в платной версии и работал в одном экземпляре. Теперь он доступен в бесплатной версии DKP CE, что позволяет использовать его без необходимости платной лицензии.

Также модуль multitenancy-manager теперь может работать в режиме высокой доступности. Контроллер модуля запускается в нескольких репликах на разных узлах кластера. Это снижает вероятность простоя модуля в случае отказа узла или потери связности.

Ускорен процесс добавления облачных узлов с типом CloudPermanent

Ранее процесс добавления облачных узлов с типом CloudPermanent выполнялся последовательно. Это означало, что каждый узел настраивался и добавлялся в кластер один за другим, что могло занимать значительное время, особенно при добавлении большого количества узлов.

Теперь процесс ускорен, так как узлы настраиваются и добавляются в кластер параллельно.

Пример сокращения времени можно посмотреть в PR во вкладке What is the expected result.

Добавлен единый механизм указания значений по умолчанию для StorageClass

Ранее пользователи могли вручную назначать StorageClass по умолчанию, используя аннотацию storageclass.kubernetes.io/is-default-class=true для нужного класса хранения. Это позволяло гибко управлять выбором StorageClass в зависимости от конкретных потребностей кластера. Но в то же время это могло приводить к сложно предсказуемому поведению в случае, если эта аннотация была указана для более чем одного StorageClass.

Теперь DKP самостоятельно назначает StorageClass, который используется в кластере по умолчанию на основе глобального параметра defaultClusterStorageClass. Это решение было принято для упрощения администрирования и стандартизации конфигураций в кластере, что исключает необходимость ручных действий и потенциальные ошибки при настройке.

Назначить используемый по умолчанию StorageClass с помощью аннотации теперь нельзя.

Добавлена возможность указывать дополнительные домены приложения при настройке аутентификации

Ранее при настройке аутентификации через DexAuthenticator в DKP пользователи могли указать только один домен приложения для аутентификации. Это означало, что для каждого дополнительного домена приложения требовался DexAuthenticator и, следовательно, отдельный экземпляр пода dex-authenticator, что усложняло конфигурацию и управление аутентификацией.

Чтобы упростить процесс настройки аутентификации и повысить эффективность использования dex-authenticator, мы добавили возможность указывать дополнительные домены приложения при настройке аутентификации через секцию параметров additionalApplications в DexAuthenticator. Это позволяет использовать только один экземпляр dex-authenticator, выполняющего функции аутентификации, для всех доменов приложения.

Полный список изменений версии 1.66.

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

Версия DKP 1.67 на канале обновлений Stable появилась 11 февраля 2025 года. Из ключевых особенностей можно выделить новый вид активной балансировки, расширяющий возможности стандартных сервисов Kubernetes, новый глобальный параметр для указания StorageClass и изменения при работе с подключаемыми модулями.

Рассмотрим изменения подробнее.

Добавлен новый вид активной балансировки

В Kubernetes можно использовать стандартные сервисы для балансировки нагрузки, но возможности по настройке проверок healthchecks ограничены. Проверки применялись на уровне сервиса в целом, что не позволяло гибко настраивать независимые балансировщики для отдельных контейнеров или подов.

Новый вид активной балансировки позволяет настроить несколько независимых балансировщиков на отдельные проверки пода. Также он даёт возможность настроить у контейнера больше одной проверки для работы независимых балансировщиков. Это позволяет точнее контролировать доступность сервисов.

Проверкой может быть TCP-порт, HTTP-запрос или запрос к PostgreSQL. Настраивается с помощью ресурса ServiceWithHealthchecks. Подробнее — в документации модуля service-with-healthchecks.

Параметр storageClass перенесён в modules.storageClass

Ранее для указания StorageClass, используемого для компонентов DKP, использовался глобальный параметр storageClass. Он позволял администраторам конфигурировать хранилище для внутренних компонентов DKP. 

Новый глобальный параметр modules.storageClass поможет разделить настройки StorageClass для компонентов Deckhouse и других частей системы.

Параметр storageClass считается устаревшим. Предусмотрена автоматическая миграция значений storageClass в modules.storageClass при обновлении DKP.

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

Основные изменения:

  • При создании ModuleSource модуль больше не устанавливается автоматически. Вместо этого он появляется в списке доступных модулей и ожидает активации. В итоге фактическая установка модуля и создание соответствующих объектов ModuleRelease происходят только после того, как модуль будет явно включен.

  • Была выпущена новая версия ModuleUpdatePolicy — v1alpha2. В ней отсутствует блок параметров moduleReleaseSelector. Если вы используете старую версию v1alpha1 и указали параметры moduleReleaseSelector, то для вас будет сгенерирован алерт ModuleHasDeprecatedUpdatePolicy. Это означает, что ваша конфигурация устарела и требует обновления. Чтобы избежать проблем, рекомендуем выполнить миграцию на новую версию. Шаги по миграции описаны в нашей документации. Теперь политика обновления модуля указывается в параметре updatePolicy ModuleConfig. Если у вас возникли вопросы или вы забыли выполнить миграцию, алерт ModuleHasDeprecatedUpdatePolicy напомнит вам об этом.

  • Если модуль доступен из нескольких источников, то можно указать используемый источник модуля (имя ModuleSource) в параметре source ModuleConfig. Это позволяет гибко управлять источниками модулей. При этом в новой версии ModulePullOverride v1alpha2 удалён параметр source. Теперь источник для модуля определяется ресурсом ModuleSource.

  • Объект Module обогащён дополнительной информацией о модуле и статусами его работы.

Полный список изменений версии 1.67.

Заключение

Deckhouse Kubernetes Platform продолжает активно развиваться. В этом обзоре мы постарались кратко осветить основные изменения, произошедшие с платформой за последние три релиза. Кратко об основных изменениях:

  • Добавлена поддержка операционных систем МОС ОС и OpenSuse

  • Добавлена возможность настройки режима обновлений DKP

  • Добавлено автоматическое создание резервных копий базы etcd раз в сутки

  • Добавлена проверка проекта на его соответствие шаблону проекта

  • Добавлены автоматические миграция, обновление и масштабирование master-узлов при выполнении команды dhctl converge

  • Добавлена возможность загружать базы данных из незащищённых реестров

  • Добавлена поддержка Kubernetes 1.31 и прекращена поддержка Kubernetes 1.26

  • Модуль multitenancy-manager стал доступен в DKP Community Edition

  • Добавлены узлы CloudPermanent для параллельного добавления в кластер

  • Добавлен единый механизм указания значений по умолчанию StorageClass

  • Добавлена возможность указывать дополнительные домены приложения при настройке аутентификации

  • Добавлен новый вид активной балансировки

  • Введён новый глобальный параметр для указания StorageClass

  • Введены изменения при работе с подключаемыми модулями

Для знакомства с платформой Deckhouse рекомендуем изучить раздел «Быстрый старт» (доступен на русском и английском языках).

Полезные ссылки на ресурсы проекта:

P. S.

Читайте также в нашем блоге:

Комментарии (0)