GitOps with Kubernetes: Why It’s Different and How to Adopt It

What Is GitOps?

GitOps is a paradigm that modernizes software management and operations by allowing developers to declaratively manage infrastructure and software code using a single source of truth, typically a Git repository. 

GitOps involves expressing the desired state of the software declaratively and storing its state in a repository. This repository retains a complete trail of changes, providing version control, auditing, and visibility over deployments and environments. It requires setting up software agents to automatically pull the desired state from the repository. These agents continuously observe the actual system state and apply the desired state.

GitOps with Kubernetes

GitOps treats each software or infrastructure component as one or more files located in a version control system, with an automated process to synchronize state between version control and the runtime environment. An orchestration system like Kubernetes is very important for achieving this. Without Kubernetes, the overall infrastructure can be too complex to manage, with multiple, incompatible technologies. These issues often present an insurmountable challenge for efficiently implementing infrastructure-as-code (IaC) processes. 

Kubernetes helps address these issues and has influenced the evolution of IaC practices. The growth of Kubernetes enabled the creation of tools for implementing GitOps.

Traditional vs. GitOps Deployments for Kubernetes

Kubernetes fully supports declarative APIs as the key mode of operation, providing the necessary backend framework and controller patterns for implementing these APIs. This system builds on declarative specifications leading to eventual convergence and consistency, which facilitates GitOps.

Kubernetes differs from traditional systems because it uses the concept of immutability – APIs cannot modify resources in the environment, only declare how new resources should be instantiated. For instance, no API can modify only the container image while leaving the rest of a pod unchanged. Every Kubernetes API request expects a full manifest of the resources to be deployed. 

This decision intentionally denied users access to convenience APIs, forcing Kubernetes users to use a declarative approach. This creates a need for a place to store declarative configurations. Git repositories are the natural option for storing such specifications, making GitOps a logical delivery tool for deploying manifests from Git.

Avoiding Configuration Drift

Configuration drift has been an issue long before the emergence of Kubernetes, affecting traditional VM-based production deployments. When multiple machines have different configurations, they may fail to function properly, especially when a CI/CD platform updates distributed targets. 

In some cases, developers test applications in a staging environment before deploying them to production. If the staging environment does not match the production environment perfectly, the tests may be ineffective. For example, an application might perform well in the staging environment but fail under real-world conditions once deployed to production. Configuration drift is one of the major reasons for deployment failures.

With Kubernetes, teams often modify clusters with ad-hoc edits outside the CI/CD system. This ad-hoc approach increases the risk of configuration drift. Over time, this configuration drift can make it harder to keep track of changes to each machine. 

One way to address this issue is to use a tool like Argo CD, which establishes a single source of truth (in this case, Git) for all deployments. DevOps teams often struggle to understand the cause of a failed deployment without a unified CI/CD process controlling all changes. Git tools can also help developers track who deployed what on each cluster and when. 

With Argo CD, every deployment is traceable to the Git repository, so the Git commit history serves as the deployment history. It ensures that all updates go through the approved CI/CD channel. When it detects differences between the state in the Git manifest and the live cluster, Argo CD marks the deployment as OutOfSync, preventing configuration drift from the start.

Related content: Read our guide to GitOps

GitOps and Kubernetes with Argo CD

Argo CD is a Kubernetes GitOps operator from the Argo open source cloud native tooling project family. Argo offers various tools to run and manage cloud native applications and jobs on Kubernetes. Together with additional Argo tools like Workflows, Events, and Rollouts, Argo CD enables application delivery for Kubernetes native applications, providing a complete solution when an organization has adopted containers and moved to Kubernetes deployments.

The GitOps methodology offers clear benefits for large-scale deployments. However, implementing it across large organizations often requires additional tools and services. For example, a large enterprise with thousands of developers running hundreds of microservices in the cloud and on-premises cannot expect each team to run and manage its own cluster in Kubernetes. 

An effective solution is to implement a centralized platform to operate and maintain multi-tenant clusters for the entire organization. This approach still gives end-users the capabilities and flexibility to manage their own workloads within a cluster. 

