GitOps delivery
With GitOps, Git is the single source of truth for what runs in your clusters. A controller watches Git and keeps the cluster matching it. Deployments become pull requests, rollbacks become reverts, and every change is reviewed and recorded.
Release, fail, and drift
Release a new version and watch pods update one at a time with no downtime. Lose a server and watch Kubernetes replace its pods. Then make a change directly in the cluster, bypassing Git, and watch the controller put it back.
How a change reaches production
- A developer opens a pull request that changes the image version or configuration.
- Automated checks run: policy tests, configuration validation, security scans.
- A reviewer approves and the change is merged.
- The controller applies it to the test environment, then to production after promotion.
- If something goes wrong, the commit is reverted and the controller rolls back.
Good practice
- Separate application code from deployment configuration, usually in different repositories or folders.
- Promote between environments through Git, not by rebuilding images.
- Keep secrets out of Git. Use External Secrets with Vault or a cloud secret store, or encrypted Sealed Secrets.
- Turn on self-healing and pruning carefully, starting with non-production clusters.
Typical tools
| Area | Common choices |
|---|---|
| Controllers | Argo CD, Flux |
| Packaging | Helm, Kustomize |
| Secrets | External Secrets Operator, HashiCorp Vault, Sealed Secrets |
| Progressive delivery | Argo Rollouts, Flagger |
More Kubernetes guides: Platform design · Security · Multi-cluster and on-prem · Kubernetes FAQ · Use case: festive-season scale
Planning a Kubernetes platform, or fixing one?
Tell us how many applications and teams you have, how you deploy today and where it should run. We will come back with an honest view: whether Kubernetes fits, what a lean platform looks like, and what it takes to run.