Flux V2 Supercharge your CD

Welcome to the amazing world of GitOps !!!
Yes, I am shouting because it is an exciting world where everything you do, write, create or think of is residing in your VCS, waiting to be picked up by various tools and agents to do your CI and CD for you without ever touching an outside source.

Today, we are here to talk about Flux V2, a successor to Flux which evolved to answer more of our needs such as support for syncing multiple git repositories! (This is what sold it for me and trust me, it will do that for you too).

Let’s talk about the winderful GitOps Toolkit:

“The GitOps Toolkit is the set of APIs and controllers that make up the runtime for Flux v2. The APIs comprise Kubernetes custom resources, which can be created and updated by a cluster user, or by other automation tooling.”

Toolkit Components:

• Source Controller
• Kustomize Controller
• Helm Controller
• Notification Controller

Documentation can be found here. Why am I giving you a link to the docs instead of explaining everything by myself? Am I lazy? Bad blogger?
… No! I just want you to have fun with awesome hands on exercises instead of taking 25 minutes to read about the tool and be way too tired to continue so ….. You are welcome!

Let’s go with the Fl(ow)ux!:

Note: you will need a repository with k8s yaml files, repo with your helm chart/s and a cluster of your own which you have access to.

If you want a plug and play demo repository, you can and should (!) use mine: https://github.com/JohnMops/DevOps

A. Create two new repos: Will be used for different environments deployments

• flux-prod
• flux-dev

Note: If you are using my repo, you will have to take the files from my repos and push them to both repos or just fork mine so you can make changes.

• brew install fluxcd/tap/flux
• Generate a github personal token in your account

B. Export your token and user to your local environment

export GITHUB_TOKEN=<your_token> export GITHUB_USER=<your_user>

C. Check that your cluster is compatible

flux check — pre

D. Use the flux boostrap capability to install flux into your cluster automatically

flux bootstrap github 
 — owner=$GITHUB_USER 
 — repository=DevOps 
 — branch=main 
 — path=kubernetes/flux/flux-v2/flux-app 
 — personal

• This will boostrap flux to your cluster and create all the needed componenets
• You can use a repo that does not exists and it will create it for you. In this case, if you fork my repo and run this command, it will create manigests and push it them to kubernetes/flux/flux-v2/flux-app. It will also create a deployment token and add it to your repo so the flux can pull files from it.

kubectl -n flux-system get deploy
- Output should be:
helm-controller           1/1     1            1           6m49s
kustomize-controller      1/1     1            1           6m50s
notification-controller   1/1     1            1           6m46s
source-controller         1/1     1            1           6m51s
You should see a long output that creates all the resources

E. Let’s configure deployments for app-prod and app-dev:

kubectl create ns app-prod
kubectl create ns app-dev

F. Create sources for prod and dev:

1. source — the source for flux to watch of type “git”
2. development — the name of the source object
3. — url : the url of this specific deployment where you have the yaml files
4. — branch : which branch to watch on that repo
5. — interval : interval to scan the repo

flux create source git development --url https://github.com/JohnMops/flux-dev  --branch main --interval 10s
flux create source git production --url https://github.com/JohnMops/flux-prod  --branch main --interval 10s

G. Create kustomizations for prod and dev:

1. kustomization : this is an object that will actually initiate the scanning and applying
2. development/production : name of the object
3. — source : waht source to scan as per what we created earlier
4. — path : what folders to watch in that source repo
5. — prune true/false : whether to delete resources if they are no longer in that source repo
6. — validation : validate yaml files on the source repo during the run
7. — interval : interval to scan the repo

flux create kustomization development --source development --path "./" --prune true --validation client \
--interval 10s

flux create kustomization production --source production --path "./" --prune true --validation client \
--interval 10s

H. Check and play:

kubectl -n app-prod get all 
kubectl -n app-dev get all

You will see all the resources in the appropriate repos deployed.

• Now change whatever you want in the app-prod and dev repos and after 10 seconds check the changes.

You now have 1 flux that watches multiple source repos and deploys them automatically to the respective namespaces, thus achieving auto CD to different environments !!!

Amazing right?! That’s not all, let’s go get our Helm on!:

A. Create a repo for your helm charts or use mine flux-helm and flux-helm-releases

B. Create sources to watch those repos:

• The below will create a sources that will be watched by flux

- For the metric server release in this case (or your own app in chart)
flux create source git metric-helm --url https://github.com/JohnMops/flux-helm-releases  --branch main --interval 10s
- For the "root" chart (the main chart from which flux will "helm apply")
flux create source git charts --url https://github.com/JohnMops/flux-helm  --branch main --interval 10s

C. Create a helmRelease object and generate a k8s manigest using your own values.yaml

- Create values.yaml and put "replicas: 4" for example
- The below command will create a helmRelease manifest that will tell flux to take the root chart from the source
we created and apply it using the values you provided to override the original once
flux create helmrelease metric-server --source GitRepository/charts --chart "metrics-server" --target-namespace kube-system --values values.yaml --interval 10s --export | tee metric.yaml
- The metric.yaml file will be used to trigger helm release via flux
- Push it to your "flux-helm-releases" repo as we do have a source that flux is monitoring

D. Create a kustomization object so flux can apply it:

flux create kustomization metric-helm --source metric-helm --path "./" --prune true --validation client \                                                                                      
--interval 10s

• What happens in the entire proccess is the below:

1. Flux monitors the root chart source “flux-helm” and the “flux-helm-releases”
2. We generate a helmRelease object that contains our root chart source in the “sourceRef” field
3. Our kustomization object tells flux to look for any k8s yaml files in the “flux-helm-releases” repo and apply them 3
4. Flux creates the helmRelease object on your cluster
5. The helmRelease pulls the root chart from the “flux-helm” repo and applies it with your values specified in the metric.yaml helmRelease yaml

Now if you want to control your metric server release simply modify the metric.yaml with additional values and flux will apply them after 10 seconds which is the interval we specified.

This is it folks, amazing, easy and fl(ow)uxing (this is a terrible joke, I know)!!

For any questions, leave comments here, email or open an issue on my github if (there is no “ifs”!) you are going to use that and of course go over the repo and check out some more cool tools and demos!