Best of 2022: GitOps: The Missing Link for CI/CD for Kubernetes
As we close out 2022, we at Container Journal wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.
GitOps has emerged as an essential process as organizations evaluate frameworks to optimize CI/CD on Kubernetes. DevOps teams are exploring how GitOps redefines CI/CD, with Git serving as the central, immutable state declaration for faster deployments and more audit-friendly secure environments. GitOps offers teams well-documented improvements in productivity, security, and compliance, which ultimately translate into a better experience for the user.
Multiple Teams, One Git
The use of Git as a version control system—usually with GitHub or GitLab—is the cornerstone of GitOps. That’s why it is increasingly considered essential for CI/CD. A number of Git superlatives accurately describe how GitOps serves as a consolidated and cohesive way of managing and operating cloud-native infrastructure applications: “Git is where everything lives,” “Git provides a single source of truth,” and so on. Through GitOps’ declarative processes, Git also lends itself well to Kubernetes, since Kubernetes clusters are also managed in a declarative way—in other words, it’s all in the YAML.
Git serves as the immutable state declaration for CI/CD cloud-native environments. This state declaration is automated. It is reconciled continuously through controllers and represents the current state of an application running on Kubernetes clusters. In this way, developer teams’ pull and merge requests are all done on Git—with audit trails remaining for all changes. The testing and security teams will continue to do their checks, making any needed modifications and creating pull requests on Git. From Git, only those with permission can apply the code to the declared state of the Kubernetes cluster.
Observability for All Stakeholders
Since application and infrastructure configuration remains in its immutable state on Git, the CI/CD process is observable to all team members. The developer can create pull requests, but they can also monitor deployments during the CD stage—usually with read-only access. If there is a problem, the developer can access the repository, make a change and commit it for deployment directly. In a more restrictive environment, the developer would need to alert the operations team that the change from Git must be completed.
Thanks to Git’s audit capabilities, which includes a trail of all changes made to the configuration, DevOps can either release the application or roll it back to the original state—even once deployed—by using Git commands to replace an error-prone version. The ability to roll back to a known stable version can reduce mean-time-to-recovery (MTTR) to minutes in most cases, even when managing a platform with thousands of clusters. The GitOps software agent or controllers will then reconcile the application to a known working state. The entire process is observable by the developer and operations teams in Git.
CI/CD Control
In a large organization, it is rare for a single CI/CD pipeline to handle the deployment of all projects. Different projects can be located in separate Git repositories, for example, while some teams—often spread around different geographic locations—may work on a number of projects with their own CI/CD pipelines. The distributed nature of today’s DevOps teams is another example that highlights the value of GitOps, as that one central and immutable source of truth for all distributed teams.
With the Git repository serving as the focal point, not every team member requires access to the entire infrastructure. This is especially important for production environments running on Kubernetes clusters, and can be further enforced with GitOps permissions that are namespace-scoped.
In many ways, GitOps creates an additional layer of control that replaces and automates kubectl command line access. Access to kubectl commands to create, deploy and manage clusters can—and should—be strictly controlled via RBAC policies.
Of critical importance is how declarative changes are applied to the Kubernetes-controlled configuration in an automated fashion. As the immutable source of truth, an alert is issued when changes are made to cluster configurations and applications running in production. In other words, everything that is in Git should be running in the same way in the Kubernetes cluster, including the way the cluster or clusters are configured.
Namespaces are typically assigned to delineate development workspaces, as opposed to the production workspace. For the operations team members, namespace permissions enable access to ingress controllers, service meshes and RBAC access to make changes during CD in a cluster.
The Great GitOps Takeaway for CI/CD
The conceptual part of GitOps to support CI/CD for Kubernetes is fairly straightforward. In addition to the complexities of configuring and managing Kubernetes clusters, the support of CI/CD through GitOps—the “missing link”—also necessitates a careful selection of tool choices. In other words, the right tool or platform is usually required for the adoption of GitOps, unless the DevOps team opts to create its own platform, which is not recommended. The use of Git as a central repository alone is thus not enough to initiate proper GitOps processes.
Tried-and-tested tools for creating and managing applications for Kubernetes exist, but can fall short for GitOps support. Many, if not most, DevOps teams rely on open source Jenkins for CI on Kubernetes, for example, as part of the production pipeline. But Jenkins—while a worthy tool for CI—was not designed to provide a number of features that GitOps usually requires. Deploying commits with Jenkins scripts means that DevOps cannot roll back releases. It also does not offer other GitOps functionalities such as RBAC, full audit trails and many version control features.
Open source alternatives created specifically for GitOps CI/CD on Kubernetes are worthy of investigation. As a GitOps Kubernetes operator, for example, open source Flux is emerging as a mainstream platform supporting CD for the production pipeline, including post-deployment cluster management in all the ways described above.
For a more opinionated Flux experience, open source Weave GitOps Core simplifies the first steps to automate CI/CD across multiple clusters. The process of setting up a GitOps process with Weave GitOps Core should involve just a few simple commands on the console.
In conclusion, GitOps can support CI/CD for Kubernetes deployments in key ways. But while relying on Git as the central repository is necessary, the use of it alone for GitOps is not enough. This is why open source tools created specifically for CI/CD—such as Flux and Weave GitOps Core—are required to support the missing link that GitOps offers CI/CD.