Bart Farrell (00:00.027) Stefan, welcome to the landscape. Pleasure to have you with us. First and foremost, what problem or problems does Flux solve? Stefan (00:36.225) Hey, thank you for having me. Flux is a GitOps tool and it tries to solve for Kubernetes users running continuous delivery at scale with a focus on supply chain security. And Flux is not a single thing, it’s a collection of tools. So it brings all your favorite tools like Kipctl, Helm, Customize, and F in the form of Kubernetes controllers. So you could imagine these tools are running inside the cluster. You don’t need to connect to the cluster at all. All you need to do is push configuration to some external storage that can be a Git repository, that can be an S3 bucket, that can be OCR artifact in a container registry. And Flux from there will do all the things that you would normally do in classical CI CD setup where you run a Kipstel apply on a Helm upgrade or I don’t customize build and Kipstel apply and so on, right? Flux does all these things on its own. Automatically once you change the desired state of your clusters, applications, infra and so on. Bart Farrell (01:59.053) And you personally, how did you get involved in this project? You just explained it very well as a collection of different tools. What’s your personal story in terms of how you got involved there? Stefan (02:11.325) many years ago, think seven. Yeah, seven years ago, I got hired by WeWorks to join their journey onto GitOps. GitOps back then was a thing that we used to call it in the office. GitOps was not known by anyone. So yeah, I joined early on the Flux project. It was just getting started. Since then I have became a Flux core maintainer. I designed the Flux version 2 along with other maintainers in the Flux project. Flux has been through a major iteration. Usually projects don’t start from scratch. It’s a very difficult decision to make and a very hard step to make. But we did that roughly four years ago. We designed Flux version two from scratch, build on Kubernetes controller runtime and other, you know, CRDs and everything. Flux started way before Kubernetes had CRDs and all of that. So yeah, here we are with Flux version two and I’m still continuing this journey at different company control plane. Sylvain Kalache (03:33.233) Flux has been around for a while and as you mentioned in your intro, it can do a lot of things. But if you had to pick one feature, which one is your favorite feature? Stefan (03:47.615) I would say, so Flux has a command line tool, a CLI, which is called Flux. And it has a command called Boostrap. So you say Flux, Boostrap, GitHub, for example, and this single command sets up Flux on your cluster, connects the cluster with your Git repo, sets up, key for you, authentication, everything. And it’s a single command, kicks off the whole GitOps process. And once after you run this command, you never have to connect to the cluster again. Flux can upgrade itself automatically. So yeah, I think this is a powerful feature of Flux which simplifies the, improves the user experience of getting started. As you said, it’s a complicated tool, but we have this one command that sets up everything for you. Bart Farrell (04:42.907) Very good, one command to rule them all. In terms of the best end user or success stories that you could share with us, which ones would they be? Stefan (04:45.407) Yeah Stefan (04:53.571) So in, I’ll give you some example, recent ones in QtCon Paris, I had a talk with a person from Cisco and the talk was about how Cisco IoT platform manages 200 million IoT devices through Kubernetes and it uses Flux for everything. Especially the Helm controller part of Flux where they orchestrate the huge IoT platform for Flux. It’s on YouTube. You can go and watch that talk. It’s quite interesting to see how a huge company uses Flux truly at scale. Other success stories for me personally was I two years ago or one year and half when GitLab made the choice between their own tooling that they’ve built for continuous delivery, Argo and Flux. and they chose to replace their continuous delivery tooling for their users with Flux. there is an issue in GitLab does all these decisions publicly. There is an issue there. It took them a couple of months to analyze Argo versus Flux versus their own internal tooling. And you can see their conclusions why they went with Flux. So that’s for me, it’s a… It’s a great user story. And another one, for example, it’s Microsoft that choose Flux for their KITOps implementation in Azure Arc. And AWS has the same for EKS anywhere where they ship EKS anywhere with Flux embedded. So these are more like platforms which integrate Flux and all… those users, the users of these platforms, you know, take advantage of flux capabilities. Sylvain Kalache (06:59.205) That’s quite impressive. Thank you for sharing these stories. So Flux is obviously something that is very central to your infrastructure. And when people are picking a tool, they want to ensure that it’s compatible with the rest of their stack. Could you share a few of the other CNCF landscape tools that Flux is integrating with? I think maybe there are too many to mention them all. but maybe some that are new or some that are not as known as other ones. Stefan (07:35.799) Yeah, so integrations are both sides, right? One is Flux integrating with some tools and of course, like most Kubernetes tools out there, it integrates very well with Prometheus. We want people to be able to use Prometheus, Grafana, the usual monitoring stack, which is usually based on Prometheus to observe what’s going on with Flux, with their continuous delivery. We worked a lot on integrating Flux with Prometheus. We shipped Flux with Grafana dashboards, which are very detailed and give you an overview of what’s happening. Flux also integrates with many, many tools through, for example, Flagr is a sub -project of Flux and Flagr does the progressive delivery part of of the story. Progressive delivery means you shift traffic when you do a new release so you don’t impact all your users. And Flagr, for example, integrates with Istio, with Linkergy, with Kuma, with Ingress and GenX and all the service nations and Ingress controllers out there. So I think Flagr as a sub -project of Flux is one tool that integrates with half of the landscape. That’s what Flagr does. But there’s also the other side of the story, right, where other tools build on top of Flux and integrate Flux in their own workflows. And one Linux Foundation project, which is quite important, is the Silva project. I don’t know if you heard about it. It’s where all the telecom companies came together under the Linux Foundation and said, okay, we need a platform, common platform for all telcos to adopt 5G and run Kubernetes at the edge. manage network functions and so on. And Silva project is built on top of Flux. So when you install Silva, it installs Flux and then all the network function deployments, the edge deployments are done through Flux and Flux APIs and controllers. Another interesting project which is out there is Tofu, right? Under the Linux foundation. And there is a Tofu controller, which is an extension of Flux. Sylvain Kalache (09:51.867) you Stefan (09:59.331) that takes Flux beyond just Kubernetes. So normally with Flux, the CNCF Flux looks at the Git repo and expects there to have Kubernetes manifests, like a Helm release, Kubernetes deployment, things like that. But with Tofu controller, you can place in your Git repos or the desired state, can place their Terraform scripts. and TOEFL controller will reconcile those and will create, I don’t know, external infrastructure, which is maybe part of your application deployment. So that’s another strong example of how Flux is extended, can be extended and not through these controllers. We have our own Kubernetes controller SDK that other projects can use and extend Flux like that. Another example is KCL, the KCL language. I hope I’m pronouncing it correctly. They have recently developed a KCL controller that works the same. There is another project, KubeVela, that also integrates Flux for GitOps. Yeah, and the list goes on. I’m going to stop here. Bart Farrell (11:18.523) I guess the question is, does the list ever end? So if it does, when is flux not the answer? When would you say, actually, you know what? This is not something that flux can help out with. Stefan (11:30.189) Yeah, we, given the fact that Flux CLI has like hundreds of commands and it can be, you know, use with shell scripts and so on. I’ve seen people trying to use it as an imperative deployment tool. When they run Flux create the Helm release from a CI pipeline and then Flux reconciled that Helm release, then they wait for that in the pipeline through shell scripts and so on. While this is possible. Sylvain Kalache (11:44.017) you Stefan (12:00.451) And we build the CLI in that way to be for people to be able to write these scripts. It’s more about, we did that more for testing Flux and not for actually running Flux like that in production. You shouldn’t be connecting to the API all the time when you want to do something. You should let Flux do its own thing. So yeah, I would say. Sylvain Kalache (12:10.308) you Stefan (12:28.141) It’s okay to run the Flux CLI, but stop at the staging cluster and in production, don’t run it that way. Sylvain Kalache (12:40.465) Okay, all right, so you can do it, but proceed with caution. So now, like I guess the burning question that we may have is around Argo. Could you compare the two tools, like maybe how one may be more appropriate than the other in certain condition? Stefan (13:06.839) Yeah, I mean, we had many discussions during the years of development with the Argo team. know each other very well. Yeah, it’s a. There are many, many differences, subtle differences between the projects. For example, Argo has the single. Let’s say I would call it, you know, generic API is the Argo apps. While in Flux we don’t want to tell people what an app is and how it should be defined. Flux is more low -level APIs. We give you the reflection of tools. For example, if you want to define your sources, you will create a Git repository object. There is no such thing in Argo. Don’t define Git as its own entity. It’s part of the app. And in Flux then your app can be composed through I don’t know, some plain yellows and that’s a flux customization to apply that. Then maybe you also need some hand releases and all those charts are defining in flux through a chart object and a hand release object and so on. So the difference is we, in flux, we went with an API, which is, I would say more close to Kubernetes in spirit, like things are not. one stuff that you deploy all of sudden, you have to compose them, you have to define dependencies between them, while Argo gives you this monolithic API, it’s an app, and you put all things in there. It’s way easier to get started maybe by just creating this app thing, looking at the Argo UI, clicking buttons, and so on. Flux is more… is guided towards more, you know, being able to do, to be more flexible on how you define your apps and being able to scale very easily without needing to connect to Flux or, you know, clicking buttons. So from a get started perspective, I think Argo is easier. But when you need to scale, you should be looking into Flux. Bart Farrell (15:28.377) In terms of other capabilities, a very hot topic right now with any CNCF project is to what extent is it AI friendly or is AI being incorporated? When it comes to Flux, where is the project at right now when it comes to AI? Stefan (15:47.363) So there is a company, a large company, I guess you heard about it called Zscaler, which is a long term flux user. And they told us they are very successful in deploying flux for AI delivery. So they are using flux and things that, coming back to the Argo piece, right? Argo, it’s all about Git. when you think of the desired state of your clusters. With Flux, we have this OCI artifact concept where there is no gate. You basically define your desired state through OCI artifacts and you push Flux, the CLI has a push command like Docker. where everything is bundled under in a container registry. And Zscaler are using these tools. Models are bundled now. This is the direction, at least, to have models published to a container registry as an OCI artifact. And they use this together with Flux Push, and they are streamlining their delivery pipelines for AI workloads using Flux that way. So that’s… One of the examples from users, are many companies which employ AI and are offering AI services to their end users and they are using Flux to orchestrate all of that. Stefan (17:31.149) Flux itself does not have an AI controller and I don’t think we want to go there anytime soon. But yeah, that’s the AI story for now. Bart Farrell (17:42.501) Very good. Now, you’ve been with the project for quite some time. Are there any shout outs that you would like to give to key people, whether they’re other maintainers or contributors? Stefan (17:52.349) yeah, I want to give a shout out to Mateus. He recently became a Flux maintainer, multiple Flux controllers. And yeah, thank you, Mateus, for all your contributions this year. And he’s helping us now with the next Flux release, which is, yeah, it takes a long time. It’s a long process. It implies a lot of, you know. attention to it and what else is there for us, help us. So I’m very happy we are expanding our flux maintainer team with new people that are happy to help. Bart Farrell (18:38.597) Wonderful. Now, I do have to ask, in terms of secret sauce or fun facts about the project, the term flux. I hear that and I think about flux capacitor from back to the future. I highly doubt I’m the first nor the last. Does that have any influence on the name? Stefan (18:55.202) Yeah, I think so. The funny story is that in the pub where we works People got together there is a flux flux capacitor box on the wall there I also have a picture with it. think it’s on it’s on Twitter So yeah, I think it relates that in a way Of course the name flux and it tries to imply the fact that continuous delivery. It’s a thing that continuously moves. It comes from flux capacitor. Sylvain Kalache (19:41.975) Great. That’s fun. If you can share the link, so we can post it in the description. I’d like to see that picture. So there is a lot of things going on with Flux. The product has been around for a while. Is there any exciting upcoming roadmap item that you’d like to share? Stefan (20:07.319) Yes, we maintain a roadmap for one year. We try to do it at the beginning of every year. know, so people know what to expect. But we also have this process in place, which is based on RFCs, like, you know, RFCs in the Linux space, in Rust, in other languages where you… Basically, if you have a crazy idea, you have to create and you want it in Flux. You have to go through this RFC process. And yeah, this year I created an RFC for having a Git -less Flux bootstrap in the future where instead of pointing the Flux CLI to a Git repo, you’d point the Flux CLI to your container registry and you no longer need Git at all. Even if Flux works great right now with OCI, artifacts, container logistic as I said, we don’t have that one command, one click experience like we have for Git. yeah, I’m gathering feedback on that idea. Lots of users got excited when I mentioned it and I’m looking forward to… for us, the Flux maintainers and the community to finalize that RFC at some point this year and maybe early next year to launch the new command which will completely decouple Flux from Git if you want to run it that way. Bart Farrell (21:44.579) And you mentioned the community. If people want to get involved in Flux, you know, as a contributor, what kind of contributors are you looking for? What’s the best way to get to start participating? Stefan (21:54.637) So there is a Fluxed organization on GitHub and Flux is made out of many controllers, components and so on. So it’s not just one repo where you can go, but in the Flux to repo, which is the repo history where the Flux distribution is and the CLI code, usually people open their issues, even if they are not about the CLI, but the whole project itself will also have their… the GitHub discussions enabled for the whole project. So that’s where you would go to find issues that need help or to join others on GitHub discussions where we basically decide, do you want to have this new future or if we go to the RFC way, which maintainer will be a sponsor of the RFC and so on. Right now we have another C merge which is about which comes from from from Microsoft and it’s about being able to use OEDC to connect to external sources. For example, an Azure Git Repository in Azure DevOps. So you don’t have to use a Sage anymore. You don’t have to rotate keys. Everything should be based on OEDC and we We have an issue, it’s pinned on the Flux2 repo where we explain all the things that how people can help us. example, if you know Google Cloud, then you are aware of how OEDC works there. You could help us and contribute OEDC authentication in Flux for Google repo stories. Or if you know very well GitHub and GitHub apps. please come and help us implement OEDC authentication in Flux through GitHub app so people don’t have to use SSH anymore and personal access tokens. We have the same for GitLab and so on. So we we can implement all of that on our own. We need help and the best help comes from users which are very custom with that particular platform. We as maintainers, we use GitHub, right? Stefan (24:18.852) And Kubernetes kind and stuff like that we don’t use on a daily basis all the cloud vendors, all the Git providers out there. So this is where the community can truly help us when it comes to specific tasks around some kind of integration that we are not that familiar with. Bart Farrell (24:38.549) You know, it’s very clear that you spend a lot of time on Flux. When you’re not working on Flux, what do you like to do in your free time? Stefan (24:47.17) I have a Shiba Inu, dog, and me and my wife, we like very much to the dog and travel around Europe with the car, get the dog in the car and travel around. yeah, traveling is one of my passions, let’s say. Yeah, I think that’s the main thing I love to do outside, working on Flux or hanging out with the Flux community. Bart Farrell (25:14.043) That’s great. And the thing is you have a very large and very healthy community. And I think that’s a really beautiful thing. It’s not something that falls from the sky. It’s lots and lots of work. It’s lots of conversations and connections. That being said, thank you very much for joining us today on The Landscape. I appreciate all of your efforts. Look forward to see what happens next with Flux. Thanks a lot. Take care. Cheers. Bye bye. Stefan (25:35.734) Thank you very much. Bye bye.