RKE2

RKE2 is Rancher's own Kubernetes distribution, provisioned Rancher-natively rather than via kubeadm — currently disabled/parked in this repo (terraform/vsphere/compute/disabled/rke.tf.disabled) rather than actively running. It was proven working end-to-end before being parked (vsphere_virtual_machine.rke2_node cloned/customized and joined in ~1m36s with no hang; the node reached Ready control-plane/etcd/master within ~50s of rke2-server starting, full static-pod control plane + Canal CNI came up clean) — so this is a real, validated pattern, not an unfinished experiment.

cattle-cluster-agent taking a while is normal, not a bug

Right after cluster creation, the Rancher-proxied kubeconfig context returns 403/system:unauthenticated until cattle-cluster-agent (the Rancher downstream tunnel) finishes coming up — expected, not something to debug.

How it differs from DKE

resource "rancher2_cluster_v2" "rke2" {
  name               = "rke2-cluster"
  kubernetes_version = "v1.28.8+rke2r1"
  rke_config {
    machine_global_config = <<-EOT
      cni: canal
      disable-kube-proxy: false
    EOT
  }
}

Rancher itself owns cluster bootstrapping via rancher2_cluster_v2 — there's no kubeadm init/kubeadm join step for Terraform or Ansible to run. Terraform's job is narrower than even the TKC case: declare the Rancher cluster object, then create plain vsphere_virtual_machine node VMs that join it.

Dedicated node template

RKE2 nodes come from their own Packer template (ubuntu-22.04.3-rke2, producing a rke2-1-28 vSphere template) — deliberately not the same template DKE nodes use, because RKE2 bundles its own containerd and doesn't want kubeadm/kubelet/containerd pre-baked in. Using the DKE template for an RKE2 node would fight RKE2's own runtime installation.

CNI

Canal (a Flannel + Calico-policy combination), Rancher's RKE2 default — different from either CNI choice available to DKE clusters.

The clone-hang bug that isn't about RKE2 at all

vsphere_virtual_machine.rke2_node hung forever right after the VM booted the first time this was built — terraform apply never returned, even though the VM itself came up fine. Not a Packer template problem: caused by combining clone.customize (static IP) with extra_config["guestinfo.userdata"/"guestinfo.metadata"] (DHCP cloud-init) on the same resource — two competing guest-customization mechanisms fighting over the same NIC — plus a missing customize { timeout = 0 } (without it, the vsphere provider waits forever for a guest-customization callback that this template family often never fires, even though customization succeeds on the guest). Fix: use customize{} alone (with an empty network_interface {} for DHCP), never combined with guestinfo, and always set timeout = 0. Worth checking first if any vsphere_virtual_machine clone in this repo hangs post-boot with no error — independent of which template is being cloned.

A standalone kubeconfig is written to the same NAS location the dke/dkes/dke_mgmt clusters use (kubeconfig_paths.rke2 in locals.tf), separate from (and in addition to) the local WSL kubeconfig merge — one is for local kubectl context switching, the other is a NAS-shared file other tooling/machines can reference directly.

Why it's parked, not deleted

Kept in the repo (as .disabled) rather than removed, so re-enabling it later is a file rename plus a template rebuild, not a from-scratch rewrite.