The Scenario
You’re adding infrastructure regularly—new clusters, new regions, new services. You want:- New clusters to automatically receive deployments
- No config file updates when infrastructure changes
- Environment membership based on resource attributes
- Different policies for different resource types
Without Ctrlplane
The typical approach:- Add new cluster to Kubernetes
- Update CI/CD pipeline config
- Update deployment manifests
- Update ArgoCD ApplicationSet
- Update monitoring config
- Forget one thing, wonder why deploys don’t work
- Adding infrastructure requires multiple config changes
- Easy to miss something
- Config files become the source of truth (and drift)
- Manual process doesn’t scale
With Ctrlplane
Define Environments with Selectors
Instead of listing clusters, define what “Production” means:Tag Resources Appropriately
When you add a new cluster:- Is automatically part of the “Production” environment
- Receives deployments for all services targeting Production
- Inherits policies that apply to Production
- Shows up in the inventory immediately
What Happens
- Environment defined — “Production” = all resources where
env == production - 3 clusters exist — All have
env: production, all are in Production - New cluster added — ap-south-1 tagged with
env: production - Automatic membership — New cluster is now part of Production
- Deployments flow — Next release automatically targets all 4 clusters
Key Benefits
| Benefit | How It Works |
|---|---|
| Zero config changes | Tag the resource, it joins automatically |
| Declarative membership | Environment definition is the source of truth |
| Immediate effect | New resources are included in next deployment |
| Scales infinitely | 4 clusters or 400, same environment definition |
| Consistent policies | New resources inherit existing policies |