GitOps is an operating model in which a system’s desired state is declared, versioned, and continuously reconciled with the running environment. Kubernetes is a natural fit because its API is already declarative: users submit desired resource definitions and controllers work to make actual state converge toward them.

This topic supports the cloud-native application delivery concepts behind the current KCNA certification and the wider Linux Foundation certifications path. GitOps is not merely “put YAML in Git.” The defining behavior is an automated reconciliation loop that continuously compares desired and observed state.

GitOps starts with declarative desired state

A declarative system describes what the end state should be rather than listing every command needed to reach it. Kubernetes manifests fit that approach: a Deployment says how many replicas and which Pod template should exist, while controllers determine the operations needed to make that true.

GitOps extends the same idea to delivery. The desired application and platform configuration is stored in a versioned source of truth. An automated agent observes that source and the target environment, then works to reconcile differences.

This is fundamentally different from a script that runs a sequence of imperative commands once and exits. Reconciliation continues after deployment, so unexpected drift can be detected and, depending on policy, corrected.

The OpenGitOps principles define the model clearly

OpenGitOps describes four core principles: desired state is declarative; desired state is versioned and immutable; software agents pull the desired state automatically; and agents continuously reconcile actual state toward it. These principles are a better test of GitOps than the brand name of any specific tool.

Git is a common source of truth because it offers reviewable history, commit identity, branching workflows, and immutable commit objects. The broader principle is versioned desired state with complete history. GitOps practices can therefore be discussed independently of one controller implementation.

The “pulled automatically” principle is especially important. A GitOps controller normally runs with access to the target environment and pulls approved desired state. This reverses the common CI pattern where an external pipeline holds cluster credentials and pushes changes directly.

CI and GitOps have different responsibilities

Continuous integration still has an important role. CI can compile code, run tests, scan dependencies, build a container image, sign the artifact, and publish it to a registry. GitOps begins when the desired deployment state references the approved artifact and the reconciliation controller applies that state to the environment.

Keeping these responsibilities separate reduces the number of systems that need direct deployment credentials. A build pipeline can produce artifacts without also holding broad cluster access. The GitOps controller can be given narrowly scoped permissions appropriate to the resources it manages.

There are valid variations, but the architectural question should remain explicit: which system is authorized to change desired state, and which system is authorized to reconcile the cluster?

Reconciliation changes how teams think about drift

In a one-time deployment model, a manual production change can persist indefinitely because no automation notices it. In GitOps, the controller repeatedly compares live resources with declared desired state. A manual edit can therefore show up as drift and may be reverted automatically.

This behavior can feel surprising during an incident. An operator who edits a Deployment directly may see the GitOps controller restore the previous manifest. Mature teams define break-glass procedures for emergency intervention, including when reconciliation may be paused, how changes are recorded, and how the source of truth is updated afterward.

Drift correction is valuable only when desired state is trustworthy. A bad commit can be reconciled very efficiently, so code review, policy checks, and staged promotion remain necessary.

Packaging tools fit inside GitOps rather than replacing it

Teams rarely manage only raw YAML. Helm, Kustomize, and other tools can generate environment-specific resource definitions. Helm charts provide useful packaging context, but a Helm chart by itself is not GitOps.

GitOps requires a source-of-truth and reconciliation model around that package. A controller can render or apply a chart and continuously compare the resulting desired configuration with the cluster. The package defines resources; the GitOps system defines how approved state reaches and stays aligned with the environment.

Keep rendering behavior reproducible. Pin chart or dependency versions where appropriate, review generated changes, and avoid hidden mutable inputs that make the same Git commit produce different desired resources later.

Promotion should move approved state, not rebuild surprises

A reliable promotion workflow makes it clear which artifact moves from development to staging and then production. Rebuilding the application independently in each environment can produce different binaries even when the source revision is the same. A stronger pattern promotes an immutable artifact reference and changes environment configuration through reviewable commits.

