Kubernetes versions follow the scheme of semantic versioning.
A given Kubernetes version x.y.z consist of a major (x, always 1), minor (y) and patch (z) version.
These versions are used for all parts of a cluster's control plane (apiserver, controller-manager, scheduler, kubelet), as well as kube-proxy and kubectl.
The version of a MetaKube cluster always refers to the version of the primary control plane components (mainly apiserver) managed by SysEleven.
The version of a Kubernetes cluster node is determined by Kubelet and is independent of the version of the control plane of the cluster.
The Kubernetes project releases a new minor version roughly every four month.
A given minor version typically receives patch (security) updates at least every month for a total period of roughly fourteen (14) months, after which the version is considered "EOL" (end of life).
Currently supported and release dates of future versions can be found here.
SysEleven aims to always support four Kubernetes minor versions for control planes at any given time.
The oldest of which is always considered deprecated, meaning that it automatically becomes unsupported with the support of a new minor version.
New minor versions become supported and are made available once they have been tested and are considered stable with MetaKube.
SysEleven aims to always make the latest patch versions available soon after their release.
Nodes with older Kubelet versions are supported as long as they conform to the version skew policy.
Following this scheme, these are the Kubernetes versions currently supported by MetaKube:
| Minor Version | State | EOL | Min. Kubelet Version | Removal |
|---|---|---|---|---|
| 1.32 | supported | 28.02.2026 | 1.29 | 31.05.2026 |
| 1.31 | supported | 28.10.2025 | 1.28 | 31.01.2026 |
| 1.30 | supported | 28.06.2025 | 1.27 | 30.09.2025 |
| 1.29 | supported | 28.02.2025 | 1.26 | 30.05.2025 |
| 1.28 | deprecated | 28.10.2024 | 1.25 | 31.01.2025 |
| Minor Version | Start of support |
|---|---|
| 1.33 | Approx. 05.2025 |
| 1.34 | Approx. 09.2025 |
| 1.35 | Approx. 01.2026 |
Before a version becomes unsupported, there's a grace period of approximately four months where the version is still supported.
However, you should upgrade your cluster to a supported version as soon as possible.
We will notify you of the exact date a version becomes unsupported at least 4 weeks in advance.
Note:
The time when we deprecate a version usually lines up with the time when it becomes end-of-life (EOL).
This means there's no new patch versions released that fix security issues.
We don't recommend to stay on a deprecated version for long.
To support newer versions, we may make changes that are no longer compatible with unsupported versions.
In order to prevent changes like these to break an unsupported cluster, we may disable updates to that cluster.
This includes:
Updates done through the MetaKube API, which include (non-exhaustive list):
Changes made in the UI (or equivalently over the API) may not reflect in the live state of the cluster.
Management by the internal MetaKube control plane, which includes automatic certificate rotation
Once certificates expire, the control plane becomes completely unusable until the cluster is updated to a supported version!
If the cluster is two versions behind the oldest supported version, version upgrades are no longer possible.
Please contact SysEleven Support if you need help upgrading an old cluster or migrating workloads to a new cluster.
SysEleven takes care of the correct configuration of your cluster's control plane components and plugins (CNI, CSI, Cloud Controller Manager, etc.) and ensures they are compatible with the new version.
Most Kubernetes minor versions are backwards compatible with existing workloads.
While some API versions may be deprecated, they will continue to work, until they are completely removed.
Your applications may rely on specific API versions to work.
While most open-source applications on Kubernetes support a wide range of Kubernetes versions, they may break with newer versions.
Likewise, newer versions of open-source applications may in turn require newer Kubernetes versions.
We recommend reading the Kubernetes Changelog for the given version and to check the Kubernetes Deprecated API Migration Guide before upgrading.
Furthermore, it's generally wise to test a Kubernetes version upgrade in a dev environment first.
Compatibility with a new release will be tested for each building block individually and depends on support for the version by the respective 3rd party software vendors.
Consult the MetaKube Accelerator documentation for details.