GitOps could be the next big thing in cloud automation so I’d give it a try with my in house hybrid Kubernetes cluster. I was recommended to try Flux CD and there’s a good reference project initiated by my colleage: k8s-gitops.
However, in order to fully understand how to use Flux CD, I chose to start from scratch. Following the official instructions it didn’t take me long to fully enable GitOps on my cluster. Here’s how I did it on my laptop running Ubuntu:
First, create a GitHub PAT(Personal Access Token) with full repository permissions. Details can be read here. Also make sure you can create a private repository in GitHub (everyone gets 1 for free). Export GitHub username and PAT as environment variables as following:
export GITHUB_TOKEN=<your-token> export GITHUB_USER=<your-username>
Latest Flux2 CLI can be downloaded here. You can also use the installation script from Flux if you fully trust it:
curl -s https://toolkit.fluxcd.io/install.sh | sudo bash
From this step onward, you will need access to a Kubernetes cluster, eg.
kubectl cluster-info command works and returns cluster information. Check Flux2’s prerequisites with:
flux check --pre ► checking prerequisites ✔ kubectl 1.18.6 >=1.18.0 ✔ Kubernetes 1.18.9 >=1.16.0 ✔ prerequisites checks passed
Then the Flux2 command below can be executed to bootstrap a private GitHub repository
flux-gitops using your GitHub PAT and the repository will be your cluster-as-code command center for GitOps practice, also the CRD(Custom Resource Definition) and controllers for Flux2 will be installed to the current cluster
flux bootstrap github \ --owner=$GITHUB_USER \ --repository=flux-gitops \ --branch=main \ --path=home-cluster \ --personal
In the generated
flux-gitops repository, the file structure looks like
flux-gitops - home-cluster - flux-system
Now you can simply add Helm charts or Kustomization templates into this repository and the changes will be applied to the cluster automatically. The following commands will create a simple namespace in the cluster, then register it with Flux2. After the changes pushed to GitHub, Flux2 controllers will apply the changes and create the new namespace.
cd flux-gitops/home-cluster mkdir my-test cd my-test kustomize create kubectl create namespace my-test --dry-run=client -o yaml > ns.yaml kustomize edit add resource ns.yaml cd .. # in home-cluster # this step is redundant as any directory with a kustomization.yaml file in it will be automatically applied. flux create kustomization my-test --source=flux-system --path=home-cluster/my-test --prune=true --validation=client --interval=2m --export > my-test.yaml # check-in everything to test GitOps # only add my-test directory if the above step is skipped git add my-test my-test.yaml git commit -m "Added my-test" git push
Then you use a
watch command to see how the new change get applied
watch flux get kustomizations NAME READY MESSAGE REVISION SUSPENDED flux-system True Applied revision: main/529288eed6105909a97f0d3539bc68e5e934418a main/529288eed6105909a97f0d3539bc68e5e934418a False my-test True Applied revision: main/529288eed6105909a97f0d3539bc68e5e934418a main/529288eed6105909a97f0d3539bc68e5e934418a False
That’s it, the Flux2 Hello-world. 🙂