Release 2.15.0 (2026 Q3)

• Kubernetes version: 1.36.5
• The release is supported. See release policy.

Available versions for transition #

¹ If the cluster has nodes running Astra Linux SE 1.8.1, update the OS on those nodes to 1.8.2 before you start the cluster update. Astra Linux SE 1.8.1 and ROSA Chrome 6.6 are incompatible with platform 2.15.0: Cilium 1.20.4 requires BTF support in the kernel, and the kernels of these operating systems do not provide it. See Known limitations.

² With the RollingUpdate strategy, before you start the update of client clusters, add a VM template of the target Kubernetes version to the provider instance: without it the update stops. See VM nodes and templates.

³ Before you update the management cluster to 2.15, check the Ingress resources of the shturval-backend SSC. If the Ingress resources in status.appliedCustomValues are current (with the prefix shturval and the cluster name, for example shturval.<cluster-name>.ip-….shturval.link), remove the annotation shturval.tech/legacy-ingress from the cluster’s ClusterConfig.

⁴ When the management cluster is updated, incoming HTTP traffic is accepted and routed through Gateway API. By default, during the update to 2.15.0, shturval-ceph-cephfs and shturval-ceph-rbd are migrated to shturval-ceph-csi if they were installed in the cluster.

⁵ For clusters that use VM templates, after the update prepare and replace the templates in all node groups so that scaling does not fail. See VM nodes and templates.

Known limitations #

• Astra Linux SE 1.8.1 and ROSA Chrome 6.6 are incompatible with platform 2.15.0. In this release, the networking module (shturval-networking) is updated to Cilium 1.20.4, which requires BTF support in the kernel. The kernels of these operating systems do not provide it. If cluster nodes run Astra Linux SE 1.8.1, update the OS to 1.8.2 before you start the cluster update. For clusters that use VM templates, replace the OS as described in Replace the operating system on nodes.

• Creating client clusters of version 2.14.0 is blocked on platform version 2.15.0.

• For clusters with RawFile local volumes, an update to 2.15.0 with the RollingUpdate strategy does not finish. Change the strategy to InPlace, or on a provider with CSI use external storage instead of RawFile.

• The platform cannot be installed on OSnova (Onyx). Client clusters on this operating system cannot use persistent volumes (PV).

What’s new #

Infrastructure #

• Cluster update management has moved to Cluster Manager. The separate update module shturval-update is no longer used.
• Cluster update strategy selection is now available. Client clusters below version 2.15 can choose a strategy when the platform is already updated to 2.15.
• Ceph CSI has moved to the operator. shturval-ceph-cephfs and shturval-ceph-rbd are no longer shipped separately. They are replaced by the single operator shturval-ceph-csi.
• The management cluster serves incoming traffic with Gateway API. Client clusters can still choose NGINX Ingress Controller or Gateway API.
• The platform can be installed with the Yandex Cloud provider in experimental mode. Cloud Controller Manager runs for nodes, and the shturval-capy-csi CSI driver is available for disks.
• Disk cloning for clusters with the oVirt provider is configured separately for Control Plane and Worker node groups.
• Connection credentials for oVirt and Basis Dynamix are stored in a Secret.
• The management cluster utility has been improved:
  • after a successful management cluster installation from the shtil console, deletion of the bootstrap cluster starts automatically;
  • the shtil install-cli log shows ClusterConfig conditions and ClusterInfo installation stages;
  • a separate flag prints the controller log stream;
  • before an installation with rootless Podman, shtil checks typical failure causes: missing uidmap, a D-Bus session, the cpu cgroup controller, and a user namespace.
• You can control PV cleanup when a cluster with CSI is deleted (oVirt, vSphere, OpenStack, vCloud Director, Yandex Cloud).
• The node problem detector service (shturval-npd) has been added.
• OIDC for kube-apiserver is now configured with an AuthenticationConfiguration file.
• Taints in MachineDeployment are enabled, so you can manage Taints on all nodes of a Worker group. Taints can now be set on Worker groups, not only on individual nodes.
• Host checks in the Shturval v2 provider have been improved: the host is ready only after every required check succeeds.

