Kubernetes versions follow the scheme of semantic versioning.
A given Kubernetes version
x.y.z consist of a major (
1), minor (
y) and patch (
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||Minimum Kubelet Version||Remarks|
|1.23||deprecated||EOL since 2023-02-28||1.21||Removal on 28th Dec 2023|
|Minor Version||Start of support|
|1.28||Approx. Q1 2024|
|1.29||Approx. Q2 2024|
|1.30||Approx. Q3 2024|
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.
The components that make up the cluster will continue to run with their current configuration.
However, until the cluster version is upgraded to a supported version, updates to the cluster may no longer be applied.
Such updates include (non-exhaustive list):
Changes made in the UI (or equivalently over the API) may not reflect in the live state of the cluster.
If the cluster is two versions behind any 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.
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.