Supported Kubernetes Versions

Terminology

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.

Upstream release cycle

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 support Policy

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.

Currently supported minor versions

Following this scheme, these are the Kubernetes versions currently supported by MetaKube:

Minor Version State EOL Minimum Kubelet Version Remarks
1.29 supported 2025-02-28 1.26 recommended version
1.28 supported 2024-10-28 1.26
1.27 supported 2024-06-28 1.25
1.26 supported EOL since 2024-02-28 1.24
1.25 deprecated EOL since 2023-10-28 1.23 Removal 24th Apr 2024

Upcoming minor Versions

Minor Version Start of support
1.30 Approx. Q2 2024
1.31 Approx. Q3 2024
1.32 Approx. Q4 2024

FAQ

What does it mean, when a version becomes unsupported?

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):

    • Updates to cloud credentials
    • RBAC changes
    • SSH key management

    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.

Is it safe to upgrade my 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.

Are my Accelerator Building Blocks always compatible with the latest minor version?

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.

References