About this talk
In this talk, Niels Groenveld, a platform architect at Cegeka, explores the concept of GitOps and its advantages over traditional DevOps practices. He explains how GitOps implements a pull-based model for deployment, contrasting it with the push-based model used in standard DevOps. The session highlights the key principles of GitOps, including desired state management and automatic reconciliation, with Flux as a key tool for achieving these principles. Groenveld discusses how GitOps minimizes sync drift, provides an audit trail through Git, and simplifies credential management. He provides a live demo to illustrate how Flux operates within a Kubernetes environment and showcases deploying applications using Helm. Additionally, he touches on advanced features of Flux and best practices for adopting GitOps within organizations.
Full transcript
No no sound? Yeah, ah okay. I see some hands. Uh great. So, welcome everyone. Uh this is my house actually. So, if you can see on the screen, this is the thermostat and it has two entries. So, as you can see uh on the right side is my partner who's always cold and she's turning the thermostat higher and lower. Wells has a partner who's always cold. Yeah,
okay. I got you back right now. So, I'm going to tell today I'm going to tell you all something about sync drift. on the li- uh on the left hand, uh this is my home automation who is always right, of course, and on the other hand is my partner who's always uh switching the the thermostat. So, uh my name is Niels Groenveld. I'm a platform architect at
Cegeka. I work for various customers where we create uh Kubernetes platforms uh with all the kinds of stuff. Uh we help developers to make their life easier and one of the things is uh GitOps which I'm going to tell you more about. Uh so, other things, yeah, I do something with platform engineering. I do something with Azure. So, if I if you hear me talk a lot
about Azure, I'm maybe a bit biased about Azure. Uh I'm sorry about that. You can forget it. You can do everything also with AWS. I'm also doing a lot of in the open source world with uh so, I'm a cloud native platform. Uh I have some certifications in that. So, GitOps versus DevOps. Um who of you calls himself a DevOps engineer? Okay, I see some hands. I
assume all the ones are developers then. Yeah, kind of. Okay, so I know a little bit what my what my audience uh is. Um so, I think you all know what what a DevOps engineer is. So, we have a DevOps engineer. We got we got dev and we got ops. Uh dev want to work on code. Ops want to work on stable uh machines. Uh management thought,
"Well, wow, let's mix that up together and we got the DevOps engineer." So, this is where GitOps comes in place. So, we make the work of developers, DevOps engineers more easier and we create something where they can work on code only. So, some traditional difference between DevOps and GitOps. So, on the left side you see the traditional model which is a push-based model. So, we got the
developer on the left. He pushes code. He's working on his new application. He's sending the code to get. Then or he creates a pipeline by himself of or the pipeline is provided by an by some other DevOps engineer party or or uh uh department. Um but in the end, your code is pushed to your environment. So, in this case we going we talk only about containers right
now with this half an hour. Um so, everything will be sent to Kubernetes. So, you have to put something like Cube CTL in your pipeline or you have to do some use Azure DevOps or other stuff to uh push your code to production or your environment. So, on the other hand we have GitOps which will make your life much easier. So, we got still got the dev.
We got Git. You push your code to get. But on the end, Flux is pulling your code from Git. So, that's the the difference uh so, you have to take in mind. It's a pull-based model versus a push-based model. And in the end, it will end up in your cluster. well, some principles of what GitOps is. So, I will skip I will keep this very really a
while and then we go to the demo I can show you some real examples. But one I think you have three principles for One of them desired state. So, like I said with my thermostat, the desired state is always in Git. So, what you have in Git is your desired state. What you also will get on your Uh it's declarative code, which means uh yeah, you describe
what you want and not how you want it. If you see a lot of testing frameworks, you can describe some how you want something, uh but in Git how you do put everything uh in your cluster later on. Uh it's declarative, so what I want I will describe it in uh in uh yeah, in my Git. Uh there is Flux, so another principle is automatically syncing and
automatically uh recon recon ciliation. So, your code is automatically pulled from Git and pushed to your AKS environment. And from that on, it will always check and sync uh what's what's happening. So, and that will push to an uh to an AKS cluster. It got some of the benefits, and the benefits of using GitOps over a traditional DevOps module where you use CI/CD pipelines is you don't
have any sync drift. So, if someone applies a temporary work or you have a developer who is uh pushing code using kubectl uh by his own machine, uh he's changing changing your uh request or memory limit or or something else. Um later on, you don't notice. You go from dev to good to staging, and later on, you end it end up in production, and then you notice,
"Oh, it worked on staging because someone changed something by hand." Well, you don't have that sync drift in uh with Other thing is is audit. So, you have an audit trail on what is happening because, well, we all know Git. Uh we who's not using the Git blame if uh yeah, did something uh really stupid. So, really nice feature with audit, which can work in your benefit
or yeah, uh all the way around. Um but with kubectl, you don't have that audit. So, I can do any Yeah, you can look into your Kubernetes cluster and check what's happening, who did it, uh but it's much harder than uh just use the Git blame. Uh and other thing is you don't need your credential uh always. So, once it's set up um Flux or you get
up GitOps product knows credentials and you can push directly to your environment without asking for your cube con context over and over again or set up your credentials in your CI/CD pipeline. So, Flux, that's what it's Small details about Flux, it's since you have graduated since I think three or four years now, 2022 something. So, it means it's really broad adopted inside the CNCF framework. So, we
have a lot of There's a lot of maintainers who are maintaining to the project. One of the things I like, sorry, is it's native on on AKS so I can just click install my add-on. There's an add-on feature which installs all the components you need for for Flux. So, yeah, production proven thing. >> [snorts] >> We have other things for GitOps but today we're going to focus
on Flux but yeah, I think maybe there's someone around here talking about Argo CD as well so you can go to to there if you want to know more about the things. Architecture plates, so what do you Yeah, what do you get? So, once I install the add-on or I do a Flux bootstrap or I would do something else to get Flux on my cluster. I got
all those components. The screen is big so that's great but there's still I got I can zoom in. So, I got the customized controller which is actually a controller where you can use Yeah, you can use customize. Customize is like a tool to put your YAML code and you can do some nice stuff in it to get at the end Kubernetes manifests. So, what I want is
why I want my Helm releases, I want my RBAC code, I want the deployment, I got policies. So, in Kubernetes there's a lot of stuff, a lot of manifests. Um Yeah, you can put on your cluster. So, that all can be controlled by by Then we got our source controller so of course our Git repo needs to be in sync. So, if you got your bound your
Git repo or you can bound a Docker registry or you can bound an Helm Helm repo. Actually, the source control is the is looking at "Oh, hey, can I Is there a new version? Is there a new commit someone pushes?" Um and the source controller will, yeah, take that new take that new information and puts it on your cluster where you can directly use it. Then we
go a little bit down. So, we got the Helm controller over and the Helm controller is actually doing stuff with Helm, of course. But, it's using the the source controller. So, we got our Git repo. You can compare it a little bit with on my local machine I do a Git repo add. Sorry, Helm repo add. So, add a Helm repo to my machine. And after that,
I can install Helm charts. The Helm controller is watching the installation you have. So, I will show you later on. I got some snippets after here. Um how you can specify your Helm release. Um and the Helm release is watched by the by the controller. And we also got the notification controller if something happens or something updates, uh we can send some notification to Slack or any
other tool we are using. So, how do I define it? So, I told you about the source controller and this is actually what the source controller is doing. So, I got my kind my kind is Helm repository. So, this manifest I apply on my Kubernetes cluster is doing actually the Helm repo add. So, in this case, I want a Bitnami chart. I bind it to my to
my AKS cluster. Um So, every time a new version comes in, it's pulled to my to my cluster. Then on the other hand, I got my Helm release. So, that's is where I specify um yeah, how should it behave? So, the the chart the Piccarreta's chart in this example. Um and the version is, like you can see, 17.x, and that dot x means, "Ah, fine. I want
to The major version is keep it on 17, but if a new minor version, uh, yeah, pops up, uh, yeah, install it. Just go ahead." So, this really gives you the flexibility to just do life cycle management within minor versions, um, without doing the the Git commit every time. So, you don't have to change your code all the time. Uh, so, another benefit of, uh, Flux is,
of course, now we have an AKS cluster, and we have all the teams involved on your cluster. So, all the parties are you have everything in place. You have our back control. I got my own name space. Uh, I can deploy to my name space, but, yeah, how does Flux work with deploying stuff to my to other name spaces? So, they have a multi-tenancy module, um, which
you can turn on or off. Uh, it's depending on the on what you need. So, if you have multiple teams running on your cluster, uh, you can just turn multi-tenancy on, and Flux will respect your, uh, our back rules. So, if you are a name space admin, or you're a name space viewer only, depending on what, uh, roles you have, uh, you can use the, yeah, you
can deploy to that to the name space. So, that makes it easy to to implement it within, yeah, or even without creating your own, uh, our back module, uh. So, cool. Uh, I'm halfway my talk, and I have I think that's enough, uh, theory for now. Um, so, I want to show you some things. Uh, this not really handy if I to do it like So, I
got my, uh, cluster here. So, if I take a look at what's inside my Git repo. So, this is Um, these are the components for Flux. So, I already did, uh, Flux bootstrap. So, once I did a Flux bootstrap, I put all my, uh, tools in here. I created a little script, which creates new files here. So, if I do create the very fancy demo script. And
if I do demo deploy, it will deploy a test application. So, it'll put it What it actually does, it is sending code to my GitHub repo. So, this is a test application with customize. Um And inside And it will sync automatically with my Kubernetes So, if I refresh now, I'll have a new Oop. Wi-Fi's not that good. Ah, here I got pod info. So, a new repository
pops up with a release. So, what's in here is an Helm release. So, you can see now, um I put something in my Git repo, which is an uh uh a namespace with some other stuff and a Helm release. So, when I go back to my cluster, and let me check. Let's zoom in a bit. I got my namespace. Uh this is pod info. here it created
three pods because that's what I described in my uh environment. I told you about reconciling. It's going to take a while, so I'm going to scale my deployment so you can see this uh in a bit so that uh Flux is actually healing my uh my cluster. So, someone accidentally put a zero replicas, so it will scale back to zero. Um it will terminate all the pods.
So, now I'm back, I've zero pods. Uh and once the reconciliation loop is done, it will take a look at my Git repo and see, "Oh, um you want three pods actually, so let's put it back. Let's heal your cluster." What did I apply on my cluster? It's here if I search get repo. Uh I got my get repo. This is my flux system and it's also
saying the URL. It's copy It's bound to my get up my own get up. Um and what it does, it's checking out my repo and putting it on the cluster. And if I take a look at the customization file it applied. So, this is the customization apply for actually installing flux and the whole architecture I just described. Uh and this is my application. So, within this application
it's showing uh I have something what I want bound to the take it from this get repo. So, here I can specify what I want, which file, what the path is of my get uh where to get it from So, this is the path I actually I told you. So, it's in apps path info and it is representing to the uh yeah, get repo what I just
showed. So, that's all. Let's see. Let's go back to my pods if they are back. No. Uh no, they're not back. So, yeah, it's depending on how long it will take until uh they go back. It's based on the reconciliation loop. So, you can set it on 1 minute, you can set it on on 10 minutes. It's depending on yeah, how aggressive you want the flux to
to to kick in. If I take a look at the logs. So, here I got all my flux stuff which is currently installed on my cluster. So, here I said the the get repo, my helm chart. This is actually the helm chart um which I put in my in my uh get repo. And reconciliation, yeah, the next run will be in 1 minute. Let's go back later.
Maybe it will uh show up later. It's always a live demo. Let's blame the Wi-Fi for this. Uh So, this is a little bit how Flux works. So, it's it's pulling your checking out your repo. It's putting the files what you want uh directly to your cluster. And if I change something here in the interval or in the pod specs, it will directly sync with my uh
Kubernetes One try? No. Ah. Still zero. one to normal kubectl commands. So, the one I did was Flux bootstrap Set it install six controllers on my cluster, pushes YAML code to Git, uh creates a Git repository by yourself. So, all the stuff is handled by by by Flux actually. Uh so, if you want to try this out by yourself at home, uh use the simple uh commands
and it's directly creating all the stuff you need for your Some other things uh customize is really handy for because now we have our code. But, I can assume I have my base code, but I want something different on dev, and I want something different on staging. How I going to create that without duplicating all my codes? I don't want to duplicate all my code over and
over time and putting my customized files to that location. Well, for that customize uses base files. So, like you see on the right the the tree. So, I have my base files where my deployment is located. I got my service over there. I got my customization file. And in the overlay networks of sorry in the overlay folders, I can specify what to change per environment. So, for
example, I have my my dev folder. I can say this namespace is for dev. Well, how does it look? So, I got my deployment on the right. So, this is my my application on three replicas. And my dev patch is I want my name prefix always to start with dev. So, on that way you can really easy just call all your namespaces, all your services. You can
yeah, create a prefix dev really easy way without just only one manifest which is patching the stuff. Yeah, that. So, other nice stuff which is introduced in since February I think in Flux 2.8. We got empty TR yeah, collapsed. So, when your deployment failed before here, yeah, it came in like an failed state. It took some really it took you a long time before it fixed itself.
So, other things is you don't need any secrets on AKS. So, we can use the managed identities. Yeah, how the secrets how does work? As if before that we have the the Sorry, the left the left one. So, you need your username and you need a pop token. So, for my example, For my example, um use my pod token for my GitHub account, but in that way
I need a pod token. I have to specify it. I have to put it in my yeah, somewhere. So, I don't want my pod token to live anywhere in my code or specify it anywhere. Um so, really nice feature about that is using managed identities. And if you're using a managed identity, the secret is rotated for you automatically. You can just point to your Azure environment. Uh
under water, it it's a service which is sending uh which is getting a token. So, yeah. Really nice feature without putting your your pod token. Uh the other thing is I talked about is yeah, the timeout. So, before you had the like a 50 minutes plus a timeout Um and after that it it's recovering. And now with this new feature, it is noticing like if I do
a bad push, so I push an image which doesn't exist, uh the push controller um directly knows like, "Oh, hey, this how it's supposed to be." Uh it will pause and it will wait for a new commit with a correct version of the pod. And then it will continue with the uh yeah, it will continue his his work. I had a demo for that, but I think
I don't have time for the demo. so, I will continue. Let's check if my pod is back. I have time for that. Uh no. Okay, never mind. So, some free things uh I had to learn the hard way. So, start with one team. So, we were introducing this within the organization I I worked for. Um yeah, don't try to migrate the whole platform. Also, you can do
this uh step by step. So, if you have one team or you have one product or start with that one. Um and all your information in Git uh and try it with one application you are uh deploying. Uh so, the thing is your developers don't have to learn it. Um so, if you do your job right as an platform engineer, uh you create the whole GitOps flow
for them. The only thing they have to do is put their code in Git, and they don't have to bother about CI/CD pipelines. Uh you don't have to create building blocks which they have to use. So, that's don't try to learn them how Flux actually works. Uh let you Yeah, use it and see how it works for your team. And add-ons make your life easier. So, if
I have the add-on, speak for like EKS, I think AWS has the same. Um with the add-on, it's all managed by you and you don't have to uh maintain all the Flux controllers. So, uh next time uh when you have sync drift at home with your partner or anyone else, uh make sure you have Home Assistant in place or something, uh which is always so you are
always the single source of truth. Thank you.
