DEV Community


Flux CD

Ricardo Castro
Senior SRE at DefinedCrowd. Strong believer in culture and team work. Open source passionate, taekwondo amateur and metal lover.
Updated on ・3 min read

Originally published on

In it's website we can read that "Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration (like Git repositories), and automating updates to configuration when there is new code to deploy." That is, obviously, powered by the GitOps toolkit have it not been developed (and open-sourced) by Weaveworks.

Following the GitOps philosophy, Flux is/has:

  • declarative since it uses Git as its source of truth where the entire desired state is described;
  • automated because it can read state (described in YAML) and act upon it;
  • auditable due to Git history;
  • designed for Kubernetes from the ground up;
  • out-of-the-box integrations so that the wheel doesn't need to be reinvented;
  • extensible allowing for particular use cases to be added.

Get the ball rolling

Here you can find the demo we will be using in this tutorial to deploy Prometheus using it's official Helm chart. We will be spinning a local Kubernetes cluster with k3d and using Flux's Helm Controller to handle the deploy. We need the following tools to make this happen:

We start by creating a local Kubernetes cluster with k3d:

k3d cluster create -a 2 gitops
k3d kubeconfig merge gitops --switch-context
Enter fullscreen mode Exit fullscreen mode

To make our lives easier, we'll export a few environment variables to handle the authentication with Gitlab:

export GITLAB_GROUP=<your-group>
export GITLAB_REPOSITORY=<your-repository>
export GITLAB_TOKEN=<your-token>
export GITLAB_USER=<your-user>
Enter fullscreen mode Exit fullscreen mode

We bootstrap Flux, pointing it to our Gitlab repository where the configuration lives:

# Run the bootstrap command:
flux bootstrap gitlab \
  --owner=$GITLAB_USER \
  --repository=$GITLAB_REPOSITORY \
  --owner=$GITLAB_GROUP \
  --branch=master \
  --path=staging-cluster \
Enter fullscreen mode Exit fullscreen mode

We can check how the Prometheus deployment is going:

# Check Flux progress
watch flux get helmreleases -n default

# Check Helm controler logs
kubectl -n flux-system logs -f deployment/helm-controller

# Check resource creation
watch kubectl get pods
Enter fullscreen mode Exit fullscreen mode

At last we can view the fruits of our work be accessing Prometheus UI:

# Port-forward to access Prometheus
kubectl port-forward service/prometheus-server 8000:80

# Check webapp
Enter fullscreen mode Exit fullscreen mode

You can clean up running:

k3d cluster delete gitops
Enter fullscreen mode Exit fullscreen mode

What did Flux do?

When we bootstrapped Flux, we pointed it at a repository and a specific folder (staging-cluster) where the configuration resides. prometheus-source.yaml points to where the Helm chart lives enabling Flux to fetch it.

kind: HelmRepository
  name: prometheus
  namespace: flux-system
  interval: 1m

Enter fullscreen mode Exit fullscreen mode

Armed with the chart location, Flux can now look at prometheus.yaml and decide what to do with it.

kind: HelmRelease
  name: prometheus
  namespace: default
  interval: 1m
      chart: prometheus
      version: '11.16.9'
        kind: HelmRepository
        name: prometheus
        namespace: flux-system
      interval: 1m
      enabled: false
Enter fullscreen mode Exit fullscreen mode

In this example we're fetching version 11.16.9 of the chart, pointing at the HelmRepository defined in prometheus-source.yaml and passing a few values, which is the case of this example just disables Pushgateway.

We've just scratched the surface of what Flux can do but, with only a bit code we were able to deploy Prometheus effortlessly. Flux can do a lot more and, in case you're interested, take a look a the documentation.

Discussion (0)