GitOps at its core is all about employing a common Git repository to enable IT teams to more consistently employ infrastructure-as-code (IaC) using the same processes used to deploy application code. The application programming interfaces (APIs) exposed via Kubernetes clusters that are now being more widely deployed are making it lot easier to now achieve that goal some five years after the initial GitOps concept was first proposed in 2017. IT organizations, of course, can embrace GitOps without Kubernetes but just like peanut butter and jelly they are generally going to be much better together.
Kubernetes clusters enable IT teams to deploy applications in the cloud or in an on-premises IT environment using a consistent set of application programming interfaces (APIs). One of the issues that has made continuous delivery (CD) difficult for most organizations to achieve is that prior to the arrival of Kubernetes every platform had its own unique set of low-level APIs that needed to be invoked to deploy software on that platform. Kubernetes can be deployed anywhere so it becomes much simpler to automate application delivery.
In addition, there is also a cluster lifecycle management API (CAPI) that provides a standard declarative definition format and a set of installers and reconciliation agents for Kubernetes clusters along with a Cluster API for Existing Infrastructure (CAPEI) that enables IT teams to leverage tools such as Terraform to install Kubernetes cluster management tools on pre-provisioned machines without requiring a central management cluster.
GitOps, meanwhile, is essentially a more opinionated approach to DevOps that relies on an instance of the open source Git repository as the single source of truth about the environment rather than a set of application or server configuration files. One of the most widely employed tools deployed alongside a Git repository and Kubernetes is provided by the open source Flux project, which monitors the state of a cluster to make sure it always matches the IaC code stored in a Git repository. Flux has already been downloaded more than one billion times and can be used alongside a Kubernetes operator, dubbed Flagger, to trigger application deployments without requiring IT teams to acquire and deploy a dedicated CD platform.
GitOps, of course, can be applied beyond Kubernetes clusters, but as organizations transition to building and deploying cloud-native applications, there is a significant amount of correlation between the adoption of Kubernetes and GitOps workflows. In fact, as organizations embrace GitOps many are finding it more advantageous to allow separate teams in their organizations to manage workflows across continuous integration (CI) and CD systems in a more loosely coupled fashion rather than relying on an integrated continuous integration/continuous delivery (CI/CD) platform. While CI/CD platforms have been around now for more than a decade few organizations have been able to truly automate the delivery of applications using those platforms so a case can be easily made for adopting a dedicated CD platform that is specifically fit for that purpose.
Two examples of how to employ GitOps include “recreate” or “rolling updates.” The recreate strategy ensures that old Kubernetes pods and new pods don’t overlap. Rolling updates ensure some pods remain available during the update to ensure the service stays up and running. The only challenge is that the old and new data stores or clients must be able to work with both versions of the pods. Other more advanced deployment patterns are known as “blue-green” where two versions of the application exist but only one is live at any given time and a “canary” deployment strategy creates new pods in parallel with the existing one to minimize any problems with the new version to a subset of users.
It’s not precisely clear to what degree organizations are deliberately adopting GitOps either. Some IT teams are simply finding more efficient ways to deploy applications on Kubernetes clusters using the APIs provided only to discover they have adopted a new methodology for deploying applications. Regardless of how organizations discover GitOps, however, its apparent the way applications are provisioned and deployed in the age of Kubernetes is now fundamentally changing for the better.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.
