[DRAFT — AWAITING APPROVAL]
GitOps for Production Kubernetes
Declarative delivery, drift detection and auditable change for production clusters.
GitOps uses a Git repository as the source of truth for the desired state of your systems. An agent in the cluster continuously reconciles the live state to match it.
Core principles
- Declarative: the system is described, not scripted
- Versioned: every change is a commit with history and review
- Pulled: an in-cluster agent such as Argo CD or Flux applies changes
- Reconciled: drift is detected and corrected continuously
Why it suits production
Changes go through pull requests, so review and audit come built in. Rollbacks are a revert. Cluster credentials stay inside the cluster rather than in CI systems.
Practical design choices
- Separate application code repositories from environment configuration
- Promote changes between environments through explicit commits
- Manage secrets with tools such as External Secrets or Sealed Secrets, never plain text in Git
- Combine with progressive delivery (for example Argo Rollouts) for safer releases
Common pitfalls
Manual kubectl changes that fight the reconciler, sprawling repository structures and unclear ownership of shared configuration. Agree on conventions early.