Cloud Native Computing Foundation Kubernetes Community Days (KCD) Chennai 2022, 30 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitOps Simplified by Saiyam Pathak

Description

GitOps is an approach to having git as a single source of truth for the application that needs to be deployed on Kubernetes. In this session, the speaker will discuss GitOps principles and introduce projects - Argo and FluxCD, the Kubernetes native GitOps tools. These are the two most popular CNCF incubating projects in the CD ecosystem that let you define the state of your application in git and sync with the Kubernetes cluster where it gets deployed. Agenda (i) What is GitOps (ii) GitOps Principles (iii) ArgoCD introduction (iv) FluxCD introduction (v) Demo (vi) Comparison between the tools.

A

um So hello, everyone, today's session is on github, simplified and, uh um like already I'll skip through majority of the introduction. um Most of things are already mentioned. um You can check out my youtube channel and discard yeah, I'm working at cevo, uh so co is a company that provides managed communities based on k3s and there is a community, a cube simplifier that I started that you should definitely join so, let's type into the session uh right away.

A

So what what is git ops, so we will go through a complete flow so that we have a complete story. Why we need it? What is get offs principles and all that stuff uh so get ops is not a very new concept. To be honest, it's been there it's. It has been practiced uh for quite some time now there have been organizations coming together to define, set principles, best practices and uh making sure that it is, it is done in a right way.

A

So when you, when you talk about git ops, everything is in git um your your infrastructure, your applications, everything you are defining in git and it gets deployed automatically, so your infrastructure gets created automatically. Your applications gets deployed automatically.

A

Now, since it is in kit, so it is version controlled, so everything will be a version deployment that gives you an easy way to roll back as well and it it maintains consistency between different teams, devs, ops and other teams who are collaborating on infrastructure parts who are collaborating on the application parts. So all those things are there constant feedback. Constant feedback is very important from the application, the metrics that is getting generated, whether the application is healthy. If any replicas uh goes down, then the constant feedback um is uh important, faster time to production.

A

Yes, um since you are only managing with git, so once the infrastructure is set up and you have github's tools installed, you have all the repositories in place to be watched by different tools.

A

Then the only thing you need is to kind of deploy on kubernetes, uh sorry, the push to get and and it will be deployed to production with the pipeline that have dev stage and testing all the scenarios and going to production.

A

um It also brings standardization across your organization, because um you would know the process of putting out a feature in production or in a particular branch or in a particular cluster. So everything is in in a github's way in managed. You know, managed work it and it brings standard.

A

So overall, git ops in in very simple terms, is everything is in get you have a kubernetes cluster and you have agents that will be pulling information from git and will be deploying clusters deploying applications to the cluster, maintaining um the different versioning of the application and advanced uh stuff as well with which we'll be talking about later.

A

Now I told you previously, like organizations, are coming uh together to create the define the principles so the four principles of kit ops, are it's declarative. So all your infrastructure and applications are as code like, we have already. You know, heard about terraform across plane in previous talks uh infrastructure as code. uh The thing is the true gitops way of doing things is: when you have your infrastructure, also in git repository you commit to git and obviously you have a control plane cluster. So you commit to get your your stuff running in the control plate.

A

Cluster will be watching that git repository and we'll be creating the clusters on the fly, we'll be deploying the apps to the cluster uh versioned and immutable. So that's the second bridge principle.

A

So again, kit is a single source of truth and everything. All the stuff is versioned. So you, whenever you commit you, you get that commit id. You can use the sha. You can use the some of the ci tools and like github actions, github actions, and you can push those uh with respect to that particular sha, and then it will be deployed automatically because the githubs is already connected, pulled automatically continuous pulling of the desired stage.

A

I think in the previous talk you heard about drift and and all those technologies, so that's that's where it fits in, like you have to continuously pull the desired state, because if you have told your application needs five replicas to run. If anything goes wrong, then your get offs in fro or the github stuff that you have deployed should be able to pull that continuously or just observe or monitor the state, which is current, which is the life and the desired, and compare those and apply if there is any differences continuously recycled.

A

Observing the system and applying the desired state is very important when you talk about github's principles, so uh it's continuously recycled you have, you can definitely uh define your interval times uh that you want to do with respect to those different tooling as well. So those are some of the github's principles um that are in place now, my githubs, uh you know I have a ci, I can uh you know I have get. I I can build the image. I can push the image the ci part has already existed for a long time now.

A

