Kubernetes versions are expressed as x.y.z, where x is the major version, y is the minor version, and z is the patch version, following Semantic Versioning terminology.

Where an upstream version x.y.z has been posted as supported in the support matrix, under Rancher Kubernetes, z is the highest patch version for that minor version (y) of Kubernetes, that has been tested and validated for the specific Rancher product version.

In the case of Rancher v2.6.2 , the following are listed as the supported k8s upstream versions for Rancher Kubernetes:

• v1.21.5
• v1.20.11
• v1.19.15
• v1.18.20

That is to say, the following are the k8s versions that are supported in Rancher v2.6.2:

• v1.21.x (v1.21.0-v1.21.5)
• v1.20.x (v1.20.0-v1.20.11)
• v1.19.x (v1.19.0-v1.19.15)
• v1.18.x (v1.18.0-v1.18.20)

Note:

As described in this Rancher docs page, the RKE metadata feature—available as of v2.3.0—allows users to provision clusters with new versions of Kubernetes as soon as they are released, without upgrading Rancher. For a specific version of Rancher, if a k8s patch version (z+i) that is higher than what is listed in the support matrix is available via a metadata refresh, then that patch version z+i is considered supported for that version of Rancher.

Also, see Could you help us understand the Rancher approach to supporting specific k8s versions and how Rancher keeps up with new k8s releases?