Drive Continuous Delivery (CD) on Kubernetes With GitOps

DZone 's Guide to

Drive Continuous Delivery (CD) on Kubernetes With GitOps

In this article, learn how to use Argo CD, a GitOps continuous delivery tool for Kubernetes.

Free Resource

In software engineering, there’s always a new technology that everyone’s talking about:

  • Way back when everything started (around 2006), it was cloud computing.
  • In 2015, it was Kubernetes 1.0.
  • Next, everyone wanted to jump on the boat known as GitOps, which was first publicized by Weaveworks in 2017 in a blog by Alexis Richardson (Co-founder and CEO of Weaveworks, and chairman of the Cloud Native Computing Foundation (CNCF) Technical Oversight Committee (TOC)).
  • Most recently, on April 7, 2020, the CNCF TOC voted to accept the Argo Project (a set of Kubernetes-native tools for running and managing jobs and applications on Kubernetes) as an incubation-level hosted project. Part of the Argo Project is Argo CD, which provides support for declarative GitOps-based deployment of any Kubernetes resource.

At nClouds, we care about GitOps because we strive to use the latest and greatest technologies where they help our clients deliver innovation faster. It’s one of our core values at nClouds: Innovation culture that delivers client value. And we’re using Argo CD, a GitOps continuous delivery tool for Kubernetes.

Let’s dive into GitOps and learn how to set up GitOps principles using Argo CD.

What Is GitOps?

Weaveworks, the same company that developed  eksctl  (a command-line utility for creating and managing Kubernetes clusters on Amazon EKS), came up with the term “GitOps” to describe how they use developer tooling to drive operations.

Weaveworks describes GitOps as:

  • "An operating model for Kubernetes and other cloud-native technologies, providing a set of best practices that unify deployment, management, and monitoring for containerized clusters and applications.
  • A path toward a developer experience for managing applications, where end-to-end CI/CD pipelines and Git workflows are applied to both operations and development."

It works by using Git (a distributed version control system for tracking changes in source code during software development) as a single source of truth for declarative infrastructure and applications. “Declarative” means that the configuration is guaranteed by a set of facts instead of by a set of instructions. With Git at the center of your delivery pipelines, developers can make pull requests to accelerate and simplify application deployments and operations tasks to Kubernetes.

Why Use GitOps?

This paradigm is focused on the developer’s experience. The GitOps toolkit has a lot of advantages.

  1. It’s based on a single source for its state file and is based on a pull pipeline approach instead of the regular push pipeline.
  • "Most CI/CD tools available today use a push-based pipeline model, where the code starts with the continuous integration (CI) system and then continues its path through a series of encoded scripts to push changes to the Kubernetes cluster. That model has the potential to expose credentials outside of your cluster. While it’s possible to secure your CI scripts, youre still working outside the trusted domain of your cluster (which isnt recommended)."
  • "A pull pipeline does not expose your cluster credentials outside of your production environment. In this approach, a Kubernetes Operator (the runtime that manages a Kubernetes application) deploys new images from inside of the cluster. When a new image is pushed to the registry, convergence of the cluster state is triggered, the new image is pulled from the registry, the manifest is automatically updated, and the new image is deployed to the cluster."
  1. Cluster state is inside a Git repository. Using Git commit history, engineers can view current deployment and change history. Caveat: If YAML manifests syntax or object reference breaks, then deployment using the GitOps tool will also break.
  2. You can roll back by using simple  git reset  commands. All old states remain available for deployments. Caveat: GitOps tools continuously poll Git repo. You need to make sure you have an adequate polling allowance from your provider.
  3. Git access control policies also apply to deployments. For example, there’s an option in Git for only a few users to have permission to push to the master branch. With this access control, a few people are given access to deployment, and others can request a change using a pull request.

How Is GitOps Different From Infrastructure as Code (IaC)?

While GitOps is a workflow for CD pipelines, IaC is a pattern, rather than a specific workflow.

"IaC has a lot of different meanings that have been implemented in a variety of ways. In contrast, GitOps is a prescriptive style of IaC best practices for the cloud-native era. It builds on and combines:

  • Orchestration of delivery — coordinated by the deployment and release automation system and triggered by updates to repos.
  • Observability — the source of truth for the actual running state of the system in production.
  • Declarative IaC (described above).
  • Containers and immutable infrastructure — prohibiting modification to a running server unless the server is completely replaced with a new instance that contains all the necessary changes.
  • DevOps best practices — cloud-native implementation, management, and monitoring.

Caveat: There’s a set of specific requirements you need to follow to determine whether this new paradigm suits your company or not. Take a look at the principles of GitOps below, according to the creators of the concept."

Principles of GitOps

The four GitOps principles enable organizations to achieve faster and more secure deployments, whether you’re recreating applications for infrastructure failover or deploying the new version in the same environment. Weaveworks describes these principles as follows:

  1. "The entire system described declaratively. Kubernetes is one example of many cloud-native tools that are declarative, can be treated as code, and provide a single source of truth. Apps can be easily deployed and rolled back to and from Kubernetes, and if disaster strikes, your clusters infrastructure can also be dependably and quickly reproduced."
  2. "The canonical desired system state versioned in Git. With the declaration of your system stored in a version control system, and serving as your canonical source of truth, you have a single place from which everything is derived and driven. For rollbacks, you can use a git revert  command to go back to your previous application state. You can use your SSH key to sign commits that enforce strong security guarantees about the authorship and provenance of your code."
  3. "Approved changes can be automatically applied to the system. You don't need cluster credentials to make a change to your system. Theres a segregated environment and the state definition lives outside of it, so you can separate what you do and how you're going to do it."
  4. "Software agents to ensure correctness and alert on divergence so your entire system is self-healing — not only when nodes or pods fail (handled by Kubernetes) but also in case of human error. Software agents act as the feedback and control loop for your operations."

