GitOps: desired-state reconciliation through the platform API

OpenGitOps defines four properties: desired state is declarative, versioned and immutable, pulled automatically, and continuously reconciled. Git is evidence of intent; the cluster API, controllers and runtime health are still required.

Complete path

CI builds and signs an immutable image, then proposes its digest in the config repository. The GitOps reconciler pulls that revision and submits resources to the Kubernetes API server, where authorization and admission apply. Deployment and rollout controllers also read and write Kubernetes resources through the API server; they do not directly mutate Pods or Services.

Argo CD phases and waves order resources and wait on health. A sync success is not proof of application correctness, so canaries use explicit readiness, metric analysis, promotion/abort rules and alerts. Repair Git after an abort so continuous reconciliation does not reintroduce a rejected release.

Failure semantics

Self-heal can restore declared fields after drift, but it cannot infer whether an emergency mutation should become the new intent. Preserve the incident, choose commit-or-revert, then reconcile. During Git unavailability, keep the last known resources, alert desired-state staleness, and avoid destructive conclusions based on an unavailable source.

Scenarios

Sources

• OpenGitOps principles
• Argo CD sync phases and waves
• Argo CD architecture
• Argo Rollouts concepts