2.14.0 — Gateway API, гибридные кластеры и удобное администрирование

Если коротко — в 2.14.0 платформа стала заметно удобнее для администраторов и команд, которые управляют сетевой маршрутизацией, подключением внешних провайдеров, ML-нагрузками и доступом пользователей:

  • появилось управление объектами Gateway API в GUI;
  • для ML-сценариев можно собирать гибридные кластеры: основные узлы на одном провайдере, GPU-узлы — через Shturval v2;
  • профили клиентских кластеров получили отдельный интерфейс управления;
  • настройка внешнего OIDC-провайдера стала доступна в GUI;
  • стало доступно управление назначением прав KubeFlow и переход в интерфейс KubeFlow из неймспейсов;
  • shtil стал удобнее для удалённой установки, CLI и YAML-сценариев;
  • новая модель и структура пользовательской документации.

Полный перечень release notes 2.14.0 приведен здесь.

Главное в релизе (TL;DR)

Основной фокус релиза 2.14.0 — расширить управляемость платформы и снизить количество ручных действий в типовых сценариях администратора:

Gateway API. Маршрутизация в GUI

В 2.14.0 добавлен сервис управления объектами Gateway API и интерфейс в GUI для работы с GatewayClass, Gateway, HTTPRoute и GRPCRoute.

Это шаг к модели маршрутизации: инфраструктурные настройки входного трафика можно отделить от маршрутов приложений, а сами маршруты описывать через стандартные ресурсы Gateway API.

Скриншот интерфейса Gateway API

Интерфейс управления объектами Gateway API

Подробнее:

Гибридные кластеры

В релиз вошло управление гибридными кластерами для сценариев с ML-нагрузками. Теперь кластер может сочетать обычные узлы на провайдере виртуализации и GPU-узлы на провайдере Shturval v2.

Типичный сценарий: Control Plane и базовые Worker-группы работают на VMware vSphere, oVirt, OpenStack или другом провайдере, а дополнительная Worker-группа для ML-задач создается на физических хостах Shturval v2 с GPU.

Скриншоты гибридных кластеров

Управление гибридными кластерами

Добавление группы Worker-узлов с провайдером Shturval v2

Подробнее:

Профили кластеров. Повторяемые конфигурации

В 2.14.0 продолжили развивать профили конфигурации клиентских кластеров. В интерфейсе платформы появился отдельный сценарий управления профилями: можно создавать профиль, задавать параметры спецификации и использовать его при создании клиентских кластеров.

Профили полезны, когда нужно переиспользовать типовые настройки: например, наборы системных сервисов, параметры логирования и мониторинга, NTP, часовой пояс или кастомные манифесты для клиентского кластера.

Скриншот управления профилями кластеров

Управление профилями конфигурации клиентских кластеров

Подробнее:

Интеграция с Vault через профиль

Один из практичных сценариев — заранее подготовить интеграцию клиентских кластеров с HashiCorp Vault через ClusterProfile: можно добавить манифесты для установки vault-secrets-operator, его CRD, создать VaultConnection. При создании клиентского кластера выбрать профиль и загруженные манифесты создадутся автоматически, а в кластере появится базовая инфраструктура для синхронизации секретов из Vault.

Финальный шаг выполняется после развёртывания кластера: администратор настраивает метод аутентификации Kubernetes на стороне Vault, создаёт VaultAuth в клиентском кластере. В итоге профиль снимает повторяющуюся подготовку с каждого нового кластера, но оставляет контроль над доступами и политиками Vault у администратора.

Подробнее: Настройка интеграции с HashiCorp Vault в профиле кластера и в развёрнутом кластере.

Аутентификация, доступы и Kubeflow

В релизе появился интерфейс конфигурации OIDC-провайдера. Администратор может настраивать подключение внешнего провайдера, выполнять проверку конфигурации и задавать маппинг полей access_token в GUI.

Скриншот конфигурации OIDC-провайдера

Конфигурация OIDC-провайдеров

Для LDAP-сценариев исправлены ошибки, которые мешали повседневной настройке: сохранение параметров после успешной проверки, анализ каталога без найденных групп.

Подробнее:

Доступы и Kubeflow

В управлении доступом добавлены:

  • возможность отозвать все назначенные права пользователя или группы из интерфейса платформы;
  • управление назначением прав доступа к Kubeflow;
  • переход из неймспейсов в графический интерфейс Kubeflow.

Подробнее:

Создание кластеров, NCI и провайдеры

В интерфейсах создания кластеров стало больше проверок и полезных подсказок. На шаге проверки данных появилась возможность запустить проверку конфигурации в тестовом режиме (Dry run), а для кластеров на Shturval v2, VMware vSphere, oVirt, zVirt, HostVM, РЕД Виртуализация и ROSA Virtualization можно одновременно указать VIP и DNS-запись для Ingress.

Создание клиентского кластера.

Shtil для GUI, CLI и YAML-сценариев

