Изменено 2026-07-01 в 19:41

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

Если коротко — в 2.13.0 платформа стала удобнее для автоматизации:

shtil теперь работает через YAML и флаги командной строки,
GPU-узлы настраиваются автоматически,
Профили конфигурации помогают создавать кластеры по шаблонам.

Дополнительно добавлены сводные отчёты по безопасности и доработан интерфейс для комфортной повседневной работы.

Полный перечень Release Notes 2.13 здесь.

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

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

Shtil теперь можно использовать через YAML-манифесты и флаги командной строки — для CI/CD и GitOps это настоящий прорыв.
Nvidia GPU интегрируются с автоматической настройкой узлов — никакой ручной настройки с драйверами и конфигурацией.
Containerd 2.x принёс cgroup v2, шифрование образов и ускорение загрузки — обновление прозрачное, ручная настройка не требуется.
Профили конфигурации кластеров позволяют создавать шаблоны настроек клиентских кластеров (например, для ML-нагрузок) и переиспользовать их.
Сводные отчёты по Kyverno и Trivy дают полную картину безопасности по всем кластерам платформы.
В редакции Enterprise ML появились Kubeflow и MLflow — фундамент для будущего релиза с фокусом на ML.

Shtil. Установка платформы своим способом

В 2.12 осуществлен переход на shtil, как основной инструмент установки. В 2.13 возвращена возможность установки без графического интерфейса, как было в stc, с дополнительным бонусом.

YAML-манифесты для установки Теперь можно описать всю конфигурацию кластера управления в YAML-файле и запустить установку из консоли. Это особенно полезно, если вы ставите платформу в нескольких ЦОД.

Пример YAML-манифеста

# Шаблон YAML-манифеста инсталляции платформы с провайдером OVirt
# Конфигурация провайдера

# name: cluster-management-provider  # [НЕОБЯЗАТЕЛЬНО] Имя экземпляра провайдера. По умолчанию - cluster-management-provider

# [ОБЯЗАТЕЛЬНО] Учетные данные для подключения к API Engine oVirt

credentials:
  oVirt:
    url: <https://ovirt-engine.example.com/ovirt-engine/api>  # [ОБЯЗАТЕЛЬНО] URL для подключения к API Engine oVirt
    username: <admin@internal>      # [ОБЯЗАТЕЛЬНО] Имя пользователя для аутентификации в API oVirt
    password: <password>            # [ОБЯЗАТЕЛЬНО] Пароль для аутентификации в API oVirt

# Настройки TLS подключения к API oVirt

# connection:
#   tlsInsecure: true       # [НЕОБЯЗАТЕЛЬНО] Отключить проверку TLS сертификата. По умолчанию - true. Установите false для продакшена с валидными сертификатами
#   tlsCertPath: ''         # [НЕОБЯЗАТЕЛЬНО] Путь к файлу CA сертификата для проверки TLS. Используется при tlsInsecure: false
#                           # Пример: /path/to/ca-bundle.crt

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

providerConfig:
  # subtype: ovirt                  # [НЕОБЯЗАТЕЛЬНО] Подтип провайдера. По умолчанию - ovirt
  datacenter: <Default>             # [ОБЯЗАТЕЛЬНО] Имя датацентра oVirt, где будут создаваться ВМ
  datacenterCluster: <Default>      # [ОБЯЗАТЕЛЬНО] Имя кластера oVirt внутри датацентра
  vnicProfile: <ovirtmgmt/ovirtmgmt> # [ОБЯЗАТЕЛЬНО] Имя VNIC профиля oVirt для сетевых интерфейсов ВМ
  template: <rocky9-template>       # [ОБЯЗАТЕЛЬНО] Имя шаблона ВМ в выбранном датацентре (базовый образ для узлов кластера)
  # csiStorage: ''                  # [НЕОБЯЗАТЕЛЬНО] Имя домена хранения для динамических постоянных томов через CSI драйвер. Оставьте пустым для отключения CSI
  # vmType: server                  # [НЕОБЯЗАТЕЛЬНО] Тип ВМ для создаваемых виртуальных машин. По умолчанию - server. Не переопределяйте без специальных требований
  # templateNetInterface: eth0      # [НЕОБЯЗАТЕЛЬНО] Имя сетевого интерфейса в шаблоне. По умолчанию - eth0. Не переопределяйте, если шаблон не использует другой интерфейс

