Kubernetes Versions and Support Policy
Kubernetes versions follow semantic versioning.
A given Kubernetes version x.y.z consists of a major (x, always 1), minor (y), and patch (z) version.
These versions apply to all parts of a cluster's control plane (API-Server, 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 API-Server) managed by us.
Kubelet determines the version of a Kubernetes cluster node, independent of the control plane version.
Upstream Release Cycle
The Kubernetes project releases a new minor version every four months. A given minor version receives patch (security) updates at least monthly for about 14 months, after which the version reaches end of life (EOL).
You can find release dates and the future version schedule here.
Our Support Policy
We aim to support four Kubernetes minor versions for control planes at any given time. The oldest one is always deprecated, meaning it becomes unsupported when support for a new minor version begins.
Note
Clusters in the regions DUS & HAM using an unsupported version automatically upgrade to the latest available patch version of the lowest supported minor version.
We release new minor versions after testing confirms they are stable with MetaKube.
We aim to release the latest patch versions soon after their upstream release.
Nodes with older Kubelet versions work as long as they conform to the version skew policy.
Supported minor versions
Following this scheme, these are the Kubernetes versions supported by MetaKube:
| Minor Version | State | EOL | Min. Kubelet Version | Removal |
|---|---|---|---|---|
| 1.36 | supported | 28.06.2027 | 1.33 | 30.09.2027 |
| 1.35 | supported | 28.02.2027 | 1.32 | 31.05.2027 |
| 1.34 | supported | 28.10.2026 | 1.31 | 31.01.2027 |
| 1.33 | supported | 28.06.2026 | 1.30 | 30.09.2026 |
| 1.32 | deprecated | 28.02.2026 | 1.29 | 31.08.2026 |
Upcoming minor versions
| Minor Version | Start of support |
|---|---|
| 1.37 | Approx. 09.2026 |
| 1.38 | Approx. 12.2026 |
| 1.39 | Approx. 09.2027 |
FAQ
What does it mean when a version becomes deprecated?
Before a version becomes unsupported, there's a grace period of about four months during which the version remains supported. Upgrade your cluster to a supported version as soon as possible.
The above table lists the exact removal date for each version.
End of life
Deprecating a version typically coincides with its end-of-life (EOL). This means we release no further patch versions to fix security issues. We don't recommend staying on a deprecated version for long.
What does it mean when a version becomes unsupported?
To support newer versions, we may make changes that no longer work with unsupported versions. To prevent changes like these from breaking an unsupported cluster, we may disable updates to that cluster.
This includes:
- Updates done through the MetaKube API, which include (non-exhaustive list):
- Updates to cloud credentials
- RBAC changes
- SSH key management
Danger
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
Danger
Once certificates expire, the control plane becomes unusable until the cluster is on a supported version!
Danger
If the cluster lags two versions behind the oldest supported version, version upgrades are no longer possible. Contact our support for help upgrading an old cluster or migrating workloads to a new cluster.
Is it safe to upgrade my cluster?
We configure 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 work with existing workloads. While some API versions may be deprecated, they continue to work until Kubernetes removes them.
Your applications may rely on specific API versions. 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 require newer Kubernetes versions.
Tip
Read the Kubernetes Changelog for the target version and check the Kubernetes Deprecated API Migration Guide before upgrading. We also recommend testing a Kubernetes version upgrade in a dev environment first.
Are my Accelerator Building Blocks compatible with the latest minor version?
We test building block compatibility for each release, depending on whether the respective third-party software vendor supports the version.
See the MetaKube Accelerator documentation for details.