Blog>>Operations>>GitOps>>GitOps — which tools should you choose?

GitOps — which tools should you choose?

In today's fast-paced tech landscape, software development teams are constantly seeking new ways to improve efficiency and speed up the release process. GitOps has emerged as a powerful way to streamline the software delivery process. As GitOps tools have quickly become a go-to solution for many organizations, it is essential to research the right tools to meet your project needs and requirements.

In this article, you will find an overview of some of the GitOps tools on the market and their key features highlighted. Overall, this guide will help you make an informed decision about which GitOps tool is right for your organization. 

What is GitOps? 

GitOps is an alternative technique of continuous deployment (CD) of infrastructure and modern cloud-native applications which brings important advantages to the table. It uses the Git repository as a single source of truth. It also utilizes GitOps agents responsible for the continuous synchronization of deployed systems to the desired state expressed declaratively in Git.

Fig.1: General principles of GitOpsSource: GitOps      link-icon
What is GitOps

When should you start using a GitOps tool?

Implementing a GitOps deployment tool can bring important benefits. If you experience one or more situations presented in the following table you should seriously think about GitOps. 

ProblemBenefits of GitOps usage
Many clusters - Increased number of application deployment environments and deployment strategies causing additional complexity of CI/CD pipelines.Separation of configuration and deployment - Application CI/CD pipelines are no longer responsible for the deployment. Deployments are performed by GitOps agents. For each K8s cluster deployments are described in the form of declarative schemas. Those files are stored in the Git repository and monitored by GitOps agents.
Undetected deployment drifts - Application is running with the wrong version or the application settings are different than they should be, especially after manual interventions in the environment or failed deployments.Desired state - GitOps agents constantly compare the declarative description of the infrastructure/application against the actual state, which is monitored by the GitOps agent, and reconcile any differences from the desired state.
Lack of deployment transparency - New team members cannot easily learn WHERE, WHEN and WHAT is deployed, nor HOW to change selected elements of the deployment.Single source of truth - All deployments are stored within a single Git repository. Developers and infrastructure engineers can cooperate smoothly.
Slow platform provisioning - Development teams frequently require new clusters for product feature testing, canary testing or problem debugging but platform provisioning is a manual or semi-manual process.Infrastructure as code - Application infrastructure descriptions can be also added to the Git repository (or stored in a dedicated repository). GitOps agents can deploy new cloud resources, new K8s clusters and required services within those clusters.
Difficult to replicate - Developers have a hard time debugging a problem when it requires a successful replication of a very specific version of the entire system, consisting of a large number of microservices and other types of elements with very specific configuration sets.Version controlled - All changes to the infrastructure and application are in Git history. The developer declares what they need using configuration files from the past. Everything is done by developers using a very well-known tool (Git) and following well established procedures (Merge Requests).
Lack of multi-tenancy - Single-cluster applications deployment, created by different teams using independent repositories and CD processes, causes deployment burden and unpredictability.Multi-tenancy support - Platform team maintain GitOps and support multiple application teams (each team can have its own Git repositories). A GitOps tool provides team separation and security using K8s role-based access control, single sign-on, and internal policy mechanisms, as well as external policy enforcement tooling.

Tab. 1 Problems addressed by GitOps

Check out our other related articles:

Git in GitOps

Declarative manifests need to be stored and versioned somewhere. Currently, there is only one king in this area - Git      link-icon. Git offers very fast branching and merging and extensive functionality. As a result, many hosting solutions have been developed around GitHub      link-icon, GitLab      link-icon and BitBucket      link-icon, for example. These Git providers offer an extensive UI for managing the repository and related functionalities like CI/CD pipelines.

There is no important difference in which Git hosting is used for GitOps. All most popular Git providers are equally good for integration with GitOps tools. The cooperation between the GitOps agent and the Git provider may work in many ways:

  • The GitOps agent reads the repository via a generated access token (or Git credentials, which is less secure),
  • The Git provider may provide the user identity for the GitOps tool - this is a way to establish single sign-on for GitOps users,
  • The Git provider’s CI pipelines may call GitOps webhooks in order to notify the presence of a new commit and this way greatly speed up GitOps pull-based deployment workflows,
  • The GitOps tool can also use the Git provider notification webhooks in order to update the commit status visible for developers or platform operators with information about resource reconciliation performed by the GitOps tool.
Fig.2: Deployment info received from a GitOps tool is visible on GitHub (left) and GitLab (right).
Git in GitOps

If you are looking for new ways to use Git repositories, we invite you to check out our precious article about Git commands

