GitOps - delivering automated deployments in Kubernetes

Despite GitOps being a relatively new methodology for delivering software application deployments in cloud-native environments, organisations, large and small, have started to adopt GitOps as their preferred approach to application deployment on Kubernetes. 

Bcorp Logo

To log or to log

GitOps is a relatively new methodology for delivering software application deployments in cloud-native environments; that's both, installs and updates. The coining of the term has been attributed to Alexis Richardson, the CEO of the cloud-native company, Weaveworks. Back then in 2017, 'GitOps' had a very loose definition, but ultimately described a system of management that involved:

  • Controlled storage of declarative configuration, that describes the desired state of the system
  • Detection of the difference between observed system state and desired state, and
  • The means to automatically reconcile system state to the desired state

On the face of it, this approach to application deployments has a lot of synergy with the way that Kubernetes gets things done. Kubernetes requires developers to describe how their applications are going to run, using declarative configuration that defines the various API objects; Deployments, Services, Ingresses, NetworkPolicies, and so on. It also uses control loops to drive the system towards the desired state expressed by the API resources.

But back in 2016, this nascent approach had little rigour or formalism. Thankfully, the GitOps community has come a long way since those early days. Collaboration has enabled the community to coalesce around a formal meaning of the term GitOps, whilst competing open source projects have created tools that implement the principles associated with GitOps. Meanwhile, organisations, large and small, have started to adopt GitOps as their preferred approach to application deployment on Kubernetes.


The OpenGitOps project is an initiative that seeks to provide a reference for GitOps, in terms of its meaning, its promotion as a methodology, and as a source for education and best practices. It's vendor neutral, and is governed by the GitOps Working Group, a part of the Cloud Native Computing Foundation (CNCF).

So, what is GitOps, and what characterises a system that is managed the GitOps way? Helpfully, OpenGitOps defines a core set of principles that describes how GitOps should be applied to a system.

GitOps - delivering automated deployments in Kubernetes

Adopting these principles provide a GitOps adopter with a number of potential benefits:

  • A common understanding of the intended desired state - no more disagreements between teams, and in teams, with regard to the intended desired state of the system. The stored configuration acts as a single source of truth.
  • Effective and controlled management of change - through the use of the inherent permissions, privileges and authorisation mechanisms built into version control systems, such as GitHub or AWS CodeCommit, change to the desired state can be carefully managed and audited.
  • Rollback and disaster recovery - when problems occur, as they often do, rolling back to a known good version can be achieved by reverting to a previous git commit. And, if it's necessary to recreate the entire system, its desired state is ready and waiting in the versioned storage system.
  • Secure deployments - in a Kubernetes setting, the GitOps agent runs inside the cluster and fetches the desired state, before applying it from within the cluster. This means Kubernetes access credentials are not required outside of the cluster boundary, reducing the risk of credentials leakage.
  • Elimination of configuration drift - the continuous reconciliation of the observed and desired state, mitigates the consequences of any unsolicited change applied by well-intentioned or reckless actors. The system is returned to a state that reflects the desired state as held in the versioned storage.

    GitOps Tooling

    Sometimes in the software industry it's difficult to say what came first; the tool that pioneered a methodology, or a methodology that produced a pervasive tool(s). With GitOps, it's definitely a mixture of both. The two main GitOps tools in the Kubernetes domain are Argo CD and Flux, each of which has implemented the GitOps principles, but also informed their definition.

      Argo CD

      Argo CD is part of a wider family of open source tools that exist under the 'Argo' umbrella, whose aim is to make it easier to run and manage workloads on Kubernetes. The Argo projects are maintained by a number of different companies, including Red Hat, but Argo was originally formulated by Intuit.

      GitOps - delivering automated deployments in Kubernetes

      Argo CD was introduced in 2018 to fix a requirement to allow for the rapid, reliable deployment of hundreds of microservices across a fleet of Kubernetes clusters. Since its introduction, it has matured, adapted, and evolved into a mature GitOps solution. It has been adopted by literally hundreds of organisations, both large, and small. It consists of an API server for administering Argo CD, a repository server for fetching the desired state and 'hydrating' Kubernetes resource abstractions (e.g. Helm charts), and an application controller for reconciling state. Amongst a number of other features, Argo CD also supplies a web UI for visualising and controlling Argo CD in its management of applications.


      Flux is the other popular GitOps solution, and is a collection of tools that interoperate to provide a GitOps solution. Perhaps as a testament to the way that the GitOps discipline has evolved, Flux first appeared in 2017, gained a sizeable following, but has subsequently been rewritten from the ground up. Flux v2 has been implemented using a modular approach, and incorporates many of the lessons learned from the early adopters of Flux v1, and the general maturing of the GitOps discipline.

      GitOps - delivering automated deployments in Kubernetes

      Each of the different toolkit components that Flux is comprised of, uses custom resources to describe the facet it manages. For example, the source controller works from GitRepository and HelmRepository resources in order to know where to fetch the desired state from. And, the kustomize controller works with Kustomization resources in order to generate and apply the Kubernetes configuration to the cluster.

      Whilst Flux has yet to reach the status of general availability, it already has a large number of commercial adopters.


      When configured well, GitOps tools can bring great benefits to organisations wanting to speed up application delivery by automating deployments. But a word of caution; technology alone doesn't solve a problem. To properly realise the benefits of GitOps, an organisation must also have a mature CI/CD capability for application delivery, with the internal processes and team responsibilities clearly mapped out. Without this, you'll be pouring petrol on the fire with GitOps. However, once an organisation has matured its workflow, and established clear lines of responsibility, GitOps has the ability to turbocharge application delivery on Kubernetes.

      Would you like to know more?

      If you found this article interesting you might be interested in our GitOps Training Course.

        Share this post on:

        We would love to hear from you

        Get in touch

        or call us on 020 3137 3920

        Get in touch