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

Содержание:

Deckhouse Kubernetes Platform 1.68: управление лейблами узлов и TLS для логов

Deckhouse Kubernetes Platform 1.69: поддержка Kubernetes 1.32 и гибкое включение пространств имён в проекты

Deckhouse Kubernetes Platform 1.70: переход на OpenTofu и перезагрузка узлов через аннотации

Deckhouse Kubernetes Platform 1.68: управление лейблами узлов и TLS для логов

Релиз вышел 1 апреля 2025 года на канале Stable. Из ключевых изменений можно выделить управление лейблами узлов через файлы в /var/lib/node_labels, новый параметр keepDeletedFilesOpenedFor для дочитывания логов удалённых подов, а также настройку TLS для сборщиков логов через Kubernetes Secrets.

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

Управление лейблами узлов через файлы в /var/lib/node_labels

Теперь можно добавлять, удалять и изменять лейблы узлов, используя файлы, хранящиеся на узле в директории /var/lib/node_labels и её поддиректориях. Полный набор применённых лейблов хранится в аннотации node.deckhouse.io/last-applied-local-labels.

Формат лейблов: ключ=значение (foo=bar) по одному на строку, в любом файле внутри /var/lib/node_labels.

Это простой способ добавлять лейблы на узел без необходимости подключаться к мастеру и использовать kubectl. Достаточно просто положить файл с лейблами в определённую директорию, и система сама подхватит изменения (например, при восстановлении связи). Это удобно для автоматизации или ручного управления без доступа к Kubernetes API.

Настройка TLS для сборщиков логов через Kubernetes Secrets

Теперь TLS-шифрование для лог-систем (Elasticsearch, Vector, Loki, Splunk, Logstash, Socket, Kafka) можно настраивать через Kubernetes Secrets вместо прямого указания сертификатов в ClusterLogDestination. Секрет должен находиться в пространстве имён d8-log-shipper и иметь лейбл log-shipper.deckhouse.io/watch-secret: true.

Ранее — при указании сертификатов непосредственно в параметрах ClusterLogDestination — не было возможности их автоматически обновлять. Использование Kubernetes Secrets решает эту проблему: теперь сертификаты можно обновлять автоматически, например с помощью cert-manager. Это облегчает управление сертификатами и повышает безопасность лог-систем.

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

Deckhouse Kubernetes Platform 1.69: поддержка Kubernetes 1.32 и гибкое включение пространств имён в проекты

Релиз стал доступен на канале Stable 3 июня 2025 года. Среди важных нововведений — обновление поддержки Kubernetes до версии 1.32, гибкое включение существующих пространств имён в проекты через аннотацию, а также автоматическая настройка доступа к кластеру после установки, избавляющая от ручного SSH-подключения.

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

Обновление поддержки версий Kubernetes

Теперь DKP совместима с Kubernetes 1.32, при этом версия 1.30 стала новой версией по умолчанию для свежих установок. В рамках этого обновления прекращена поддержка устаревшей версии 1.27, а поддержка версии 1.28 будет прекращена в следующих релизах платформы. Минимальная требуемая версия Kubernetes теперь — 1.28.

Это изменение означает, что при развёртывании новых кластеров автоматически будет использоваться Kubernetes 1.30, если явно не указана другая версия. Для существующих кластеров на версии 1.27 потребуется предварительное обновление до 1.28 или выше перед переходом на актуальную версию DKP.

Гибкое включение существующих пространств имён в проекты Deckhouse

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

Чтобы преобразовывать существующие пространства имён и их ресурсы в полноценные проекты без пересоздания объектов, достаточно добавить аннотацию projects.deckhouse.io/adopt к пространству имён — система автоматически создаст пустой проект с тем же именем.

Проверяем наличие проектов:

root@dev-master-0:~# k get project
NAME        STATE      PROJECT TEMPLATE   DESCRIPTION                 AGE
deckhouse   Deployed   virtual            This is a virtual project   181d
default     Deployed   virtual            This is a virtual project   181d

Создаём и аннотируем пространство имён:

kubectl create ns test 

kubectl annotate ns test projects.deckhouse.io/adopt=""

Проверяем проекты:

root@dev-master-0:~# k get project
NAME        STATE      PROJECT TEMPLATE   DESCRIPTION                 AGE
deckhouse   Deployed   virtual            This is a virtual project   181d
default     Deployed   virtual            This is a virtual project   181d
test        Deployed   empty                                          1m

Результат: из пространства имён test создался проект test.

