Kubernetes Support Matrix

Use the Kubernetes support matrix to confirm Kubernetes version relationships for releases and to distinguish cluster creation, upgrade compatibility, and third-party cluster onboarding boundaries.

For the conceptual lifecycle guidance, see Version and Lifecycle.

How To Read This Page

TermMeaning
Supported for cluster creationThe Kubernetes version that can be used when creates a new platform-managed cluster for that release.
Compatible VersionsThe Kubernetes versions that workload clusters can run before the global cluster is upgraded to that release.
Third-party cluster product-tested scopeThe product-supported Kubernetes onboarding range and the default capabilities covered by product validation on third-party clusters.

Version Support Matrix

The following table shows the Kubernetes version support for each release.

INFO

This documentation is maintained for a minor release line and does not publish a separate documentation set for each patch release. The table reflects the Kubernetes minors supported by the current documented state of that release line. If a later patch release adds another Kubernetes minor, the same row and its compatible-version range are updated. Use the target versions offered by the platform and release-specific artifacts for exact Kubernetes builds.

At any point in the release line, create clusters only with a Kubernetes target offered and validated by the installed patch. The minor-level row can expand when a later patch adds another validated Kubernetes minor.

VersionSupported for cluster creationCompatible Versions
4.41.351.35, 1.34, 1.33, 1.32
4.31.341.34, 1.33, 1.32, 1.31
4.21.331.33, 1.32, 1.31, 1.30
4.11.321.32, 1.31, 1.30, 1.29
4.01.31, 1.30, 1.29, 1.281.31, 1.30, 1.29, 1.28

Product-Tested Scope for Third-Party Clusters

Product-Supported Kubernetes Range

Third-party Kubernetes clusters have completed product onboarding validation for Kubernetes 1.28 through 1.35, inclusive. Kubernetes minors outside this range are not declared product-supported for third-party cluster onboarding.

The current product-tested range applies to 4.3 and later releases that provide third-party cluster onboarding. It is maintained as one shared range instead of being copied into each release row, and is updated when product validation covers additional Kubernetes minors.

The product validation program continues to test additional Kubernetes minor versions. A version that is planned for testing or still being evaluated is not product-supported. After a version completes product validation, the range on this page is updated. Use the currently published range as the authority for product support.

This range is separate from the Compatible Versions column. Compatible Versions determine whether workload clusters satisfy the prerequisite for upgrading the global cluster. The third-party onboarding range determines whether a third-party Kubernetes cluster can be onboarded.

Default Validation Scope

For third-party clusters within the published Kubernetes range, default product validation covers:

  • Core Kubernetes workload and resource operations, such as creating and managing Deployments.
  • Extend workflows used to install and upgrade Operators and Cluster Plugins.
  • ClickHouse-based logging installed and upgraded through Extend.
  • VictoriaMetrics-based monitoring installed and upgraded through Extend.

Extend is included in the default validation scope because the validated logging and monitoring capabilities depend on Extend for installation and upgrade. Customers can also use Extend to install other capabilities when the exact Operator or Cluster Plugin declares compatibility with the target environment.

Default product validation does not mean that every specific Operator or Cluster Plugin is validated. For any other Operator or Cluster Plugin, check its product documentation and Customer Portal compatibility metadata, or contact technical support.

The published Kubernetes range and default validation scope do not replace the prerequisites of the selected onboarding method. Follow Third-Party Cluster Onboarding and the applicable Import, Register, or provider-specific procedure to verify connectivity, credentials, and environment-specific preparation.

For model boundaries, see Cluster Management Models. For upgrade planning, see Upgrade Overview and Pre-Upgrade.

Upgrade Requirements

For 4.3 and later, workload clusters only need to remain within the documented compatible version range before upgrading the global cluster.

In 4.2 and earlier, all workload clusters must be upgraded to the latest Kubernetes version in the compatible versions list before upgrading the global cluster.

For upgrade procedures, see Upgrade.