An introduction to Flux - Part 1: History and features

The following blog provides an overview of Flux, its lifecycle, adoption, unique capabilities, and several references to help you get started. This is not intended to be a getting started guide. If you’re looking for one, a great hands-on guide is available here: https://www.techtarget.com/searchitoperations/tutorial/Try-out-this-GitOps-tutorial-with-Flux-and-Kubernetes

About Flux

Flux is a Cloud Native Computing Foundation (CNCF) Continuous Delivery tool built exclusively for Kubernetes workloads. At its most basic, Flux deploys Kubernetes manifest files from Git Repositories into the cluster it is running within. Flux then continuously monitors the cluster and source objects in Git, reconciling changes in Git and reverting cluster side changes to ensure the running manifest remains synchronized. Within the cloud native ecosystem, Flux is one of the original continuous delivery tools built natively for Kubernetes. First released in 2016 by Weave and then donated to the CNCF, Flux continues to be a leader and experiences strong adoption by the community with regular monthly releases.

Quick Links:

Documentation: https://fluxcd.io/flux/get-started/

Github: https://github.com/fluxcd/flux2

Community: CNCF Slack https://slack.cncf.io/ #flux

Website: https://fluxcd.io/

Flux Ecosystem

Flux has a limited set of ecosystem products. The main product that is associated with Flux is Flagger, and the second is the Terraform Controller.

Flagger https://fluxcd.io/flagger/
Terraform https://weaveworks.github.io/tf-controller/

Flux Timeline

Flux’s first release was in late 2016 and was primarily used by Weave, the founders of Flux. Shortly after, on January 27th 2017, Weave released version “0.1.0” and declared the project ready for public consumption and collaboration. Since the 0.1.0 release, Flux has experienced continued growth and adoption. With each release, the team at Weave worked with users to enhance the core GitOps services which ultimately resulted in a decision to rework Flux. In May 2020, the Flux v2 project was launched, and the original Flux project was moved to maintenance mode. The goal of Flux v2 was to remove unforeseen limitations in the original design, such as the use of a singular API for multiple services, and rearchitect each component for massive scale. Soon after the announcement and subsequent release of Flux v2 Weave donated Flux to the Cloud Native Computing Foundation, helping cement Flux as a vendor-agnostic open–source project.

In March 2021, Flux was promoted from Sandbox to Incubating. The Promotion to “Incubation” clearly signals that Flux is ready for production use, and organizations looking to adopt cloud-native continuous delivery should seriously consider the project as an option.

Friendly note: Flux V1 is officially EOL as of November 2022. If you’re running V1 head here https://fluxcd.io/flux/migration/flux-v1-migration/ to learn how to migrate

Flux Terminology

Source: A location where the declared state of a resource is stored.

Artifact: The representation of a managed resource that is a 1:1 replica of the resource as it is defined in its Source.

Garbage Collection: The task of cleaning up cluster-side resources that no longer exist in Git. https://github.com/fluxcd/flux/blob/1.11.0/site/garbagecollection.md

Bootstrap: The official and best practice way to set up Flux such that it maintains itself from a supplied Git Repository.

Kustomization: The core object that implements an object to a cluster. When you define a Flux Kustomization, Flux will, in turn, create a Kustomize file that deploys the object.

This is not to be confused with Kustomize, a discussion on the topic can be found here https://github.com/fluxcd/flux2/issues/321

Flux: ```apiVersion: kustomize.toolkit.fluxcd.io/v1beta1```

Kustomize: ``` apiVersion: kustomize.config.k8s.io/v1beta1```

In short, when Flux uses the term Kustomization it is referring to an API,

“The Kustomization is the Custom Resource or API through which a Flux user defines how Kustomize controller delivers workloads from sources.”

If you’re still confused, you’re not alone. Despite the confusion, Flux isn’t looking at changing the name. There are a few open Git Issues on the topic, the main discussion can be found here https://github.com/fluxcd/flux/issues/3533.

Key Components

Architecture

Local Cluster Management: Yes

Remote Cluster Support: Yes

Multi-tenancy: Yes

The most common approach to working with Flux is to bootstrap Flux into each Cluster such that it acts as a distributed continuous deployment controller in a many-to-many (source to cluster) architecture. However, Flux may also be deployed as a central installation that’s configured to connect with remote clusters. The central deployment model includes support for multi-tenancy that can be configured to provide a form of self-service.

State Management

Sources:

Git Repositories Local and Remote
Buckets – Block Storage services that include Amazon s3, Google Cloud Storage
Helm Chart Repositories and associated Helm Chart Custom Resources

Source Change Tracking: On-Demand/Webhook & Polling

State Storage: Cluster

Secret Management: Mozilla SOPS CLI (https://fluxcd.io/flux/guides/mozilla-sops/)

The most prevalent source for storing your resources that Flux will deploy and manage is Git, however multiple options exist. Flux can work with Enterprise Git Repositories (GitHub Enterprise, GitLab Enterprise), SaaS Git Repositories (Github.com) as well as Git Repositories hosted within a Kubernetes cluster where Flux is running. In addition to Git, Flux is also able to leverage block storage, cloud services such as S3, and Helm Chart Repositories.

User Experience

Client Tools:

Flux CLI
Kubernetes CRs via Kubectl
(Optional) Weave GitOps Webapp

Setup: Automated Bootstrap, Helm, Terraform

Installation

Flux is relatively simple to deploy. The best practice is to bootstrap Flux into a cluster using the Flux CLI. The bootstrap process configures secure connectivity to a specified Git repository where the core configuration for Flux is then stored, creating a GitOps-managed Fflux installation.

The Flux documentation outlines the bootstrap process as follows:

“The bootstrap command above does the following:

Creates a git repository fleet-infra on your GitHub account
Adds Flux component manifests to the repository
Deploys Flux Components to your Kubernetes Cluster
Configures Flux components to track the path /clusters/my-cluster/ in the repository”

Alternative installation approaches can leverage the community-maintained Helm chart or Terraform.

User/Client Interaction options

The bootstrap process creates all the Flux CRs within your cluster. From this point forward, users have 4 ways of working with Flux:

Flux CLI
Kubectl
Source Repositories
Weave GitOPS UI

The fundamental Flux object is a Kustomization – a plain text file – that instructs Flux how to deploy your applications. This works in tandem with Source CRs and operates adjacent to Helm objects. Users have several approaches for creating and managing Kustomization files, including letting Flux automatically generate the file. Ultimately your chosen approach is going to be dependent on factors such as:

Per cluster overrides
Multi-tenancy
Automation
Needs for developer self-service

Web UI: Flux does not have a UI included by default; users must choose to add the Weave GitOps UI separately. Some users, such as engineers who are unfamiliar with Kubernetes, may benefit from a rich user interface that simplifies interactions and clearly communicates the status/health of their applications. The Weave GitOps UI provides an at-a-glance view into the current status of managed objects and contains core interactive features such as creating new applications to be managed and deploying Helm applications.

NOTE: A Kustomization can be hand built using the Flux CLI “Flux Create” command or autogenerated by Flux. The best practice approach is to create a Kustomizaiton and store it alongside the related manifest files inside Git. This enables the strongest level of controls and can be integrated into a CI process that, in turn, helps remove the chance of an erroneous change finding its way into production.

Flux has an expansive set of feature and ecosystem plug-ins, too much to cover in a single blog, so we have created a 2-part series on Flux. In the next blog on Flux, we will dive into some of Flux’s unique capabilities and look at the ecosystem that has been built around Flux. Stay tuned for the next installment, coming soon.

Author
Recent Posts

Chris Jones