Image digests are useful because they identify immutable container content. Git commits can then record exactly which image digest an environment should run. If a release needs to be rolled back, the desired-state repository can be changed back to the previously approved artifact and configuration.

Rollback is still an operational change, not magic. Database migrations, external APIs, and irreversible state changes can make an old application version incompatible. Git history provides configuration reversibility; application architecture determines whether the whole system can safely reverse.

Secrets need a separate design

Putting plaintext credentials into a Git repository is not made safe by calling the workflow GitOps. Desired state often needs references to secrets, but the secret material should be protected through an appropriate secrets system, encryption workflow, or secret-delivery mechanism.

The Git repository can hold encrypted secret objects, references, policy, or metadata depending on the design. The controller and decryption components should have narrowly scoped access, and repositories should be treated according to the sensitivity of what they contain.

Auditability is one of GitOps’ strengths, but it also means history persists. Accidentally committing a credential and then deleting it in a later commit does not erase the secret from repository history. Rotation is required if sensitive material is exposed.

Multi-cluster GitOps requires clear ownership boundaries

As organizations add clusters, the desired-state structure needs to distinguish shared platform components from environment-specific configuration. A single controller with unrestricted access to every cluster can become a large blast radius. Multiple controllers or carefully scoped identities can provide stronger boundaries.

Repository structure should reflect operational ownership rather than an arbitrary folder convention. Teams need to know who can approve platform changes, who owns application configuration, which environments a controller can reconcile, and how cluster-specific differences are expressed without uncontrolled duplication.

Broader Kubernetes fundamentals are useful background because GitOps automation ultimately creates and updates normal Kubernetes resources whose runtime behavior must still be understood.

Healthy GitOps makes every environment explainable

A well-run GitOps environment answers simple questions quickly: what should be running here, which commit requested it, who approved that change, which artifact is deployed, and is the live cluster currently converged with that state? Those answers are more valuable than merely installing a popular controller.

Measure reconciliation health, failed syncs, drift, controller permissions, and source availability. Test what happens when the source is temporarily unreachable or when a bad change is committed. Operational resilience matters because the GitOps controller becomes part of the delivery control plane.

The durable model is declarative, versioned, pulled, and continuously reconciled. When those properties are present, GitOps can reduce configuration drift and make Kubernetes delivery more auditable. When they are absent, storing manifests in Git is simply version control, not a complete GitOps operating model.

Policy can be placed around the desired-state change before reconciliation begins. Pull requests can run schema validation, security policy checks, image-verification checks, and environment-specific tests. The GitOps controller then applies only state that survived those gates. This does not eliminate runtime policy, but it moves many failures earlier in the delivery process where feedback is cheaper and safer.

GitOps also makes ownership visible when repository permissions and approval rules mirror operational responsibility. A platform team can own cluster-level controllers and policies while application teams own namespaced workloads. Changes can require different reviewers depending on path or environment. The repository becomes a record of intent, while the cluster remains the execution environment. Keeping that boundary clear prevents emergency kubectl access from quietly becoming the normal deployment mechanism.

Recovery planning should include the GitOps control plane itself. If the controller is unavailable, the running workloads usually continue, but desired-state changes and drift correction stop. If repository credentials expire or the source is unreachable, reconciliation can fail even though the cluster is healthy. Teams should monitor controller health, repository access, sync status, and reconciliation latency so a delivery-control outage is detected before the next urgent release depends on it.

For beginners, the easiest way to recognize genuine GitOps is to ask whether the live environment is continuously reconciled from reviewed desired state. If operators must run a deployment command to make every change happen, the process may still be Git-backed CI/CD, but it is not following the full pull-and-reconcile model. This distinction prevents tool vocabulary from obscuring the operating principle.

That is the practical distinction for Kubernetes teams. A mature GitOps workflow also defines how emergency manual changes are reconciled afterward, so break-glass actions do not become permanent undocumented configuration.