---

# Конфигурация кластера управления

cluster:
  apiEndpoint: <192.168.1.100:6443> # [ОБЯЗАТЕЛЬНО] Адрес API-сервера кластера (IP или FQDN с портом, например, 192.168.1.100:6443)
  # clusterName: cluster-management # [НЕОБЯЗАТЕЛЬНО] Имя создаваемого кластера управления. По умолчанию - cluster-management
  # disabledServices: []            # [НЕОБЯЗАТЕЛЬНО] Список выключенных сервисов репозитория shturval
  # enabledServices: []             # [НЕОБЯЗАТЕЛЬНО] Список включенных сервисов репозитория shturval
  # externalKubeAPILB: false        # [НЕОБЯЗАТЕЛЬНО] Использовать внешний балансировщик для API-сервера. По умолчанию - false
  # externalingresslb: false        # [НЕОБЯЗАТЕЛЬНО] Использовать внешний балансировщик для Ingress. По умолчанию - false
  # ingress: ''                     # [ОБЯЗАТЕЛЬНО, если externalingresslb: true] Wildcard DNS-запись для ingress (например, apps.corporate.domain). Переопределите externalingresslb на true для использования этого поля
  # controlPlaneNodesCount: 1       # [НЕОБЯЗАТЕЛЬНО] Количество Control Plane узлов. Должно быть не менее 1. По умолчанию - 1
  ingressvip: <192.168.1.101>       # [ОБЯЗАТЕЛЬНО, если externalingresslb: false] VIP-адрес для Ingress контроллера
  # podSubnet: 172.16.0.0/16        # [НЕОБЯЗАТЕЛЬНО] CIDR подсети подов. По умолчанию - 172.16.0.0/16
  # secure: false                   # [НЕОБЯЗАТЕЛЬНО] Включить расширенные параметры безопасности. По умолчанию - false
  # serviceSubnet: 10.96.0.0/12     # [НЕОБЯЗАТЕЛЬНО] CIDR подсети сервисов. По умолчанию - 10.96.0.0/12
  # shturvalVersion: 2.12.0         # [НЕОБЯЗАТЕЛЬНО] Версия платформы. Должна соответствовать версии утилиты shtil

# Конфигурации узлов, специфичные для провайдера
# По умолчанию shtil заполняет все автоматически, позволяя конфигурировать дополнительные группы worker узлов

# provider:
#   name: cluster-management-provider # [НЕОБЯЗАТЕЛЬНО] Должно совпадать с именем экземпляра провайдера. По умолчанию - cluster-management-provider

  # Конфигурация Control Plane узлов
  
#   controlPlaneNodeConfig:
#     capovNodeConfig:
#       cpu:
#         cores: 4                    # [НЕОБЯЗАТЕЛЬНО] Количество ядер CPU на Control Plane узел. По умолчанию - 4
#         sockets: 1                  # [НЕОБЯЗАТЕЛЬНО] Количество CPU сокетов на Control Plane узел. По умолчанию - 1
#         threads: 1                  # [НЕОБЯЗАТЕЛЬНО] Количество потоков CPU на сокет. По умолчанию - 1
#       memory:
#         sizeMB: 16000               # [НЕОБЯЗАТЕЛЬНО] Размер памяти в МБ на Control Plane узел. По умолчанию - 16000
#         guaranteedMB: 16000         # [НЕОБЯЗАТЕЛЬНО] Гарантированная память в МБ. Должна совпадать с sizeMB. По умолчанию - 16000
#       osDiskSizeGB: 100             # [НЕОБЯЗАТЕЛЬНО] Размер диска ОС в ГБ на Control Plane узел. По умолчанию - 100

  # Конфигурация Worker узлов

