Platform Engineering Blog
This is where I document real platform engineering patterns I've built and deployed in production. For me Kubernetes is the engine of modern platforms, so my focus is on GitOps-based management using Terraform for infrastructure provisioning and Argo CD for application workload delivery across Azure, AWS, and edge environments. I work primarily with AKS, EKS, ARO, and RKE2.
GitOps Cluster Onboarding Patterns
For me the key principle is always Terraform manages infrastructure, Argo CD manages workloads. However, I have developed two distinct patterns for onboarding clusters to Argo CD.
The terraform module always creates the cluster and all necessary cloud resources like IAM roles, security groups, networking, etc. The difference is how the Argo CD cluster secret is created and applied.
Automated Onboarding (Terraform-Driven)
When you provision a cluster, the module automatically creates the kubernetes secret and applies it to Argo CD using the Kubernetes provider. This goes against the pure GitOps principle of pull-based reconciliation and also against my earlier key principal of Terraform managing infrastructure and Argo CD managing cluster config, but in practice it works well because It's fast and requires minimal manual steps. Just run terraform apply and the cluster provisioned and onboarded to Argo CD.
| Pro's | Con's |
|---|---|
| Simple and fast to implement / deploy | Creates coupling between infrastructure provisioning and cluster configuration |
| Less scalable from a disaster recovery point of view since if the platform cluster is destroyed you need to re-run terraform to recreate the argocd secret. |
Best for:
- Teams that want cluster onboarding to happen automatically as part of infrastructure provisioning.
- Green field projects where you control the entire stack.
Implementation Guides:
Declarative Onboarding (GitOps-Native)
Uses External Secrets Operator to fetch cluster credentials from Key Vault/Secrets Manager and creates declarative Argo CD cluster secrets that continuously reconcile. Fully pull-based and self-healing.
We effectively use some kind of key/value storage as the source of truth for cluster credentials. by having the terraform module output ca certificate and cluster url
| Pro's | Con's |
|---|---|
| Fully embraces GitOps. | Could be perceived as more complex to implement and |
| maximum resilience and zero coupling between Terraform and cluster configuration. | requires more manual steps when deploying new clusters. |
Best for:
- Mature platforms where you want complete separation between infrastructure provisioning and cluster configuration.
- Environments where the platform cluster might get recreated, and you need automatic recovery to ensure maximum uptime.
Implementation Guides: