Releases & Support

Version string

v1.36.4-stratum.3
 │       │
 │       └── the Stratum build number for this Kubernetes patch
 └────────── the Kubernetes version this release is built from

The Kubernetes version leads because it is the question asked most often and it determines the support window. The suffix increments when Stratum ships a change against an unchanged Kubernetes build.

stratum version

What a release contains

Every release is the same single artifact, for amd64 and arm64, both built natively. Each carries its own component binaries and images, so a release is self-describing: the artifact is the version.

Published alongside it: an SBOM, signatures, and provenance for the build.

Support model

Stratum follows upstream Kubernetes rather than setting its own cadence. Upstream publishes a minor roughly every four months and maintains each for about fourteen, so roughly three minors are supported at any time.

A Stratum release for a given Kubernetes minor lands behind the upstream date, deliberately: each build is validated — conformance, HA failover, upgrade and restore — before it is published. Shipping late with evidence is preferred to shipping on the upstream date without it.

Within a supported minor, patch releases pick up upstream Kubernetes and etcd patches including CVE fixes, and correct defects in Stratum's own code.

Upgrading between releases

See Upgrades & Rollback. The short version: one minor at a time, no downgrades, no cross-major changes, and the tooling refuses rather than letting you find out afterwards.

Changes awaiting release

The dashboard's node shell is on by default. A cluster whose config leaves out spec.dashboard.enableNodeShell offers a root shell on its nodes to any dashboard user whose RBAC can create privileged pods, the cluster-admin sign-in token included, from the first restart on this release. Set enableNodeShell: false on every control plane before upgrading to keep it withheld. A cis: true cluster keeps it off unless asked for, because its Pod Security admission refuses the shell's pod. See The dashboard.

Cluster certificate commands now stop gracefully on the first SIGHUP, as they do on SIGINT and SIGTERM. stratum certs rotate-ca --cluster and stratum certs migrate-etcd-ca --cluster stop at the next step boundary and allow cleanup to run; previously SIGHUP terminated them immediately. A second signal forces termination. Follow the command's recovery guidance before resuming. See the certificate lifecycle upgrade notes.

The kubelets have their own client CA. On a cluster created by this release, a certificate the cluster root signs, admin's included, no longer reaches a kubelet's API, and the API servers reach the kubelets with an RBAC identity rather than system:masters. A cluster created earlier keeps the cluster root as its kubelets' client trust until stratum certs migrate-kubelet-client-ca --cluster --yes moves it; until then stratum hardening check fails its new kubelet.1 and live.kubelet controls. See the certificate lifecycle upgrade notes.

kube-vip no longer runs as system:masters. Its certificate names the user system:kube-vip with no group, and the Role kube-system/stratum:kube-vip grants it only its election Lease. Its pod no longer mounts the directory holding the admin kubeconfig. See kube-vip's identity.

kube-scheduler's pod mounts only its own kubeconfig, which moves to /var/lib/stratum/kubeconfig/scheduler/. It no longer mounts the PKI directory or the directory holding the admin kubeconfigs. An upgrade writes the new file before restarting kube-scheduler. See kube-scheduler's files.

NodePorts answer on every address of the interfaces Cilium attaches to, as kube-proxy's do, including a kube-vip VIP. Before, Cilium served them on each node's primary address only, so a NodePort reached through the VIP answered only from the controller holding it. Upgrading restarts the Cilium agents once, one node at a time.

Every cluster runs a dashboard, on NodePort 30443 of every node unless spec.dashboard moves or disables it. A cluster where another Service already holds that port, such as a fleet manager exposed on 30443, keeps the other Service and serves the dashboard on a ClusterIP until the port is free. Set spec.dashboard.nodePort on every control plane to give the dashboard a NodePort of its own. See Connect to the dashboard.

admin.conf is no longer system:masters. Its certificate carries the group stratum:cluster-admins, which the ClusterRoleBinding stratum:cluster-admins binds to cluster-admin, so deleting that binding revokes every admin.conf without a CA rotation. A new root-only super-admin.conf keeps system:masters for Stratum's own clients and for recovery. See admin.conf and super-admin.conf.

An upgraded cluster moves off system:masters on its own. On each control plane's first start of this release, once the bindings the new certificates need exist, Stratum reissues every leaf and restarts that control plane's components, one control plane at a time. Copies of admin.conf made before the upgrade keep system:masters until they expire or the cluster CA is rotated. The new masters.1 control in stratum hardening check fails while any certificate on a node other than super-admin's carries system:masters. See Upgraded clusters and system:masters.