Git is not always the only source of truth

GitOps tools have been improved over time and more extensive functionality added. The interesting one is the ability to monitor the following non-Git repositories:

  • Helm repositories
  • S3-compatible buckets

Docker registries such as DockerHub      link-icon, GitLab      link-icon, Harbor      link-icon, JFrog      link-icon, Quay      link-icon, and AWS ECR      link-icon can perform the role of the Helm repository. These Helm repositories contain K8s manifests and Go templates bundled in special archives called Helm Charts. Helm Charts      link-icon are versioned in the Helm repository and the GitOps tool can use the Helm repository as the only source of truth. When a continuous integration process creates a new version of the Helm Chart (an application release) then the GitOps agent detects the change and updates the environment. However, a more flexible way is to use the Helm repository together with the Git repository. In that case the Git repository contains the configuration of the Helm repository for the GitOps tool and narrows the scope of possible changes, e.g. sets a semantic versioning limit for Helm Chart reconciliation. 

Object storage, like Amazon S3      link-icon, is also used to store the results of CI application builds. For this reason, the usage of S3 buckets, as the source of truth, can be found in some GitOps tools.

Why is Kubernetes used for GitOps?

The guiding principles of GitOps are not tied to a specific technology, however, a fully functional GitOps implementation (which fulfills all four principles      link-icon of GitOps) is only available using the Kubernetes platform. Kubernetes (K8s)      link-icon is an advanced resource orchestrator whose internal architecture contributed greatly to the birth of the GitOps concept.

The most crucial elements under the hood of Kubernetes are Resource Controllers      link-icon. Each of these controllers implements a control loop mechanism that is responsible for monitoring a specific type of K8s resource (e.g. Pod, Deployment, ReplicaSet) and ensuring that the state of the resource does not differ from the target state. In K8s, the target state of each resource is described declaratively by the user using YAML manifests. Resource target specification and actual resource status are bundled together in the form of abstraction called the resource object, which is the first class citizen of the K8s user interface.

The significant effectiveness of control loop and resource reconciliation in K8s is achieved using informers, work queues      link-icon and comparing a hash of a K8s resource object with a hash of the real resource state. Any change applied by the user to the resource object causes that K8s Controller is notified about the change and the configuration of the real resource is adjusted. The K8s Controller is also notified about change of real resource (i.e.: resource lifecycle state), the controller updates status of the resource object and that change is visible to the user.

Fig.3: Kubernetes controller reconciliation loop
Why is Kubernetes used for GitOps?

Another important characteristic of Kubernetes is its extensibility. This is possible thanks to the concept of operators      link-icon. An operator is a controller that manages a custom resource representing an entity residing inside or outside the cluster. For this purpose, an operator adds Custom Resource Definition      link-icon (CRD) as an extension to the Kubernetes API. The above-mentioned capabilities of K8s became the basis for the implementation of the first GitOps solution, called Flux. The Flux      link-icon operator is tied to a new type of custom resource called GitRepository      link-icon. When a GitRepository resource is added to K8s then Flux starts to monitor a given external Git repository, reads new or changed K8s manifest files from the repository, and applies the fetched manifests in order to create or update applications working in the cluster.

apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
  name: podinfo
  namespace: default
spec:
  interval: 5m0s
  url: https://github.com/stefanprodan/podinfo
  ref:
    branch: master

Lis. 1 GitRepository CDR in Flux GitOps tool

GitOps without Kubernetes

When there is no requirement for constant drift detection and configuration reconciliation for the deployed system then it is possible to implement limited GitOps. Limited GitOps doesn’t require Kubernetes as a runtime platform. It can be established using quite simple tooling, like git-repo-watcher      link-icon running in the deployment environment. Be aware that some custom scripting could be required. A Git watcher observes a Git repository. A new commit to the repository causes pulling upstream changes to the deployment environment and invocation of a custom deployment script. In the case of an infrastructure as code (IaC) use case, the custom script can invoke an IaC tool like Terraform      link-icon for the deployment.

Services DevOps

What GitOps agents are available?

Looking at the full-featured GitOps tools, only three solutions are worth comparing. The first is Flux      link-icon, which has existed since 2017. It is a very well-developed project where you will find features not available in other GitOps tools (e.g. support for Terraform or S3 bucket). The second tool is Argo CD      link-icon, which was created in 2018 and is currently one of the fastest adopted solutions      link-icon among all CNCF projects. These two solutions were developed as part of the LF CNCF open-source initiative and are categorized as graduated solutions      link-icon. The third tool is Fleet      link-icon and is being developed as of 2020 by Rancher      link-icon. It is not as extensive as its two older rivals, but it has all the most necessary GitOps functionalities.

