🔭A Guide to the Essential Concepts and Terminology of GitOps

Hello, and welcome to your Aiden's Lab Notebook.

GitOps is a keyword that continues to gain attention in the DevOps industry. GitOps is a DevOps methodology where all necessary information, from application code to infrastructure configuration, is stored and managed in a Git repository.

As various concepts and terms within GitOps have been established recently, I thought it would be helpful to organize them clearly for you. So, I'm going to compactly summarize the essential concepts of GitOps.

To provide you with practical and structured information about GitOps, this article has been structured with reference to the curriculum of the CNCF's Certified GitOps Associate (CGOA) certification. This should also be useful for those preparing for the certification, right?

I've broken down and clearly explained five key topics related to GitOps below. By the time you finish this article, you'll have a solid foundational knowledge of GitOps.

1. Core Principles of GitOps

2. GitOps-Related Terminology

3. GitOps Deployment Patterns

4. GitOps-Related Methodologies

5. GitOps-Related Tools

Core Principles of GitOps

To understand GitOps, we first need to go over its four core principles.

1. Declarative Management

The first major principle of GitOps is to define the final state of a system as source code, or in other words, declaratively. Unlike a procedural approach that describes 'how' a system should reach a desired state, this approach specifies 'what' state it should be in.

The YAML files that define Kubernetes resources, which are familiar to us, are a prime example of this declarative approach. GitOps manages the system based on this declared final target state.

2. Version Control

The next major principle is version control. In GitOps, all information about the final target state that the cluster should be in (also called the Desired State) is stored and managed in a Git repository.

This means that the final state of the cluster defined by the user is stored and changed only in the Git repository. To put this in more professional terms from design theory, 'Git serves as the Single Source of Truth (SSoT)'. This means that the only real information the system can reference is managed in one place: Git.

This Desired State is recorded in the Git history with each version, along with commit messages. This makes it easy to track and manage when, why, and how a particular state changed. If a problem occurs after a modification, it's also easy to safely Rollback to a previous state.

3. Pull-Based Automation

Pull-based automation starts from the difference between the update method of traditional Continuous Deployment (CD) and that of GitOps.

The CD pipelines we're familiar with use a push-based approach, where changes are pushed to the cluster. In contrast, GitOps uses a pull-based approach, where an agent like Argo CD or Flux installed inside the cluster pulls the latest state from the Git repository. This is a significant difference from traditional DevOps methods, which is why pull-based automation is called a major principle of GitOps.

Moreover, the pull-based approach reduces potential security risks because it doesn't require granting cluster access credentials to systems located outside the cluster (e.g., a CD pipeline). This has the effect of making the cluster's boundary clearer and reducing the attack surface.

4. Continuously Reconciled

The final core principle of GitOps, continuous reconciliation, refers to the constant process of adjusting (Reconcile) the cluster's actual state (Actual State) until it matches the final target state defined in Git (Desired State).