#   workerNodeConfigs:

    # Создание дефолтной (default) группы Worker узлов

#     - nodeConfig:
#         groupName: default                            # [ОБЯЗАТЕЛЬНО] Наименование дефолтной группы Worker-узлов
#         roles:
#           - name: node-role.kubernetes.io/workers     # [НЕОБЯЗАТЕЛЬНО] Роль Worker-узлов
#       workersCount: 3                                 # [НЕОБЯЗАТЕЛЬНО] Количество узлов в дефолтной Worker группе. По умолчанию - 3
#       capovNodeConfig:
#         cpu:
#           cores: 8                  # [НЕОБЯЗАТЕЛЬНО] Количество ядер CPU на worker узел. По умолчанию - 8
#           sockets: 1                # [НЕОБЯЗАТЕЛЬНО] Количество CPU сокетов на worker узел. По умолчанию - 1
#           threads: 1                # [НЕОБЯЗАТЕЛЬНО] Количество потоков CPU на сокет. По умолчанию - 1
#         memory:
#           sizeMB: 32000             # [НЕОБЯЗАТЕЛЬНО] Размер памяти в МБ на worker узел. По умолчанию - 32000
#           guaranteedMB: 32000       # [НЕОБЯЗАТЕЛЬНО] Гарантированная память в МБ. Должна совпадать с sizeMB. По умолчанию - 32000
#         osDiskSizeGB: 300           # [НЕОБЯЗАТЕЛЬНО] Размер диска ОС в ГБ на worker узел. По умолчанию - 300

    # Создание инфровой (infra) группы Worker узлов

#     - nodeConfig:
#         groupName: infra                              # [ОБЯЗАТЕЛЬНО] Наименование инфровой группы Worker-узлов
#         roles:
#           - name: node-role.kubernetes.io/infra       # [НЕОБЯЗАТЕЛЬНО] Роль инфровых Worker-узлов
#       workersCount: 0                                 # [НЕОБЯЗАТЕЛЬНО] Количество узлов в infra Worker группе. Установите 0 для отключения
#       capovNodeConfig:
#         cpu:
#           cores: 8                  # [НЕОБЯЗАТЕЛЬНО] Количество ядер CPU на infra узел. По умолчанию - 8
#           sockets: 1                # [НЕОБЯЗАТЕЛЬНО] Количество CPU сокетов на infra узел. По умолчанию - 1
#           threads: 1                # [НЕОБЯЗАТЕЛЬНО] Количество потоков CPU на сокет. По умолчанию - 1
#         memory:
#           sizeMB: 32000             # [НЕОБЯЗАТЕЛЬНО] Размер памяти в МБ на infra узел. По умолчанию - 32000
#           guaranteedMB: 32000       # [НЕОБЯЗАТЕЛЬНО] Гарантированная память в МБ. Должна совпадать с sizeMB. По умолчанию - 32000
#         osDiskSizeGB: 300           # [НЕОБЯЗАТЕЛЬНО] Размер диска ОС в ГБ на infra узел. По умолчанию - 300

Примеры YAML-манифестов здесь.

Флаги командной строки

Для тех, кто предпочитает скрипты — можно передать все параметры через флаги.

shtil install ovirt \
    --api-endpoint=10.11.12.13 \
    --ingress-default-fqdn="*.some.address.com" \
    --use-external-ingress-lb=true \
    --url-provider="https://ovirt.example.com/ovirt-engine/api" \
    --user-provider="user@internal" \
    --password-provider="mypas\$\$word" \
    --datacenter-provider=Datacenter1 \
    --datacenter-cluster-provider=some_dc_cluster_name \
    --vnic-profile-provider=ovirtmgmt \
    --template=LinuxVM_001 \
    --bootstrap-license=/path/to/license.yaml