But what about the deploy part? The deploying to kubernetes is where the continuous delivery portion comes and regular pipelines in regular pipelines. We what we use, we use, cube, cdl apply uh we. If, if we up, we write some bash scripts or some cron jobs to do this jobs. What we will be doing, we'll be doing cube, ctl apply, we'll be uh providing the kubernetes access and the cloud credentials some or the other way, uh but still the monitoring will be missing right.

A

We again need to have some sort of mechanisms to uh monitor those application and make sure whatever we have in the git repository they are matching with whatever is there deployed in the cluster and if not, then they they do it. That is where gitoffs is needed, uh but it is not needed in this way like in the way where you are manually, doing all these things or somehow uh calculating how to do this.

A

So there are tools that helps you in and doing the get offs the right way, uh especially when it comes to communities and um but get offs, is not only for humanities. It is for the traditional workloads as well, but majority of it is actually being used in kubernetes, so we'll be discussing two tools today, one is flux and one is rbo cd. uh So first is flux, so flux is a cncf incubating project.

A

uh It's a cnca project and the v2 version came early 2022 and it uh flux keeps the kubernetes clusters in sync, with git and automatic updates. um All the points that I mentioned it it does that uh so it syncs from git image reference update in the yaml file, sending notification managing helm releases managing customizations, so you can have yaml files, you can have customizations, you can have helm charts and everything can be in-gate and you have defined your cluster and cluster state and the applications it get.

A

Flux will be installed in your kubernetes cluster, so you will be bootstrapping, uh you know your cluster and installing flux, so you will be bootstrapping the repository and installing flux in your cluster and that will be monitoring the github, uh which is there, the git repository and any change which is there. It will be, you know, uh deploying it to kubernetes in some to some of the node, which is a worker node, where your actual workload runs in a particular name space uh they all like.

A

It supports multi-tenancy, uh multi-cluster deployment and all those stuff as well. uh Let's see on an architecture level how it works, so you have git, gitlab or, um and you have a source controller. So when you deploy flux, there's a component called source controller which is deployed onto the cluster uh now source controller will take whatever is there in the uh repositories and it will talk to the other controller based on whatever is there in the in the repository like the customize controller and the help controller?

A

Now you can use plain yaml files and not customize, but flux automatically converts those yaml files on the fly to customize and then they deploy. So it heavily relies on the customized controller, and then you have the help controller for the hand, repositories so get manifest in the cluster bundle them as uh artifacts by creating custom resources. So we will be creating the custom resource uh for the, for this flux also has something called image: reflector, controller and automation, controller, which means it can monitor the repository.

A

So if there is a change in the image version, the tag, then you can, it can automatically uh take that push that to the git repo and obviously, flux is already monitoring that gate report. So it will apply that changes to your communities cluster. So this is how the complete cycle can be thought of when you are talking or thinking about flux and how it is doing get offs.

A

Now I told you bootstrap, so this is how flux would be bootstrapping. You can use flux, cli or the terraform provider, so the command is simple. You first download flux and you use the command flux. Bootstrap github repository, uh give the owner repository the branch, the path and when you do cube, ctl get parts and stuff like that, so it will have the helm controller, the customized controller source, controller notification controller.

A

All these will be there and uh they are actually as deployments and same, you have the services from them and it will create its own uh directory structure inside the github, um where it will be having a component so that it can talk to flux. So that's how flux works and does uh stuff in a good ops way. uh It's it's! It's pretty interesting! uh Now, let's talk about another interesting tool, which is argo.

A

So argo uh has many projects. First of all, argo cd is one of them, so you have workflows, rollouts uh and and two other projects which are there like. There are four uh main argo is the main umbrella. Rvcd is part of that, so argo cd is not the only one which is there, uh but we are talking about argo cd, specifically because we want to kind of discuss kit, ops, so a typical architecture. What it will look like in today's demo will be a repository in that repository. You have github actions.

A

uh The github actions will be building and pushing um a particular file to a particular folder structure inside the same repository, and you have argo cd, which is installed onto the kubernetes cluster. Argo cd is pulling. The particular directories changes so as soon as there is a change in that particular directory done using github actions, argo cd will pull that change and deploy onto a particular namespace on a node uh wherever the application has to be done, um picked up by the scheduler, of course.

A

uh So that's how today's demo will look like and that's how the argo cd would be looking in the picture.

A

uh So get ops again get as a single source of truth: uh argo, cd, easily trackable, easy roll backs. uh You can have disaster recovery setups, uh for example, you can have a cl um a cluster a across uh b. uh So if a cluster a goes down a cluster b, you can have like pointed to argo cd and you can have apps of apps like the application set. As soon as the cluster is registered, all those apps will be deployed onto the new cluster. uh You can have sso, you can have multi-cluster.

