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
Top comments (4)
Thanks for sharing.
I did not know the Flux solution, I only use the Kubernetes Agent for now, and it works very well for me 🤓
I like the CICD tunnel offered by the Kubernetes Agent 😁
I think that if people want only have the Gitops aspect in a projet, Flux integration is great
I am currently defining a ci/cd using Gitlab and Flux integration.
The main difference I find is that the use of Flux is more like a "pull" pattern : there is no more CD pipeline. Well, not like before. Your CD pipeline consists of making changes in git repo (define a flux config, update an app version in a Helm chart) and Flux takes the rest in charge.
Gitlab agent is more a "push" pattern : your CD pipeline tells your agent to act, like traditionals pipelines.
But there might be a smart way to use them together : Flux to react on changes. And agent could be used in a predefined CD step which says something like "if repo has this particularity (ex: a tag flux) then add it as a git source to flux". Then flux will do the rest. With this pattern, you only have to respect a convention in gitlab to have your app deployed and updated automatically. Lightweight self-service platform!
Yes you are right. Thanks for your comment.
With the Kubernetes agent, you can have zero pipeline like Flux if you want.