Flux For GitOps

We covered GitOps as it pertains to Kubernetes in the last blog post. Let us discuss the first of the (reasonably) mature tools used in GitOps projects – Flux.

Readers who want a quick refresher on GitOps can read the last post below –

https://www.vamsitalkstech.com/cloud/gitops-the-key-enabler-of-cloud-native-platforms/

Flux is a tool that can sync sources of code and configuration – such as Git and Helm repos- with target Kubernetes clusters. It can automate updates to both whenever the sources change or are themselves updated. The typical mode of deployment is for Flux to run on the target cluster itself while watching a Git repo for any changes in K8s manifests.  Flux also features a K8s operator called FluxCD. FluxCD is a GitOps operator which is opinionated, in that it ships with a core set of integrations by default. For instance Helm charts, a tool called Kustomize and Prometheus integration. Whereas Helm is the standard for K8s application packaging – much like yum for linux, Kustomize is a templating tool that solves a lot of the issues faced when describing your own complex application using Helm charts.

Let us discuss Kustomize for a minute. We are all familiar with the need to edit multiple YAML files as a way of modifying K8s objects. With a simple kubectl apply, we can synch a cluster with the declarative state we want. However, this introduces several headaches as applications multiply in a microservices architecture. The developer and operators are left with a large number of config files to write, debug and deploy. Templating systems like Helm and Kustomize allow a single file to work for multiple environments by supporting variables. Since K8s 1.14, Kustomize has been integrated with kubectl. Prometheus is used to add observability to the GitOps workflow described above.

The workflow of Flux is that a GitRepository object is first created and then a Kustomization object is used to sync with an instance of the GitRepository object. FluxCD also provides a handy CLI.It also has Slack integration as well as supports webhooks for integration with any 3rd party messaging or monitoring systems.

One of the big advantages of Flux is the ease of setup and maintenance. One limitation however is that a single Flux instance can only watch one remote repo and can apply those changes based on the namespaces that the Flux service account has permissions to. For multi-tenant applications, users will need to run several Flux instances. Once Flux has been installed using ‘fluxctl install’, it starts periodically pulling from the remote repository and applies manifests and/or applications. This sync can also be triggered with a ‘fluxctl sync’ command.

Fluxv2 has been factored out into the GitOps Toolkit –  a set of APIs and tools for Continuous Delivery on K8s. The v2 includes support for multitenancy as well as scalability.

The below list from – https://toolkit.fluxcd.io/ – captures the expected features alted for Flux v2

Features:

• Source configuration from Git and Helm repositories, and S3-compatible buckets (e.g., Minio)
• Kustomize and Helm support
• Event-triggered and periodic reconciliation
• Integration with Kubernetes RBAC
• Health assessment (clusters and workloads)
• Dependency management (infrastructure and workloads)
• Alerting to external systems (webhook senders)
• External events handling (webhook receivers)
• Automated container image updates to Git (image scanning and patching)
• Policy-driven validation (OPA, Kyverno, admission controllers)
• Seamless integration with Git providers (GitHub, GitLab, Bitbucket)
• Interoperability with workflow providers (GitHub Actions, Tekton, Argo)
• Interoperability with Cluster API (CAPI) providers

In the months to come, Fluxv2 will be an exciting tool for container platform operators, developers and SREs. We will discuss the most popular GitOps tool- ArgoCD in the final post in this series on GitOps.