sigs.k8s.io/cluster-api@v1.6.3/docs/book/src/reference/versions.md (about) 1 # Cluster API Version Support and Kubernetes Version Skew Policy 2 3 ## Supported Versions 4 5 The Cluster API team maintains branches for **v1.x (v1beta1)**. For more details see [Support and guarantees](https://github.com/kubernetes-sigs/cluster-api/blob/main/CONTRIBUTING.md#support-and-guarantees). 6 7 Releases include these components: 8 9 - Core Provider 10 - Kubeadm Bootstrap Provider 11 - Kubeadm Control Plane Provider 12 - clusterctl client 13 14 All Infrastructure Providers are maintained by independent teams. Other Bootstrap and Control Plane Providers are also maintained by independent teams. For more information about their version support, see [below](#providers-maintained-by-independent-teams). 15 16 ## Supported Kubernetes Versions 17 18 A Cluster API minor release supports (when it's initially created): 19 * 4 Kubernetes minor releases for the management cluster (N - N-3) 20 * 6 Kubernetes minor releases for the workload cluster (N - N-5) 21 22 When a new Kubernetes minor release is available, we will try to support it in an upcoming Cluster API patch release 23 (although only in the latest supported Cluster API minor release). See Cluster API [release cycle](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-cycle.md) 24 and [release calendars](https://github.com/kubernetes-sigs/cluster-api/tree/main/docs/release/releases) for more details. 25 26 For example, Cluster API v1.5.0 would support the following Kubernetes versions: 27 * v1.24.x to v1.27.x for the management cluster 28 * v1.22.x to v1.27.x for the workload cluster 29 * When Kubernetes 1.28 is released, it will be supported in v1.5.x (but not in v1.4.x) 30 31 Support in this context means that we: 32 * maintain corresponding code paths 33 * have test coverage 34 * accept bug fixes 35 36 Important! if the changes in Cluster API required to support a new Kubernetes release are too invasive, we won't backport 37 it to older releases and users have to wait for the next Cluster API minor release. 38 39 Important! This is not a replacement/alternative for upstream Kubernetes support policies! 40 Support for versions of Kubernetes which itself are out of support is limited to "Cluster API can start a Cluster with this Kubernetes version" 41 and "Cluster API can upgrade to the next Kubernetes version"; it does not include any extended support to Kubernetes itself. 42 43 Whenever a new Cluster API release is cut, we will document the Kubernetes version compatibility matrix the release 44 has been tested with. Summaries of Kubernetes versions supported by each component are additionally maintained in 45 the [tables](#release-components) below. 46 47 On a final comment, let's praise all the contributors keeping care of such a wide support matrix. 48 If someone is looking for opportunities to help with the project, this is definitely an area where additional hands 49 and eyes will be more than welcome and greatly beneficial to the entire community. 50 51 See the [following section](#kubernetes-version-support-as-a-function-of-cluster-topology) to understand how cluster topology affects version support. 52 53 ### Kubernetes Version Support As A Function Of Cluster Topology 54 55 The Core Provider, Kubeadm Bootstrap Provider, and Kubeadm Control Plane Provider run on the Management Cluster, and clusterctl talks to that cluster's API server. 56 57 In some cases, the Management Cluster is separate from the Workload Clusters. The Kubernetes version of the Management and Workload Clusters are allowed to be different. 58 59 Management Clusters and Workload Clusters can be upgraded independently and in any order, however, if you are additionally moving from 60 v1alpha3 (v0.3.x) to v1beta1 (v1.x) as part of the upgrade rollout, the management cluster will need to be upgraded to at least v1.20.x, 61 prior to upgrading any workload cluster using Cluster API v1beta1 (v1.x) 62 63 These diagrams show the relationships between components in a Cluster API release (yellow), and other components (white). 64 65 #### Management And Workload Cluster Are the Same (Self-hosted) 66 67  68 69 #### Management And Workload Clusters Are Separate 70 71  72 73 ### Release Components 74 75 #### Core Provider (`cluster-api-controller`) 76 77 | | v1.3 (v1beta1) (EOL) | v1.4 (v1beta1) | v1.5 (v1beta1) | v1.6 (v1beta1) | 78 |-------------------|----------------------|-------------------|-------------------|-------------------| 79 | Kubernetes v1.18 | ✓ (only workload) | | | | 80 | Kubernetes v1.19 | ✓ (only workload) | | | | 81 | Kubernetes v1.20 | ✓ | | | | 82 | Kubernetes v1.21 | ✓ | ✓ (only workload) | | | 83 | Kubernetes v1.22 | ✓ | ✓ (only workload) | ✓ (only workload) | | 84 | Kubernetes v1.23* | ✓ | ✓ | ✓ (only workload) | ✓ (only workload) | 85 | Kubernetes v1.24 | ✓ | ✓ | ✓ | ✓ (only workload) | 86 | Kubernetes v1.25 | ✓ | ✓ | ✓ | ✓ | 87 | Kubernetes v1.26 | ✓ | ✓ | ✓ | ✓ | 88 | Kubernetes v1.27 | | ✓ >= v1.4.2 | ✓ | ✓ | 89 | Kubernetes v1.28 | | | ✓ >= v1.5.1 | ✓ | 90 | Kubernetes v1.29 | | | | ✓ >= v1.6.1 | 91 92 \* There is an issue with CRDs in Kubernetes v1.23.{0-2}. ClusterClass with patches is affected by that (for more details please see [this issue](https://github.com/kubernetes-sigs/cluster-api/issues/5990)). Therefore we recommend to use Kubernetes v1.23.3+ with ClusterClass. 93 Previous Kubernetes **minor** versions are not affected. 94 95 \** When using CAPI v1.2 or v1.3 with the CLUSTER_TOPOLOGY experimental feature on, the Kubernetes Version for the management cluster must be >= 1.22.0. 96 97 The Core Provider also talks to API server of every Workload Cluster. Therefore, the Workload Cluster's Kubernetes version must also be compatible. 98 99 #### Kubeadm Bootstrap Provider (`kubeadm-bootstrap-controller`) 100 101 | | v1.3 (v1beta1) (EOL) | v1.4 (v1beta1) | v1.5 (v1beta1) | v1.6 (v1beta1) | 102 |------------------------------------|----------------------|--------------------|--------------------|--------------------| 103 | Kubernetes v1.18 + kubeadm/v1beta2 | ✓ (only workload) | | | | 104 | Kubernetes v1.19 + kubeadm/v1beta2 | ✓ (only workload) | | | | 105 | Kubernetes v1.20 + kubeadm/v1beta2 | ✓ | | | | 106 | Kubernetes v1.21 + kubeadm/v1beta2 | ✓ | ✓ (only workload) | | | 107 | Kubernetes v1.22 + kubeadm/v1beta3 | ✓ | ✓ (only workload) | ✓ (only workload) | | 108 | Kubernetes v1.23 + kubeadm/v1beta3 | ✓ | ✓ | ✓ (only workload) | ✓ (only workload) | 109 | Kubernetes v1.24 + kubeadm/v1beta3 | ✓ | ✓ | ✓ | ✓ (only workload) | 110 | Kubernetes v1.25 + kubeadm/v1beta3 | ✓ | ✓ | ✓ | ✓ | 111 | Kubernetes v1.26 + kubeadm/v1beta3 | ✓ | ✓ | ✓ | ✓ | 112 | Kubernetes v1.27 + kubeadm/v1beta3 | | >= v1.4.2 | ✓ | ✓ | 113 | Kubernetes v1.28 + kubeadm/v1beta3 | | | ✓ >= v1.5.1 | ✓ | 114 | Kubernetes v1.29 + kubeadm/v1beta3 | | | | ✓ >= v1.6.1 | 115 116 The Kubeadm Bootstrap Provider generates kubeadm configuration using the API version recommended for the target Kubernetes version. 117 118 #### Kubeadm Control Plane Provider (`kubeadm-control-plane-controller`) 119 120 | | v1.3 (v1beta1) (EOL) | v1.4 (v1beta1) | v1.5 (v1beta1) | v1.6 (v1beta1) | 121 |----------------------------|----------------------|-------------------|-------------------|-------------------| 122 | Kubernetes v1.18 + etcd/v3 | ✓ (only workload) | | | | 123 | Kubernetes v1.19 + etcd/v3 | ✓ (only workload) | | | | 124 | Kubernetes v1.20 + etcd/v3 | ✓ | | | | 125 | Kubernetes v1.21 + etcd/v3 | ✓ | ✓ (only workload) | | | 126 | Kubernetes v1.22 + etcd/v3 | ✓ | ✓ (only workload) | ✓ (only workload) | | 127 | Kubernetes v1.23 + etcd/v3 | ✓ | ✓ | ✓ (only workload) | ✓ (only workload) | 128 | Kubernetes v1.24 + etcd/v3 | ✓ | ✓ | ✓ | ✓ (only workload) | 129 | Kubernetes v1.25 + etcd/v3 | ✓ | ✓ | ✓ | ✓ | 130 | Kubernetes v1.26 + etcd/v3 | ✓ | ✓ | ✓ | ✓ | 131 | Kubernetes v1.27 + etcd/v3 | | >= v1.4.2 | ✓ | ✓ | 132 | Kubernetes v1.28 + etcd/v3 | | | ✓ >= v1.5.1 | ✓ | 133 | Kubernetes v1.29 + etcd/v3 | | | | ✓ >= v1.6.1 | 134 135 The Kubeadm Control Plane Provider talks to the API server and etcd members of every Workload Cluster whose control plane it owns. It uses the etcd v3 API. 136 137 The Kubeadm Control Plane requires the Kubeadm Bootstrap Provider. 138 139 \* Newer versions of CoreDNS may not be compatible as an upgrade target for clusters managed with Cluster API. Kubernetes versions marked on the table are supported as an upgrade target only if CoreDNS is not upgraded to the latest version supported by the respective Kubernetes version. The versions supported are represented in the below table. 140 141 ##### CoreDNS 142 143 | CAPI Version | Max CoreDNS Version for Upgrade | 144 |----------------------|---------------------------------| 145 | v1.5 (v1beta1) | v1.10.1 | 146 | >= v1.5.1 (v1beta1) | v1.11.1 | 147 | v1.6 (v1beta1) | v1.11.1 | 148 149 #### Kubernetes version specific notes 150 151 **1.29**: 152 * In-tree cloud providers are now switched off by default. Please use DisableCloudProviders and DisableKubeletCloudCredentialProvider feature flags if you still need this functionality. (https://github.com/kubernetes/kubernetes/pull/117503) 153 154 **1.28**: 155 * No specific notes 156 157 **1.27**: 158 * No specific notes 159 160 **1.26**: 161 * No specific notes 162 163 **1.25**: 164 * No specific notes 165 166 **1.24**: 167 * Kubeadm Bootstrap Provider: 168 * `kubeadm` now sets both the `node-role.kubernetes.io/control-plane` and `node-role.kubernetes.io/master` taints on control plane nodes. 169 * `kubeadm` now only sets the `node-role.kubernetes.io/control-plane` label on control plane nodes (the `node-role.kubernetes.io/master` label is not set anymore). 170 * Kubeadm Bootstrap Provider and Kubeadm Control Plane Provider 171 * `criSocket` without a scheme prefix has been deprecated in the kubelet since a while. `kubeadm` now shows a warning if no scheme is present and eventually the support for `criSocket`'s without prefix will be dropped. Please adjust the `criSocket` accordingly (e.g. `unix:///var/run/containerd/containerd.sock`) if you are configuring the `criSocket` in CABPK or KCP resources. 172 173 #### clusterctl 174 175 It is strongly recommended to always use the latest version of [clusterctl](../clusterctl/overview.md), in order to get all the fixes/latest changes. 176 177 In case of upgrades, clusterctl should be upgraded first and then used to upgrade all the other components. 178 179 ## Providers Maintained By Independent Teams 180 181 In general, if a Provider version M says it is compatible with Cluster API version N, then version M must be compatible with a subset of the Kubernetes versions supported by Cluster API version N. 182 183 To understand the version compatibility of a specific provider, please see its documentation. This book includes [a list of independent providers](providers.md)