Keep clusters from developing separate ways of working.
Manual changes introduce differences that may surface only during an incident or upgrade. GitOps uses a version-controlled repository as the source of desired configuration. A tool such as Argo CD compares that configuration with the cluster. This exposes drift, but still requires explicit boundaries for access, automation and recovery.
What the support involves.
Cluster onboarding and separation
Define cluster roles, environments, network access and permissions upfront. Distinguish infra and worker clusters and prod and nonprod where required. Real personal data does not automatically belong in a test environment; anonymisation and access policy need separate verification.
Platform components as code
Argo CD, ApplicationSets, Helm and Kustomize can make configuration repeatable. Components for ingress, certificates and observability receive explicit versions, configuration and ownership. Choose open-source and CNCF projects for maintainability and fit rather than popularity alone.
Change, recovery and handover
Reviews and checks precede synchronisation. Agree whether synchronisation runs automatically or requires an explicit action. Exercise failed deployments, configuration recovery and cluster replacement. Reverting Git does not replace restoring application data.
Concrete deliverables.
The scope defines which clusters and components are included. Kubernetes does not take over application security, data backups or operational ownership.
- A repository structure with reusable configuration and environment boundaries.
- An agreed onboarding and change process with suitable checks.
- Runbooks and an exercised handover covering deployment and recovery.
The connection to practice.
The technical article on five AKS clusters describes Argo CD, ApplicationSets, Kustomize and Helm in practice. The Wigo4it case provides the context of that experience.