A

So multi-cluster is very, very awesome when you talk about argo cd- and we will be talking about that so same application can be deployed across all cluster using something called application set. It is part of argo cd from the 2.3 onwards.

A

You can also define using customization files, different configurations of the same file to be deployed across different environments, so you can do that using a customization and you can define what all files will be there for dev stage and prod those are very powerful features.

A

It has a very, very rich web ui, which is, I think, enough to do anything for the operators. It also has the cli uh that is there. You can use the cli, for you know, for projects for connecting the clusters um for uh adding the destinations and all that, so on so forth. uh For me to use metrics that you can use audit trails for app events and api calls uh presync and postsync hooks, uh which which are there.

A

So that's what argo cd is uh when it's working, it's very simple and similar to what we talked about user um or a ci, goes and pushes to get so. There is a repo server. A repo server is maintaining the internal cache of the repository, because not every time you need the copy of the whole deposit. You just need the git diff, so it does that.

A

Then you have the main controller, which is there it actually syncs from taking from the repository server and the live straight from the api server, and it makes sure that they both are remain in sync. Replicas goes down, it makes sure they are in sync. Any image change so seen in the repo server make sure it is in sync, um then it it keeps on notifying the ui. So the notification changes are instant like if it goes down, then you'll be able to see in the ui that something is happening. Diff is getting applied.

A

uh All that thing so you'll be able to see that in the uh argo ui as well, and then yes, it obviously deploys to there when you are in ha mode. So argo offers he mode installation very simple, cube, ctl apply command. Is there that you can use for installation uh it install text which can be used for authentication repo server? Is there notification controller? um It started part of as argo labs. So there are many awesome projects going in argo labs and once it reaches reach is a maturity state.

A

Then that project is into our cd so again from 2.3.3, believe or 2.3.x.

A

Notification controller also became part of the main argo cd repository uh and then the server that exposes the api and consumed which is consumed by the cli and the web ui. So web ui and the cli interaction directly with our go server. So you need to provide the server and the app management our back management, so argo has its own rbac, where you can create users and admins and stuff like that auth delegation to external identity providers- ydc, listen, listen to the github web events as well can be done.

A

Also, you get application controller uses argo cd repository server to get the manifest and k, it's api server to get the live state, and it also has uh the redis as the ha proxy, so that was in the um h a mode. So now you know what flux is. You know what git ops is the gitoff's principles? What flux is where argo sets in how they work both. Let's see some of the differences, because uh that's that's also important to understand the the differences. So flux is incubating.

A

Project and r is also incubating project flux is contributing by the 14 companies. Argo is actually much more. uh I forgot to change the number over here, uh so it's it's. I think more than 30 plus uh contributing companies. So argo cd is on a higher state of the contribution in terms of collaboration. When you talk about uh bootstrapping, I showed you the screenshot of flux bootstrapping, so that is used for install and uh bootstrap via the flux cli.

A

There is no native mechanism for bootstrapping, though there is an external project, open source project by code fresh that can be used. uh But again bootstrapping is simple. You just apply ro cd to install, and then you can use the cli to kind of create projects and stuff or you can just use. The argo ui which is there uh next portion is the reconciliation built on githubs toolkit and reconciliation can be set per component, so in flux.

A

This is an advantage where you can set the reconciliation on per object, which is there, but in argo you can it's a global setting, which is there for all. The application in three minutes is by default and can be changed via the config map, but it is not per application. It's like the global setting, which is there uh application deployment. So I told you, flux always uses customize.

A

Even if it's a plane, yaml flux will create the customize on the fly, whereas in argo cd uh it it detects whether it's customized or uh yaml, and it will directly apply it- keeps it closed to cube. Ctl apply for helm, flux, uses, helm native golang library, so you will be able to use the commands like helm, ls and and all that against your cluster.

A

But argo renders that and pipes it to cube ctrl to keep it more native to the cube, ctl apply way and you cannot use the helm cli command against the cluster when you're using argo cd, uh argo cd has something which is called application sets to deploy many deployed too many clusters and you have control over the ordering uh using the sync waves and phases.

A

That is a very powerful feature where you have the control over the ordering, meaning that once you deploy, so you can wait for a particular file, a particular yaml file to get deployed, and then you deploy the next one. So the ordering is in your hands. It's obviously it's. uh It would be more work on the conflict side, but it is possible and it gives you more flexibility and control secrets.

A