Argo CD can help implement this unified approach to cluster management, enabling GitOps adoption. The following are some additional considerations for an efficient GitOps strategy in Kubernetes:

  • Onboarding—the user onboarding process should be simple, allowing multiple microservices to move to Kubernetes. There should be one central team to handle these responsibilities rather than expecting each team to install, set up, and maintain a deployment operator. Integrating SSO is especially helpful when the system has thousands of users, making it easier to introduce new users to the service.
  • Multi-tenancy and management—users of multi-tenant environments require flexible, secure access to distributed resources. Kubernetes offers a powerful built-in role-based access control (RBAC) system, but this may not be sufficient for managing access to hundreds of clusters. A continuous deployment solution like Argo CD can add access control functionality, providing seamless integration with single sign-on (SSO) providers and facilitating user access to multiple clusters. 
  • Observability—an effective CD tool must enable developers to observe and track the state of their managed applications. ArgoCD offers an intuitive UI that provides insights into the configuration of an application—this is important for providing quick access to information such as whether the application is in sync with Git, which specific elements are out of sync, and if something is broken. 

Some organizations try to implement their own in-house solution that satisfies their requirements, but this is more challenging for larger enterprises. Adopting Argo CD can thus be a better approach. 

There are two important concepts to understand when using Argo CD: 

The Application

The Argo CD Application is a logical grouping of resources in Kubernetes, defining the source and destination of a resource manifest. The source contains a repository URL and a repository directory. 

Not every directory contains a plain YAML file, although some may contain several. Rather than enforcing a specific configuration management tool, Argo CD offers strong support for multiple tooling options. A directory might contain, for example, a Helm chart definition as YAML or a set of Kustomize overlays.

The application destination is the target deployment location for the resources in a group. It contains an API server URL belonging to the target cluster and the name of the Namespace. 

The URL specifies the Kubernetes cluster to host the deployment of all application manifests. Application manifests can be deployed across multiple clusters, although it is best to deploy separate applications in separate clusters. The Namespace name specifies the Namespace for each Namespace-level resource.

Argo CD Applications essentially act as a mapping between the application resources found in Git and a target cluster where the resources should be deployed. 

The Project

An Argo CD Project is a logical grouping of Applications. It provides isolation between teams, enabling each team to fine-tune access control within the Project. While Applications offer a flexible, independent management strategy for specific teams, Projects help support large systems where multiple teams have varying access levels. 

Without Projects, each team may require separate Argo CD instances. The more instances created, the greater the management overhead, so this is not ideal. Another issue is that individual users can escalate their own privileges to gain full access to a cluster via the GitOps operator. 

By arranging Applications into Projects, organizations can avoid confusion and reduce human error. Argo CD adds a layer of abstraction with the Project concept—Projects can separate application sets for easier management. This approach restricts the Git repositories and Kubernetes clusters that a Project can use. It also restricts the Kubernetes resources that each Application can deploy within a Project.

Learn more in our detailed guide to Argo for Kubernetes

Codefresh: The Kubernetes GitOps Platform Powered by Argo

Codefresh is a complete software supply chain to build, test, deliver, and manage software with integrations so teams can pick best-of-breed tools to support that supply chain. Codefresh unlocks the full enterprise potential of Argo Workflows, Argo CD, Argo Events, and Argo Rollouts and provides a control-plane for managing them at scale.

Codefresh provides the following key capabilities:

Single pane of glass for the entire software supply chain

You can easily deploy Codefresh onto a Kubernetes cluster, run one command to bootstrap it, and the entire configuration is written to Git. By integrating Argo Workflows and Events for running delivery pipelines, and Argo CD and Rollouts for GitOps deployments and progressive delivery, Codefresh provides a complete software lifecycle solution with simplified management that works at scale.

Built on GitOps for total traceability and reliable management

Codefresh is the only enterprise DevOps solution that operates completely with GitOps from the ground up. Using the CLI or GUI in Codefresh generally results in a Git commit. Whether that’s installing the platform, creating a pipeline, or deploying new software. The CLI/GUI simply acts as extended interfaces of version control. A change to the desired state of the software supply chain will automatically be applied to the actual state.

Simplified management that works at scale

Codefresh greatly simplifies the management and adoption of Argo. If you’ve already defined Argo workflows and events, they will work natively in Codefresh. Codefresh acts as a control plane across all your instances – rather than many instances of Argo being operated separately and maintained individually, the control plane allows all instances to be monitored and managed in concert.

Continuous delivery and progressive delivery made easy

Those familiar with Argo CD and Argo Workflows will see their configurations are fully compatible with Codefresh and can instantly gain value from its enterprise features. Those new to continuous delivery will find the setup straightforward and easy. The new unified UI brings the full value of Argo CD and Argo Rollouts into a single view so you no longer have to jump around between tools to understand what’s going on.

The World’s Most Modern CI/CD Platform

A next generation CI/CD platform designed for cloud-native applications, offering dynamic builds, progressive delivery, and much more.

Check It Out

How useful was this post?

Click on a star to rate it!

Average rating 5 / 5. Vote count: 1

No votes so far! Be the first to rate this post.