Однако не все объекты пространства имён могут быть автоматически интегрированы: если в шаблоне проекта уже определён ресурс, который существует в пространстве имён, то такой объект не будет адаптирован автоматически. В подобных случаях потребуется либо удалить конфликтующий объект, либо адаптировать вручную с помощью дополнительных аннотаций.

Автоматическая настройка доступа к кластеру после установки

После установки кластера пользователи часто не знают, какие действия выполнять дальше. Хотя Deckhouse может выводить рекомендуемые kubectl-команды, для их выполнения нужно подключаться к control-plane-узлу по SSH, что неудобно. Теперь после успешного развёртывания кластера Deckhouse через консольную утилиту dhctl установщик автоматически генерирует kubeconfig (~/.kube/config) и настраивает локальный TCP-прокси через SSH-туннель. Это позволяет сразу использовать kubectl локально и не подключаться к control-plane-узлу по SSH вручную. 

Гибкая настройка времени drain для NodeGroup

В модуле node-manager появился новый параметр nodeDrainTimeoutSecond, позволяющий явно задать максимальное время (в секундах) на операцию drain узла для каждой NodeGroup.

Ранее можно было либо использовать вариант по умолчанию (10 минут), либо уменьшить время до 5 минут (параметр quickShutdown, который устарел). В редких случаях (например, когда поды долго переезжают на новый узел) этого времени могло не хватить, что приводило к задержкам в обновлении кластера.

Пример указания значения параметра:

apiVersion: deckhouse.io/v1
kind: NodeGroup
metadata:
  name: worker
spec:
  nodeDrainTimeoutSecond: 900 // Указываем в секундах.
  cloudInstances:
    classReference:
      kind: YandexInstanceClass
      name: worker
    maxPerZone: 1
    minPerZone: 1
    zones:
      - ru-central1-a
  disruptions:
    approvalMode: Automatic
  nodeType: CloudEphemeral

Исправление маршрутизации NAT в Yandex Cloud

В схеме размещения withNATInstance для Yandex Cloud NAT-инстанс теперь создаётся в отдельной подсети, а не в той же, где находятся узлы кластера. Это предотвращает петли маршрутизации, из-за которых ранее трафик мог зацикливаться, а узлы теряли доступ в интернет.

Ранее NAT-инстанс размещался в одной подсети с узлами. После изменения логики маршрутизации на стороне «Яндекса» старая схема перестала работать для новых инсталляций: это могло приводить к потере доступа к NAT-инстансу, отсутствию интернета на узлах в приватной сети и циклам маршрутизации, когда трафик не мог выйти за пределы подсети.

Автоматическая очистка логов в loki по объёму данных

В модуле loki появилась новая система управления хранением логов, основанная на объёме данных. Теперь при превышении заданного пользователем лимита автоматически удаляются самые старые записи.

Как это работает:

1. Система отслеживает заполнение PVC.

2. При достижении порога (95 % от размера PVC или «размер PVC минус место для двух минут логов») начинается очистка.

3. Удаляются самые старые данные, пока объём не станет ниже порога.

Например, если установить лимит в 50 ГБ, удаление начнется только после его превышения и не закончится, пока объём не станет меньше выбранного порога.

Параметр retentionPeriodHours больше не управляет сроком хранения данных и используется только для алертов мониторинга. Если loki начнёт удалять записи до истечения заданного периода, пользователю будет отправлен алерт LokiRetentionPerionViolation и необходимо будет либо уменьшить значение retentionPeriodHours, либо увеличить размер PVC.

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

Deckhouse Kubernetes Platform 1.70: переход на OpenTofu и перезагрузка узлов через аннотации

Релиз опубликован 8 июля 2025 года. Основные изменения включают в себя переход с Terraform на OpenTofu в облачных провайдерах, управление перезагрузкой узлов через аннотации и уточнение логики автообновлений с учётом заданных окон для патч-версий.

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

Уточнение логики автообновлений с учётом окон обновлений

В режиме обновления Auto теперь учитываются заданные окна обновлений не только для минорных (1.69 → 1.70), но и для патч-версий (1.70.1 → 1.70.2). Раньше в этом режиме с учётом окон обновлений применялись только обновления минорных версий, а обновления патч-версий — по мере их появления на канале обновлений.

Управление перезагрузкой узлов через аннотации

Добавили возможность инициировать перезагрузку узла Kubernetes через установку аннотации update.node.deckhouse.io/reboot на соответствующем объекте Node. Это дополняет существующий механизм drain (отключения узла) через аннотацию update.node.deckhouse.io/draining. Эта возможность особенно полезна для работы через консоль и позволяет выполнять все необходимые операции по управлению состоянием узла в одном месте без дополнительных ручных действий.

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

