Kubernetes: DKE, TKC, and RKE
devhome runs three genuinely different kinds of Kubernetes cluster side by side — not three names for the same thing. They're provisioned differently, and that difference is deliberate: it's the same spread of cluster-creation patterns you'd actually encounter across real platform teams (roll-your-own kubeadm, a vendor's CRD-driven cluster API, and a fleet-manager-native cluster type).
| DKE | TKC | RKE2 | |
|---|---|---|---|
| What it is | Custom kubeadm clusters | Tanzu Kubernetes Cluster (vSphere Supervisor CRD) | Rancher-native cluster |
| Provisioned by | Terraform (modules/k8s) directly creates VMs + runs kubeadm |
ArgoCD applies a CRD to the Supervisor; vSphere/CAPV creates the VMs | rancher2_cluster_v2 (Rancher provisions) + Terraform-created VMs from a dedicated Packer template |
| CNI | Calico or Flannel (per-cluster choice) | Antrea (Supervisor default) | Canal |
| Terraform's role | Owns the whole lifecycle | Only polls/registers after ArgoCD+Supervisor create it | Declares the Rancher cluster object + node VMs |
| Registration into ArgoCD/Vault/Rancher | Same modules, run after cluster exists | Same modules, run after CAPI reports Ready |
Same modules |
| Status | Active (dke-mgmt, dke, dkes) |
Active (tkc-dev) |
Disabled/parked (rke.tf.disabled) |
See DKE, TKC, and RKE2 for the full detail on each.
Official downloads
- Kubernetes releases / kubeadm install docs — DKE clusters
- Rancher releases — RKE2/Rancher management
- Calico releases — CNI used by DKE
What all three share
Regardless of how a cluster gets created, the post-creation onboarding is uniform:
register into ArgoCD (argocd-register-clust module), wire Vault Kubernetes auth
(vault-k8s-auth module), and import into Rancher — see
Bootstrapping a New Cluster. This is what keeps
three different provisioning mechanisms from turning into three different
operational mechanisms — once a cluster exists, it's managed identically no matter
how it was born.