CriteriaFlux Argo CD Fleet
Target usersPlatform operators. Development teams. Platform operators.
Main focusComposability      link-icon and extensibility      link-icon.Focused on user experience and UI.Managing very large groups of clusters.      link-icon
Runtime
platform
KubernetesKubernetesKubernetes
Supported K8s resources customizationsHelm and Kustomize      link-icon.
Flux can also natively manage and reconcile Terraform resources      link-icon.
Helm      link-icon, Kustomize      link-icon and Jsonnet      link-icon.Helm and Kustomize      link-icon.
Multi-repositoryYes      link-icon. Supports Git and Helm repositories. S3-capable buckets      link-icon can also be added as a repository.Yes      link-icon. Supports Git and Helm repositories. Also has the ability to specify multiple sources      link-icon for a single application.Yes. Supports Git and Helm repositories.
Multi-tenancy and tenant access controlYes      link-icon. Relies strictly on the RBAC capabilities      link-icon of Kubernetes.Yes. Isolation done by its own very granular permission system      link-icon which may restrict source repositories, destination clusters and namespaces.Yes. Namespace      link-icon-based. Together with Rancher provides great resource isolation. Relies on Kubernetes RBAC.
Multi-clusters Supported with usage of other tools like CAPI      link-icon or Karmada      link-icon.The concept of clusters      link-icon is directly supported by Argo CD. Very straightforward with ApplicationSets      link-icon. Scalable up to ~100 clusters.This is the main Fleet functionality. Fleet provides the concept of clusters and cluster groups      link-icon.
Fleet was designed to scale to many thousands of clusters. Such a scalability is achieved with an internal additional level of Helm repositories distributing bundles      link-icon.
Deployment pipelinesFlux Alerts       link-iconmay trigger external pipelines such as Github Actions      link-icon or Tekton      link-icon.PreSync, Sync, PostSync and FailSync      link-icon hooks that nicely integrate with pipelines (Argo Events      link-icon and Argo Workflows      link-icon or Tekton      link-icon) covering more advanced use cases.No.
Progressive deployment strategiesYes, using Flagger      link-icon.Yes, using Argo Rollouts      link-icon.With usage of additional tools      link-icon like Flagger.
Image update automationYes (Image Update Automation      link-icon).Yes (uses Argo CD Image Updater      link-icon).Yes      link-icon.
User managementNo. K8s service account       link-iconis used for Flux.Implements internal user/group management      link-icon.
Also single sign-on      link-icon authentication using OICD providers.
No. Based on K8s service accounts.
User InterfaceCLI first approach. WebUI possible after installation of Weave GitOps UI      link-icon.Yes. It gives a great overview of installed applications. It really shines in the case of a large amount of deployed K8s resources.CLI embedded only. Rancher provides a nice UI       link-iconfor Fleet.

Tab. 2 Full-featured GitOps tools comparison

Jenkins X - a tool with limited GitOps capabilities

Jenkins X      link-icon is a CI/CD solution running natively in Kubernetes. Jenkins X’s hot-feature is environment promotions      link-icon in which a separate repository is required for each supported environment. It offers very minimalistic GitOps capabilities      link-icon, e.g. no drift detection of K8s resources. After a new commit to a Git repository Jenkins X creates a new K8s Job to execute a user-created makefile which is supposed to update K8s resources (i.e. invoke kubectl/Helm commands).

Which GitOps agent to choose?

For those new to GitOps, the friendliest tool will be Argo CD. Its user interface will be very helpful. Infrastructure operators can start with Flux, its nicely-designed CDRs encourage usage of Kustomize. Rancher users may start with Fleet. It's also good to know that Fleet is the perfect tool for having an Argo CD deployed on all clusters! 

Which infrastructure as code tools can be used in GitOps?

GitOps is used not only to deploy applications and required services, but also for managing infrastructure based on the infrastructure as code (IaC) approach. IaC is the use of imperative code or declarative schemas to automatically create and configure infrastructure. Since infrastructure description code or schemas are placed in a Git repository, the use of GitOps for infrastructure management has become one of the most important use cases of GitOps. This greatly simplifies the work of development teams, which, using the Git repository, easily declare what infrastructure they need to run an application.

The best IaC tools to be used together with GitOps:

Crossplane

