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 gitopsk3d kubeconfig merge gitops --switch-context
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>
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 \--personal
We can check how the Prometheus deployment is going:
# Check Flux progresswatch flux get helmreleases -n default# Check Helm controler logskubectl -n flux-system logs -f deployment/helm-controller# Check resource creationwatch kubectl get pods
At last we can view the fruits of our work be accessing Prometheus UI:
# Port-forward to access Prometheuskubectl port-forward service/prometheus-server 8000:80# Check webapphttp://localhost:8000/
You can clean up running:
k3d cluster delete gitops
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.
apiVersion: source.toolkit.fluxcd.io/v1beta1kind: HelmRepositorymetadata:name: prometheusnamespace: flux-systemspec:interval: 1murl: https://prometheus-community.github.io/helm-charts
Armed with the chart location, Flux can now look at prometheus.yaml and decide what to do with it.
apiVersion: helm.toolkit.fluxcd.io/v2beta1kind: HelmReleasemetadata:name: prometheusnamespace: defaultspec:interval: 1mchart:spec:chart: prometheusversion: '11.16.9'sourceRef:kind: HelmRepositoryname: prometheusnamespace: flux-systeminterval: 1mvalues:pushgateway:enabled: false
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.