 Hello, and welcome to Getting Started with GitOps and Flux. I am going to be giving a introduction to both the topics, so GitOps first and then Flux, and then at the very end, I will be giving a demo on how to actually get started with Flux. My name is Priyanka Ravi. I am a developer experience engineer at Weaverx, and before my time here, I was actually on a GitOps delivery team at State Farm, so I am a Flux user myself. So basically I'm going to be coming into this with a lot of user experience from that time. Why GitOps? Why should you even care? Why are you here? There's a lot of reasons to love GitOps, and there's a lot of benefits that come with it. Individual teams and organizations who implement GitOps experience many benefits, including stronger security guarantees. Because of GitOps tools' unique ability to treat everything as code, it basically directly impacts security. For example, if all configuration and security policy is treated as code, everything can be held in version control. So basically any and all changes that are made are reviewed and inputted into an automated pipeline. There's no manual processes, so you're less likely to be at work on a weekend, which leads me to increase developer and operational productivity. Because there's no manual processes, it actually allows developers to work on things that actually matter, such as the actual application. And it enhances developer experience because you wouldn't have to be there on a weekend debugging something that maybe someone entered in manually and you don't have this audit trail of how it got there and what changes were made. Because of all the things that I also just mentioned, it also improves stability. There's a higher reliability, it's more consistent, and because it's all through code, it also is very standardized. What are the benefits of Flux? Flux actually reduces developer burden by removing the cube control problem. You don't have to worry about cube control versions to be able to interact with the cluster. You get rid of all those manual steps and so you can focus on things that matter. Also, it's extensible, it's super versatile, it works with existing tools, it's very flexible. Basically, it's a modular natural extension of Kubernetes. And because of the microservice architecture that Flux has, you can pick and choose what you actually wanna include to tailor your own experience with Flux. And it comes with out-of-the-box support for Customize and Helm. And like I said, it's designed for Kubernetes, it was designed entirely to be a natural extension of Kubernetes. So these are eight things that we like you to know about Flux. And so it's basically just a little flux in short. Flux provides get-ups for both apps and infrastructure. You basically just get push and Flux does the rest. Flux works with your existing tools and it also works with any Kubernetes in all common Kubernetes tooling. It does multi-tenancy and as we like to say multi-everything and you can use it to alert and notify and users trust Flux, myself included as well. And Flux has a lovely community that's very easy to work with. I am going to come back to these statements at the end. So I will elaborate more on them. I just wanted to get your feet wet with these concepts. All right, so what is get-ups? Get-ups is an operating model for cloud native applications such as Kubernetes but I do wanna highlight that it's not just for Kubernetes. If you are doing a multi-cloud infrastructure you can still use get-ups for your other platforms but because we're focusing on Flux we're going to limit this talk to Kubernetes. Also, it utilizes a version controlled system most commonly get but you can utilize other sources of truth but most commonly you'll see get as the single source of truth. So that way you have something like an audit trail all those changes are actually recorded and you can go back and actually view this source of truth. Also, it enables continuous delivery through automated deployment, monitoring and management by a version controlled system. Most likely you're already using these tools such as get if your developers are probably already using get. So it's something that you can kind of just take advantage of this tool that you're already using and that's the beauty of get-ups. And so also it manages your infrastructure and applications declaratively. All right, so I wanna talk about the get-ups principles which are basically just a set of best practices that have been defined by the get-ups working group through discussions with many different vendors and users experiences. You can go to opengetups.dev to learn more about the get-ups working group and about these principles. But I just wanna say don't feel like you have to have them all done in order to utilize get-ups. Everyone's journey looks different and you can start using get-ups and add in hardening and tweak to your setup to meet these guidelines as you go. The first principle is that a system managed by get-ups must have its desired state expressed declaratively. Basically, there's a lot of benefits you get from having your desired state expressed declaratively such as, you know, because it's written in code it's reusable, there's an audit trail. There's a lot of reasons that it's a good idea to have it written expressed declaratively but it's also important for later principles that we're gonna talk about such as a software agent pulling it. But yeah, there's lots of benefits and reasons to do it. And then the second principle is that a desired state is stored in a way that enforces immutability versioning and retains a complete version history. So basically because it's immutable there's no sneaking in a change. There's no way for someone to come in and actually add a change that's not a part of this complete version history. And versioning has a lot of good benefits as well. You can always revert back to an old version. And so yeah, there's lots of benefits to all of those things. And then the third principle is that software agents automatically pull the desired states declarations from the source. And so because your stuff is all codified all your state declared state, your desired state is codified an agent can come along and actually pull in what you have stated that you want it to look like and then it will actually apply it to your Kubernetes environment. So the fourth principle is that software agents continuously observe the actual system state and attempt to apply the desired states. So basically something like flux would be actually continuously observing the desired system state. So whatever's in your repository and actually attempt to apply it and make sure that it's actually what is actually deployed. So whatever you desire is actually the deployed state and you can rest easy knowing that it will always be that way. So what is flux? Flux is a get centric package manager for your applications but get isn't the only system you can actually use with flux. But basically it provides a set of continuous and progressive delivery solutions for Kubernetes. It is a natural extension of the benefits that already come with Kubernetes. And at the core of it basically that it continuously monitors your version control system and applies the desired state that's been declaratively stated there. The nice part of this is that you don't have to worry about things like configuration drift because it also hard applies on a schedule. So if things have gotten out of sync for some reason it will actually set it back to your desired state. And as I mentioned earlier flux really reduces developer burden because it removes the need for manual deployment processes. Everything's automated, which is really nice. So you don't have to worry about those things. Okay, so flux is actually a set of Kubernetes controllers. And if you're not familiar with controllers a controller handles the life cycle of objects in Kubernetes. Basically like if something needs to be done so when an object is created, updated, deleted, et cetera. These are the different controllers that flux is made up of but I will come back to this and I will go over these in a little bit more detail later. I just wanted to show you an overview that it is a microservice architecture and this is how it works. All right, now I am going to go back to those statements that I promised that I would go more in detail with. And so the first one is that flux provides GitOps for both apps and infrastructure. Flux along with Flagger actually deploys apps with Canaries, Feature Flags and AV Rollout. So you can utilize any of your progressive delivery needs basically and there is a great self led workshop that includes Flagger and would be a great resource if you are interested in trying it out. And that can be found at eks.handson.flagger.dev. Also Flux can manage, also manage any Kubernetes resource. So basically everything you're already using Flux can really manage that. It works very well with the whole Kubernetes environment and it was created with all of that in mind. Also infrastructure and workload dependency management is built in. So one nice neat feature is that you can utilize Depends on. So let's say your application actually relies on a database already being stood up. You can actually utilize Depends on to tell your deployment that, hey, I want my database to already be stood up before my application is even stood up. And so until that database is ready, it will not actually deploy the application. So you can rest assured knowing that all of those necessary factors are met already, which is a neat feature. The next thing is just push to Git and Flux does the rest. It really is that simple. Flux enables application deployment and with the help of Flagger, like I mentioned earlier, also progressive delivery through automatic reconciliation. So it really just continuously is looking for those changes and then just applying them automatically. And Flux can even push back to Git for you with automated container image updates to Git. So it can do image scanning and patching. And so basically the image reflector controller and the image automation controller work together to update a Git repository when new container images are available. Also, it works with your existing tools. This is the great beauty of the whole, the tool. It works with your Git providers, GitHub, GitLab, BitBucket. And like I mentioned earlier, you can even use S3 compatible buckets as a source. So it's not all just Git but all major container registries work and all CI workflow providers as well. So basically all the tools that you're probably already using is just now drop in Flux and it's gonna take over managing your deployments, which is great. Flux works with any Kubernetes and all common Kubernetes tooling. Like I said before, it was really created with Kubernetes in mind, probably all the tools that you're already using in Kubernetes Flux will work with. So it works well with customized, Helm, RBAC and policy-driven validation, OPA, Kyverno, Admission Controller. So it simply is just really, it just falls into place and it just works very well with all the existing tooling. Flux does multi-tenancy and multi-everything as we like to say. Basically Flux uses true Kubernetes RBAC via impersonation and supports multiple Git repositories. You can have a multi-cluster infrastructure and apps work out of the box with cluster API. Flux can use one Kubernetes cluster to manage apps in either the same or other clusters, spin up additional clusters themselves and manage clusters, including lifecycle and fleets. And so multi-tenancy is something I'm gonna show like it's a little bit in the demo, just like a brief nod to it, but there are different types of multi-tenancy. You can do soft-tenancy where you have a cluster with multiple namespaces. So like a team can be given a namespace and Flux can do that, but it can also do hard-tenancy where you give each team their own cluster as well. So it can do multiple types of multi-tenancy, which is really awesome. Flux alerts and notifies. Flux actually provides health assessments. It can alert to external systems and it can do external events handling as well. Basically you can just get push and then you can get notified on Slack and other chat systems. This is a really cool feature because you can actually set it up to tell you when a change has been made and Flux has been, any situation that you basically need to know about you can actually set alerting on, which is really cool. And then users trust Flux. Flux is a CNCF incubating project and was one of only two projects alongside Helm categorized as Adopt on the CNCF CI CD Tech Raider. And we get a lot of feedback from users and myself being a user as well. I can really attest to it does everything that it promises it does and it is very simple and easy to use and it makes life just a lot easier. So we have gotten the feedback that people really do trust this tool. And Flux has a lovely community that is easy to work with. We welcome contributors of any kind. The components of Flux are on Kubernetes core controller runtime so anyone can contribute and its functionality can be extended very easily and get started contributing to Flux. You can find a contributing guide in our docs but yeah, we really do welcome anyone of any level. We're very happy to have you. Feel free to reach out to us if you need any help getting started with something like that. All right, now I'm coming back to what the actual Flux controllers do. The first one is the source controller and what it does is it fetches resources and stores them as artifacts. Basically at its core the source controller is continuously monitoring the Git repository and looking for any changes and then it pulls in those artifacts and stores them. And then the customized controller actually applies these manifests and it runs manifest generation using customized. So that's an important key component I wanna mention there. We get a lot of confusion for sure around the Kubernetes customized and the name of the customized controller. So the customized controller actually does use customized Kubernetes customized in the background. So what I'm talking about by Kubernetes customized is the method of actually using Kubernetes customized you can tell it which resources you want it to apply. You can do patching, all of those things. So everything you're really familiar with with Kubernetes customized. Basically you can still use Kubernetes customized YAMLs, but if you don't, what the customized controller is doing in the back end is actually just creating one so that it can actually apply the necessary resources. And if it's not specified then it'll just apply, it'll create a customized with all of those resources that are in that file path. The helm controller, it does the deployment of helm charts. Basically it allows someone to declaratively manage helm chart releases with Kubernetes manifests. The notification controller does notification dispatch. It specializes in handling inbound and outbound events. The image reflector controller and the image automation controller, they basically work together to make sure that if there's an image that's a new container image that's available, it'll actually update your Git repository. So basically they work together in tandem. And all the controllers also work together to produce an outcome. As you could tell, like the customized controller obviously applies the manifest that the source controller pulls along with what the helm controller also does is something similar. So they all really work together and that's the beauty of this microservice architecture. So I wanna mention that Flux works really well with other tools. I know I mentioned like a couple of them briefly before in one of the statements, but I wanna really highlight that it works with so many existing tools. I'm not gonna list them all because it's really a lot but it really does fit very well into your probably your already existing environment which is really great. And I wanted to hit on a few reasons why I and others really love Flux. It just makes life so much easier. It's all this automation and it's really simple to use. It really is just like drop in and then it does what it says it does. And then multi-tenancy is really simple with it as well. I from experience have actually set up multi-tenancy with Flux and it's pretty easy and relatively simple to use. I mentioned depends on earlier which is a really great feature if you do have things that need to be deployed in a certain order. Helm integration is fantastic with Flux. It's really great if you are using Helm it's a natural extension that you can just utilize with your current Helm deployments. The notifications and alerting is really simple to use with Flux as well. Bootstrap which I will be showing in my demo is a really easy way to get started with Flux which is a really neat thing and then that kind of leads me to the Flux CLI which I think is fantastic. I will be showing it in my demo but I really it is one of my favorite CLIs that I've ever used because it's so user friendly and I will be showing that as well. And then these are some things I want to leave with before I get to my demo. To get started with GitOps you can try Flux using our getting started guide and then we have really great docs. You can join our CNCF Slack community at hashtag Flux. You can catch us there if you have any questions or need any help with anything. You can also sign up for our mailing list for monthly updates, announcements, so on. And then you can go star us on GitHub. You can catch the Flux repository here and you can also join the conversation in GitHub discussions. So I am going to be doing a brief walkthrough of utilizing the Flux CLI to Bootstrap in a cluster to set up Flux. Using Bootstrap is a really quick and easy way to get up and running with Flux. And then I'm going to show you how to create a new tenant using the CLI and basically this will create you a new namespace, a service account and a role binding. And then the last thing I'm gonna do is I'm gonna show you how to create a new source and a customization sync to actually set up continuous reconciliation with a separate project repository. I wanna note that I'm basically gonna be showing a really, really brief example of utilizing soft tenancy, which is where you have a cluster and multiple namespaces as opposed to hard tenancy, which is where you would have multiple clusters for your teams or uses. However, I just wanna note that Flux can also do hard tenancy and there are really great resources online for that. But my own personal experiences with more limited to soft tenancy where each team was given a namespace for their app deployments. And so as you can see here on my screen, the Flux demo repo does not exist yet. And so we are going to actually be bootstrapping and then that will actually create that repo for us. And I just wanna start by saying that the Flux CLI is a fantastic resource if you are new to using Flux. I'm gonna show you an example of how you can use it if you're stuck basically. I'm just gonna run Flux Bootstrap GitHub dash H and this is going to pull up the help command. And as you can see here at the top, it actually gives you a little snippet of what the Bootstrap will do. And in this case, it says the bootstrap command creates the GitHub repository if it doesn't exist. And then it actually commits the toolkit component manifest back to the main branch. And then it also configures the target cluster to synchronize with the repository. So it's gonna be basically setting up Flux to be continuously reconciling on itself. And then also if the toolkit components are present on the cluster, the Bootstrap command will perform an upgrade if needed, which is really, really neat and super powerful because if there's a new version of Flux that's already been released, then all you have to do is just rerun the Bootstrap command. And it's not disruptive at all. And it will just actually update all of those components, which is really cool. And then it also gives you some examples on how to actually use the command. So you can really just like copy and paste one of these and then just like, you know, add in like the info you need. And it will just work, which is really neat. And then it gives you a list of all the flags. And it's not just for Bootstrap, by the way, you can do this with any Flux command, which is why I really love this CLI. It's very, very user friendly. It's really neat to use. So as you can see here, I am running a Flux Bootstrap command. And what this is telling it to do is create this Flux demo repository, a private repository. And then it's also telling it to specifically listen on this path called clusters, my cluster. So it's not just gonna be blindly applying anything that's in this repo. It's gonna be specifically applying things that are within that actual path. And then as you can see here on the right side, you can see that the components are up and running. So these are the different controllers that I mentioned earlier. If you do notice here though, there are a couple of controllers missing. So Bootstrapping actually doesn't come with the image controllers by default. If you do want it, there is an additional flag you can add on after you bootstrap. You can run the Bootstrap command again with that additional flag. And it will also create those image controllers as well for you. But yeah, you can see it was very simple to get up and running. And after that, you can come back to this repo and now we see that it exists and it pushed back those manifests like it said it would. So we can see that there's this customization.yaml in here. And I just wanna reiterate, I know there's a lot of confusion with the names, but this is what I was talking about earlier when I mentioned a Kubernetes customization. So this YAML obviously tells it to apply these resources. And like I mentioned earlier, the customization controller is so named because it in the background actually creates this YAML as well if it's not already there. But if for some reason you wanna limit the resources or you wanna add patching or things like that, you can still utilize Kubernetes customization as well. It will work with your current setup if you are utilizing customization already. But as you can see here, there are two resources that we are telling it to apply, the GOTK components.yaml and the GOTK sync. So the GOTK components YAML actually creates the flux system namespace as you can see. And then it also creates custom resource definitions that are necessary for flux to work. Along with in this file, you'll also find all of the components, the controllers all declared in here as well. So this is where all of those are stood up. And then the GOTK sync YAML actually has our source and our customized that are created. So the first one you see here is the get repository source and it's actually pointing to this repo that we're already currently in. So that flux demo repo. And it is telling it to listen on a one minute interval. And so that what that means is every minute this source controller will actually come, check this repository and pull in those artifacts. And then here you can also see this customization, which is actually pointing back to that same source wrap that was just created above. And then it is specifically pulling in this case on a 10 minute interval. So every 10 minutes, it will actually take those artifacts and apply them. And then it is also listening like we told it to on that specific my cluster path. So only that path will be applied. Only artifacts found in manifest found in that path will be applied. And then if we go back, I am going to actually clone that repo so that we can actually add a new tenant and push the changes to that repo. And so we're gonna change into that. And then, so this is actually that additional repo that I was talking about that project repo. It's very simple application that we like to use for our examples. It's just a UI that's gonna be created. It has a little simple backend of front end and it's just a few YAMLs in each. And so we're going to be creating basically a tenant that's then going to have a sync pointing to that repo, that additional repo. So now we're gonna create the tenant and we're going to use the flux CLI to do so. You can also, there's two ways to do this. You could, yeah. So first we're actually going to create the directory for this new tenant to live in to be pushed into. And then we're gonna run this flux create tenant command. So I've added this dash dash export command so that it will actually export it into this RBAC.YAML. But if you left that out, it would actually create the tenant. But again, we wanna do everything declaratively. So we wanna actually push this up. So what this is doing is it creates that namespace and then it creates this service account called test. And then along with that, it creates this role binding that then binds the service account and the cluster role to the needed, I mean, sorry, the user reconciler and the service account test to this needed cluster role. So now we are going to actually push this up to the flux demo repo in that folder that we just created called test. And so if we go back and look at that repo, we will be able to see that in there now. So yeah, as you can see, now there's a test with that RBAC file that we just created. So now we have to go tell because the sync interval that we set on this one is 10 minutes. So the customization controller is gonna take 10 minutes to actually pick this up on its own. We're gonna take advantage of something called flux reconcile. So this is actually going to tell the controllers to actually go pull it. And so one key thing here is that you could actually have run flux reconcile source get and flux system itself first and then run the flux reconcile KS flux system. But adding that flux reconcile KS flux system and then that flag dash dash with source actually bypasses the need for that. It basically first reconciles the source and then the customization. So I really love that command. It's just something I wanted to point out makes life a little easier because then you don't have to wait for two commands. And then as you can see here, when I run cube control get namespace, you can actually see that now the test namespace has been created as of 17 seconds ago, which is awesome. So when that was reconciled, it did stand up the new namespace for us. And then now we are going to actually create. Yeah, so as you can see here, the two, the commit actually does match up with the one that is in there. So that's a good way to actually check that. Like if you notice something's not in there, then you can check with the last commit that was pulled by it was. So now we are going to set up a sync for that pod info deploy app. So we're going to set up a source and then a customization as well to actually listen to that other repo so that we can deploy that application in our new test tenant. So here is a flux create source get command. And so basically we're just saying, hey, create this in the namespace test and we're giving it the URL for that, that repo I showed. And we're telling it to export it into this new sync.yaml within the same tenant folder. And then we're going to do something similar for customization, we're going to tell it to create a customization in that namespace. And we're going to point it to that source that we just created right above. And we're telling it to the path is just whatever's in that repository. We want everything to be applied and we're exporting it to the same file. So now if we cat that file, we'll see that there are both of these components. So exactly what we kind of looked at before with the other source and customization, but now we're telling it to create it for this pod info deploy app. And so we're going to push these changes as well into our flux demo repository under our test tenant folder. And so once that's pushed, we can go back and make sure that that's there. Let's make sure it's been pushed. There it is, our sync.yaml with everything that we told it to do. And so now we're going to again, because that interval is a 10 minute sync, we are going to go in and actually run that reconcile command again to get it to speed things up. And once we do that, we should be able to see that the changes are made. So now we can actually do a flux get source get and then the dash a flag is to get all the sources that are out there. And we can see that now there is a test, in the test namespace, there is a new source called pod info. And same thing with the customization, we can see that now there is a customization. And we can also see that it successfully applied. If it was unsuccessful, we'd see an error message where the message is. And so now we can actually go get the pods and test and we can see that both are up and running, just like that customization message told us that it was applied. And so after this, we can actually port forward it and make sure that the app was successfully deployed, which it was. And then now basically we're going to just make a little tweak to the pod info deploy app so that we can actually see flux in action, pick up a change and actually apply it. And so I've already cloned that repo and we're just going to make a small change in the UI color. So you can see here there's an environment variable that controls that pod info UI color. And we're just going to change that value and we'll push this change. And once this is pushed, then we'll let flux actually pick it up and make that actually restart the pod with those changes. So now if we give it a little bit, I'm actually, because this customization only had a one minute interval, we can actually wait for it and let it do its thing. And as you can see, it's already recreated the container and it is almost up and running. Give it another second. Yeah, there it is. So it's already restarted it on its own. We didn't do a record style in this case, but it did it on its own. And then if we give it a second, I did have to actually restart the port forwarding. So that was on me. And then, yeah, there it is. So the background has been changed to the color that we told it to. So that did it all on its own. That's the magic of flux. That's what makes it really amazing is that it just like continuously is picking up those changes. And then what happens when a bad actor comes along and actually makes a change that you didn't want them to. So if someone comes along and makes a manual change or something happens and configuration drift does happen. So what you actually desired is suddenly not the state that's out there. It will take care of you in that case too. So I'm gonna show you that by actually deleting the deployment for the front end. I'm gonna completely delete it manually by running a cube control delete. And so once I do that, you'll see that flux will actually reapply it. So running a cube control delete deployment, it is gone, you can see it's terminating. And then I'm actually going to reconcile it in this case. So we don't have to wait that minute. And there you can see it's already back up and running. It's already standing itself back up. And then if we give it another second, it will be successfully running. And that is really the main things I just wanted to hit on. And yeah, it's a, those were the features I really wanted to show. And there's so much more that flux can do, but this was just a little taste of the real cool features of flux. So that wraps up the demo portion where I showed you how to get started with Bootstrap and how easy it is to get started with flux with that. And then also how to create a tenant and then how to create a source and customization to point to a different repo. And I really hope that this was an informative demo and it really showed you to how truly easy it is to get started using flux. And if you are interested in using it, please check out, we have more information at fluxcd.io. And if you have any questions for us, please reach out on the hashtag flux channel on the CNCF Slack.