GitOps with Kubernetes
What is GitOps?
--
GitOps is a continuous delivery paradigm (coined by Weaveworks.) Designed around Kubernetes, it allows developers to use a familiar tool, namely Git, for cluster management and application delivery. The core idea of GitOps is having a Git repository that always contains declarative descriptions of the infrastructure currently desired in the production environment and an automated process to make the production environment match the described state in the repository. If you want to deploy a new application or update an existing one, you only need to update the repository — the automated process handles everything else. It’s like having cruise control for managing your applications in production.
GitOps workflow for Kubernetes
GitOps can be considered an evolution in IaC that uses Git as the version control system for infrastructure configurations. IaC often follows a declarative approach to infrastructure management by defining the desired state of the system and tracking the system’s actual state. As with IaC, GitOps requires you to declaratively describe the desired state of the system. By using declarative tools, all of your configuration files and source code can be version controlled in Git.
As in figure 0.1 work flow of gitops shown well each steps describe below,
1- Application Repository:
GitOps organizes the deployment process around code repositories as the central element. There are at least two repositories: the application repository and the environment configuration repository. The application repository contains the source code of the application and the deployment manifests to deploy the application. The environment configuration repository contains all deployment manifests of the currently desired infrastructure of an deployment environment. It describes what applications and infrastructural services (message broker, service mesh, monitoring tool, …) should run with what configuration and version in the deployment environment.
2- Built pipeline :
with GitOps you have a clear separation between CI and CD. Your CI pipelines stay as is and their end result is still an artifact and/or container that is stored in a binary repository. Once the artifact is created, GitOps takes over and applies it to the target cluster. Instead of triggering the CI/CD with a commit in the source code, with GitOps the trigger is a commit to the configuration repository.
3- Image registry & Environment repository:
When using GitOps with Kubernetes, the operator will often be a Kubernetes Operator. The operator compares the desired state in the repository to the actual state of the deployed infrastructure. The operator will update the infrastructure whenever a difference is noticed between the actual state and what exists in the repository. The operator can also monitor a container image repository and make updates in the same way to deploy new images.
4- Deployment pipeline & Security :
Gitops 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.
BENEFITS OF GITOPS:
Most existing processes for infrastructure configuration management face challenges like failed deployments, poor infrastructure design, server outages, etc. GitOps will help to deal with these common challenges.
1-Lack of configuration consistency — even with centralized configuration, the actual configuration and a declared one can alter and change with manual processes.
2-No idea how an application is running or where — this sometimes entails a full-scale investigation to determine state and configuration of infrastructure.
3-Failed deployments relying on a disaster recovery strategy — disaster recovery requires a strict process, typically with manual processes, which isn’t always reliable. This results in unplanned downtime that affects customers and hurts developer productivity.
4-Missing documentation — it can be difficult to figure out how some applications were built and who managed them.
5-Relying on previous state for success — this can be unpredictable, which affects the stability and state of a project.
6-Built-in auditing history — when you use Git to manage Kubernetes clusters, you gain a complete audit log of all changes to the cluster originating outside of Kubernetes with a full audit trail of who changed what. This enables consistent operations and supports compliance.
7-Greater visibility on the lifecycle of developed features — GitOps provides a consistent model for infrastructure and application changes across the organization. Development processes are visible and fully reproducible through Git.
8-Improved security — Git provides strong guarantees on correctness and security, with strong cryptography used to manage changes and verify authorship. This dramatically improves security and means that CI systems are no longer a threat vector for production systems.
CONCLUSION:
Developers already use Git for the source code of the application. GitOps extends this practice to an application’s configuration, infrastructure, and operational procedures. You can handle multiple environments or clusters with GitOps. A common pattern would be to deploy to a staging environment first for running load testing or integration testing. This is an extra layer of reliability, making sure there are no issues with the deployment prior to Production.
