This topic describes how the system resolves TKr images.

TKr Resolution

When the Cluster object is created or updated, the Kubernetes API server invokes the TKr Resolver mutating webhook. The Cluster (or its ClusterClass) must have the run.tanzu.vmware.com/resolve-tkr annotation. Otherwise, TKr resolution is skipped entirely. The TKr Resolver uses the value of the run.tanzu.vmware.com/resolve-tkr annotation as a label query to constrain the set of candidate TKrs. An empty string selects all TKrs.

The values of the run.tanzu.vmware.com/resolve-os-image annotation on the Cluster topology controlPlain and machineDeployments are used as label selectors for OSImage objects to be used with the controlPlain and machineDeployments respectively. Exactly one OSImage shipped by the resolved TKr must satisfy the query for either controlPlane or any of the machineDeployments.

Provided Cluster spec.topology.version is used as a version prefix. The TKr Resolver webhook looks for the latest available TKR satisfying the above constraints. If not found, the Cluster create/update request is denied.

The TKR Resolver webhook mutates the Cluster:
  • The run.tanzu.vmware.com/tkr label is set to the name of the resolved TKR
  • Cluster spec.topology.version is set to the Kubernetes version of the resolved TKR
  • Cluster variable TKR_DATA is updated to contain a mapping from the Kubernetes version to the set of values from the TKR and OSImage for the controlPlane.
  • TKR_DATA variable overrides for individual machineDeployments are updated to contain a mapping from the Kubernetes version to the set of values from the TKR and OSImage for the machineDeployment.