Установка через shtil здесь.

Containerd 2.x и современные возможности контейнеров

В 2.13 выполнен переход на Containerd 2.x в качестве среды выполнения контейнеров. Обновление прозрачное — никаких дополнительных действий не требуется, всё происходит автоматически.

Преимущества подхода:

cgroup v2 — более точный контроль ресурсов и лучшая изоляция контейнеров.
Шифрование образов — дополнительный уровень безопасности для чувствительных workloads.
Ускоренная загрузка образов (streaming) — контейнеры стартуют быстрее, не дожидаясь полной загрузки образа.
Монтирование образов контейнеров как файловых систем — отлично подходит для монтирования обученных моделей и больших датасетов.

Вы сразу заметите эти улучшения, когда работаете с большими образами (ML-модели, датасеты) или строгими требованиями к изоляции.

Автоматическая настройка GPU

В конфигурации узлов (NCI) расширены возможности настройки container runtime. Теперь все необходимые параметры для настройки nvidia runtime можно задать декларативно, без использования императивных команд.

NCI — иллюстрация

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: nvidia-runtime
spec:
  nodeconfigselector:
    node-role.kubernetes.io/gpu: ""
  priority: 100
  runtimecfg:
    configSections:
      - exist: true
        params:
          - exist: true
            key: default_runtime_name
            value: nvidia
        path: plugins."io.containerd.grpc.v1.cri".containerd
      - exist: true
        params:
          - exist: true
            key: base_runtime_spec
            value: ""
          - exist: true
            key: cni_conf_dir
            value: ""
          - exist: true
            key: cni_max_conf_num
            value: 0
          - exist: true
            key: container_annotations
            value: []
          - exist: true
            key: pod_annotations
            value: []
          - exist: true
            key: privileged_without_host_devices
            value: false
          - exist: true
            key: runtime_engine
            value: ""
          - exist: true
            key: runtime_path
            value: ""
          - exist: true
            key: runtime_root
            value: ""
          - exist: true
            key: runtime_type
            value: io.containerd.runc.v2
        path: plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia
      - exist: true
        params:
          - exist: true
            key: BinaryName
            value: /usr/bin/nvidia-container-runtime
          - exist: true
            key: CriuImagePath
            value: ""
          - exist: true
            key: CriuPath
            value: ""
          - exist: true
            key: CriuWorkPath
            value: ""
          - exist: true
            key: IoGid
            value: 0
          - exist: true
            key: IoUid
            value: 0
          - exist: true
            key: NoNewKeyring
            value: false
          - exist: true
            key: NoPivotRoot
            value: false
          - exist: true
            key: Root
            value: ""
          - exist: true
            key: ShimCgroup
            value: ""
          - exist: true
            key: SystemdCgroup
            value: true
        path: plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia.options

Профили конфигурации. Шаблоны для типовых сценариев

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

Например, профиль “GPU workload” может включать:

Конфигурацию узлов с GPU;
Системные сервисы для работы с GPU (NVIDIA Device Plugin);
Настройки интеграции с Vault;
Настройки интеграции с Argo CD.

Создайте профиль один раз и используйте его для всех похожих кластеров. Как итог: сокращение рутины и “копипастов”, избежание ошибок, сокращение времени от идеи до работающего кластера.

Логи. Структурировано и с продвинутым поиском

Графический интерфейс логов кластера оптимизирован:

Логи теперь сгруппированы по стримам — легче ориентироваться в потоке сообщений.
Появился поиск по параметрам логов с перечнем доступных полей для выбора — можно искать по namespace, pod, container, уровню важности и другим атрибутам.

Подробнее о работе с логами кластера здесь.

Скриншот логов, сгруппированных по стримам

