1:04:49
2022-11-21 11:28:21
44:16
2022-11-21 13:36:53
44:08
2022-11-21 14:41:53
10:27
2022-11-21 15:56:25
Visit the Certified Kubernetes Administrator - Exam Preparation course recordings page
United Arab Emirates - Certified Kubernetes Administrator (CKA) - exam preparation
WEBVTT
-->
Hell is it? I think your voice is breaking, but I am able to see your
-->
Machine now. Yeah, so what is the problem here? CubeCtl scale rs 7b
-->
CubeCtl get rs, but you are not
-->
It says not found
-->
Did you my deployment your replica set name is my deployment by deployment? Yeah
-->
a problem
-->
Deployment
-->
You can scale the deployment you need to deploy. This is the command right you need to deploy
-->
Scale your deployment. What is your deployment name? CubeCtl get deploy do CubeCtl get deploy. Okay, so CubeCtl scale
-->
Deploy my deploy if and if and replicas equals five deploy
-->
Deploy you need to specify the resource name
-->
You are trying to deploy and deployment, right? So it should be CubeCtl scale
-->
deploy
-->
Space my deploy resource name of the resource and then the replicas if and if and replicas
-->
Yeah, perfect
-->
What is that can you please come again with your question?
-->
Okay, one way is
-->
By looking at the labels that is there is no specific commands that you can execute but
-->
From the resource perspective you can pick a label and then you can use it in the sector query if that resource matches
-->
then it is let's say you have a replica set that has a
-->
Just give me a minute go back to the board. Okay, so you have a deployment and
-->
The deployment has a label my my app equals hermohab
-->
Right. So if you want to see whether if a specific part belongs to this deployment, then you can execute a query
-->
using the selector
-->
app equals
-->
Hermohab if that part is listed here, then it is maintained by the top-level resource
-->
Okay
-->
That's how you can see so from the pod perspective. You can't say
-->
What all the top-level resources manage in this part that is not something that you can find only with the label selector
-->
you can identify go to the top-level resource look at the
-->
label selector and query for that
-->
Query for query for the pod with those labels
-->
You
-->
Yeah, you can do that selector equals there are many
-->
You can refer the documentation. Yes. There are many operators that we can use under the selector level
-->
You can use operators like get all the parts that has only this key
-->
You don't bother about the value as long as it has a key get all the
-->
Things and then get all the thing that that has a value in some list of values
-->
There are multiple operators that you can use at the selector query level
-->
Yes, that is possible not app which means get all that doesn't have this label on it
-->
Correct correct, but the best but the best practices in your deployment file just include the label
-->
This is the deployment file for the my deploy if you look at any deployment file
-->
You will see label related
-->
configurations in three places
-->
The first place is under the metadata. We have labels. You see that here labels app my deploy
-->
This is the first place
-->
second place under the specification we have selector and
-->
It also has a label and the third place is under the template. We have the label
-->
See that
-->
So this is the YAML file created by the kubectl client for us
-->
So these three are three different things what this first one is a deployment is created to the deployment
-->
And label is assigned app equals my deploy
-->
So how a label is assigned to the deployment using this?
-->
metadata label under the metadata
-->
Okay, and then this deployment is going to create child revel
-->
replica sets right replica set and parts and
-->
The label that should be assigned to those child level resources
-->
You can see it under the template template label, which means it will get that
-->
labels app equals my deploy
-->
That is this one
-->
the labels on the resources and
-->
The third one is this selector. This is the important one what you give here
-->
This is what going to be used in the selector query app equals my deploy got the idea
-->
So which means in our case, it's all look same, but you can have a different values here
-->
Maybe on the resource level you can have a different labels
-->
But what you give here?
-->
Should be here at least a subset of what you give here should be here because then only
-->
These parts will match to this selector query if you are giving a different labels here and different labels here
-->
Then that that is an invalid configuration. You won't be able to spin up the deployment
-->
So basically it's creating the resources and with the match labels
-->
You are going to this is what will be used in the sector query by the resources like replica set or the deployment
-->
Yes, go ahead, please
-->
Correct part template has is created at run at runtime only will know the ID right so kubernetes will assign it
-->
You
-->
Can do anything this is this is not an assist system reserved label keyword it can be anything
-->
Right. I hope it is clear
-->
So you generally for the applications that you deploy to the production the application team will have more control on the labels that they
-->
Are going to assign and do stuff if if if you miss to do it then kubernetes will do it
-->
Okay, okay going back to the question from hamo, I totally
-->
Forgot the question that came from hamo. So it is about
-->
Or fan parts what was the question again, okay
-->
Got it out of the box. We don't have a straightforward command to achieve it, but with a bit of
-->
Scripting we can achieve it. We can identify the top-level resources get their sector labels
-->
Look for the parts that doesn't have any of those
-->
Top level resource labels and then delete it. So we need to do do some
-->
Bit of scripting and we can automate it
-->
But out of the box, it's not possible. Yep
-->
You are welcome
-->
Okay, I think this is the perfect time to take a quick coffee break
-->
So let's take an coffee break for 15 minutes and refresh yourself and be back by
-->
310 p.m. Thank you
-->
I'm back. I'll come back. So just an
-->
Quick attendance check
-->
Can you please raise your hands in the teams if you're back to your desk? Okay velocity
-->
So I'm not sure I don't have an
-->
Option to record this because this meeting came from your organization
-->
So I'm not sure whether they I don't have permission to start recording
-->
If it is not recorded maybe from tomorrow
-->
You can request your organizer to join and begin the recording so that we can cover these scenarios, right?
-->
And in the last one and a far. Yes
-->
We discussed a lot of things respect to a deployment replicas it and then the parts
-->
you can follow along the video file that I shared and
-->
You can connect with any one of the colleague, but if you still feel that he likes
-->
I really want to catch up on it
-->
Maybe after the training time if you find some time I'm available anyways, so
-->
If we can have a connect for just the 30 minutes or so I can quickly given a
-->
Quick overview on the topics that we covered, right?
-->
So it's up to you so you can check with the colleagues or you can later
-->
I will drop my email is in the email
-->
We can have an quick one-to-one and I will make sure you are on board on these topics. All right, welcome
-->
Sure. Sure. Maybe you can also check with others if somebody has the similar problem
-->
They can also join into that meeting. Okay
-->
Perfect
-->
Okay again, welcome back so we are at the last part of the day one of training and
-->
The thing that we discuss before our coffee break is
-->
We now know how to create a deployment and creating a deployment creates a replica set and then the parts and we know
-->
The role and role of replica set here that is CS equals DS
-->
In addition to that. We also learned
-->
Labels and
-->
Labels select us how this simple but powerful
-->
Kubernetes resource ties up this entire hierarchy, right?
-->
We even learned how to assign and as in the label using the labels in the sector query using different operators
-->
those stuff we discussed and
-->
then
-->
What else?
-->
Yeah, some cases like quarantining apart adopting apart using labels those things
-->
we tried
-->
Okay
-->
so now the next topic that we are going to discuss is about
-->
Deployment itself we created a deployment
-->
But then we discussed more on the features of the replica set
-->
The reconciliation loop it executes and so on so but what this top-level resource deployment
-->
actually does
-->
Or what what all the features that it brings to the table?
-->
That's what we are going to discuss now
-->
so let's say we have velocity and
-->
She deployed an application name of the name of her application is let's say speed
-->
Speed is the name of velocity supplication. I think we are more into physics lessons now, right?
-->
I'm just kidding. So this is the name of the application and right now she developed version 1.0
-->
And she deployed to the kubernetes cluster. So in the cluster
-->
There are hundred replicas of speed application that are running hundred replicas, let's say
-->
And now velocity came up she did some
-->
enhancements and bug fixes and she came up with version 2.0 of the speed image and
-->
now she want to
-->
Roll out this new version of the application, which means all the 100 parts that are running version
-->
1.0
-->
Needs to be replaced with new 100 parts. That's going to run version 2.0. Correct
-->
So how we are going to achieve by specifying something called?
-->
Deployment strategy
-->
At the deployment level
-->
We can specify the strategy as recreate or
-->
Rolling update if you set it to recreate
-->
which means all this 100 old parts will be deleted and
-->
Then new 100 parts will be spin up
-->
Which means
-->
This will come with the downtime the time it takes for all the 100 parts to be deleted and the time it takes
-->
For the new parts to be up and running all the 100 part must go through the liveness probe and it should be healthy
-->
and ready
-->
Then only it can accept the request
-->
So there is going to be a downtime that comes with the recreate strategy
-->
but if we choose rolling update, let's say velocity chosen
-->
strategy as and rolling update for our application and
-->
Under the rolling update she can make use of couple of properties. Let's say max unavailable
-->
max search
-->
She can give Alice for both but just to give you an idea, let's say she said max unavailable as and 25% each and
-->
Then she update the image and apply the DML file. Then what will happen is
-->
Because she specified max unavailable as and 25 you have 100
-->
version 1.0 running and
-->
You set the strategy as and rolling update max unavailable 25 and you trigger the rollout
-->
What will happen is it will bring?
-->
25 version 1.0 parts down and
-->
Then you will have 75 version 1.0 running
-->
you will first bring the cubanets will first bring 25 parts down and
-->
Then it will bring up version 2.0. Let's say
-->
so which means at that moment you have
-->
75 version 1.0 and 25 version 2.0 and again another
-->
25 version 1.0 down bring 25 version 2.0, which means at that moment you will have 50 version 2.0
-->
50 version 1.0
-->
Right. So similarly did this iteration this iteration will move on and at one moment
-->
All you have is 100 version 2.0 zero version 1.0. So if you look at this process
-->
rollout process
-->
There is only 25 percentage of the parts were unavailable
-->
Because the max unavailable is set to 25 only 25 parts were unavailable
-->
75 parts were available throughout this deployment process
-->
which are
-->
Processing all the records that this application receives. Okay, you're bringing down only 25 percentage 25 percentage 25 percentage
-->
And then bringing up new parts
-->
Which means during the rollout process you have mix of both version 1 and version 2.0
-->
Which means it's your applications team's responsibility to make sure these two versions are backward
-->
compatible if there are any breaking changes then
-->
Users will face errors if they try to access the application during this rollout time
-->
So there are breaking changes, obviously need to go with
-->
Recreate or some other deployment patterns in combination with recreate. Okay, that is max unavailable
-->
She can also set max search
-->
What it means
-->
Here in the unavailable scenario, we have 25 parts that are unavailable, right?
-->
What if if your application is really really
-->
doing busy and
-->
Even the 25 percentage unavailability you won't be able to tolerate you really need that 100 percentage
-->
That is 100 parts all the time. Then you can play with the max search property and
-->
How it's going to work instead of bringing down the parts. It will spin up additional 25 version 2 0 parts
-->
You will have version 1.0 running and a surge of 25 percentage that is 25 parts will be spin down
-->
Once it is up and running then I will bring 20 parts down
-->
Kubernetes will bring 20 parts down so that you will have a mix of this and then again additional and then bring 20 down
-->
So similarly the iteration is going to move on 25. Sorry 25 25 25 something like this
-->
You will create additional parts here you are deleting the you are setting the unavailable here you are setting the search
-->
Okay, so you need to be careful while while doing
-->
setting high value for the search because
-->
You are spinning 25 new parts. Do you have?
-->
Enough resources in the cluster to accommodate that new 25 parts, even though it's going to be for a short time
-->
But do you have the resources if resource is a constraint in the cluster then better go for max unavailable and set some lower percentages
-->
Okay, so that the deployment that week this go ahead please 75. Yeah, it should be 75
-->
Yeah, I made a mistake there. Okay
-->
So that's the whole idea here
-->
So for the deployment that we created we didn't specify the strategy at all, right?
-->
So the default is rolling update with max available and max suggests and 25 25
-->
so if I do keep CTL get deploy you can describe the deployment and you can understand the
-->
Strategy but then if you output it as an AML and if you scroll up here you can see
-->
Strategies rolling update with max search max unavailable as a 25 25
-->
Which means at the same time 25 will be brought up and then 25 will be added
-->
Right, so you can configure one of it or even you can specify some hard numbers instead of the percentage
-->
Right purely depends based on how we want you can configure this so this is this is the two strategies
-->
Recreate and rolling update that comes out of the box from the core kubernetes distribution, right?
-->
So on top of it you can traditionally we are following some kind of deployment patterns right?
-->
Canary deployments blue-green deployments
-->
So those patterns you can apply on top of this any one of these strategies that has nothing to do with kubernetes
-->
But out of the box from the kubernetes at the deployment resource level you can specify the
-->
Strategy
-->
recreate and rolling update if you are going to set max unavailable as an 100 percentage if you set max unavailable as an
-->
100% it is nothing but the recreate strategy
-->
Isn't it because it's going to do the same behavior and that what's deleted
-->
Create under new parts. That is nothing but the recreate
-->
Okay, so
-->
Resource level that is number one. Let's say
-->
Velocity see chosen rolling update as the strategy and she set some values for the max unavailable
-->
So she is all set. She already chosen the strategy now
-->
she included those values in the deployment dot eml file and
-->
She updated the version of the image from version 1.0 to version 2.0 and then she is going to apply that eml file
-->
the moment when she applies
-->
It's going to trigger
-->
the rollout
-->
Rolling out the new version of the application rollout
-->
Based on the strategy. It's going to bring down bring up bring down bring out bring down bring up and after a few seconds
-->
Or a minute. It's going to complete the
-->
Rollout process correct. So while rollout is in progress. You can actually view
-->
status of your rollout kubectl rollout
-->
Status for the deployment
-->
My deploy so this will actually show you and a running update of
-->
the deployment progress you can even
-->
Pass a rollout. Let's say already some 50 percentage is completed and
-->
You are seeing a lot of alerts
-->
Coming from the cluster and
-->
You suspect maybe this deployment is causing this rollout is causing some issues
-->
So you may want to pause that rollout for a moment
-->
To observe those logs and informations to see what went wrong so you can pause it
-->
so which means it will simply the rollout will pass it to the current state, which means
-->
40 old 60 new it will simply stay in the same state without any progression and
-->
After analysis you can simply resume the role or resume
-->
and
-->
Once the rollout is successfully completed, which means all the old parts are replaced with the new parts
-->
You can actually view
-->
The history of rollout for that specific deployment
-->
for example velocity
-->
humans back to started with zero point one point six zero point two point three zero point three point five one point zero point
-->
Today she is deploying one point zero point two for the speed app
-->
So she can actually see all this
-->
history of rollout she performed for that specific deployment speed and then today she deployed this and
-->
after deployment
-->
there are a lot of errors that are there are a lot of incidents that users are reporting and
-->
Then you found out that
-->
There is an bug in this specific version one point zero point two
-->
You can easily and undo will
-->
Will revert back to the previous version which means all the 100 parts will be replaced with
-->
parts version one point zero point one
-->
This is again going to trigger another rollout. You can undo to the immediate previous version or you can even go back in time
-->
specifying to revision
-->
From here you can go back to zero point two point three
-->
Let's say each each will be associated with some kind of revision number
-->
So you can specify that revision number here to revision number two that is associated with zero point two point three version of your application
-->
So status pass
-->
resume history
-->
Undo you can do all of these operations for the rollout
-->
Which is associated with an deployment resource
-->
Okay, so with this I'm going to quickly demonstrate that so that you can also give it a try
-->
So we already have a deployment, but I'm going to create a new deployment for this purpose kubectl create
-->
Deployment I need an an image with different versions, right?
-->
So I'm going to pretend like the developer of the application and I'm going to deploy
-->
Multiple versions of the application so for that I'm going to pick any image from the docker hub and I'm going to try
-->
Deploying multiple versions of a same application
-->
Let's go with the same engine X
-->
Okay, I'm going to first start with
-->
One point two to a fan Alpine and then I am going to update it to one point two two and then
-->
point
-->
To three Alpine and
-->
Then finally to the one point two three. Let's give it a quick try
-->
So first I'm going to start with one point two to a fan Alpine tag
-->
image
-->
Engine X and the code tag is one point two two
-->
Something wrong with me
-->
Keyboard engine next one point two
-->
See, I forget the tag name already one point two to a fan Alpine
-->
And the name of the deployment is my web
-->
And I want to get the ML file for this
-->
I
-->
Output as an ML
-->
Perfect I'm going to write this to an ML
-->
I
-->
Perfect let's open that file
-->
Come on I'm trying to open a file
-->
Okay, let's go with this defaults if you want you can clear it up it's up to you
-->
I'm going to go with the default strategy. I'm happy with the default strategy
-->
That cubers is going to assign
-->
Let's keep it simple
-->
Okay a more simpler version
-->
And I want let's say
-->
Some fire replicas and it's going to use this image, right?
-->
So as like labels
-->
We have one more cuban its resource called annotations
-->
So be aware of the indentation under the template in the same indentation as labels
-->
I am giving
-->
Annotations
-->
Okay, it takes the same format as labels
-->
But annotations are meant for different purposes
-->
annotations are heavily used by automation tools or
-->
Kubernetes is also using heavily the annotations. There are many
-->
system reserved keys annotation keys that we will use to enable or disable or to set some system level
-->
Properties kubernetes system level properties. You can also use any
-->
thing like for example
-->
Logo URL and then you can give the URL for the logo PNG something like that
-->
You can put some metadata informations on the rotations also
-->
right, for example, the build tool will use annotations to
-->
put the
-->
Build hash template something like that. Okay
-->
You can't use annotations in the selector query
-->
You can use label only label in the sector query
-->
Alright, so for the annotations we have one system
-->
Reserved annotation key called kubernetes at IO change cause
-->
some user-friendly text
-->
That you can have as an value for this rotation
-->
To quickly identify what's happening with this rollout for example
-->
Deploying initial
-->
Version
-->
1.22 if an Alpine some some user-friendly text that you can provide here
-->
So this is going to reflect in one place that we will see in a moment
-->
Okay, this key isn't reserved one
-->
Fine, so with this change now, I'm going to save this file and apply this yaml file
-->
We are deploying the first version of our application kubectl
-->
Apply if nf my web
-->
Kubectl rollout
-->
Status for the deploy my web
-->
As you can see it's showing as there as a running update on the current rollout
-->
Successfully rolled out perfect. So now you can view history of this deployment
-->
So far we deployed only one version
-->
So it should at least show one entry
-->
See revision number one
-->
That that the annotations that we gave it reflected here, right if you want to view more information little bit more information
-->
about that specific revision then you can use revision flag and
-->
specify the revision number
-->
That will tell what is the image that's used?
-->
and
-->
some additional metadata information
-->
Okay, we deployed our first version and we are able to view the
-->
Rollout history comments, right? So now I'm going to make a change. I
-->
Did some bug fixes and enhancements. I came up with the new version 1.22
-->
Go back here and I'm going to update the image
-->
To use the 1.22 version
-->
I'm dating from 1.22 Alpine
-->
So in this case, I'm manually updating it so in your CACD scenario
-->
You can add an annotation automatically
-->
After your build process and everything is completed so that it will get reflected updated from
-->
1.22 to 1.22
-->
And save the file
-->
I
-->
Play it so which means all the five parts will be replaced with new five parts that uses version 1.22
-->
Cubectl apply
-->
Cubectl rollout status
-->
Based on the strategies that is there in the ML file it's performing the rollout
-->
and
-->
Perfect so if I do history again
-->
Now I can see to two revisions under the history, right?
-->
Let's deploy one more and then we can try down to operation pass and resume. You can try it while you are
-->
Doing the hands-on. So let me show the undo for that. I am going to deploy one more revision
-->
Let's say I'm going to deploy 1.23
-->
Back open your email file
-->
Dating from
-->
You
-->
Bear with me there is an split-second delay when I'm typing here
-->
All right save this
-->
Go back apply it
-->
Okay, so if I do history again I
-->
Can now see three revisions, right? So let's say after deploying 1.23
-->
I'm getting some errors and blah blah blah. I want to roll out then the same command roll out undo
-->
The deployment
-->
My web if I press enter it will roll back to one point two two half one point two two
-->
The immediate previous version if I want to go back then I need to put
-->
Two revision and specify the revision number
-->
Let's say the revision number is one
-->
And you can view the rollout status the parts getting being replaced
-->
And it's successfully rolled out and
-->
If you view the history now
-->
One became for the revision number will be keep on incrementing so one
-->
Became four. So we don't see the one here because it already became four, right? So we deployed the initial version back
-->
Okay, so these rollout features are available only at the deployment resource level
-->
This is not applicable for replica set this is not applicable at the pod resource level
-->
Okay, so that's the two thing that we learned from here one is strategy second is
-->
Making use of this rollout capabilities
-->
well, you are
-->
Deploying the new version of the application. So how many versions it will it will maintain that also
-->
You can have more control. Let's say get deploy
-->
my web
-->
Output as an email
-->
There is one default here revision history limit so by default it will keep past 10
-->
rollout
-->
In the history if you do if you do rollout history command if you want 100
-->
Then you can include this in your email file and then put it as an handle simply over at this default
-->
Okay revision history limit
-->
How many revisions you want to see positive visions
-->
Alright with this our
-->
deployment
-->
resource
-->
Comes to an end. I am going to share this email file with you
-->
Please give it a try any questions on the deployment
-->
Deployment and in the rollout features
-->
Let me also include the kubernetes documentation
-->
You
-->
Okay, it already has all the information that we discussed
-->
Okay, so
-->
Yep, any questions before I give time for you to try this any questions on the deployment. Perfect. Let's give these comments a quick try, please
-->
Yes, please is that a question
-->
Why we use dry run is that a question
-->
Okay, so okay, so if you are
-->
If you want to create an email file from scratch. Yes, you can go ahead and you can write an email
-->
from scratch
-->
specifying the API versions kind
-->
Specifications you can define it as a kind
-->
Or you can copy from the kubernetes documentation some templates and you can modify it right there are two ways
-->
Scott from scratch or get a template from kubernetes documentation
-->
another way is
-->
You are right. You are writing some kubectl command behind the scene
-->
This guy is translating your command to an email and then submitting to the API server
-->
If you do kubectl create deployment and press enter is generating an email file and is submitting it to the API server
-->
So what we are going to do is we are going to ask this kubectl
-->
For the command that you wrote a dry run, which means don't submit the request to the server
-->
Just print the email that you will you will send it to the server, but don't submit to the server
-->
Okay, and we are able to see that email and have we are writing it to an file and having that as a base
-->
We do some changes and then we are applying on our own by using the application. Okay, dry. Okay this option, right?
-->
Okay, you can also give it a sense server, which means request will be submitted as well as you will get the email
-->
I there are multiple options that you can do here
-->
Okay, let me show the
-->
Client means at the kubectl client client refers to this kubectl client
-->
Okay, so you can give options like
-->
dry run
-->
client kubernetes
-->
Let me show from the documentation
-->
So you can't set it to server
-->
Where is it? Where is it? Here it is
-->
It can be non server or a client if if it is a client
-->
Then it will only print the object that would be sent without sending to the server if server
-->
Then the records will be submitted to the server without persisting that resources
-->
Go ahead. Correct. Correct
-->
So basically, yep, if we don't persist that resource to that city, so it's also more often writer, correct
-->
So, yep
-->
That's the purpose come again
-->
Sorry, I missed the question
-->
Yes, so basically every request that you submit because you ask this question
-->
Let me provide a quick level over here. Whatever the request that you submit from your client or dashboard or GUI
-->
The first component that's going to process is the API server, right?
-->
so
-->
in the API server
-->
within the API server
-->
Let's say this is the core logic that's going to persist to the etcd database. Okay, so before that core logic
-->
kicks in your request will pass through three gates that I mentioned in the morning at
-->
authentication
-->
Authorization admission controller. So if and only if your request passes in all the gates, let's say
-->
Velocity is an valid employee
-->
Velocity has a permission to create a deployment
-->
velocity
-->
In each spot specification. He has all the required namespace information resource information something like that. Then only it will be persistent
-->
So when I say by persisting this is what it is
-->
Storing that specification in the aml file by including all the defaults and stuff
-->
Okay, so to answer your question. Yes, if there are something that are missing
-->
Let's say you're submitting without request
-->
But you have an admission controller that will perform some validation if an if an request is missing reject the request, right?
-->
So those validations will happen. Of course
-->
If you submit right and as a client then it will go through the admission controller layer level
-->
Authentication authorization, it will be simply rejected if any one of it fails. Okay, you can try an example with dry run as a server and observe the
-->
difference
-->
Setting dry run as a server and without dry run server and submit a resource and find the difference. Okay, I hope it helps
-->
Dry run server
-->
Let me see if I can include some documentation link so that you can try it. Okay, so here you can see that
-->
Look at this one if you are giving it as an server
-->
Your request will actually go through
-->
authentication authorization and then the admission controller at the admission controller layer level
-->
We will do some validations. Even the kubernetes can do some mutations, which means as
-->
Administrator you can run some admission controllers that will do some modifications to your request, which means
-->
What you submit is not what you are going to see in the kubernetes because
-->
Your cluster administrator may have an admission controller that will perform some mutation
-->
let's say if you are submitting and request without namespace an
-->
Admission controller will include a namespace with value as and Luis
-->
So those kind of manipulations also we can do so if you dry run as a server
-->
it will go through authentication authorization and then the admission controller step and
-->
then that
-->
File object will be returned to the user
-->
It won't be persisted to the etc database, but it will go through the server side process
-->
Which means you will already see the one that has the defaults and steps already included in it
-->
But in the client you won't have the defaults included because the default included logic happens in the server side
-->
Okay, is it clear or I did I confused you a lot already? Okay, great great there
-->
Good I could see a few of them already completed the rollout exercise good job
-->
Okay, I think we are at the end of the training so if you are progressing you can continue on this
-->
We only have five more minutes left to conclude the day one
-->
So I'm going to do a quick review on the topics that we completed today
-->
Let me go back to the
-->
Agenda one that we discussed in the morning. It looks like we covered only few resources
-->
But then the knowledge that we gained. Yep. Go ahead
-->
Change cause okay. Let me share it
-->
In the chat. Okay, maybe you need to look at your
-->
Intendation
-->
Yes, sure sure sure sure who is this? Okay training room
-->
Are you in the training room? I'm not seeing you here