Create and Manage Kubernetes Clusters with Cluster API and ArgoCD

The idea

Kubernetes Cluster API provides declarative APIs for provisioning, upgrading, and managing clusters. Instead of clicking through a cloud console or running one-off scripts, you describe clusters as Kubernetes resources.

ArgoCD fits this model well. It can watch a Git repository and continuously apply desired state into the management cluster. That desired state can include both applications and the cluster objects that create workload clusters.

Pattern: management cluster runs Cluster API + ArgoCD; Git stores the desired workload cluster definitions.

Architecture

The lab uses Kind locally. One Kind cluster acts as the management cluster. Cluster API runs there, and ArgoCD syncs manifests that create additional Kind workload clusters.

Git repository | v ArgoCD on management cluster | v Cluster API resources | v Workload clusters: c1, c2, ...

Once workload clusters exist, ArgoCD can also deploy namespaces, quotas, role bindings, and application resources into those clusters.

Create the management cluster

Because the whole exercise runs locally, Kind needs access to Docker. A simple management cluster can be created with a config that mounts the Docker socket.

kind create cluster --config mgmt-cluster-config.yaml --name mgmt
clusterctl init --infrastructure docker

After initialization, Cluster API installs its CRDs and controllers. The management cluster can now reconcile cluster lifecycle resources.

GitOps flow with ArgoCD

The useful part is putting cluster definitions in Git. ArgoCD watches those manifests and applies them to the management cluster. Cluster API controllers then create or update the workload clusters.

clusterctl generate cluster c1 \
  --flavor development \
  --infrastructure docker \
  --kubernetes-version v1.23.0 \
  --control-plane-machine-count=1 \
  --worker-machine-count=1

That generated YAML becomes the source of truth. Changing the YAML changes the desired cluster state.

Operational view

This approach is powerful because it turns cluster management into a reviewable change. You can use pull requests, history, and rollback patterns for cluster lifecycle work.

Cluster creation is repeatable.
Cluster definitions are versioned.
ArgoCD shows sync and health state.
Workload clusters can receive baseline resources consistently.

Notes

This post was originally based on a public walkthrough by Piotr Minkowski and adapted into my own lab notes. The main value for me was understanding that GitOps can manage cluster lifecycle, not only app deployment.

Cluster API describes clusters as resources; ArgoCD keeps those resources reconciled from Git.

For real cloud environments, the same idea applies with AWS, Azure, or GCP infrastructure providers. The local Kind lab is just the lowest-cost way to learn the pattern.