NCI. Вся конфигурация в модальных окнах

Интерфейс конфигурации узлов (Node Configuration Interface, NCI) переработан:

Параметры Kube API Server
Теперь можно настраивать параметры API-сервера прямо в графическом интерфейсе NCI. Не нужно править YAML или использовать kubectl. Feature gates, Admission Controllers, параметры аудита доступны через UI.
Модальные окна для всех разделов
Конфигурация всех разделов NCI вынесена в модальные окна, что упорядочило интерфейс. Стало легче сосредоточиться на конкретной секции настроек.
Видимость состояний NodeConfig
Добавлено отображение состояний конфигураций узлов (NodeConfigs) кластера. Теперь видно, применилась ли конфигурация на узлах, в каком статусе находится каждый NodeConfig.

Подробнее на странице Конфигурация узлов (NCI) и в разделе Kube API Server.

Скриншот конфигурации NCI в модальном окне

Скриншот NodeConfig в кластере

Сервисы и безопасность. Больше контроля и прозрачности

Трёхпозиционный переключатель для сервисов
Управление режимами работы системных сервисов в кластере оптимизировано через трёхпозиционный переключатель: Absent/Manual/Auto. Это работает на страницах установленных сервисов и в настройках конфигурации сервисов для установки.

Скриншот трёхпозиционного переключателя управления системными сервисами

Сводные отчёты по безопасности
В интерфейс платформы добавлены сводные отчёты по всем кластерам:

Kyverno — политики безопасности и соответствия (Compliance) в едином представлении.
Trivy — результаты сканирования образов контейнеров на уязвимости.

Скриншоты сводных отчётов по Kyverno и Trivy по всем кластерам

Теперь доступно полное представление по всей платформе, а не только по отдельным кластерам.

Сохранение пользовательских настроек
Платформа запоминает ваши настройки фильтрации, пагинации и поисковые запросы при переходе между страницами. Сокращение рутинных действий, настройте один раз и работайте комфортно.

Дополнительно по конфигурации кластеров

Для кластеров с провайдерами без Cloud Controller Manager добавлена возможность указать DNS-запись Ingress при использовании внутреннего балансировщика. Это упрощает настройку сетевого доступа в классических инфраструктурах (vSphere, Shturval v2, oVirt).

Также в клиентских кластерах дефолтная конфигурация ресурсов приведена в соответствие с требованиями к клиентскому кластеру. Теперь меньше шансов, что кластер не раскатится из-за нехватки памяти или CPU.

В редакции Enterprise ML

В редакцию Enterprise ML интегрированы две ключевые платформы для машинного обучения:

Kubeflow — организация процессов ML в Kubernetes (пайплайны, эксперименты, сервинг моделей).
MLflow — управление жизненным циклом ML-моделей (tracking, registry, deployment).

Интегрированные платформы создают фундамент для следующего релиза, где ML станет центральной темой. Однако, уже сейчас вы можете начать строить ML-инфраструктуру на платформе.

Компоненты платформы. Kubernetes, Cilium, containerd

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

Kubernetes 1.34.3
Cilium 1.19
Cluster API 1.11.0
Container Runtime / Containerd 2.x

Подробнее о том, как это работает в платформе:

Исправлено

Перечень устраненных ошибок в 2.13.0 приведен на странице Релиз 2.13.0 (2026 Q1)

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

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

Shtil. Установка платформы своим способом #

Containerd 2.x и современные возможности контейнеров #

Автоматическая настройка GPU #

Профили конфигурации. Шаблоны для типовых сценариев #

Логи. Структурировано и с продвинутым поиском #

NCI. Вся конфигурация в модальных окнах #

Сервисы и безопасность. Больше контроля и прозрачности #

Дополнительно по конфигурации кластеров #

В редакции Enterprise ML #

Компоненты платформы. Kubernetes, Cilium, containerd #

Исправлено #

Что дальше #