So again, there is a big difference in the secrets, because flux provides a guide for managing encrypted secrets with mozilla swaps, cvc clients and all the other stuff. Argo cd has plugins like vault, and it totally leaves up to the user for the secret management, which is, there uh are back again a big difference, uh flux our back, relies strictly on the r back capability capabilities of kubernetes service accounts and all that stuff.

A

Argo cd is very flexible and it has its own user groups mechanism at a very rich, very rich ui, which is there so yes, rocd, rich ui flux, no ui, it has an experimental ui, but that's not official, so we keep it to no ui. So I hope you understood what argo cds fairflux is. What git ops is? Let's try to understand that with a sample demo. So let me reshare my screen.

A

I will have to share the complete window, to be honest,.

A

Okay, so I already have argo cd uh deployed onto a kubernetes cluster, so that will be a very interesting demo, because what I'm trying to show you is the true git tops way of doing things. uh So this is a repository uh kcd chennai that you can find uh there is. There are two uh repositories in it. One is called infra and in infra I will be defining what clusters I want using cross plane that you already, uh I think, learned in the last session. So it is good.

A

So what I have is, I have a kubernetes cluster, which is cube. Ctl get nodes. I already have a kubernetes cluster in place and I have you: ctl get called hyphen a. I already have argo cd and cross plane configured, so I already have cross plane. Sorry, I already have cross plane configured and I already have uh installed the co cross plane provider, the ceo kubernetes cross, plane uh provider, which is already there and you can see in argo system name space.

A

I already have all the argo components which are there, the repo server server application, controller and stuff like that. uh Now uh the thing that we are going to show is, I have an infra project so in in argo cd, this is the ui and you can create a new application which can monitor a particular repository.

A

So what I did is you can go here and you can see the app details, so this project is watching uh the kcd repository the infra folder, so any changes made to the infra folder will automatically be deployed on to this cluster. The manifest will be applied onto this cluster. So what we'll do is, let's create a cluster, so let me show you first, what all is there already so argo cd cluster list.

A

So you can see, I have three clusters, but one is the in cluster where algo cd is already there. One is the test cross plane and one is the kcd all uh both of these are here, and my in cluster is already running in some other region, which is there so.

A

Let's do cluster three. I already have created a live demo example, because this is a live demo. I hope it works, uh so I have defined uh the spec section and all that stuff with respect to sigo uh kubernetes, which is there so I will get add.

A

It comment live demo. It push origin main, so it has committed to this particular repository. So you can say uh the cluster three dot yaml is committed to um this repository and it will automatically sync from this. But what we'll do is we'll do a manual sync.

A

Because we don't have time to kind of wait uh for that, and here we can check, see it. You'll get evil, kubernetes.

A

We'll put that on watch.

A

And we'll apply actually.

A

Yep, you can see the live demo. Cluster is already getting created, so let's do.

A

I say and we'll just make a quick.

A

Yeah, actually, the session got started late, so I I had prepared for 30 minutes: okay, okay, yeah, how many more times yeah I I only take five more minutes. Five, more minutes.

A

So the next thing, which is there is the I'll quickly tell you, because that is very important: the deploy folder, which has the application set.yaml. So this is what I was telling in argo. You can define something of kind application set and it can be deployed to any number of clusters. So when you set the generators, what it means is all the clusters that you add to rbo cd will have this application deployed once it's added, so it will automatically deploy this particular application, and this application will be.

A

You know, looking like this, so uh that's a sample just sample application, which is there. It is coming from this particular repository. So overall, what will be happening? Any changes made to this repository. There is a github action which will be changing the deploy folder and after that, uh any changes. Obviously, application set internally creates application, so any changes made to this deploy folder will automatically be synced with all the uh clusters which are there.

A

So if I go to the applications, I can see uh in all the clusters, which is there like the kcd chennai. This is how the application will be present.

A

So let me just refresh this.

A

Okay, again in in the in the view of time, what will happen is uh once the cluster gets created. You need to run this command, which is again. This gist is available. I will put all the links in the description, so you have to argo cd cluster, add and you have to uh add a cluster pointing to the cube config file and give the server name.

A

So what this will this command will do is it will add the cluster to argo cd and since we have the application set, which is there so as soon as the cluster will be added to argo cd, you will be seeing a new tile which will appear for a new cluster and the application. Will this application will be deployed onto that cluster? So this shows you the power like I can have.

A

I can create hundred clusters, have a mechanism to get the cube, config file and add to argo cd and then argo cd will automatically deploy 100 apps to all the clusters, and you can see the amount of uh you know, effort that will be saved and this just one service. Suppose you have 50 plus services. So you can see how this will work uh yep. That's that's pretty much it that I have to cover for the uh for the presentation and demo.