GUI #

Vertical autoscaling (VPA)

HPA replica change policies

Pod restart and revision rollback

TLS certificate decoding

Bulk deletion

Backup contents

Backup restore

Private registry in NCI

Access by users and groups

ServiceAccount permissions

Applied ShturvalServicePatch

Cluster visual marker

Import of several manifests

Shturval v2 host credentials

Gateway API

CSI integration and PV cleanup

Yandex Cloud disk CSI

oVirt disk cloning

Node problem detection

Worker group Taints

Shturval v2 host checks

• The system services step of client cluster creation adds a choice of how to manage HTTP traffic.

• The namespace dashboard shows Gateway API routes: HTTPRoute and GRPCRoute.

• Workload screens have been extended:

  • vertical autoscaling (VPA) can be managed for Deployments and StatefulSets. See VPA for workloads.
  • the HPA screen can set scale-up and scale-down rules: how much the replica count may change, over what interval, and how long to wait before the scale changes.
  • the pod template can set Node Affinity, Pod Affinity, and Pod Anti-Affinity.
  • Deployments, StatefulSets, and DaemonSets can restart pods with rollout restart and return to a previous revision with rollout undo.

• Certificate and key values in a Secret of type kubernetes.io/tls can be decoded in the GUI.

• Object lists in the platform, cluster, and namespace support bulk deletion.

• Velero backup screens have been improved:

  • a one-time backup or a schedule can list resources to include and resources to exclude, and can select all resources;
  • the restore screen can select which resources to restore.

• The Container Runtime section of an NCI can connect a private registry.

• In the access management screens, permissions are now shown on tabs by users and groups instead of by the scopes where they apply.

• Role, ClusterRole, RoleBinding, and ClusterRoleBinding assignment is available in the ServiceAccount screen.

• The installed cluster service page shows the status of the applied ShturvalServicePatch (SSP) and supports uploading an SSP by importing a manifest.

• The GUI now has a screen for the cluster visual marker. You no longer need to set hex codes and cluster annotations manually to highlight the cluster interface.

• The cluster deployment and platform installation dashboard is interactive: stage progress updates as the deployment proceeds, and the screen shows what needs attention. See deployment status.

• The manifest import screen can upload several YAML files at once.

• The Shturval v2 provider configuration can set the user password for sudo commands and choose the version used to prepare hosts for the cluster.

Security #

Vault certificates

Before VEX is connected

After VEX is connected

• Clusters can be installed with Vault certificates and a token connection to the Vault server.
• Vulnerability Exploitability eXchange (VEX) delivery to the platform is available, along with control over the VEX connection, so marked vulnerabilities can be excluded from image analysis reports.

Fixed #

• shtil errors while installing the management cluster:
  • rootless Podman on ALT Server 10, Astra Linux 1.7.5, and Debian 11;
  • the kube-apiserver check with rootless Podman on Astra Linux 1.8;
  • cluster objects left behind after a failed installation;
  • deletion failing when the connection to the provider is lost.
• The Ingress IP remaining on hosts after a Shturval v2 cluster is deleted.
• The previous service management mode remaining after an SSP with a changed mode is applied.
• Incorrect egress gateway behavior. The VIP now comes up on the node with the assigned label. When the VIP moves, the label is removed from the previous node and cluster traffic is not disrupted. A policy for several namespaces is applied correctly, and the number of egress gateways is not limited.
• Changes in a service ShturvalServiceConfig specification being ignored because the shturval-services controller hung during long-running operation.
• Custom resources with the same kind in different API groups not displaying correctly.
• The problematic NCI counter. Configurations that are not assigned to any cluster node are no longer counted as problematic.
• Kubernetes certificate reissue.
• A cluster-scoped resource not being restored together with a namespace-scoped resource from the same backup.
• The velero namespace remaining in a backup when backup schedule data is updated.
• The configured Keycloak setup disappearing from the GUI if, after it was configured in the GUI, the configuration is changed by an SSP on shturval-auth.