GitOps & Cluster Lifecycle Overview

Once a cluster exists (provisioned by Terraform), everything that runs inside it is delivered via ArgoCD (GitOps pull-based sync), and the cluster itself is managed as part of a fleet via Rancher.

flowchart LR
    TF["Terraform<br/>modules/k8s"] -->|kubeadm cluster exists| REG
    subgraph REG["Registration (Terraform modules)"]
        direction TB
        A["argocd-register-clust<br/>adds cluster as ArgoCD target"]
        V["vault-k8s-auth<br/>wires ServiceAccount into Vault"]
        R["Rancher import<br/>(manual or scripted)"]
    end
    REG --> ARGOCD["ArgoCD on dke-mgmt"]
    ARGOCD -->|ApplicationSet sync| APPS["In-cluster apps:<br/>Calico/Flannel CNI, ESO,<br/>MetalLB, ingress, workloads"]
    ARGOCD -.fleet mgmt.-> RANCHER["Rancher on dke-mgmt"]

See:

• Bootstrapping a New Cluster — the actual step-by-step
• ArgoCD — the ApplicationSet pattern and its one sharp edge
• Rancher — fleet-level cluster management

Why dke-mgmt is special

dke-mgmt hosts ArgoCD and Rancher themselves — it's the control plane for every other cluster's GitOps and fleet management, not just another workload cluster. Its own availability is a single point of failure for deploying changes, though not for already-running workloads elsewhere, since GitOps sync is pull-based and workload clusters keep serving traffic even if dke-mgmt is briefly down. See Architecture Overview.