🇬🇧 GitLab 💚 Kubernetes - Act 2
GitLab 💚 Kubernetes : act 2
GitLab likes Kubernetes. This is a long story between these two tools. GitLab has been working to integrate Kubernetes into its platform, enabling you to interact with it without leaving the DevOps platform.
I don’t know if you have already seen or read my old blog post https://about.gitlab.com/blog/2022/06/08/configuring-your-cluster-with-kubernetes-integration/ but things have changed.
The certificate integration is an old story, we will never talk about it again. The agent is in constant evolution and we can find new features and fixes in each release of GitLab. More secure, more performant, it’s constantly evolving.
The arrival of Flux’s integration
This year, in February, a little “bomb” arrived. This blog post on the GitLab blog talked about Flux and why GitLab decided to leave ArgoCD for Flux.
That’s right, but, does this change anything about the Kubernetes integration I knew? For me, as a developer, I read this blog post without immediately understanding the impacts of this decision.
If you want to know why GitLab decided to replace ArgoCD with Flux, you can refer to this issue: https://gitlab.com/gitlab-org/gitlab/-/issues/357947.
Flux ?
Flux is a GitOps tool, like ArgoCD. It’s part of the CNCF since 2019 and today it has the “Graduated” status (cf https://www.cncf.io/projects/flux/).
As a developer, it’s difficult for me to give you a real and relevant comparison of these two tools 😅. ArgoCD has a graphic interface, showing the synchronization status of your components in your clusters. Great! But this interface results from the difference in the GitOps model chosen by Flux and ArgoCD. Flux is natively based on the Kubernetes model while ArgoCD has its own model.
With Flux, automatic synchronization is a standard. Of course you can deactivate it and execute a manual synchronization.
ArgoCD offers you the possibility to configure your synchronization policy with the syncPolicy property. You can use the CLI or UI to do this.
For more details about the differences between Flux and ArgoCD, I recommend you these links:
- Wescale blog post (in french)
- post on dev.to written by Vaibhav Rajput
- https://www.ambient-it.net/flux-vs-argocd/
- https://www.cncf.io/blog/2023/09/15/what-is-flux-cd/
How to configure and to use Flux on your project?
I won’t explain all details here, you can find all of them in this GitLab repository: https://gitlab.com/jeanphi-baconnais-experiments/gitlab-kubernetes-demo
The main command to configure Flux on a project is flux bootstrap. This allows you to initiate your cluster deploying Flux resources. After this, any changes applied on your project or on the project containing the Flux configuration will be automatically deployed on your cluster. There is no pipeline to do this. It’s the behavior and the strenght of a GitOps tool.
This is an example of the flux bootstrap command:
flux bootstrap gitlab \
--owner=jeanphi-baconnais-experiments/gitlab-kubernetes-demo/demo-flux \
--repository=flux-config \
--branch=main \
--path=cluster/demo-flux \
--deploy-token-auth
This initializes a flux configuration in the project you define (here flux-config) with 3 yaml files.
Some Kubernetes resources are installed on your cluster in different namespaces.
A new file, describing the deployment of your application have to be created, like this one:
With this file, your application becomes deployed on the Kubernetes cluster 🎉.
Flux vs Agent Kubernetes: two GitOps solutions available
Finally, if you want to configure the deployment of your Kubernetes project, you can use Flux or the Kubernetes Agent. How can I choose between these two solutions? And why might the agent have feared the arrival of Flux?
If GitLab recommended using Flux, the agent could be less used. However, GitLab assures that the Kubernetes agent will not be deprecated until release 18.0 at least, so until 2025.
In the 16.0 release in May, the Kubernetes agent was mentioned in the remote dev environment project, a big new feature of this release. It appeared in a beta mode, suggesting that the Kubernetes agent is always concerned for new projects.
With Flux and the agent, configuration files can be saved on projects dedicated for configuration. With the agent, people can use the features “CI/CD tunnel” to implement GitLabCI pipelines and make actions on the Kubernetes cluster.
With Flux, configuration may be a little bit more complex, but the separation between functional projects and the Flux configuration is clear. Flux implies to have more components deployed on your cluster.
I don’t use either solution in production, so I’d be curious to get feedback about them.
Links
https://docs.gitlab.com/ee/user/clusters/agent/gitops/example_repository_structure.html