Question, do you consider yourself a lazy person?
Yes.
Okay.
Like me, you can find this talk very interesting, I think.
So, we are here to talk about Augusti D Kubernetes, of course, and we will see later
how laziness deal with Augusti D and Kubernetes.
Before starting, let me present myself.
I'm Graziano Casto, I'm from Italy.
That's why we are named.
Lugger?
Okay.
Yeah, thank you.
Can everyone hear me?
No.
Lugger?
This way?
Okay.
It's great.
Anyway, I'm a developer election engineer in Akamas,
and Italian company in doing performance engineering stuff on Kubernetes.
I'm an open source contributor.
I'm a tech lead to the CNCF talk developer experience.
And Kubernetes is a really steam member.
If you want to know more about how to contribute to contribute to the developer experience
talk or any other talk in the CNCF or join the really steam
Kubernetes or other seek, let me know.
I'm here around the conference for the whole day.
You can check my link link to connect with me or check my website
and get all my articles and my talks.
By the way, this is me at 3am working on my site projects or working projects.
Something that was wrong and I need to change something on the cluster.
Behind the scene, there is RGCD, of course, managing all the resources.
And at 3am, I do the most reasonable thing that everyone do.
To open Kubernetes and fetching the resources directly on the cluster.
Wait for a couple of menus.
The change is live, everything is okay.
And I go back to sleep.
The problem is that you can have two different situations here.
The first one, self-healing in Nagasaki D is enabled.
So your change is after, let's say, five menus is no more in the cluster.
So you should awake back to fix the issue.
The second one is, okay, I'm going back to sleep.
But tomorrow morning, I will update back my repository to bring back the changes into the repository.
But guys, I'm not only lazy.
I also forget to do something.
And someone else, day after, update the Git repository,
figure the RGCD and new changes go on.
The cluster overriding my changes from the last day.
So at this point, everyone have a problem.
The only point is when.
Soon, if you have self-feeling on the RGCD,
or maybe a couple of days later.
So the problem is not that I'm lazy.
Yes, this is a problem.
The problem is that working with GitOps,
we assume that the Git repository is your source of truth.
That's just a lie, because the Git repository is your source of intent.
It's like watching at a map and see, okay, from the point A to the point B,
it's just a straight line.
But in the middle of this straight line, there is a mounting.
So you can't go straight to reach your destination.
That's the same with the cluster.
Someone else can fetch the resources with Cubsitial.
Your self can fetch the resources and forget to bring back the changes
on the Git repository.
Or you can have some operators or agents that do something
on the cluster without a human in the loop.
So the Android Ruby in this situation is very high.
And you can't be sure that the Git repository
is exactly the state of the cluster at any point into the timeline.
Just to give you a final example of this analogy,
every you, there is someone from Portugal here.
No? Okay, that's one. Sorry.
I traveled for the first time in Portugal last year.
And I was very happy because I was able to find a cheap photo
just 500 meters from the conference venue.
Then I realized when I was there that working for 500 meters in Portugal
is not the same like working for 500 meters in Milan.
In Portugal is more like hiking than just walking.
And that's the same.
By the way, how can we solve this situation?
The idea is to have a mechanism, a process or something we will see later
that do a pre-flight diff when you open new PRs on your Git Observatory
to check that what you have in the exact time you open the PR on the cluster
is what you are actually managing with the new PR you're opening on your Git repository.
This way you are able to think changes if no drift are detecting on the cluster
between the cluster and the repository or block the sync if something is
drifting for the initial state.
And hopefully you can also have a report that, okay, this is the fields
and to your resources that need to be changed to to be compliant with your cluster.
So let's start with the demo and then I will show you all the phases of this pipeline.
I recorded the demo to avoid panic time and I hope that the video is working.
Okay, this is my Git Observatory.
First thing I'm going to apply the RGCD application to deploy my initial state on the cluster.
Okay, now let's check that my services are running.
This is the simple guest book application you can find on the Kubernetes documentation.
It's a front end and not back end, basically.
Okay, everything is running.
Now I will move to the deploy section to scale the replicas for the deployment
from free replicas to five.
Okay, I recorded it yesterday night so maybe something is not very straightforward.
Okay, five replicas.
Now I'm patching the resource.
Let's wait to scale in place.
Okay.
Now back to the Git Observatory where my RGO application is.
First, open the branch to create the PR.
Okay, let's say this is the day after.
Another colleague wants to update the limits for the deployment.
So open the branch, create the PR.
RGO application targeting the main branch on the repository.
This is the front end.
You can see that replicas here is still free.
And I'm going to update CPU and memory request to 400 million.
Okay.
Nice.
Now I can make my changes and I'm opening the PR.
Why I'm using GitHub desktop because I'm lazy.
I don't want to interrupt with the terminal.
Okay.
Create the PR request and now a pipeline and GitHub version is triggered.
That now is triggered.
That basically install a tool as a scroll call call.
I will show you later what call call is.
Basically do as an upshot of your entire cluster state into a temporary folder.
In this case, or you can just do it in another repository.
And do and perform free ways merge.
Between your base branch, your PR branch and your snapshot.
This way it can detect which are the intentional changes you did in your PR.
And which are the brief.
After this track provide you into the GitHub, include PR comments, a comment.
Showing you the diff of only the drift detected.
Okay.
Now it's going to do this snapshot for the cluster.
Okay.
Drift detecting into frontend.yamol.
Okay.
And now the job is completed.
Let's go back to the PR.
This is the error.
Back to the poor request.
You can see that first a new label was added to the PR.
Call code 9 that identifies all the PR that can't be merged because of drift.
And you can see the difference found into the PR compared with the actual state of the cluster.
Now I'm back to the code.
Bring back the change.
Call me to the new change and now the cluster should be aligned.
When the change is pushed, the pipeline is triggered again.
Perform the same check with another snapshot.
So every time you run this GitHub action, a new snapshot is created.
Just to ensure that the cluster doesn't change from one commit to another.
And now after all this process, you can see that the label is changed from Calco.
Then I took Calco proof and the report is basically clean.
You can see some error because to access to cluster level resources.
So I have to configure my user in a certain way.
And just for your demo, it doesn't make sense to do that.
The cool thing is that this is a simple CLI application using the go client for Kubernetes.
And you can access all the resources available in the cluster.
So if you are using, for example CRD for cross plane, whatever.
You can export all so the CRD, not all the way deployment services or whatever.
Calco proof new changes and you basically can merge the PR.
If there are a bunch of tools, you make the main calculation to sort time the name at places.
Sorry, I've left.
Can you limit the drift calculation to some name at places to set off at places?
Yeah, the Calco validates command, I will show you later, have a namespace argument to limit the,
this is an option to only this namespace.
Now, the tool is called Calco is a site project I did it this summer in Croatia.
By the way, you can scan this small QR code, but I will show you the link to access the repository in the documentation.
I created this tool for another use case to have this snapshot to import the resources from one cluster to another.
Then I implemented the auditing feature.
You can create your snapshot repository and scan your new snapshot giving a deep between the last one and the previous one with the report.
And now the use case that validate the git flow process.
The feature itself is very straightforward.
Export, I'm using the several preferred resources from the discovery PI into the go client for Kubernetes.
I synthesized the resources because before creating the manifest removing some annotation or metadata because then there's a very big and commit a push into your GitHub repository.
This is all the phases for my PR first.
The PR is running on the CI pipeline is running on the master branch for every change into the manifest folder.
And this is my RGOSID application.
This is important to disable the self-feeling because in that way you are able to deny RGOSID to override your changes live on the cluster.
Then you can download the Calco tool directly from GitHub releases or you can use brew if you're using macOS, for example.
And the first thing to do is to create your context.
So you create your context by giving the cube a config to access the cluster.
You want to create the temporary folder and give a description to your context.
The second step is the drift check.
First thing you perform the export simple Calco export there is other arguments to customize the export but for this simple use case is enough.
The output is a folder like that.
So your cluster namespaces resource type and single resources.
Then there is the Calco validase command which is the one that performed the free way between the resources.
This command have different arguments.
The first one is the base.
You should give to Calco the base branch for your repository in this case master.
Then the directory where the files are stored, where you want to perform the default.
There's an option here that the temporary directory we created with the Calco export.
Here is the name space argument so that you can filter your resources and perform the validation.
Only so only on the guest book name space.
And the name for the report file which will be used for your comment into the PR.
This is how Calco validates works.
The first thing is identifying the changes into the PR.
So check out the master branch, check out the PR and do this first diff.
For any changes do the free way diff.
In this way he can distinguish between intentional diff.
So the diffs that are into the PR and the drift which are not into the PR but are live into the cluster.
And then generate the report.
Of course now I'm doing this demo to keep it simple with raw manifest.
So final llamals you can use it also with help or customized or other templating system.
Just needed another first step before which is the rendering of the chart.
You are not going to use the Calco validate here because Calco validates just the autopilot to work with final files.
You are moved files which basically iterates over all the files found into the repository.
Calco diff is an internal command that do the same thing basically but file per file.
So you should iterate into the CI pipeline.
I'm working to do a similar thing without just to improve the developer experience.
Let me say this is the final step.
So the labeling is a simple call for GitHub action.
You can get the final report into GitHub document and the label Calco Denio Calco Plough.
This is customizable.
And that's all basically.
Do you have any questions or?
Can you use the scope of the chart also just to make the default one in namespace of a project in a sense?
Can you use the scope of the export or the validation?
Both.
Okay.
That's right.
We have a quick discuss about like 600 namespaces with the project and something like that.
Would be too much.
So for the validation, you can use the namespace guest book to filter the validation process only on one namespace into your export.
If you want to reduce the export for your entire cluster, I'm working to bring the same arguments to the export command.
Right now it's just export anything.
Exactly.
Yes.
So on the same field.
Yeah.
Okay.
So what happened if I'm changing into the PR, the same field that was changed into the cluster.
Like in the example, if I change the replicas.
For example, right now the standard behavior to give it simple is the PR win.
So if you are updating the replicas, the PR wins over the cluster state.
I'm working on that to implement another argument to decide if you want to have it as a drift into the comment and then decide if emerging the project.
If emerging the PR or evaluating it in another way.
Any other questions?
When?
What?
Sorry.
What?
Can you repeat the question?
Okay.
Yes.
This is.
Yeah.
This is a not-to-mitted process to avoid you to access from the PR.
And I'm using this tool that actually was born for another use case, which is the cluster not-shocked thing.
Because I created this tool to have an exact copy of the cluster to move resources from one cluster to another from our namespace to another or to input the resources into an RIP for example.
Then the tool was evolved to create a no-dating for the cluster.
So basically the same tool is running into a job.
Create this no-shocked each night and create a report from the last no-shocked to the PR.
This one.
Creating a report to okay.
Today you changed these fields.
Then since the calculation was already up and running into our CI, I used it to implement also this use case.
But yeah, you can use directly our capacity.
Any other question?
There is also another project R goes March D for something or do something similar.
I don't remember the name.