Отдельно доработан shtil — утилита для установки кластера управления. В GUI-сценарии стало проще запускать установщик на удалённой Linux-машине: мастер установки можно открыть в браузере по IP-адресу или hostname этой машины, без ручного проброса портов. Для CLI-сценариев уточнены команды и алиасы, а также добавлена возможность задать путь сохранения итогового kubeconfig постоянного кластера управления.

Для установки кластера управления через YAML-манифест расширена настройка Worker-групп. Теперь в provider.workerNodeConfigs можно описывать не только дефолтные группы, но и дополнительные группы узлов. Это удобно для автоматизированных установок, где состав кластера управления нужно зафиксировать заранее — например, сразу разделить системные, инфраструктурные и специализированные Worker-узлы без последующей ручной донастройки в интерфейсе.

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

Подробнее:

Скриншоты проверки данных и настройки Ingress

Кнопка проверки данных

Указание VIP и DNS-записи для Ingress

NCI и Container Runtime

В NCI добавлен интерфейс конфигурации плагинов Container Runtime. Это важно для сценариев, где нужно управлять настройками runtime декларативно, в том числе для GPU-узлов.

Скриншот конфигурации Container Runtime в NCI

Конфигурация плагинов Container Runtime в NCI

Подробнее:

Провайдеры

Управление провайдерами тоже стало удобнее:

  • сервисы провайдеров можно включать и отключать локально - в интерфейсе управления экземплярами провайдеров без перехода в кластер управления;
  • для oVirt доступно выбрать Storage Domain, где будут создаваться диски виртуальных машин независимо от Storage шаблона ВМ, добавленного в экземпляр провайдера;
  • для vCloud Director добавлена возможность установки CSI при инсталляции клиентского кластера;
  • в stc template появились флаги для регулирования сетевых особенностей ВМ: --fix-vmware-network помогает избежать проблем overlay-сети Kubernetes на VMware с vmxnet3, а --dhcp-no-domain-name не даёт DHCP подставлять корпоративный DNS-суффикс, если узлы кластера должны резолвиться без него;
  • для хостов Shturval v2 можно задать пароль SSH-пользователя в Secret провайдера, чтобы команды sudo выполнялись с паролем. Это помогает использовать хосты, где политика безопасности не разрешает sudo без пароля.

Подробнее:

Эксплуатационные настройки. SSC, ClusterConfig и VLSingle

Стало проще описывать зависимости между сервисами платформы на уровне ShturvalServiceConfig. Для SSC используется класс сервиса - spec.serviceclass. Другие сервисы могут ссылаться не только на конкретный SSC через dependency, но и на класс через dependencyclass.

Сервис управления сервисами (shturval-services).

ClusterConfig

Если есть доступ к ClusterConfig, доменное имя или Ingress-сертификат кластера можно изменить через него. После этого cluster-manager сам обновит связанные ресурсы. Такой подход быстрее, проще и снижает риск возникновения ошибок по сравнению с ручной правкой нескольких объектов.

Подробнее:

VLSingle

Для логов VictoriaLogs теперь создается ресурс экземпляра хранения логов - VLSingle в неймспейсе кластеров кластера управления, а не VLogs: через него задаются срок хранения, лимит диска и размер хранилища логов. VictoriaLogs остаётся названием подсистемы логирования, а VMSingle используется в другом сценарии — как локальное хранилище метрик для мониторинга.

Как настроить ротацию логов.

GUI: фильтры и индикация

В повседневной работе с кластерами стало больше контекста и информации прямо в списках и на дашбордах:

  • отображаются счётчики в формате «здоровые объекты / всего объектов» для узлов кластера, Pods, конфигураций узлов (NCI) и системных сервисов;
  • сведения о версии кластера и Kubernetes теперь видны не только на дашборде, но и в интерфейсе настройки обновления;
  • состояние объектов кластера подсвечивается на вкладках и рядом со счётчиками, поэтому кластеры, требующие внимания, легче заметить с первого взгляда.

Дашборд кластера

Фильтры, индикация окружения и ошибки

Поиск, фильтры и сортировка в таблицах переехали в отдельный скрываемый блок. А в пользовательских настройках можно выбрать, показывать ли блок Фильтры по умолчанию скрытым или раскрытым.

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

Обзор графического интерфейса.

Скриншоты интерфейсных улучшений

Индикация состояния объектов кластера

Новая фильтрация

Визуальная индикация окружения кластера

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

Компоненты платформы. Kubernetes и сервисы shturval

В этом релизе обновлены ключевые компоненты:

Полный перечень чартов и версий см. на странице Сервисы репозитория Shturval.

До обновления проверьте кастомные ресурсы volumegroupsnapshots, volumegroupsnapshotcontents и volumegroupsnapshotclasses. Подробности описаны в release notes 2.14.0.

Пользовательская документация

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

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

Исправления и стабильность

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

Полный перечень исправлений приведен на странице Релиз 2.14.0 (2026 Q2).

2.13.0 — Автоматизация установки и прозрачность работы →