Automated GitOps With Flux

Introduction

While containers evangelized the software development life cycle, Docker and Kubernetes revolutionized the whole software industry as the new breed of cloud-native tools. The way software is built and shipped is not the same today. A lot more has changed over the last decade or so. Kubernetes has become the industry standard and de facto orchestration platform, and every enterprise is thinking of including it in their cloud-native stack. Application deployments on Kubernetes have also surged in numbers because of the fantastic features that it provides.

The software development and delivery have come a long way from agile methodologies to DevOps best practices to modern cloud-native approach called GitOps. GitOps is where we use Git as a single source of truth for all our Kubernetes-related deployments.

This article will talk about the later aspects of GitOps through Kubernetes and 'Flux' in particular.

What Is Flux?

Continuous integration and delivery form the crucial parts of modern cloud-native software development. CI/CD simplifies and automates the software deployment process in the organization that follows DevOps principles. So, naturally, when it comes to CI/CD, we always think that the code should be pushed either to a version control system or deployment environments for it to be generally available, but what if we try to do the opposite. So, instead of push, we pull; that's where Flux has a job to do.

In simple words, Flux is a GitOps operator for handling Kubernetes' continuous delivery. It is a powerful way to handle Kubernetes-related deployment practices securely.

Flux is here to help developers, DevOps, and platform engineers working with Kubernetes deployments to follow GitOps principles by assisting them to have a single source of truth for their deployment configuration.

How Does Flux Work?

Weaveworks created Flux CD and later open-sourced it to Cloud Native Computing Foundation (CNCF). Flux is a continuous delivery tool for Kubernetes workloads that allows IT teams to declaratively manage the Kubernetes deployments.

Flux is an operator, and it runs directly inside the cluster. Through Role-Based Access Control (RBAC), it is connected with a set of permissions. In the system and infrastructure managed by Git, Flux gets connected with your Git repos and starts watching all the changes done. Whenever a developer commits the code, Flux gets operated on the cluster to deploy the changes. No extra script or tool is involved here other than Flux to deploy the code.

Image source credits: Weave Flux Github Repo

One of the fantastic features of Flux is its automated coordination between version control (Git) and cluster. Whenever there are any changes made to the repository, such changes are automatically deployed to the cluster the GitOps way. 

Currently, Flux v1 is in maintenance and support mode, where no new and significant feature updates happen.

Flux V2

Flux is a tool, which helps Kubernetes clusters to synchronize with sources of configuration, and automate updates to configure when a new code is deployed. Flux v2 is built to use Kubernetes API extension system, and integrate with Prometheus, and other core components of the Kubernetes ecosystem. Flux V2 provides support to multi-tenancy and helps to synchronize an arbitrary number of Git repositories, between the long-requested features.

The idea of the original Flux was to ensure that the definitions in a Kubernetes cluster match the configuration provided in Git. Flux v2 delivers that premise with an up-to-date understanding of how Kubernetes applications are built and operated, which is useful for current operating procedures and tools. Flux v2 helps to synchronize multiple Git repositories. Flux v2 helps Kubernetes for operations and observability, with high capability

Flux V2 is based on a set of Kubernetes API extensions, which controls Git repositories and other sources of configuration applied into the cluster. For example, you can create a GitRepository object to mirror configuration from a Git repository, and then create a 'Kustomization object" to synchronize the configuration.

Flux V2 uses the Kubernetes role-based access to control, thus you can lock when any synchronization changes. You can receive notifications from systems, like Slack, when configuration is synced and ready, and receive webhooks to know when to synchronize. The flux V2 command-line tool is used to bootstrap the system in a cluster, and to access the custom resources that make up the API. The Flux V2 architecture has more accessible moving parts, which helps for the GitOps Toolkit.

Image source credits: Flux Docs

 The main goal of Flux V2 is automate deploying newly-built container images into our Kubernetes clusters, that powered the Software-as-a-Service (SaaS) Weave Cloud. Initially, the change was committed to Git after rolling an update of each ReplicationController. Then, GitOps came to use so that you can commit all the changes to Git. You can use some parted of the Kubernetes libraries, like Kubernetes API extensions, like CRDs (CustomResourceDefinitions)) and Helm controllers, to write your own controllers.

The foundation for Flux v2 is the GitOps Toolkit, which is a set of components for building GitOps-based delivery and automation. In the Flux V2 with GitOps Toolkit, there are distinct controllers that can run independently to perform functions, like mirroring Git, syncing Git, and image updating loops. For example, the kustomize controller controls the git source controller, and updates when there is a new revision available. Flux v2 is built with the GitOps Toolkit, which is a set of composable APIs and specialized tools for building continuous delivery on top of Kubernetes. Using Flux v2, with GitOps on Kubernetes is more powerful and easier.

Flux v2 is built on a set of controllers and APIs known as the GitOps Toolkit.

The components of the GitOps Toolkit are:

• Source controller: The source component enables you to create sources, like a GitRepository or a HelmRepository. The source controller acts on several CRDs. This controller provides a common interface for artifacts acquisition. The source API defines a set of Kubernetes objects, which cluster admins to interact with automated operators to move the Git and Helm repositories operations to a dedicated controller.
• Kustomize controller: The kustomize controller provides continuous delivery pipelines defined with the Kubernetes manifests files. Flux v2 uses the kustomize to deploy the manifests, and the kustomize controller acts on Kustomization CRDs. This controller is a Kubernetes operator, which is dedicated to run continuous delivery pipelines for infrastructure and workloads defined with Kubernetes manifests and assembled with Kustomize.
• Helm controller: The helm controller helps to deploy the workloads based on Helm charts. This controller is a Kubernetes operator, which allows you to declaratively manage helm chart releases with Kubernetes manifests. HelmRelease is the Kubernetes custom resource. Helm actions are achieved by the controller based on the creation, mutation, or removal of a HelmRelease resource in the cluster.
• Notification controller: The notification controller responds to the inbound events and sends the outbound events. This controller is a Kubernetes operator, which is specialized in handling incoming and outgoing events. The notification controller manages the events that come from external systems, like GitHub, GitLab, Bitbucket, Harbor, Jenkins, and so on, and notifies the GitOps toolkit controllers about the source changes. Then, manages the events that come from the GitOps toolkit controllers, like source, kustomize, and helm, and sends them to the external systems, like Slack, Microsoft Teams, Discord, and Rocker based on the event severity and the objects included.

Conclusion

Kubernetes is here to stay, and GitOps, on the other hand, is in full swing to help Kubernetes-related deployments. GitOps is still new and has a long way to go. While other modern practices make things complex, GitOps is on its journey to make things as simple as possible just by employing the full potential of the Git, pull, and push based approach. Cloud-native approaches like GitOps modernize the customer experience, enriching the trust and security while deploying the apps to production. Flux is a great tool that enhances the continuous delivery of Kubernetes-based applications.