GitOps agents like Argo CD or Flux within the cluster continuously compare these two states. If a discrepancy occurs (as we'll mention later, this state discrepancy is called State Drift), they detect it and can automatically reconcile it.

This process of continuous reconciliation is the core mechanism that ensures the cluster's consistency and stability.

GitOps-Related Terminology

You might have come across some unfamiliar terms while I was explaining the core principles of GitOps. So, let's go over four key terms you need to know in GitOps.

1. Desired State

The cluster's Desired State is the final target state defined by a developer or administrator. In GitOps, this specifically refers to the final target state defined as code in a Git repository.

Since it's managed in a Git repository, the change history of the Desired State can naturally be managed and tracked.

All activities in GitOps aim to align the cluster's actual state with the Desired State.

2. State Drift

State Drift is a phenomenon where the Desired State declared in the Git repository does not match the current actual state of the cluster. State Drift can occur for various reasons, such as manual code changes by an administrator, configuration errors, or unexpected failures.

GitOps agents like Argo CD or Flux continuously detect such drift and either correct it or send alert notifications to the user.

3. Feedback Loop

The 'repetition of reconciliation' mentioned in the last core principle of GitOps is an actual implementation of the Feedback Loop concept.

A Feedback Loop means continuously measuring the actual state of the cluster, comparing it with the Desired State, and controlling the cluster in a direction that reduces the difference. This ensures that the cluster maintains a stable state even when external changes or internal errors occur.

4. Rollback

When a problem occurs in the cluster and it needs to be reverted to a previous state, GitOps can perform a Rollback very effectively.

Since the Desired State is managed in Git, it's not difficult to change it to point to a previous commit using commands like git revert or, depending on the situation, git reset.

When a Rollback like this occurs, the GitOps agent detects the change and automatically restores the cluster to that version, enabling fast and stable failure recovery.

GitOps Deployment Patterns

There are various deployment patterns that can be used in the GitOps methodology. Let's take a compact look at four of the core GitOps deployment patterns.

1. Deployment and Release Patterns

• Environment-per-Branch Pattern

  • This approach involves operating separate Git branches for each deployment environment, such as development (dev), staging, and production (prod).

  • Changes are typically merged via Pull Requests in order from dev to staging, and then from staging to prod.

  • The advantage is that the state of each environment can be clearly isolated and managed.

• Environment-per-Directory Pattern

  • Instead of using multiple branches, this approach manages configurations by creating directories for each environment, such as overlays/dev and overlays/prod, within a single main branch.

  • It works by using tools like Kustomize to overlay environment-specific changes on top of a common base configuration.

  • The advantage is that it can reduce the complexity of branch management.

• App of Apps Pattern

  • This pattern is useful for deploying and managing a large number of microservices or applications.

  • It involves having one parent application that manages multiple child applications.

  • It's commonly used with tools like Argo CD and has the advantage of being able to manage the deployment of complex systems centrally and consistently.

2. Progressive Delivery Patterns

• Canary Deployment Pattern

  • This approach involves releasing a new application version to only a small subset of users first.

  • It can be implemented by changing traffic weights (e.g., stable: 90%, canary: 10%) in the manifest files of the Git repository.

  • The advantage is that it allows for verifying the stability of the new version with real traffic, minimizing risk.

• Blue/Green Deployment Pattern

  • This approach involves deploying a new version (Green) in an environment identical to the currently running version (Blue), and then switching traffic all at once.

  • In a GitOps environment, this can be implemented by modifying the manifest in Git to change the traffic routing target to the Green version.

  • The advantage is that it enables safe, zero-downtime deployments, as traffic can be immediately switched back to the Blue version if a problem occurs.

3. Pull vs. Event-driven

The Pull-based approach we looked at earlier checks for changes in the manifests within the Git repository at a set interval. In contrast, the Event-driven approach starts synchronization when a specific event occurs.

For example, when a new commit is pushed to the Git repository or a new version of an image is registered in an image registry, a GitOps agent can be made aware of these changes via a Webhook.

Therefore, the Event-driven approach allows for faster feedback and more rapid deployments.

4. Architectural Patterns

In GitOps architecture, it is recommended to manage the repository containing the application source code and the repository containing the k8s manifests that define the application's deployment method separately.

This approach, based on the principle of Separation of Concerns, helps development teams focus on application code and operations teams focus on deployment and operations.

Additionally, it is advantageous for security as access permissions to the manifest repository can be managed more strictly.

GitOps-Related Methodologies

At this point, looking at other methodologies deeply related to GitOps can help us understand GitOps more effectively. So, this time, let's look at four major methodologies related to GitOps.

1. Configuration as Code (CaC)

CaC is a methodology for managing the configuration of infrastructure or applications as scripts or source code files. GitOps enables CaC by clearly defining application configurations as code using Kubernetes manifest YAML files and versioning them with Git.

By combining GitOps and CaC, updates to various configurations, from application deployment versions to resource requirements and environment variables, are left as Git commits, making it possible to transparently track and review changes for stable operations.

2. Infrastructure as Code (IaC)

IaC, a methodology for managing infrastructure like VMs or networks as code, can also be easily realized in GitOps.

If you store and manage infrastructure code created with IaC tools like Terraform or Pulumi in a Git repository and track its change history, you can develop and manage your infrastructure code more stably, right?

That's why GitOps and IaC are often used together.

3. DevOps and DevSecOps

GitOps promotes collaboration between teams by allowing developers to participate in deployment just by pushing code to a Git repository, and enabling cluster operators to clearly understand the entire deployment status through Git. Ultimately, GitOps can be seen as a methodology that implements DevOps based on Git.

Furthermore, security checks like static analysis or vulnerability scanning can be easily included in an automated pipeline based on Git Pull Requests. Access control and branch protection rules in the Git repository can also strictly control who can change cluster components. Therefore, GitOps also makes it possible to realize a DevSecOps culture that considers security from the early stages of development.

4. Continuous Integration (CI) and Continuous Deployment (CD)

Let's talk about CI and CD in GitOps.

In a GitOps workflow, the main roles of a CI pipeline are to build the application source code, run unit/integration tests, and create a deployable image from the application configuration to push to an image repository. The responsibilities of CI in GitOps are clearly defined in this way. In other words, the CI pipeline does not directly deploy the application to the cluster.

In GitOps, the role of CD is handled by the GitOps agent running inside the cluster. For example, if a developer updates a Kubernetes manifest managed in a Git repository, the GitOps agent detects that change and deploys the new Kubernetes resources to the cluster.

In this way, the external CI pipeline does not need to access the cluster in GitOps, which is advantageous from a security perspective as it reduces the attack surface for infiltrating the cluster.

GitOps-Related Tools

You've worked hard to get here. For the final section of this article, let's look at some GitOps-related tools. You might even see some familiar ones.

Manifest Formatting and Packaging

Formatting refers to changing the content of a file into a desired format. Manifest formatting refers to the task of converting the content of a manifest file into a format desired by the user.

When you need to change the content of a Kubernetes manifest YAML file for each environment, manually modifying the manifest file every time the environment changes is a lot of work and prone to errors. Manifest formatting tools have emerged to solve this problem. Kustomize is a prime example.

Kustomize helps you deploy by changing the content of a base YAML file to match different environments like dev, staging, and prod. We've covered Kustomize before, so if you're curious about its core concepts and a hands-on guide, check out this article.

Applications deployed on a Kubernetes cluster are often composed of various Kubernetes resources. If you need to share such an application for deployment on another cluster, should you manually move the manifest YAML files for its component resources? You could, but wouldn't it be more convenient if you could bundle the manifest files into a single unit for sharing? This is the problem that led to the emergence of manifest packaging, and a representative tool is Helm.

Helm is also known as the Kubernetes package manager. Just like Pip, which we use to install libraries when developing in Python, Helm helps you easily download Kubernetes applications stored remotely and deploy them to your cluster.

The content of the resource manifest files for Kubernetes applications shared with Helm is not fixed but templated to allow for specific values to be inserted. This is an advantage as it allows the same application to be easily deployed with different configurations depending on the cluster or environment.

In a GitOps workflow, you can make the change history recording and tracking easier by storing and managing the cluster/environment-specific configuration values referenced by Kustomize and Helm in Git.

State Store System

The core system that stores and manages the cluster's Desired State is called the State Store. You might have guessed it already, but in GitOps, the State Store is a Git repository.

Because it allows for tracking change history and collaboration through Pull Requests, Git is an excellent choice for a State Store. Another advantage is that it's intuitive to use because it doesn't require a separate database or state management system.

Reconciliation Engine

The core components of GitOps, the reconciliation engines, are representatively Argo CD and Flux.

Argo CD provides an intuitive web UI that allows you to see the deployment status, synchronization status, and resource relationships of an application at a glance. It also offers features for centrally managing multiple Kubernetes clusters. It supports the App of Apps pattern we looked at in the GitOps deployment patterns.

Flux is composed of a set of independent components called the GitOps Toolkit. Its characteristic feature is its flexibility, as users can choose to install only the necessary features for their GitOps implementation.

It's a tool that primarily manages Kubernetes clusters in a terminal environment and aims for close integration with the Kubernetes ecosystem. It's a suitable tool for users who prefer a more minimalist approach compared to Argo CD.

Interoperability with Notifications

Most GitOps tools offer integration with various notification channels like Slack, Microsoft Teams, and email. This means that when events like a successful application deployment, State Drift detection, or a synchronization failure occur, the responsible person can be notified in real-time.

Thanks to this interoperability with notification tools, teams can quickly become aware of the cluster's state and take necessary actions.

Wrapping Up

In an increasingly complex and sophisticated cloud environment, GitOps is becoming a good best practice for developers who want to achieve both maintainability and structure. That's why I thought introducing it to you would be helpful when you need to make decisions related to cluster deployment in the future.

So, I've compiled a comprehensive summary of the essential concepts and terminology for understanding GitOps. I hope this has given you a solid grasp of GitOps.

If this article has sparked more interest in GitOps for you, I recommend looking into the differences in how Argo CD and Flux each implement GitOps. You'll gain a deeper understanding of how GitOps is used, beyond just the theoretical knowledge.

I'll be back with another interesting topic in the next article. Thank you.

✨Enjoyed this issue?

How about this newsletter? I’d love to hear your thought about this issue in the below form!

👉 Feedback Form

Your input will be help improve Aiden’s Lab Notebook and make it more useful for you.

Thanks again for reading this notebook from Aiden’s Lab :)