Skip to content

TKC (Tanzu Kubernetes Cluster)

TKC clusters are provisioned through the vSphere Supervisor (Tanzu/WCP) rather than by Terraform directly creating VMs — cluster creation itself is GitOps-driven, which makes this the most different of the three cluster types operationally.

The flow

  1. argocd_application.tkc_dev applies k8s/tkc/ to the Supervisor cluster via ArgoCD — this manifest is a TanzuKubernetesCluster CRD object, not a set of pods. Applying it is what tells vSphere/CAPV to actually provision the cluster's VMs.
  2. null_resource.tkc_dev_kubeconfig polls the Supervisor until the underlying CAPI Cluster object reports Ready, then extracts the admin kubeconfig from the tkc-dev-kubeconfig Secret the Supervisor writes automatically.
  3. module.argocd_register_tkc_dev creates the argocd-manager ServiceAccount/token in the new TKC and registers it in ArgoCD with bootstrap=true, so every bootstrap ApplicationSet on dke-mgmt immediately targets it too.
  4. module.vault_auth_tkc_dev configures a dedicated Vault Kubernetes auth backend (kubernetes/tkcs, not the shared default path) so External Secrets on this cluster can authenticate and read devhome/* — creates the vault-auth ServiceAccount/token and binds the eso-reader role.
  5. rancher2_cluster.import_tkc_dev imports the cluster into Rancher using the standard agent-manifest flow.

So unlike DKE, where Terraform owns the entire lifecycle end-to-end, here Terraform's job is almost entirely reactive — wait for something ArgoCD/Supervisor already did, then wire the result into the same registration modules every cluster type uses.

A gotcha specific to this path: Supervisor DNS reconciliation

The vmoperator-network-config ConfigMap (in vmware-system-vmop) is not a standalone setting you can edit directly — it's a live projection of the Supervisor's own Workload Management config in vCenter (the namespace-management API's worker_DNS field). Patching the ConfigMap by hand only sticks until vCenter's WCP service next reconciles it, which silently reverts nameservers back to empty and sends every TKC worker node into a MachineHealthCheck replace-loop (CreateOrUpdateFailure: No nameservers in vmoperator-network-config ConfigMap) — forever, since the underlying WCP-side value was never actually set. The real fix is setting the Supervisor's Workload Network DNS field itself (in vCenter's Workload Management config), not the ConfigMap it generates.

Supervisor host

The Supervisor's own API lives at a fixed address in this lab (10.0.0.170 in the current TKC config) — distinct from any individual TKC cluster's own API endpoint.

Operational gotchas belong on their own page

The Supervisor (WCP) that backs TKC has accumulated a large amount of hard-won operational knowledge — etcd TLS/iptables cross-host routing bugs, a dynamic internal VIP that drifts with zero restarts, a stale-license-asset failure mode, and more — kept on a dedicated page rather than here since it applies to the Supervisor itself, not specifically to any one TKC cluster: see Supervisor (WCP) Operations.