Теперь в статусе ресурса ModuleSource отображается информация о доступных версиях модулей. Раньше узнать версию модуля можно было только после его установки на кластер, теперь это возможно сделать заранее — просто посмотрев статус ModuleSource.

root@master-0:~# k get ms deckhouse -oyaml
...
status:
message: ""
modules:
- checksum: sha256:0045e98ac9093bc2f923c009ebb11fad6ef758e656f5c8837103be72148a0edc
name: console
version: v1.38.4
...

Поддержка современных алгоритмов шифрования для сертификатов control plane

Добавили возможность выбирать более надёжные алгоритмы шифрования для сертификатов control plane (например, RSA-3072, RSA-4096 или ECDSA-P256) вместо стандартного RSA-2048. Для этого в ClusterConfiguration добавлен параметр encryptionAlgorithm, который определяет алгоритм генерации сертификатов.

Поддерживаются:

• RSA-2048 (по умолчанию, для совместимости);

• RSA-3072, RSA-4096 (более стойкие варианты RSA);

• ECDSA-P256 (современный алгоритм на эллиптических кривых).

Перечисленные алгоритмы доступны с Kubernetes версии 1.31. В Kubernetes версии 1.30 и ниже поддерживается только алгоритм RSA-2048.

Гибкое управление вытеснением подов с локальным хранилищем в descheduler

В модуле descheduler появилась возможность контролировать вытеснение подов, использующих локальное хранилище (Local Storage). Для этого в кастомный ресурс Descheduler добавили параметр evictLocalStoragePods. Он позволяет включать или отключать вытеснение подов, которые используют локальное хранилище.

По умолчанию поды с локальным хранилищем не вытесняются, чтобы не потерять данные или не нарушить работу приложений. Но с включением параметра evictLocalStoragePods: true в настройках Descheduler возможно автоматическое вытеснение таких подов для перераспределения нагрузки или других целей управления ресурсами в кластере.

Переход с Terraform на OpenTofu в облачных провайдерах

Мы переходим в провайдерах для Yandex Cloud, zVirt и Dynamix с Terraform на OpenTofu в качестве инструмента управления инфраструктурой, так как не можем обновлять Terraform для исправления уязвимостей (CVE) из-за лицензионных ограничений.

Рефакторинг monitoring-ping: переход с Python на Go

Модуль monitoring-ping полностью переписан с Python на Go. Ключевые изменения:

• Вместо утилиты fping используется собственная реализация на базе библиотеки fastping.

• Метрики теперь экспортируются через HTTP-экспортер и PodMonitor (вместо записи в файл и последующего экспорта через node-exporter).

Преимущества:

• distroless-образ;

• упрощение поддержки кода;

• лучшая интеграция с Kubernetes-экосистемой;

• более точные измерения RTT за счёт учёта задержек между ядром и пользовательским пространством.

Сравнение RTT у fping и fastping:

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

Заключение

Версии DKP 1.68–1.70 принесли значительные улучшения в удобство управления, безопасность и отказоустойчивость платформы. Ключевые изменения:

• Упрощение управления инфраструктурой:

  • управление лейблами узлов через файлы (/var/lib/node_labels);

  • гибкое включение существующих пространств имён в проекты через аннотации;

  • переход с Terraform на OpenTofu для облачных провайдеров.

• Безопасность и автоматизация:

  • настройка TLS для лог-систем через Kubernetes Secrets;

  • поддержка современных алгоритмов шифрования (RSA-3072, ECDSA-P256);

  • автоматическая настройка доступа к кластеру после установки.

• Оптимизация работы кластера:

  • управление перезагрузкой узлов через аннотации;

  • автоматическая очистка логов в loki по объёму данных;

  • уточнение логики автообновлений с учётом окон обновлений.

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

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

• основной GitHub-репозиторий;

• русскоязычный Telegram-чат;

• Telegram-канал по Deckhouse для инженеров.

P. S.

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

• Автоматические резервные копии etcd и миграции master-узлов: дайджест обновлений Deckhouse Kubernetes Platform 1.65–1.67

• Как легко настроить аутентификацию для нескольких доменов в Kubernetes: Deckhouse Kubernetes Platform

• S3 в мире Kubernetes: как объектное хранилище сделать частью контейнеров (подход от команды Deckhouse)

• Новости виртуализации Deckhouse: готовность к продакшену, автоматическая перебалансировка ВМ по узлам и другие фичи