GitOps in practice: the future of Kubernetes deployments

GitOps turns your Git repository into the control point for your cluster: the repo declares what should be running, and an agent inside the cluster works continuously to make it so. This covers how it works, the four principles behind it, and how to set up a minimal pipeline.

The term GitOps was coined in 2017 by Alexis Richardson, then CEO of Weaveworks, for a pattern his team already used: describe the whole system declaratively, keep that description in Git, and let automation continuously reconcile the running system to match.¹ Nearly a decade later it is the standard way many teams operate Kubernetes, because it turns deployment from a series of manual actions into a property of a version-controlled file.

01Git as the source of truth

The core idea of GitOps is that the desired state of your whole system lives in Git, and Git is the single source of truth. No one runs kubectl apply by hand against production, and no one changes things in a console. To change the cluster, you change a file in the repository and merge it. The cluster follows the repository, not the other way around.

This changes where changes originate, and the benefits follow from it. Every change is a commit, so you have a complete, attributed history of everything that ran. Every change is reviewed, because it is a pull request. Rolling back is git revert, and auditing is git log. The practices engineers already use for code now apply to infrastructure, because the infrastructure is described as code in a repository, which is what Kubernetes' declarative object model was built for.⁵

02The four principles of GitOps

GitOps is vendor-neutral, and the CNCF's OpenGitOps project reduced it to four principles that any real implementation should meet:²

1. Declarative — the entire desired state is expressed declaratively, as what should be true rather than a script of steps.
2. Versioned and immutable — that desired state is stored so it is versioned and immutable, with a full history. Git is the natural place, but the principle is the point.
3. Pulled automatically — software agents pull the desired state from the source, rather than having changes pushed in from outside.
4. Continuously reconciled — agents continuously compare actual state to desired state and correct any drift.

OpenGitOps reaching 1.0 in 2021 mattered because it gave the industry a shared, tool-independent definition: GitOps as a set of principles rather than a specific product.³

03Push versus pull

Traditional CI/CD pushes: a pipeline runs, authenticates into the cluster, and applies changes from outside. GitOps pulls: an agent running inside the cluster watches the Git repository and applies changes from within.² This matters for two reasons. In the pull model, your CI system never needs cluster-admin credentials; it only needs to write to Git, which removes a commonly breached class of secret from the pipeline. And because the in-cluster agent is always watching, it does not just apply changes at deploy time; it keeps the cluster matching Git and undoes manual drift. The repository is not only a deploy trigger; it is the state the cluster is held to.

04Argo CD and Flux

Two mature, CNCF-graduated tools cover most GitOps on Kubernetes, and either is a solid choice:⁴⁶

• Argo CD presents GitOps as an application-centric system with a web UI that shows each application's desired versus live state and its sync status. Teams that want a clear dashboard often start here.⁴
• Flux is a set of composable controllers (the GitOps Toolkit) that fits a Kubernetes-API and command-line workflow and slots into automation. Teams that prefer building blocks over a bundled UI often prefer it.⁶

They solve the same problem with different ergonomics: Argo CD leads with a UI, Flux with composability. Choose based on how your team works. Both are graduated projects with large communities.

05A minimal GitOps pipeline

The smallest real GitOps loop has a few parts. You keep your Kubernetes manifests in a Git repository, install a GitOps agent (Argo CD or Flux) in the cluster, and point it at that repository. From then on, each change follows this flow:

1. Edit a manifest in the repo (e.g. bump the image tag).
2. Open a pull request; a teammate reviews and merges it.
3. The in-cluster agent detects the new commit and pulls it.
4. The agent reconciles the cluster to match the repo.
5. The agent keeps watching and reverts any manual drift.

# You never run kubectl against production. You merge to Git,
# and the cluster converges on what Git says.

That is the whole model. Adding environments means adding directories or branches, promoting a release is a merge, and the agent handles the rest. Because reconciliation is continuous, a successful deploy is a state the agent maintains rather than a single moment.

06Rollbacks, drift, and disaster recovery

Continuous reconciliation is what makes GitOps a resilience strategy rather than only a convenience. Rollback stops being a special procedure: because every state that ran is a commit, reverting to a known-good version is a git revert, and the agent brings the cluster back to match.² Drift, such as someone hot-fixing production by hand, is detected and, depending on your policy, corrected automatically, so the cluster does not quietly diverge from what was reviewed. And disaster recovery becomes straightforward: if a cluster is lost, you provision a new one, point the agent at the same repository, and it rebuilds the declared state. Your recovery plan is the repository.

The main idea in GitOps is that a deployment is a state you declare rather than an action you perform. Once the cluster's job is to match a reviewed, versioned file, much of the usual operational drama becomes a merge.

07Where OcxlyDev lands

We treat Git as the control point for infrastructure and let an in-cluster agent do the reconciling, because it turns deployment, audit, rollback, and disaster recovery into practices we already use for code. Start small: one repository of manifests, one agent, one application reconciled from Git, then grow environments and workloads into the same loop. Which tool you pick, Argo CD or Flux, matters much less than committing to the four principles.² Declare what should be true, keep it in version control, and let the cluster work toward it. For many teams this is already how Kubernetes deployments are done.