Crossplane      link-icon - provides a set of custom resource definitions      link-icon representing various external cloud resources (AWS, GCP, Azure, etc.) Adding a manifest with Crossplane CDRs to the Kubernetes cluster (adding may be done with a GitOps tool) causes the Crossplane K8s Operator to create declared resources in the external cloud and later monitor the health of the created resources. With Crossplane installed, Kubernetes becomes an orchestrator of external, non-Kubernetes resources.

Fig.4: Crossplane usage as part of GitOps
Crossplane gitops tools

Pulumi

Pulumi      link-icon - a collection of libraries for many general-purpose languages (Python, Go, C#, etc.) allowing development of code that manages cloud resources using language conditionals, loops, and variables. Pulumi is especially useful when management of cloud resources, services or even applications must be accomplished with more complex logic. Pulumi can be enabled for GitOps by the installation of pulumi-kubernetes-operator      link-icon in the cluster. 

Terraform

Terraform      link-icon - the most popular IaC solution created by HashiCorp      link-icon which uses an unique configuration language (HCL      link-icon). HCL is based on JSON and defines infrastructure resources to be created or modified. It currently contains 3000+      link-icon various infrastructure/resource providers. Terraform resources defined in HCL cannot be natively installed in Kubernetes thus its usage in K8s-based GitOps tools is problematic. However, Weaveworks has implemented the Flux Terraform controller      link-icon for Kubernetes. It supports both the desired state enforcement of Terraform resources as well as the drift detection required for automatic resource state reconciliation. 

Summary

Deploying a GitOps solution requires choosing a set of appropriate tools. Different tools cover different aspects of GitOps functionality. The selection of a range of appropriate tools must meet specific functional needs. Most of the mandatory elements of GitOps are briefly covered in this blog post, however some others, like deployment pipelines, progressive delivery, policy enforcement and secret management, would require dedicated articles to explain.

The table below summarizes the different categories of useful tools available within the Kubernetes platform for creating a fully-functional GitOps continuous deployment system.

GitOps continuous deployment functionTools performing the function
Repository of declarative manifests Git,
Helm repositories (DockerHub      link-icon, GitLab      link-icon, Harbor      link-icon, JFrog      link-icon, Quay      link-icon),
S3-compatible buckets (AWS S3      link-icon, Minio      link-icon, BackBaze      link-icon, Wasabi      link-icon)
Repository management and continuous integrationGitHub      link-icon, GitLab      link-icon, BitBucket      link-icon
User managementOICD providers (GitHub, GitLab, Octa      link-icon, OneLogin      link-icon, KeyClock      link-icon, Google      link-icon, Microsoft      link-icon, Auth0      link-icon)
Docker registryDockerHub, GitLab, Harbor, JFrog, Quay, AWS ECR      link-icon,
Orchestration platformKubernetes      link-icon
K8s resource customizationKustomize      link-icon, Helm      link-icon, Jsonnet      link-icon
GitOps agentFlux      link-icon, ArgoCD      link-icon, Fleet      link-icon, Jenkins X      link-icon
Deployment pipelineArgo Workflow & Events      link-icon, Tekton      link-icon, Rafay      link-icon, K8s Jobs      link-icon, GitHub Actions      link-icon, Spinnaker      link-icon
Infrastructure provisioningIaC (Crossplane      link-icon, Pulumi      link-icon, Terraform      link-icon)
Progressive deliveryFlagger      link-icon, Argo Rollouts      link-icon, Spinnaker      link-icon
GitOps monitoringPrometheus      link-icon, InfluxDB      link-icon, Grafana      link-icon
Policy enforcementPolicy as code (OPA      link-icon, Kyverno      link-icon, Datree      link-icon, jsPolicy      link-icon)
Secrets managementVault Secrets Operator      link-icon, Sealed Secrets      link-icon, Kamus      link-icon, Mozilla SOPS      link-icon

Tab. 3 Ecosystem of GitOps tools

Parniewicz  Damian

Damian Parniewicz

Senior Software Engineer

Damian Parniewicz is a Senior Software Engineer with nearly 20 years of experience. He specializes in networking technologies. His previous roles included network systems design, implementation and deployment, IT and network infrastructure provisioning, as well as problem solving for network protocols,...Read about author >

Read also

Get your project estimate

For businesses that need support in their software or network engineering projects, please fill in the form and we’ll get back to you within one business day.

For businesses that need support in their software or network engineering projects, please fill in the form and we’ll get back to you within one business day.

We guarantee 100% privacy.

Trusted by leaders:

Cisco Systems
Palo Alto Services
Equinix
Jupiter Networks
Nutanix