What Is Argo CD?

One of the ways to set up GitOps principles is by using Argo CD, a part of the Argo Project. Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. It has a nice user interface and makes delivering, shipping, and maintaining cloud-native applications more accessible — you no longer need to remember commands for deployment and monitoring of an application. Later on in this blog, we’ll provide a step-by-step tutorial on how to use Argo CD.

Why Use Argo CD?

With Argo CD, you’re building a developer-centric experience that lets DevOps worry about the state of the cluster, and developers control the state of their application in a way that’s most efficient for them.

Think of Argo CD as rules for GitOps that provide infrastructure stability and application reliability. It’s a Kubernetes controller that continuously monitors the applications running on the cluster, comparing them to the state defined in the target state Git repository. If there’s a difference, it will mark an application as ‘OutOfSync.’ There’s an option to sync running applications with target Git repositories both manually or automatically.

Key Features of Argo CD:

  • History and rollback to any application configuration in the target Git repository
  • Automatic deployment of an application to a Kubernetes cluster
  • Management and deployment to multiple clusters
  • User interface with a real-time view of an application
  • Hooks that support deployment strategies (Argo Rollout, canary, and blue-green strategies can be implemented)

Setting up GitOps Principles Using Argo CD

To use Argo CD to deploy or update Kubernetes resources, begin by pushing manifests on a Git containing all the necessary infrastructure. It can either be a simple image version change or deployment of a new application.

Prerequisites of setups:

  1. Install Argo CD. As shown below, we have installed Argo CD on Amazon EKS. Argo CD services and application resources live in a newly created  argocd  namespace.

  1. Install Argo CD CLI. On a Mac, Argo CD CLI can be installed using Homebrew, as shown below.


brew tap argoproj/tap
brew install argoproj/tap/argocd

  1. Access Argo CD API Server. By default, the Argo CD API server is not exposed over the Internet. In the beginning, port forwarding is the simplest way to access a server. In a separate terminal, run the following command:


kubectl port-forward svc/argocd-server -n argocd 8080:443

  1. Credentials of an Argo CD server. The default username of the server is ‘admin.’ The initial password of Argo CD is auto-generated to the initial pod name of the Argo CD server. The initial password of the Argo CD API server can be retrieved using this command:


kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o name | cut -d'/' -f 2

  1. Log in to the server using CLI. Username  admin  and the password retrieved above are used to log into the Argo CD Server. Then, you can change its password:

  1. Deploying an application. Using Helm, install NGINX ingress controller.


helm install nginx-ingress stable/nginx-ingress

  1. Now, you can create the Argo app based on the nClouds repo. We used the following CLI commands with the nClouds repo:


kubectl create namespace argo-cd-demo
argocd app create argo-cd-demo --repo https://github.com/nclouds/argo-demo.git --path . --dest-server https://kubernetes.default.svc --dest-namespace argo-cd-demo --sync-policy automated

Other GitOps Tools

While the toolkit for GitOps is growing continuously, the central elements are the control agents inside your Kubernetes cluster:

  • Flux, a CNCF Sandbox project since August 15, 2019, is a tool that automatically ensures that the state of your Kubernetes cluster matches the configuration youve supplied in Git.
    • Uses an operator in the cluster to trigger deployments inside Kubernetes, which means that you dont need a separate continuous delivery tool.
    • Monitors all the container image repositories that you specify. It detects new images, triggers deployments, and automatically updates the desired running configuration of your Kubernetes cluster — and does so within the bounds of a configurable deployment policy.
  • Jenkins X, launched in 2018, has capabilities to promote the environment via GitOps, and it implements CI/CD pipelines. For a serverless approach, Jenkins X implements GitOps strategy using:
    • Tekton Pipelines (a Kubernetes extension that defines a set of Kubernetes Custom Resources acting as building blocks to assemble CI/CD pipelines).
    • Prow (a Kubernetes-based CI/CD system that provides job execution), includes GitHub automation in the form of policy enforcement, chat-ops via /foo commands, and automatic pull request (PR) merging.

Every team gets various environments. Then, Jenkins X manages the environments and handles the promotion of new versions between environments. It can also spin up Preview Environments (those created on a PR basis, before you merge your PR changes into the master so that you can get fast feedback).

In Conclusion

If the following are essential to you, we recommend that you use GitOps for your Kubernetes deployment as:

  • A version control system (to house all information, documentation, and code)
  • Operational workflow management
  • An audit trail
  • An easy way to revert to your previous application state
  • A single source of truth

And if you want to have continuous delivery and the ability to monitor applications continuously on a Kubernetes cluster, then we recommend that you use Argo CD.

ci/cd ,continuous delivery ,devops ,devops implementation ,gitops ,kubernetes ,kubernetes implementation ,kubernetes tools ,kubernetes tutorial ,tutorial

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}