GitOps - Kubernetes Deployment Automation with FluxCD and Flagger
In our previous article, we gave a high-level overview of the current Kubernetes and GitOps landscape. In this article, we’ll take the next step by exploring Kubernetes and GitOps in more depth, and introduce the tools we use to build a practical deployment workflow that follows GitOps-principles.
Kubernetes is an open-source platform for automating the deployment, scaling, and management of containerized applications. It allows administrators to build a cluster of nodes, which can be either virtual machines or physical servers. It organizes workloads into pods, schedules them across nodes, and exposes them via services for communication.
Resources in Kubernetes are defined in a declarative manner, meaning you specify the desired state of the system rather than a set of step-by-step instructions. The configuration files, which are called manifests, are usually defined in YAML or JSON format. Kubernetes continuously monitors these resources and ensures that the actual state of the cluster matches the defined desired state. This ongoing process is known as reconciliation, and it is done by special control-loop processes inside the cluster called controllers. It applies not only when resources are initially created but also when the system encounters changes or failures. For example, if a node crashes, Kubernetes automatically reschedules the affected pods on healthy nodes to maintain the desired state.
Kubernetes is an extensible platform with a rich ecosystem of tools that can help administrators maintain, deploy, and monitor applications running on the cluster. Its modular design allows integration with a wide variety of third-party solutions for serviceability, security, networking, and continuous delivery.
GitOps is a modern approach to continuous deployment and infrastructure management that leverages Git as the single source of truth for declarative infrastructure and applications. By storing all infrastructure changes in Git, every modification becomes traceable, enabling auditing and the implementation of customized CI/CD and approval workflows.
Its declarative and version-controlled nature makes it suitable for managing Kubernetes clusters and their resources. Popular GitOps tools include FluxCD and ArgoCD.
At DGITAL we have chosen FluxCD to manage our Kubernetes clusters, because of its modular and extensible nature. It is a widely-adopted and trusted CNCF Graduated project.
The tool runs within the cluster and is built on top of the Kubernetes API. It provides source controllers that monitor various configuration sources. While it is primarily used with Git repositories, it also supports other sources, such as Helm repositories, OCI artifacts, and S3 buckets. Kustomize and Helm (for applying Helm Charts) controllers consume the output of source controllers, and create Kubernetes resources from the defined manifests. See the figure below to understand how the different controllers relate to each other.
These repositories can be organized flexibly, ranging from a monorepo setup to separate repositories for individual teams, environments, or applications. Therefore, it can be adapted to the needs and workflows of your organization.
FluxCD can be installed using its CLI tools, which also provide capabilities for managing and monitoring its controllers. Furthermore, there are several graphical dashboards, such as Weave GitOps and Capacitor, that offer a visual overview of the state of the system, resource status, and synchronization activities.
Flagger is a progressive delivery operator for Kubernetes. It is mainly used alongside FluxCD, but it can be used as a standalone tool as well. It supports various deployment strategies such as canary deployment, blue-green deployment, and traffic splitting for A/B testing. When a new version of an application manifest is applied to the cluster, Flagger splits the traffic between the new and the old version based on the defined deployment strategy.
While the new version is rolling out, Flagger is capable of monitoring various metrics, and makes decisions based on them. For example, it can roll back to the previous application version if the error rate or response time is higher than the configured threshold. The metrics can be queried from providers such as Prometheus or AWS CloudWatch.
Flagger, on its own does, not have networking capabilities, it relies on other tools like service mesh solutions (e.g., Istio, Linkerd), or ingress gateways providers (e.g., NGINX).
In conclusion, Kubernetes combined with GitOps tools like FluxCD provides powerful flexibility for defining and managing infrastructure as code, as well as automating application deployments. However, this flexibility comes with a challenge: the wide range of tools and design choices can make it difficult to select the right stack and structure workflows effectively.
In the next article in this series, we’ll walk through a practical GitOps implementation that shows how to deploy microservices efficiently using FluxCD and Flagger.