Релиз 2.14.1 (2026 Q3)

Доступные версии для перехода

Номер исходной версии Особенности обновления
2.13.0 До обновления: проверьте CRDs shturval-snapshotter1; в закрытом контуре обновите утилиту stm2; убедитесь, что bootstrap-кластера нет5.
При ошибке обновления: для кластеров с провайдером oVirt и включенным shturval-capov-csi см. известные ограничения.
После обновления: замените шаблоны ВМ3; при необходимости восстановите сбор логов4.
2.13.1 До обновления: проверьте CRDs shturval-snapshotter1; в закрытом контуре обновите утилиту stm2; убедитесь, что bootstrap-кластера нет5.
При ошибке обновления: для кластеров с провайдером oVirt и включенным shturval-capov-csi см. известные ограничения.
После обновления: замените шаблоны ВМ3; при необходимости восстановите сбор логов4.
2.14.0 До обновления: убедитесь, что bootstrap-кластера нет5.

1 В составе релиза 2.14.0 компонент shturval-snapshotter обновлен с 8.1.1 до 8.3.0. Для CRD volumegroupsnapshots, volumegroupsnapshotcontents и volumegroupsnapshotclasses из API-группы groupsnapshot.storage.k8s.io версия ресурса изменилась с v1alpha1 на v1beta1. Перед обновлением проверьте, есть ли в кластере кастомные ресурсы типов VolumeGroupSnapshot, VolumeGroupSnapshotContent или VolumeGroupSnapshotClass. Если есть — сохраните манифесты и связанные данные на стороне системы хранения. При необходимости конвертируйте манифесты на groupsnapshot.storage.k8s.io/v1beta1. После успешного обновления примените конвертированные манифесты заново.

2 В закрытом контуре перед загрузкой бандла в зеркало обновите утилиту stm из бандла новой версии. Подробнее — Работа с зеркалом после инсталляции.

3 Для кластеров с шаблонами ВМ подготовьте и замените шаблоны во всех группах узлов, чтобы исключить ошибки при масштабировании — см. Узлы и шаблоны ВМ.

4 После обновления кластера управления может нарушиться сбор логов в клиентских кластерах, версия которых отличается от версии кластера управления. Чтобы восстановить отображение логов на вкладке «Логи» без обновления клиентских кластеров, в каждом таком кластере перезапустите поды Vector Agent в неймспейсе logging. После обновления клиентских кластеров до версии кластера управления сбор логов будет восстановлен — перезапуск подов не требуется.

5 Проверьте, что временный bootstrap-кластер, поднятый при инсталляции платформы, планируемой к обновлению, удален. Иначе после обновления отдельные операции в кластере (например, масштабирование Control Plane) могут выполняться нестабильно и не завершаться. При необходимости удалите bootstrap-кластер по инструкции Деинсталляция временного кластера.

Известные ограничения

  • На платформе Штурвал версии 2.14.1 заблокирована возможность создания клиентских кластеров версии 2.14.0.

  • Для создания клиентского кластера с версией ниже 2.14.1 и провайдером Shturval v2 необходимо изменить версию в ShturvalProvider. Инструкция — Как создать клиентский кластер с провайдером Shturval v2 версии ниже 2.14.1.

  • Обновление кластера с провайдером oVirt и включенным «Модулем oVirt CSI» (shturval-capov-csi) может остановиться на этапе SystemServicesUpdated с причиной SSCUpdateWait. Обновление сервиса shturval-capov-csi завершается ошибкой: поле spec.selector у DaemonSet shturval-capov-csi-node и Deployment shturval-capov-csi-ovirtplugin неизменяемое (field is immutable).

    Чтобы продолжить обновление, остановите «Модуль управления сервисами» (shturval-services), удалите нагрузки CSI и снова включите shturval-services:

    1. В кластере уменьшите для Deployment shturval-services-controller-manager в неймспейсе shturval-services-system реплики до 0.

    2. Удалите Deployment и DaemonSet модуля CSI:

    kubectl --ignore-not-found=true -n shturval-capov-csi delete deployment/shturval-capov-csi-csi-ovirtplugin daemonset/shturval-capov-csi-node
    1. Смасштабируйте Deployment shturval-services-controller-manager до 1 реплики.

    Контроллер заново создаст нагрузки CSI, после этого этап обновления системных сервисов сможет завершиться.

Устранены ошибки

Обновление

  • Циклическая перезагрузка Control Plane узлов при обновлении кластера (первично развернутого на версии 2.10.0 или более ранней версии), с самоподписанным или корпоративным сертификатом.
  • Отсутствие валидации идентификатора клиента в конфигурации Keycloak при обновлении кластера управления с подключенным Keycloak.
  • Зависание обновления кластера управления с одним Control Plane узлом на обновлении сервиса shturval-auth.
  • Ошибка применения конфигурации при обновлении кластера с ОС Ubuntu 24.04 (Noble).
  • Ошибка применения конфигурации при обновлении кластера с ОС ALT Server 10.4 (Mendelevium) из-за дрифта установленных пакетов.
  • Ошибка применения параметров ядра при создании шаблонов ВМ на ОС RHEL 9, Rocky Linux 9 и SberLinux.
  • Исправлена обработка старых конфигураций Ingress при обновлении кластера управления: платформа корректно распознает legacy-схему Ingress и применяет совместимый сценарий обновления.
  • Устранена необходимость удалять свободные хосты провайдера Shturval v2 До обновления кластера.

Эксплуатация и провайдеры

  • Ошибка развертывания клиентского кластера с провайдером VMware vCloud Director после этапа поднятия Control Plane узлов.
  • Игнорирование выбранного шаблона ВМ в InfraMachineTemplate при добавлении или редактировании группы Worker-узлов в кластерах с провайдером VMware vSphere.
  • Использование дефолтного StorageClass при включенном CSI в кластерах c провайдером VMware vCloud Director.
  • Ошибка развертывания кластера с провайдером oVirt с флагами.
  • Добавлены предупреждения и предварительные проверки для установки с rootless Podman.
  • Добавлена диагностика ошибок подготовки шаблона ВМ, если генерация конфигурации GRUB не укладывается в таймаут.

Графический интерфейс

  • Уточнен текст сообщения при проверке конфигурации кластера.
  • Исправлено отображение статусов применения доступов для внутрикластерных тенантов.
← Типовые ошибки доступа
Релиз 2.14.0 (2026 Q2) →