Adaptation of Git Ops Methodology in Container Deployment in Kubernetes Cluster of Enterprises

Overview

As per Cloud Native Computing Foundation (CNCF) survey, a large part of enterprises has adapted to Kubernetes for their application deployment orchestrator. They are running their production workload in k8s cluster. Kubernetes adaptation enables different ways for deployment of application containers. They offer several deployment strategies to manage a broad range of application development and deployment needs. Git-Ops offers a declarative approach of operations with all the benefits of Git style.

Container Deployments in Kubernetes

Kubernetes ‘deployment’ object, which provides a declarative way to deploy the application image, has all the information related to the number of instances to be created, which image to use, what label to put, and all the metadata of the app in the cluster.

There are different ways to deploy an application in Kubernetes or its enterprise offering e.g., Red Hat Openshift and all eventually creates the deployment object which introduces differences as different developers prefer different methods. With time, this leads to configuration drifts in the cluster. Therefore, it is very hard to track this in reverse chronological order.

Git Ops in a Nutshell

The name ‘Git Ops’ itself implies that it has something to do with Git and Operations. Since we are talking about IT, it is IT operations which generally creates infrastructure, install necessary software packages, maintaining security, deploy, and manage application life cycle and such others. Git is the methodology required to make things declarative and manage versions of every single change introduced in system, which can easily revert in future (if necessary). Git has many other useful features which are known to cloud developers as well. Therefore, to manage the operations mentioned above in a declarative manner and follow the Git process is called Git Ops.

Fig 1. GitOps-in-a-nutshell Source:VMware

Core Principles

The main principles of Git Ops are:

1. Infrastructure as Code: Everything about the system’s IT infrastructure must be managed as code in declarative which can be re-executed multiple times to create similar infra.
2. Git as the single source of truth: Any authorized user can sense system evolvement in chronological data following Git version logs. It is the single point of truth taking place in their IT.
3. Continuous deployment automation: Once the app is built, the workflow towards delivery/deployment in different environments must be totally automated and in declarative fashion which can be restored easily without manual touch in the destination environment.
4. Developer-centric approach: It is utilized to leverage tools and techniques that developers are friendly with. The core objective is to save developer’s time (as it is costly) and let them focus on the actual business logic development.

Since the context of this blog is deployment of application as container, so going forward application deployment means container deployment in k8s cluster.

The New Buzzword: Implementation of ‘GIT-OPS Automation’ in K8s cluster.

What Does Git Ops bring to the Table?

Utilizing Git Ops for continuous container deployment automation offers the following benefits:

1. Increase in developer’s productivity as they need not deploy containers manually. They must commit code in git repository and post this, successful app deployment process could be triggered automatically.
2. For any rollback to the earlier versions, they need not maintain any data as everything is now declarative and managed by the Git version.
3. Increased resiliency in app features as deployment is superfast and automated. Any new feature or bug fixes needs code push and relax.
4. Security index high as Git provides a single source of truth.
5. Consistency in process and operations.
6. Robust workflow in deployments as Git tracks and manages changes.
7. Sharing knowledge about workflow or understanding of current system state becomes easy as a new member can track everything at a single point instead of following up with different people.
8. Configuration changes in the application need not be done at cluster level. Thus, the developer does not need to learn k8 terminologies e.g., config map, route; instead, they can check their changes as code in some helm charts are stored in Git repository.

Probable Demerits of Git Ops

We must understand the probable demerits to decide whether Git Ops is a good fit for a particular environment or not.

Few disadvantages are listed below:

• Another control plane: To implement Git ops, another control plane is required which observes, compares, and remediates the differences between Git repository and cluster resource. Platform owners must analyze the cost benefits of owning a new license
• Increase in infrastructure resource bill: The installation and execution of control plane needs a Virtual Central Processing Unit (vCPU) and memory which attracts additional infrastructure cost. Platform owners must analyze the cost benefits of provisioning additional infrastructure
• Learn standardized workflow: In Git ops, all the deployment or other operations in k8s cluster are handled by yaml files and major control plane required this as helm charts. Thus, the developer group needs to learn to deliver their app/config in standardized helm chart format
• Not addressing the full development cycle: Git ops is addressing the challenges for container deployment phase and not addressing full software development life cycle

How Git Ops was implemented in Kubernetes Application Deployment Automation

We have used Helm chart for application manifest packages and stored them in application Git repository in separate branches. For Git, GitLab was used and hosted in a virtual machine (VM). We have installed ArgoCD in one of the clusters and registered our helm chart Git repository as source and cluster end points as destination clusters. ArgoCD provides the control plane which implements Git Ops methodology in container deployment by constantly observing the cluster state and comparing it with the defined state in Git. In finding differences, it remediates the changes in cluster to bring its state back to the defined state in Git.

Developers prepare deployment and configuration documents (generally yaml files), provide image source as image registry full path, and package everything as helm chart and commit in Git repository. In ArgoCD, there is a feature to enable auto sync or you can click sync button (if not auto enabled) which reads registered Git repository and senses the changes. It compares the same with cluster and executes everything to bring the cluster at the same state as defined in helm chart.

Fig 2: Git Ops CD illustrations

Conclusion

Since the Git Ops approach is relatively new, it is possible that there are gaps, and it will mature with time. In our lab exercise, we sensed that scaling it for enterprise-level helps save both time and cost. With rapid adaptation of Kubernetes, the enterprises need not plan to get their developers trained on k8s resourcing and deployments, but can utilize the existing skillset i.e., Git; however, they can leverage k8s deployment and cherish cloud-native benefits.