Certified Kubernetes Administrator Exam Preparation | Videos

language: EN

                  WEBVTT
as a team and then quickly troubleshoot so that everybody can be aware of what's
going on with you all right so it's up to preference if you want to be part of
this group you can join if you prefer more to be working with your own
window you can do it right perfect so you are in the classroom you have
access to your virtual machine so in this virtual machine it already
Docker is installed
okay so is that what about others maybe because of some temporary connection
let's wait for a moment and let's see if it works after that okay joining the
training room is not a mandatory thing if in case if you are facing any
issues while doing some hands-on and if you need my help it will be easy for me
to quickly pick into your mission as long as you have access to your
virtual machine that's okay now                

on 2022-10-26

language: NN

                  WEBVTT
i think it was a mistake on that command francoise you don't need to specify part
keep ctl port forward my engine next you don't need to give to give the part that
it was a mistake on my document there apologies for that i just noticed it i will correct it
all right
i could see most of you already completed maybe i will give some additional three more
minutes i could see some few busy hands still
all right time up time up for this activity if there are no questions let's discuss further
on the same part commands any questions perfect so what we did is we created a part
imperatively which means with cli command run command we created it but now what we are going
to do is while you executed the cube ctl run this cube ctl client it created an equivalent
aml file for your command and it submitted that aml file to the cluster to the minikube
cluster so what we are going to do now we are going to write one aml file from scratch let's
say and then we are going to submit this aml file to the cluster with the help of cube ctl
where we have more control on specifying a lot of specifications okay so instead of
creating something from the scratch we can actually seek the help of cube ctl cli hey can
give me some the aml file that you use to to for this specific command let's say the same command
cube ctl create pod where is it
this one cube ctl run image nginx my part so if i press enter the request will be
submitted to the server and the part is created immediately correct so instead of that
i can actually add some couple of flags here if and if and dry run
dry run equals client and i want the output in an aml format so this is the new flags
that we are adding dry run as a client and output it as an aml so if i press enter
cube ctl won't submit anything to the server side it just give princess the aml file here in our
terminal so if i do cube ctl get parts that's the above command didn't created any parts
because it's it's the command doesn't reach the server it was just a dry run on the client
side where we got the aml file
okay so you can have this as a base
you can do whatever the modifications that you wanted to do for example i am going to
create a folder here
documents
sample
so let's say here i'm going to write the content this is pretty much the content that i'm going
i'm going to write this to an file and i can open the file in an editor or any editor of your preferences and i can do what are the modifications i need to do let's say i'm going to do some modifications on this yaml file let me increase the font size a bit
okay better compared to the previous one so here there are some properties maybe in all properties i can remove to keep it simple this data dns policy let me come up with an minimal
yaml specification that's it apart as you can see the api version where this the controller can handle this resource and the kind this part which means you are going to create a part if you are going to create a deployment kind will be deployment
so here you are specifying the resource that you want to create and then the metadata for the resource which means the label that it should put on it the name of the part
and then for the part you need to depending a specification under the specification you have containers which is in plural so you are going to give array of container specification but we have only one specification here let's say i'm going to call this container as in my container
okay so this is an very simple basic part specification so you can write from scratch or you can or any for most of the commands you can do the dry run client flag and output there is an email and then use that as a base to create your own email for your applications
okay so once you have the email file ready then all i need to do to apply this is cube cdl create if any of name of the file that's it you can just apply or create both does the same job if this is the first time you are creating the resource then you can just create if a resource already exists and you are doing an update and then applying you can use update
apply command if i use apply and the resource doesn't exist apply will also do create okay so you can use anything create or apply so let's say i'm doing cube cdl create and this is going to this already created a part with the specification if i describe it you will see the container with the name icon maybe i can view the logs cube cdl logs my part can see that
you can also specify the container name
because it is just one container it printed the logs of it okay you can delete also with the file cube cdl delete if any of
which means based on the specification that is there in the email it will check whether in the current infrastructure you have a matching object if that object is found it will be deleted
okay so what we just learned creating an pod resource from man declarative specification how we created the email file the in the indentation in the email file is important two spaces and below labels we have key value pair that should come as after two spaces
under the specification two spaces containers if it is array of value I fund and then then this should come there so that is important so as long as you are following that then your email file will work perfectly fine if there are some problem with the email file then while doing the create or apply it will
throw some errors saying some problem with the syntax blah blah blah
all right so creating and part specification by declaratively
so here in this case this part specification is very very simple and straightforward now we are going to discuss how an typical production grade part specification will look like what all the additional things that you can find in any part specification
okay so let me go through that one by one the first thing that we are going to see is
it's meant for an specific use case I am going to talk about the problem scenario and then how it is implement how the solution is implemented in the kubernetes world that is the part two of the story part one of the story is if I
have a container running it's I have a pod running apart with one container
and that is running one application process maybe your microservice or nginx process is running on process it's already processing lot of records that are coming in a lot of records that are coming in its processing it
what happens here comes on request while processing this request number 97 let's say something went wrong with your application process
it crashed and then the process exceeded because it was the parent process was the only process let's say it was running it exceeded the container status will also
will move to exited state as the processes needs to exit and then the container has nothing to run so container status will also move to exited state so if a container is status is exited then the platform will take an action
platform means here I am referring to kubernetes kubernetes will take an action to restart that container or in some cases it may create and replacement for this
when it is taking that action when kubernetes is taking that action it's observing the status of the path if the status is exited then it is restarting it when it moves to exited if the process exits
ok vanilla approach straight forward here nothing complex here how about I have the same process running similarly it's executing many requests and here comes one request while processing that request
your application went into some kind of stall mode or it went into some kind of deadlock situation which means whatever the request that goes after that it's all getting failure responses
none of the access succeeds after this request all the users are getting error but in this scenario process is not exited it's still in the running state
but it's not in a position to serve any request because it's in some kind of faulted mode let's say because this is not exited container status or part status will be showing up
and platform won't take any action because from the platform's view container status is up
but from the user's perspective the applications are not not at all accessible so this is a scenario this is the problem case where we really want kubernetes to consider or to identify these scenarios as well and take an action like restarting it or creating and replacement mostly it will do the restarts only restarts is going to be a first start of the application and that should work perfectly fine
so instead of relying kubernetes relying only on the part status to determine the health of the application to determine the health of the application instead of relying on the part status
we are going to take that to an one level deeper instead of checking on the part status we are going to do that health check at the application level
which means this application is exposing some business end points right maybe if it is in product search service it's exposing some business end points in addition to those end points your developer will write a piece of code logic to expose and health end point
and the logic in the end point can be as simple as if someone calls this end point send then success code 200 ok code as simple as that so this piece of logic resides close to your business code so once your developer exposes this end point then while submitting the yaml file what even will do is
in the part specification yaml file that we just did one right there he will include one section called liveness probe and then he will specify the end point he will specify the interval with this information if he submits to kubernetes what kubernetes will do is
it will call this end point every defined interval which means every 30 seconds kubernetes is going to invoke this end point locally
and then maybe the first time it calls your application return 200 back to kubernetes so kubernetes won't take any action after 30 seconds
again your service return 200 back to kubernetes service is healthy healthy healthy let's say there comes a time where let's say at the 10th 10th time I mean after 300 seconds or so your service returns a failure response which means kubernetes call the health end point assume this scenario happened
and your health health call comes after that so as like users are getting error you are also going yes is that a question ok no as like how users are facing error this kubernetes will also get an error response
something like that and then again after 30 seconds again an error after 30 seconds again an error so here in the configuration even will also mention the failure threshold how many subsequent failures failed responses I can consider as an failure to declare that service as an unhealthy so let's say the threshold he specified is 3
so that's the time kubernetes will take an action so based on the specification provided by event kubernetes senses that this service is unhealthy and then it will immediately restart that service ok the action there is restart if your application fails liveness probe that's part will be restarted by kubernetes
so that restart is going to be refreshed out of the application where you won't have this scenario it will look perfectly fine ok so that is liveness probe so in any application you will see liveness probe configured for the parts open the first sample the second one let's say
so as like nginx let's say this is your application image this is a sample web application that we use for demo purpose it can be any image your application image that you event build or nginx use anything and as part of that application logic you must expose an end point
ok so we provide that under the liveness probe section liveness probe healthy end point it can be an htp probe if your application is is is not exposing any apis it can be an pcb probe tcp probe or it can be execution of some commands exact probe there are three probes that you can do one in this application you can call an htp get htp end point
or you can do a simple tcp probe or it can be an exact probe you have some shell commands that you want to execute that's going to determine whether application is healthy or unhealthy you can put that command here exact probe in this example we are using htp probe
and then we are specifying initial delay second which means if the application starts don't do health check for first five seconds because it may be initializing that time and then if the call to the end point health end point doesn't return any response within once again consider that as a timeout timeout is also considered as a failure scenario
interval every ten second this end point will be called by kubernetes and subsequent three failure means application is unhealthy you can consider that liveness probe fail if you if you get subsequent three and sequent three failure responses on this end point
okay so let's see this in action let's see this in action right so before that the sample application that we are going to use this card application if i open card part you can see the specification similar to the one that i just shown it's just that the image is different and then the container port is using 8080 or nginx was using 80 that's the only difference okay let's let's execute this let's apply
this configuration and let's view the card application that we are going to work for this demo
okay
i think it's a different folder let me check
the downloads are documents
okay
it's in document ck hands-on within that right
come on
open in a terminal
kubectl
apply if nf 1 1
card part ml and check whether the part is already running
still creating
still creating
and put a watch flag and you can watch it
okay it's running now it's an simple react web application let's see how the application looks like kubectl port forward
name of the part
any port number in the host machine and then the port within the container
i am going to access this application localhost 8082
come on
there is a delay for a split second
for me
come on i'm trying to access this
localhost 8082
yep we are able okay
i think it is serving from the cache
yeah there it is so this is the simple application and
and
it has many tabs that we will use for demo sake okay but now let me go back here and stop the port forwarding
let me try to refresh this once
okay i stopped the port forwarding and i'm going to delete this part so that i can create the second file where i have the liveness con liveness prop configure
because that part is also going to be in the same name so i'm deleting that kubectl apply so in this aml file we have the liveness prop configure
i'm going to do the same set of steps
one spot created i'm going to check whether it is running it is running to the port forwarding
and open the browser
browser
refresh it got it right
so here as is a demo application every time when kubernetes invokes the health endpoint as port office liveness probe
it's getting printed here as you can see it's printed in this table you can see kubernetes is calling this application and this application is returning 200 back to the kubernetes
okay so now we are going to intentionally fail the liveness probe to see how kubernetes react basically it's going to restart but we are going to see that so here we are going to fail for next three calls because three is the threshold
so which means for the next three calls this application is going to send 300 500 500 some error response to the kubernetes
and kubernetes will immediately
will take an action because this application failed the liveness probe it will take an action the action in that case will be restarting that part
as you can see it's already
restarted you can see the port forwarding and everything stopped behind the scene
if i go back there
and if i try to do kubectl get parts
you can see the restart count is already updated as an one thirty three seconds ago
you can describe this part
to view more details on the event section here it says
liveness probe failed
reason is unhealthy
HTTP probe failed we set as for 500
container failed liveness probe and it will be restarted
and then the container restarted
okay
so
to do that if if your application is unhealthy it's it will it can do the restart but for that you must have the liveness probe here
or else if a scenario like this happens
then kubernetes will be of no help here because kubernetes doesn't even aware of the fact that its users are getting error
you need to declare the application as unhealthy for that we need to expose an health check endpoint
if business endpoints are failing then the health check endpoint will also fail
that will notify the kubernetes about it because it's constantly pulling that endpoint
by that way it will be restarted
any questions on the liveness probe before i give the stage for you to try
is this clear liveness probe
yes no
perfect perfect
so these commands are also there in the
pdf
or you can even try this set of commands that i tried i will put it in the etherpad for your reference
okay launch the application go to liveness probe tab and then you can simulate that error scenario and see how kubernetes behaves
all right
so we have
around seven minutes ten minutes for our lunch break
so let's take this ten minutes to try this hands-on on liveness probe
as well as the hands-on on this part to create and part specification declaratively
let me include this command
let's try that and then the liveness probe and then you can go for a lunch break
and then be back by
one pm
is that okay for all you can you can go for lunch and then at the end you can do this exercise up to you i'm leaving it up to you
to do an working lunch to complete these commands
any questions before that
all right
yep
i'm going to drop from this call i will be back by 12 55
so have a great lunch
and see you guys back by one pm thank you thank you for listening
hello everyone yeah hello hello
yeah so is it is it obvious on my face let me turn off the camera
never just kidding
okay so
yeah okay
i'm good but it just that my stomach is not good
okay other parts are working fine
okay so i just seen you all your chats and then sergeant said chat buzzy can you would you like to summarize that
if you don't mind
yeah yeah please
uh-huh
uh-huh
uh-huh
uh-huh
uh-huh
uh-huh
each end we have
okay we have only one end point right by the end point
okay
uh-huh
uh-huh
uh-huh
uh-huh
okay
uh-huh
uh-huh
uh-huh
Mmh, mmh, mmh.
Mmh, okay.
Mmh, mmh.
Mmh, mmh.
Mmh, mmh, mmh.
Mmh, mmh, mmh.
Mmh, mmh, mmh.
Mmh, mmh.
Mmh, mmh.
Mmh, mmh, mmh.
Mmh, mmh.
Mmh, mmh, mmh.
Mmh, mmh.
Mmh, mmh, mmh.
Mmh, mmh, mmh.
Mmh, mmh, mmh.
Mmh, mmh, mmh.
Mmh, mmh, mmh.
Mmh, mmh.
Mmh, mmh.
Mmh, mmh.
I don't think we can have those kind of data in the New Relic backend.
Do you think?
Number of transactions received.
Okay.
Successfully processed.
Correct. Correct. For that we don't need.
Total amount of transactions received.
Number and amount.
Total amount of transactions successfully processed.
Number of transactions is the count.
Total amount of transactions.
Total amount.
Number.
Yeah, but we need to, we can check with Circon on this.
Because there are many amount, right?
Charged amount or the delivery fees there.
Is it going to be a combination of charged or delivered?
Those things we need to clarify.
Total amount of transactions received.
Amount of transaction.
What do you mean by amount here?
Transaction successfully processed.
I feel, I feel 0.12 and 0.34 are same.
But we can better check with Circon.
Is he available? Is there?
Maybe we can drop a message to him.
Asking what this amount of transaction means.
Okay, I will ping him right away.
Okay, and then the fourth one.
Success rate equal number of transactions successfully processed.
Divided by number of transactions received.
Correct.
Yes, we don't need it here.
Error distribution.
Which means this is from the error.
So on the error event.
Maybe here we need the JSON.
We need to capture the type of errors.
Let's see.
Some of the errors.
Something unavailable or some invalid input.
There may be different kinds of error that we see.
Correct.
Correct. Correct.
I understand for few SAP endpoints.
They are returning some standard error format.
But for others they are returning some random error messages, right?
So.
First we need to group it by error code.
Status code.
And then if possible in the JSON if we can also include the error message.
It will be.
Easy to identify the problem.
Like we sometimes used to get that.
If SAP is down we get some errors.
Sometimes error for not found.
Yeah, so in the error distribution we need to have a JSON.
But for the others.
We don't need a JSON.
And we need to check whether the amount means whether it is the field that they are referring.
Or not.
I just let me give me a minute.
Let me go ahead.
Go ahead for the total amount of transaction.
Yeah, received I think for the result we can.
Received S is right.
We already sending some APM data to the new relic.
So received we can easily get it.
But for successfully processed we need to send a custom even because successfully processed means.
The SAP call.
Should succeed and then on the success spot we need to capture that correct.
So received received part.
Yes, we can directly do that.
But successfully processing or we need to do in custom event only.
So what you are saying is you want the event type to be foot page journal entry.
And then the attributes.
Array will have.
Let's see.
Status.
Queued.
And for the different different status it's going to have different.
And I can have one more attribute if I want.
If I want to include some.
Inputs like a JSON.
Then I can have another key and then the object I can put the JSON.
OK OK OK.
So for the endpoint level we can have the grouping.
Performant.
One event four states are four events.
That's that's what we need to determine.
Right.
So if it is going to be just one even four states.
And we are going to query the same event for all different.
Visualizations let's say.
Same event for all different dashboards are visualizations.
Will it have any impact on the performance.
Even when you OK.
And having a different events.
Having one event capturing all the attribute values.
OK I'm just seeing some blocks from the new relic.
Yeah go ahead.
Yes it's on the task success.
We we yeah it's in the task description and.
We think that it's about.
Success response from SAP.
We thought it.
Mm hmm.
Mm hmm.
OK but what is the difference between one and three.
Number of transaction received.
Total amount of transaction received.
Both are same right.
OK process.
OK OK OK.
Yeah yes.
Kind of lubrication.
but i really doubt about this amount aggregation on on our integration side because this is
something that directly vertical can provide we are just passing the data while passing
the data we are capturing and showing the amount i am not sure whether
by amount circumment this or the quantity he mentioned as an amount
i already asked a question to him in the chat but but let's see
okay
okay                

on 2022-10-26

language: EN

                  WEBVTT
training room just a reminder if you wish you can join so that they can see
your progress
am I still connected just a quick check you guys hear me right okay okay I will
constantly do this kind of health check never mind I'm more into kubernetes
yes please go ahead and let me know for any questions while others are trying                

on 2022-10-26

language: EN

                  WEBVTT
Last four minutes to complete this activity.
Last four minutes to complete this activity.
Last four minutes to complete this activity.
Last four minutes to complete this activity.
Alright its time up for this activity.
Alright its time up for this activity.
Any challenges or questions or do you need additional time please feel free to let me know.
Yeah I request someone to speak out right because we have this network issue.
It's all clear all okay shall we proceed?
Okay thank you so much Shahid.
Okay.
Yes please yeah Jason can be Jason and we have option as and why you can look at the documentation.
Why it means it won't print anything but it will show some additional columns.
But from the type perspective generally most 90 percent let's say we go with the YAML format.
But there are here and there there are some organizations that are using Jason for all the specifications of their applications.
But that is very rare alright.
So the next topic that we are going to discuss is which means now we have a clarity for every microservices.
Let's see let me zoom this in a bit okay.
So for every microservice M1 you are going to create a deployment.
That's going to get a replica set.
It's going to create the parts.
Let's say if you set it as 5 for M1 microservice you have you will have five instances running in your cluster.
For M2 microservices you are going to create a deployment.
That's going to get a replica set.
Maybe you set one instance so one one part will be running.
And for M3 you have a deployment.
That's going to get a replica set because you specified your SN3 three parts will be running here.
So similarly multiple deployments will be running in the cluster which are created by multiple teams that are running all in your cluster.
So question number one is if you delete this part then immediately this replica set is creating and replacement.
If you delete this part then this replica set is reacting to it.
So in the cluster you have three replica set how this replica set identifies their children's or child's or the one that it is created by it.
If I delete this how this knows that the one that it is missing is the one that is created by it earlier.
So it's creating and replacement these two replica sets are not reacting to it.
The same goes for deployment also how deployment identifies the replica sets that it owns.
Or it manages one thing that was very obvious is as someone already mentioned it can be through a name because it has the name that starts with the deployment name all the part name starts with the replica set name.
But for that also I mentioned that we don't have any logic here based on names.
How it works is it works by one kubernetes resource called labels labels is one another kubernetes resource.
So when we created a deployment we created a deployment called my engine next correct.
That's all we didn't we didn't give any other input.
We gave the image name and we give the name for the deployment.
So we didn't specify any labels explicitly.
So if because you haven't specified any labels explicitly kubernetes assign some label implicitly,
which means let's say app equals the default label that applied it can be something like app equals the name that you gave my engine next.
This is the this is the label on the deployment and this deployment is creating a replica set,
right and this deployment will put this label on it assign this label on this replica set app equals my engine next in addition to this label on one single resource.
You can assign as many labels as you want in addition to this label kubernetes will also assign one label that will carry the unique idea of this replica set.
For example, pod template hash equals that unique idea of the random long unique idea of this object or this resource.
So two labels will be on on the replica set the label that that assigned by deployment that label that kubernetes assigned it after creating this replica set because only after creating you will get an ID for it.
And then this replica set created the three parts and if you look at the parts all the three parts will have these two labels.
Because replica set will create the part and then it will assign these two labels on it.
Okay, so if I go back here and if I do kubectl get all get all with show labels just for and quicker view.
I'm just reading all the resources because I have only this deployment for now.
So I just put show labels flag you can do get deploy name of the deploy and show labels show labels will show an additional column that will have the label information.
You can also describe any specific resource and you can view the label.
But if you want to have a quick view you can do show labels look start from the deployment first.
This is the top level resource and as you can see it has the app equals my engine X label and this deployment created this replica set and it has app equals my engine X label and then for template hash equal the unique idea of the replica set itself.
Okay, and if you look at the part created by the replica set it all has its label on it.
Okay, so this is just part one of the story how kubernetes is assigning label on the resources part two is how this label is going to be utilized by the kubernetes.
Assigning labels is just the first half of the story second second half is how this labels are going to be utilized by kubernetes.
As selectors label selectors, which means in your infrastructure you have five six ten parts of that ten parts from different different applications.
If you simply do cube CTL get parts, then all the ten parts will be written.
Am I right because it's going to turn all the parts.
So here I can use some kind of filtering logic and I can say if an FN selector equals key value app equals my engine X which means this is going to get the parts that has the label app equals my engine X.
So maybe out of ten only five will match to it because only those five parts has the label maybe this five part has that label that will be returned here.
Okay, so using the labels in the selector query that is the second part of the story as any the labels and using the labels.
Let's say if I go back here even you can assign your own label.
Let's say I'm going to label this part.
Let me pick this part.
You can label any resource not only part deployment replica set node any kubernetes resource.
You can label cube CTL label.
I think it will be helpful if I zoom this in a bit.
Okay, keep sitting label.
I am going to label a part.
Name of the part and then the key value.
Let's say ENV equals broad.
Okay, it takes me to put it in this format.
Okay, I copied the entire thing right?
So I don't need to repeat it either.
It can be part slash or part.
All right, it label.
So if I do cube CTL same command show labels.
You can see that this part now has a label ENV equals broad.
So if I do simply cube CTL get parts, it's going to return all the parts.
I have only five parts.
I can just simply do selector query.
And I can specify get the part that has this label with this value.
There are many many many many things that you can do only the key or multiple values.
There are many combinations that you there are many operators that we have in operator not in operator and so on.
Right, but let's keep it simple for now.
So you can see here only one and one entries return because that's the one that has this label.
Okay, so assigning a label and using the label as a label selector.
Fine, but how this is related to the discussion that we are having here.
How the top level resources are going to identify the child level resource.
Let me give you an example.
You created a deployment that created a replica set and it internally created the set of parts five parts.
And all the five parts has the label happy equals my engine next and pod hash template as an 1 a b 3.
So blah blah blah blah blah.
I mentioned that replica set is doing CS equals DS job.
Current state measures the desired state job in an infinite loop.
So what I mean by that are what it actually does is.
Cube CTL get parts hyphen hyphen selector.
Let's say by this label app equals engine next my engine next and then pod hash template equal to 1 a b c t a.
So what it does is actually the executes this query in the cluster.
And this query is going to return some results.
Right? What is the count of the result?
Why that is the current state if you delete this the next moment replica set executes this query to this query only four results will be written.
So current set is for the same set is five.
So it will spin up a new part and for the new part it will assign this label.
So the next moment when it runs for this query five will match current set will matches to the desired state.
So this is the same exact query replica set is using to do its reconciliation loop logic.
Infinite reconciliation loop logic.
Okay, and apart from the label these two objects are no way related it blindly blindly works by label.
The same goes for the relationship between deployment and replica set.
It's totally loosely coupled.
I can give you an example.
If you carefully listen this you can try while I give some time for the hands off.
Okay, so here I have.
Cube CTL get parts.
I have these five parts running.
And all the five parts has those labels.
Am I right?
I can I can show.
The labels I miss the labels apologies for that.
So here.
These are all the labels that are there in the part.
What I'm going to do is I'm going to remove this label from one of the part.
I'm going to remove this label then what will happen?
Obviously when the next time when Cuban replica set queries only these four parts will match
because that's the one that has this label correct
because I'm going to not delete the part just remove the label only if I remove this label,
then this part will no longer be considered by the replica set.
Because when the next time it executes the cubes it will get parts.
I find FN sector only this four will match and it will think
that current set is for and it will create a new part.
And from that from not from that moment on this part will no longer be considered.
It will become an orphan part, which means we successfully quarantine this part.
Let me show you that in action, right?
Cube CTL.
The one that we are going to do is DJ 8 by 8 keep that in mind.
Cube CTL label.
Cube CTL label.
I'm going to label a part the name of the part.
I want to remove this label to remove a label the same command.
You need to just put key minus key minus will remove the entire label on it from the resource.
Okay, and label the same way.
I'm going to remove the other label also other label is part template hash.
Part template hash because I misspelled it.
Come on, I just labeled it.
What happened?
Okay, it's already a label.
So if I do Cube CTL get parts.
Show labels.
See this label will remove and you can see there is already a part created 69 seconds ago.
This is the one that got created because after removing the label the current set became four.
So it's been up a new point and it as in the labels on it.
You can see we have six parts now.
So if you delete this part nothing will happen.
Because this is already an orphan part standalone part or fat.
Okay, so it purely works by the label and again,
if you label let's say while you are trying the hands-on try to assign these two label on this sixth part.
Then the next moment when it queries all the six part will match to the sector label.
Cube CTL get part selected then all six part will match.
Which means current state is six desired state is five.
So it will remove randomly one of the pocket.
So in this case it is the same application.
Even if you are going to run a standalone Postgres database
and assign the same label here on the Postgres database,
it may delete one of the one of the existing component or the Postgres component.
It won't even see whether it is of the same family or not.
It just blindly works by the labels on it,
which means if you are if you are asserting some label here
and if the replica set adopts this which means you successfully adopted and thought
so quarantining or adopting both you can achieve with the help of the labels.
I don't think in production you will be doing that
but the reason why I explain this is how this we are saying
we are talking about this hierarchy literally
this hierarchy is completely loosely couple
and it works only by the labels and labels as such
the concept is pretty simple isn't it?
You are going to assign some key value para and resource
how to label using Cube CTL label command
how to unlabel using Cube CTL label command
how to use the label in the selector query
how kubernetes resource like replica set uses label selector in its reconciliation loop
and a simple demo on quarantining or adapting a part by labeling or unlabeling from it.
That's all we discussed.
I'm going to give a quick pause here for you to try this command
and let me know for any questions.
I will share this commands in the etherpad
and if you confirmations please if it is clear good to try.
Let me put it here this commands here.
Thanks for that confirmation by the way.
Okay, so labeling and labeling using label in the selector adopting quarantine.
So this concept we discussed here.
So at least let's take some five minutes at least to try this and explore the labels and try to assign an unlabel.
So please spend some time on the hands-on because on the day two or day three,
I will be giving a lot of exercises with scenarios.
So I'm sure you will be able to crack all the scenarios that I provide.
But what is more important from an examination perspective is timing.
You will be really having a limited time.
So you need to be really have fast hands while doing the samples, right?
So if you try more during this hands-on time,
then it will be simpler during the system or else we will take a lot of time just to solve one single.
Use case.
Okay.
Yep, let's take some five to ten minutes.
Not more than that to try the labels, please.
Thanks for choice.                

on 2022-10-26

language: EN

                  WEBVTT
Even it's is it is the problem still there for you or the audio or is it already started
out even okay, okay, I suspect this teams really so teams is not so reliable for this
long meetings and all based on my past experience maybe zoom but let's see if it
is a problem then maybe we can consider switching to a different one let's observe for the rest of the day
in
there is a hedge hedge missing in the hash so that's the reason it's not adopted by the deployment if
you notice here you missed an edge you see that in your last part yeah okay
okay let's let's go let's take a coffee quick coffee break for 15 minutes if you want you
but after the 15 minutes break we are going to start with the deployment resource especially
we are going to talk about a rollout feature of deployment resource okay please try this labels
and let me know for any questions after the break thank you
hello I'm back yeah welcome back welcome back welcome back
thanks for those confirmations all right what we are going to do now we are going to continue
our discussion we discussed about part we discussed about replica set and there is
one guy that we are yet to discuss that is this top-level resource called deployment why
I need to have this guy sitting at the top right so replica set has a duty to perform that
disease to DS and what this is doing that's what we are going to discuss now so from the
deployment resource perspective we have one capability called rollout rollout feature which
means let's say even built an application the name of the application is even app and the
the first version that he released is 1.0 and in the cluster he is running 100 he
created a deployment with replica as an 100 100 100 parts are running with version 1.0
and then he made some bug fixes and enhancements and he released a new version of the image 2.0
okay so here he wants to replace all this 100 version 1.0 application with 2.0 right
all the all these 100 parts need to be deleted and new 100 parts needs to be
created that's going to run 2.0 so this is nothing but rolling out new version of the
application just give me a second someone is at my door let me quickly check apologies
for that hey Adi get lost Adi hey what are you doing you are in a meeting
you are making me nervous give me a job hello yep what happened I'm back hello am I audible
now hello yep was that a question okay okay so yep so he wants to roll out a new version
of the application 2.0 so how to perform this so basically he want to roll out a new
version of the application and what we are trying to target is how I can perform this
with zero downtime that too during peak business hard so at the deployment level
we can specify something called strategy there are two strategies that we can specify one
is recreate another one is rolling update recreate and then the rolling update if you
specify strategy as an recreate which means all the old version 1.0 will be deleted once
it is all deleted then new 100 version 2.0 parts will be created which means the time
it takes for to delete and then the time it takes for all the 100 points to be up and
running go through the liveness readiness proof and be ready and then only it will start to
so which means obviously you are going to have some downtime if you are going to choose
recreate strategy but if you choose rolling update if you choose rolling update as a strategy
then you can make use of two properties max unavailable max search so let's say
you are going to choose max unavailable as an 20 percentage let's say you are going to
configure your deployment as max unavailable as a 20 percentage and you are going to deploy
the new version of your application so what will happen is in the 100 application that are
running with version 1.0 we just started the rollout with max unavailable as in 20
so as a first iteration 20 percentage of the part which is let's say we have 120
percentage is going to be 20 20 version 1.0 part will be brought down so which means at
that moment i will have 80 version 1.0 part running okay and then kubernetes will bring
up 20 version 2.0 parts up which means at that moment you will have mix of version 1.0
and 2.0 80 and 20 and then bring another 20 down so which means it will become 60 1.0
bring 20 up this means 40 version 2.0 so similarly the iteration will proceed
and at one point in time it's going to be 0 version 1.0 and 100 version 2.0 which means
we successfully rolled out the new version of the application so it means as the name says
throughout the deployment window or the rollout window we had only 20 percentage of the part
unavailable which means remaining 80 percentage of the parts were available
and it was processing all the incoming traffic max unavailable that's what it means
if you set max unavailable to 100 percentage which is nothing but the recreate strategy where
all the old part will be written new part will be created it's going to be whole 100
okay fine this is the max unavailable what if even if the 20 percentage of the unavailability
your service can't tolerate because it's really really super busy you need that many
instances to be available then you can have a play around max search property so what it means
if you set the max search to 20 basically you can do both configure both properties how
many to bring down how many to spin up that you can do it here search means think of it
let's say version 1.0 i have 100 if i set search to 20 instead of bringing down old part first
it will bring up 20 new parts up so which means you will have 100 version 1.0
running you'll be your a surge of 20 new parts and once this is up and running then
i will bring 20 down this will become version 80 and then 20 version 2.0 okay and then again
a search 40 make it 40 so similarly it's going to proceed and at the end you will have 100
version 2.0 and 0 version 1.0 so you can go for search provided in your infrastructure you
can have you have enough resources to accommodate that search here it is 120 is fine but what if
you have 1000 and if you set it to 20 it's going to be 200 parts so 200 additional parts
which means it's going to take a lot of resources so resource availability is a concern then don't
go for search maybe you can go with max and available with some less value okay so first
step is at the deployment level you can specify the strategy hey this is the strategy
i'm going to use rolling update with max and available this much max search this much so
the deployment that we already created we didn't explicitly specified one right we just
did with yaml file as well as with imperative we didn't specified one explicitly
so the default is rolling update with max search and max and available set to 25 percentage
come on
so we have one deployment you can actually view the ml that is stored in the kubernetes etcd
database which has all the defaults included the ml that's actually used by kubernetes to
create that resource right just in the get command output it as an ml-o-ml that will
print the ml with all the defaults and everything included that is stored in the
etcd database so here this is the deployment specification where you can see the strategy
default is included rolling update okay need to scroll down a bit
rolling update max search max and available those informations are provided here okay
so this is number one where you can specify the strategy and number two feature that it
says rollout kubectl rollout for one specific deployment let's say for events app maybe he
did multiple deployment multiple versions deployments in the past for this one single
deployment he initially deployed version 0.7 and then 8 0.9 version 1.0 version 1.5 now he is
version 2.0 right so for one single deployment he's just updating the image version and then
he's rolling out a new version so you can actually view all the history of rollouts
performed for that deployment so this will history command will list all the past
rollouts you did for that specific deployment okay and then if he is going to do an
version 2.0 deployment what he will do he will open the ml file he will update the image
and then he will save the file and then he will apply that's going to trigger the rollout
process that is replacing the parts with the new image parts right so while rollout is in
progress you can actually do view the status of the rollout status deploy even app so how
many are currently being replaced how many old are there how many new are there you can view
the status and you can even pause the deployment rollout while the rollout is in progress in the
monitoring tool you are observing a lot of alerts so you suspect maybe this may be a
cost so you can immediately pass the rollout which means maybe 50 percentage are replaced
50 percentage are still yet to be replaced it was still in the same state because you
passed the rollout maybe after the troubleshooting you found out that it's because of a different
issue so you can resume the rollout cube ctl rollout resume deploy and so on okay
you deployed version 2.0 and after an hour there are a lot of user incidents that are creating
and you found out that there is some serious bug with this version 2.0
then you can undo the rollout which means all the 100 parts will be replaced with version
1.0 the previous version you can go back to the immediate previous version or you can go back to
any version in the past using undo command okay so for one specific deployment you can view
the history of all the rollers that you did in the past you can view the status of current
rollout that's being in progress that's just in progress you can pause resume and you can
even undo to immediate previous version or to any version in the past
okay so let me quickly show that commands right
let's let's explore those rollout commands real quick and then we are all set for the topic                

on 2022-10-26

language: EN

                  WEBVTT
If you have any questions or comments, please feel free to ask them in the comments section below.
If you have any questions or comments, please feel free to ask them in the comments section below.
If you have any questions or comments, please feel free to ask them in the comments section below.
If you have any questions or comments, please feel free to ask them in the comments section below.
If you have any questions, please feel free to ask them in the comments section below.
If you have any questions or comments, please feel free to ask them in the comments section below.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Last three minutes please to complete this activity.
Last three minutes please to complete this activity.
Last three minutes please to complete this activity.
Alright. It's time up for this activity.
I hope it is clear.
Let's go to the next topic that is about ingress.
Okay. So please listen here carefully because you are going to try it.
I will just explain what you are going to do and how it works and you are going to try it.
Okay. So please carefully listen here.
Simple example only. So you are going to create
or you are going to deploy two applications.
Let's say the name of the deployment is web one.
And you are going to create some three parts.
And you are going to create one more web two.
Create a deployment replica set.
Maybe you can have five parts and create a service for this
web one and create a service for this
web two. So you have two services.
So what we are going to do we want to expose this web one
and web two to the outside world instead of setting load balancer
as a type. I want to expose these two services under one
single IP.
I am going to create one ingress and this ingress will have that
public IP publication and accessible IP. Let's say
and there is one request that comes here
saying let's say www dot ABC dot com slash red and there is
another request that is coming here slash blue. So here you are going to
specify some rules and in the rule you are
specifying that in the host in the path in the URL path
if it is slash red then it that request corresponds to web one
if it is slash blue. Yep. Is that a question? Okay. If it is slash blue then the
response request corresponds to web two. So you are going to specify
some rules. We will call it as an ingress specification.
So as an web one team you will submit the specifications to the kubernetes
service and say hey if it matches this URL path or some header
information so there are many things that you can configure. So it is still going to be
ABC dot com ABC dot com which means one single domain name but
based on the URL route or some header information we are going to
forward the request to one of the services. This is layer seven load
balancing let's say service does therefore this is at the HTTP
based load balancing.
Okay. So this is what we are going to do now two services we are going to
define and rule and we are going to hit the high P with different different addresses
and we are going to see how we get responses from these two different services.
Okay. So for this to work you
are going to create one yaml file with kind as in so
far we created part service deployment.
Correct. So for the ingress we had to specify kind as an
ingress and under the specification you are going to specify the rules
if the part is red then the service corresponds to is web one
if part is another rule first rule second rule part is
blue then the service corresponds is web two so you are going to define
one such yaml file and you will submit this yaml file to the cluster
doing during you will do apply command and you are submitting it to the cluster.
Okay. So if you submit it to your current cluster
thing will happen once you have played you can do cubes it'll get ingress
but nothing will happen. The reason behind is
out of the box in the core cubers distribution we have
one component called cube controller. So if you submit a part replica
set a deployment in this cube controller component you have
a controller for those cubers resources. That's the one that's acting on it if you submit an yaml
file for a part a part is created because a cube controller has
a part controller that acted on your yaml file but
in this cube controller we don't have any controller logic to handle
resources of type ingress. So this has all the
all other resources like part set full set deployment
all the controllers rolled up into one binary and we call it doesn't cube controller.
So in this cube controller we don't have any controller to handle
ingress types. So which means you need to install an
ingress controller. You need to install one ingress controller in your cluster so that if you submit the cluster
can pick up the configuration and they can do all required stuff for it to work.
The reason why it ended up like this because
there isn't any standard ingress controller that is available out there. There are software
there are hardware based and different teams are using
different ingress controllers for different purposes. For example we have nginx
we have FTO counter we have
ambassador glue
terrific there are many many solution but the most popular is
nginx ingress controller. Okay so
the very very first step is you need to have
an ingress controller up and running and then
you need to submit your ingress specification. The moment when you submit
ingress controller will act on it which means event can submit one colon
can submit one. So what this controller will do is it will
merge all of this configuration whatever he submitted he submitted and he have it
will have it in one single configuration. So that when a request comes in the
configuration will the rules that are there in the configuration will be matched
and the respective service will be picked and then the request will be forwarded to
the respective services.
Okay so that's the whole idea
so if you there are many chances that couple of folks
will submit conflicting rules. Let's say he will submit red means
service 3 he will he may submit red means
service 10. So here it is an conflicting rule so
what ingress is going to do if a request comes to slash red end point
forward to S3 or S10. So if you submit a conflicting rule
ingress will simply accept it. It won't whine about
conflicts and so on. So it won't do anything and the behavior is also
undocumented which means it can happen anything like maybe request all the
some some error on the caller side
right. So the result or the behavior is
I mean that's something that's with the documentation itself so it can
be anything so we don't we can't tell what's going to happen. So it's it's as much as
possible we should avoid submitting it. So as a cluster administrator
later we are going to talk about admission controller where we can have more control.
So there and on that layer whenever a user submits we can actually
reject that request straight away if already and same
rule with the same configuration or with the same route
path or any conflicting if already exists we can reject the request.
So we are going to talk about that but for now if you don't have that control or admission controller
the cluster will accept it. So in an one single cluster
let's say in your organization some set of teams
can use nginx ingress controller. Some set of teams can use
some set of teams can use another ingress controller.
So in one single one single cluster you can have many
ingress controllers it shouldn't be only one across the cluster that is not the case.
While submitting the ingress rule you need to specify that
class name. Ingress class name let's say
nginx or ambassador so which means if you submit it in your cluster if you have
three nginx controllers running from different vendors then this will be processed only by nginx
not by ambassador or not by glue. So with the annotation we will specify which
ingress should work on this controller should work on this.
So the core idea here is this is the one
virtual hosting pattern in the kubernetes because
this is an costly operation and this is
this is not right. That's it. Any questions
on the ingress.
It can be a different namespace for example in the example that you are going to try
you are going to try it in an cube system namespace. So generally all the
system components you will have it in the cube system right.
So it can be in the cube system and your application can be in any namespaces.
It will work perfectly fine because it's a cluster level resource.
You want to
specify to which
namespace you want.
The ingress specification itself is namespace scoped only.
So you are submitting the ingress right. So here you can specify which namespace it should correspond to.
Controller is acting at a cluster level but whereas the ingress specification that you submit is all
namespace scoped only. Welcome. Okay so this is the sample that you are going to try.
It's already there in the documentation. Just give it a quick try so that you can
get an idea. So I just included the link to give you a quick
run through. You are in the mini cube and in the mini cube we don't have ingress controller
but it is there as an add on. All you need to do is just
enable that add on. Enable ingress. Once we enable
ingress you can see this namespace ingress
nginx namespace under which it will create the nginx
ingress controllers. You will see one in running state. These two are just more of an
initializer parts. You can ignore that. You will see one in running state. So first
step is make sure your nginx ingress controller is running.
After that you are going to deploy couple of deployments
and two services. Correct. So first deployment called web
and service for that. And then service can be any type. It can be cluster API or node port that doesn't
matter but not load balancer. Right. And you can
create an ingress ingress specification and you can specify
the root. If the host name is hello world dot info. That is the
root path. So for this to work maybe you can access your
yeah it will follow. You can modify your
host file and you can include the IP address of your
ingress to map to the hello world dot info. Right. Or else you need to
call the IP. If you want a domain name just in an etc host file just add an entry.
So here if you look at the ingress if the request
comes for a root path then it should go to
a service with the name web. Just one root. I can apply that. You can do get
ingress. You can you will get an
address here if you hit it in the root folder it will go to the web service.
And you can create a second deployment web to create a second service for the deployment
and add one more role to the same ingress specification file. If the
request is for slash we to go for web to service if you apply it
and then if you call root path it will go to
web one web publication. If you slash we do then it will go to web to
application. Okay. A simple example but that pretty much
explains the work for a lot of things that we can do in the ingress but this is enough for now
like we can do include
SSL certificate and then based on some actions you logic the default back ends
those things and all we can configure here. Even you can widely some set of IPs.
You can later refer the engine next ingress documentation for that. Okay.
So with that let's take some five to ten minutes please to complete
this activity or ingress.
Link I already included in the etherpad.
Last two minutes to complete this activity.                

on 2022-10-26

language: EN

                  WEBVTT
Hello, welcome back.
So let's wait for a few more minutes.
Alright, I think we got almost everyone. We can start.
So the last topic that we discussed before our lunch break is about config map and secrets.
What it all takes to inject config map as environment variables, as files, so those things we discussed in detail.
Correct. So with that, that topic comes to an end.
Now we are going to enter into a new topic.
Here in this topic, we are going to discuss about three resources.
Persistent volume, persistent volume claim, storage classes or SC in short.
PV, PVC and SC. So these are all the three resources we are going to discuss and then we are going to do a quick hands on on it.
OK, so if you still remember.
To define a volume in a pod specification.
What we do?
Two step process we tried one.
We define a volume.
We give something like name of your volume and then the storage provider.
Let's say if it is a host path or NFS.
And then the specification related to that, right?
So this is about creating the volume and within the container specification.
We will have something called volume mounts and here we specify name of the volume.
And then the path within the container.
Where you want to mount that will give it to the mount part, isn't it?
So this is step number one and this is step number two.
So if you look at here.
Defining the volume.
Are creating the volume is defined in the pod specification.
This is in pod specification.
Wherein we put that information.
If tomorrow if you want to change to a different.
From NFS you want to change to host path or to an Azure disk or to NGC persistent disk.
Then you need to keep changing here.
Which means even though nothing get affected in the pod specification.
You need to deploy this ML again and again for this to take effect, right?
So which means pod specification and then the volume specification.
Is tightly coupled changes in one will deploy changes deployment for both.
And also there is no way we can directly manage this mounted volumes.
Is there a way I can view get volumes and see these volumes and all right.
So to make it loosely couple and to better manage the volumes.
Kubernetes resource came up with two new resources called persistent volume and persistent volume claim.
So the idea here is.
Okay, let's not have this definition here.
Remaining still still say the same.
Remove the volume specification from the.
Pod specification.
Okay, and then for the volumes.
Let's create an email file.
Let the administrator create one email file with kindness and persistent volume.
And here it's going to have the specification and here it's going to tell it's an NFS.
And this is the server details and within which they export folder.
Okay, so your system administrator.
Will create an persistent volume email file like this and he will submit it to the cluster.
So which means after submitting if he does keeps it till PV get PV can actually see the volume created a volume with the name.
Let's say.
My back and anything name doesn't matter here so in a volume created here.
So if you submit a volume will be created and in the result you can see that the volume is unbound which means a volume created nobody is using this volume yet.
It's not bound to any part yet it's unbound it will be an unbound state.
Okay, so what your system administrator will do is similarly he will create multiple PVs.
Maybe one with the Azure this one with the GC this one with the host but maybe he will create multiple.
PVs so which means at the end what they have is a pool of persistent volumes.
He basically statically provision the volumes and now in the kubernetes he has pool of.
PVs few are allocated out of you are not allocated to any part you have those PVs.
Now the next step is let's say your application here it needs a volume.
And you can have some specification that let's say if you want an one TB pen drive what you will do you will go to an.
Shop and you will ask the service personal that hey I want one TB pen drive in Kingston.
Okay, so you are you are asking the shop salesperson and he is going to check in his tracks and if one is found is going to give it back to give it to you.
So which means you are making a claim.
And the sales person.
Is honoring your claim if a match is found.
In his warehouse so similarly your part is going to ask what it needs via persistent volume claim.
PBC let's say my PVC which means for the PVC you need to as application team they will submit the PVC PVC dot email.
Kinders and PVC under the specification you will ask hey I want.
Some 10 GB in a network file share that's where this network file share is located it's not it's not specified here in the PVC.
We are just asking I want to end up as 10 GB that's it.
So if you submit this PVC to the cluster what cubaness will do is it will try to find a match in this match from the volume pool.
Out of 10 provision volumes that are there in the volume pool is there anything that is NFS and have 10 GB.
If one is found then that baby will be bound to this PVC.
It's more of it's just one to one mapping only one day one baby one baby that's it.
If no match is found then your PVC will be in pending state.
Maybe in future if then matching babies created then it will get down to it.
So step one is your administrator should provision the volumes.
Step two is you need to submit the volume PVC claim.
And if these two will be bound.
And this is the PVC you are referring in your in your part specification.
Okay which means before applying the part specification you must apply your PVC.
And it should have a volume bound to it when only your part will start up because.
The bounded volume should get map loaded to this data directory.
So by this way you can manage the PVC's cubes it'll get PVC.
You can see all the PVC's and the statuses get baby and you can manage in statuses.
And here you are referring only the PVC.
So by this way they put this much effort to make these things loosely couple and better manage the volumes.
Okay.
So that's what this diagram also says.
So that storage administrator can provision from any of the using any of the storage types.
Like GCE persistence, AWS blocks, elastic blocks, Azure file, NFS, CSI it can be anything.
So the flow is administrator provisions the volume maintains a persistent volume pool.
And your application for your application you are going to submit a PVC file that is the claim.
And the claim will be honored by the cluster.
Honored means your PV's will get bound to the PVC.
And then you will mount the PVC to the container.
Okay. So here in this flow.
The very first step is provisioning the volume.
Is there a way instead of manually provisioning should I configure dynamic provisioning.
So which means if a PVC is submitted asking for Azure disk 10 GB.
It just submits the PVC. No PV exists let's say.
Just in time create a 10 GB volume in an Azure disk and then bound that volume to the PVC.
If he's asking for NFS 20 GB just in time create it and then provision it and then bound to this PVC.
That is dynamic volume provisioning.
We can achieve dynamic volume provisioning with the help of storage class.
Okay. With the help of storage class we can achieve it.
So before we see how storage class works.
Let's quickly do an exercise.
Hands on on PV and PVC.
Once we are clear then we can quickly look into the storage class.
Okay. So if I go back to my machine.
And I'm going to first create the PV.
If you still remember we are going to create a PV as the first step.
That is my PV file.
Okay. Here it is 8.4 NFS volume.
This is the one. Kindness and persistent volume.
The name of the PV.
I'm going to call this as my PV.
This is the base and then you can alter it.
And if you want label you can put it here.
And you're creating 1 GB in a network file share.
But I don't have this network file share right now.
So it's better.
I can give some kind of host part.
Which will always be available.
Or in the host machine.
It can be any type.
I'm going to go with the host part.
I should be having it somewhere here so that I can copy paste.
This one.
Okay.
Basically I want to create a 1 GB in a host machine.
Part that I've got.
And that's going to be called as my PV.
Okay. There are a couple of other mandatory parameters that you need to provide.
While creating the PV.
Number one. Access mode.
Access mode. That is important.
There are many.
Three access mode.
Many.
Red ones.
That is the access mode.
It is.
Read it once.
Read only many. Read it many.
Read it once part.
Which means you are mounting a part right.
So that you want multiple parts to access it.
Only read only loaded essentially only.
So those things you can specify with the access mode.
So that is important. You need to provide the access mode.
In both PV and PVC.
Okay. So I'm going back here.
And I'm going to add access mode.
It should come under this condition.
Access mode.
One.
Read write many.
This is an important one.
Another important parameter is.
Because we are going to use static provisioning.
Here we are creating the persistent volume by hand. Right.
Not we are not using dynamic volume provisioning.
So if you're using static volume provisioning.
And you don't want the dynamic volume.
Provisioner.
To provision the volume.
It's better to provide the storage class name as an empty.
We will discuss about that in a moment.
But for static provisioning volumes you can set it to empty.
So that if you're not setting it.
Then there is a default storage class.
That will take effect and it will immediately provision the volume.
Okay. In the PVC arrays.
You can keep it empty.
Let's say I'm going to call this as an example.
It's a mini-literals for now.
I think this is a minimalistic configuration of a PV.
1GB in hours. Blah blah blah. Right.
Let's apply this file 8.4.
Kubectl get PV.
Or PV-scout.
As you can see PVs are cluster scoped.
You can see there is no namespace information printed here.
Because it is cluster scoped.
PVC is namespace scoped.
PV is cluster scoped.
Kubectl apply FNF 8.4.
Storage class name.
I called it as a storage name class. My bad.
How if I wrote it as a storage name class?
Storage class name.
It's a split-second delay while I'm typing it.
From here to there.
Just bear with that.
Going back to the terminal here.
Okay. It says PV created.
Kubectl get PV.
You can see PV created.
Access mode.
Re-game policy. There are couple of re-game policies that we will discuss later.
Status is available.
Which means it's not yet bound to any PVC. It's available.
Claim. No claims are bound to it. So it is empty.
And the storage class name is printed.
Okay. So we successfully created a PV.
Step 1 completed.
Step 2. For one of the application.
Let's say we are going to run a MySQL database.
And MySQL database needs a volume so that it can persist the data.
Let's say it stores all the data in varlib MySQL.
We want to persist this.
So for that it's going to need a volume.
So it creates a PVC.
It's going to create a PVC.
The name of the PVC is.
Let's say database.
Okay. So which means we first need to create the PVC.
Take iFile.
Open it. So this is the PVC.
I'm going to call this as my PVC.
And as you see, as you can see here.
We are specifying only.
We need one GB. That's not more than that.
In fact, you can specify in which type you want.
Any specific type you can specify.
And we are also specifying the label selector here.
Which means in your PV pool you may have hundreds of PV.
Look for PV with this label.
Maybe out of 100, maybe three will filter.
Out of three it will try to allocate one for you.
So you can also specify label selector.
Okay.
And then again I'm going to specify the access mode here.
You need to specify the same access mode so that that part will be matched to this.
I'm going to give this these two properties.
In my PVC as well.
So that this PVC will match to the PV.
All right.
So with this change I'm going to apply this YAML file.
Get PVC.
Then give it here.
Apply.
Volume claim.
If you see created.
Give it here.
Get PVC.
Look at this is already says in bound state.
We created and already the existing PV.
Bound to this.
You can get PV and you can verify that.
Look at it.
My PVC from NPOV and NS.
This PV is bound to this PVC.
Which means all good.
If you go now.
And if you submit this YAML file SQL.
The name of the PVC is my PVC.
Then your SQL server will look perfectly fine and all the data that is in here will go to the.
Host.
Okay.
So what is more important here is.
Understanding what PV and what we did this and static provisioning.
From that access mode.
And then you can specify the reclaim policy and all that we will discuss after.
All of this information create a PV.
And then from your application perspective.
For your application need you are going to submit a PVC.
And this PVC is referred in your pod specification.
Okay. If you are submitting a PV and it is unbound state.
If you try to spin up the pod it will fail.
Because it will try to mount the volume.
There is no volume mapped to the PVC.
So pod will not start up.
So you need to first make sure it is bound.
Then only you need to run your application.
Okay.
Alright. So now.
What I am going to do is.
I am going to create one more claim.
Copy this.
Altogether a different claim.
I am going to rename this.
My PVC.
Let's say called it as MyPVCtest.yml.
And here I am going to call this as an.
ImprovPVC.
We don't need this label center.
Let's remove this. Keep it simple.
Access mode.
1GB read rate menu.
That's it.
And I am going to remove this storage class name also.
I want 1GB.
This is the only requirement that I am asking to the Kubernetes.
Through PVC.
Right.
Let's see what happens if I apply this.
Kubectl.
Apply.
My PVC.
Kubectl.
Get PVC.
Type.
PC.
So as you can see here.
This is also showing now bound.
And it is bound to also an volume.
The volume name looks very.
Random.
And the storage class is standard.
If I do get PV.
Kubectl.
Get PV.
What happened to my machine.
Okay.
Here we go.
This is the one that we created.
This is the one that is dynamically provisioned by the Kubernetes.
Using the storage class name standard.
Okay.
So which means.
If I query for Kubectl.
Get SC.
As part of the minikube installation.
There is one storage class that is there.
Name of the storage class standard.
And that is set to default.
And it's using minikube host path provisioner.
So I submitted a PVC.
Without specifying any storage class name.
So the default one executed.
So it provisioned in a host path.
And then it bound that.
Dynamically provisioned volume to your PVC.
Which means what all you need to do is.
If you want to.
Let's say in your team you are going to use storage from different providers.
Let's say.
You have.
You are going to use Azure disk.
GCE persistent disk.
And then you are going to use the host path.
Let's say.
So for each of this you are going to have some kind of provisioner.
Provisioner component.
Basically installing it as a plugin is going to give the provisioner.
Provisioner.
Okay.
Provisioner is the one that's going to actually provision the word.
I mean creating the volume there and then.
This is the one that's going to do every step.
So by referring this provisioner you need to create a storage class.
Storage class.
Storage class.
Let's say the name of the storage class is Azure.
This name of the storage class is GCP.
Name of this storage class is.
Minikube.
Let's say.
So while users are submitting PVC in their email file they can specify which storage class they want to use.
Let's say for events application he wanted in a Google platform so he can simply give GCP.
Because storage class is GCP.
The moment when you submit this storage class will be used.
This provisioner will be used.
And dynamically a volume will be created here.
And then it will be moved down to this one.
If Colin submits with storage class name as an Azure then this provisioner will be used to dynamically provision.
If Darlington submits without storage class name then out of these three you can set one as a default.
So that if anybody submits without a storage class name.
They will get involved from the Azure system.
I should just.
Okay.
So.
It's about you're going to statically provision or dynamically provision it.
So we already seen one sample for statically provisioning it.
And we just seen one sample on how if a submitted PVC standard provisioner provision dynamically provisions a volume.
By all means the PVC must map to an PV or else your application part that covers the PVC it won't start up.
Okay.
So with this I'm going to keep a pause here.
Or any questions.
If no questions it's time to try this and stop.
The question has come as meanwhile.
Any questions.
Is this clear.
Yes.
Good.
Basically resizing the volume.
That was the question right.
Yes you can resize the volume not PVC.
PVC is just about the time when you bound.
That's the time it will take effect after that.
You can expand the volume.
It will work.
That won't be a problem.
It's up to one sponsored buying.
But mostly as we will end up updating the PV and PVC and then submitting it.
It is extra size provided.
Let's say you are you are created a PVC.
Let's say you are using a dynamic provisioning and you said one GB and already I showed this one GB created.
Now if you want more space then you need to do that update here.
And in the in the in the already allocated PV it will it will do update it.
So this this should your back end storage provider must support that kind of expansion.
It's not not with the Cuban needs.
It's with the storage provider.
Some storage provider supports it.
Some storage doesn't support.
Right.
But most of the cloud provider solution supports it.
OK.
Right.
OK.
It's OK.
It's reclaimed policy and we are going to discuss that.
But let me ask you asked about it.
What what should happen if you delete a PVC.
OK.
That's what the reclaimed policy is all about.
Let's say we have only three values retain recycle and delete.
So far dynamically provision volumes the second one that you created you seen in the delete because that's the default volume.
Which means it will be automatically deleted if you delete the PVC.
If you delete the PVC PV will also the associated PVC will get deleted.
If if if you set the reclaim policies and delete.
OK.
So if you if you don't want that you want the PV to be because PV is holding some data.
Why deleting the PVC should delete the PV.
If you want to retain then you can specify the written policy.
So which means if you delete the PVC PV won't be the associated PV will not be deleted.
It will be moved to release space so that you can do some manual recovery on the date.
All right.
Similar to that recycle is just I think recycle will simply recycle the data and it will.
What recycle will do.
I forget it.
Let me check.
It is the common thing that we use.
Recycle recycle recycle means the volume back into the pool of one once it is released from this claim.
OK.
It will be back into the unbound.
It will be set to unbound so that other PVCs can simply use it.
I think that I will be deleted.
That I will be deleted and then the status will be changed to unbound.
Which means if there are any new PVCs come in maybe if match is found that we will get out to it.
OK.
That's it.
Any other questions.
OK.
No questions.
Please give it a try.
Let me share those all the two embers that I used here that you can have this as a reference.
Are you know what to do support those two properties.
But let me copy paste it.
OK.
OK.
OK.
OK.
OK.
OK.
OK.
OK.
OK.
OK.
Thank you, thank you, thank you, thank you, thank you.
Thank you.
Thank you.
Thank you.
Last two minutes to complete this activity.
Thank you.
Alright, time up for this activity.
Let's go to the next section.
So what we just completed?
PV, PVC and then storage class.
Okay, so the next one we are going to discuss is a pretty straightforward resource.
A simple, very, very simple resource and it has a valid use case where we can go for using one such resource.
In your cluster, let's say you have three nodes and Ivan is the administrator.
He wants to see how each of these nodes are performing.
So for that, he wants to run some kind of software here in this machine so that it can gather some metrics about how these nodes are performing.
So he wants to run one here, install one software here, one software in this machine so that it can keep observing this node.
And he can see all of these metrics gathered from these machines in another software and he can see some kind of visualizations.
So more often an agent like tool, isn't it?
An agent or team and like to or he wants to run a lock character, one lock character in every node.
So in Kubernetes world, everything will run as a part.
So if even wants to deploy this application, he may go with deployment, setting the replicas replicas as entry replica will create three parts.
But is this will be placed one one copy of part in every node?
That is not the guarantee. That is not the guarantee that replica setting up.
We never discussed about that. If you give the number of replicas as number of nodes, it will always place just one in every node.
It will try to distribute, but it is not a guarantee that it will run one copy of part in one node.
But here, in case of events, metrics application or logging collector application, we need that guarantee.
I want one copy of part in every node because metrics collector, logging collector are those application that falls under that nature.
So for these kind of agent like or daemon like application processes that you want to deploy and Kubernetes Kubernetes community came up with a new resource called daemon set,
which means if you create a daemon set, daemon set will also create parts.
But the reconciliation loop logic of daemon set is create one part in every node.
That is its logic. Let's say if you delete this part, then the next moment daemon set will realize that this node doesn't have one copy of the part and it will immediately create that one.
One per node. That's its logic.
Daemon sets logic.
That's it.
Daemon set ensures that all nodes run a copy of your part in bracket.
They also specified some. So what it means is you have three node, but this the application that you're going to run,
it may not run in node two because node two is using some kind of legacy hardware.
This software may not work there.
So you want this daemon set to focus only on N1 and N3 and exclude N2.
If you're not by default, it will it will consider all the nodes in scope.
But this time you want to exclude N2 from the scope.
If that is the case, then you can make use of the labels concept here.
You can label the node one as type equals modern.
Node two as a type equals legacy.
Node three with label as and gives it a label node N3 type equals modern.
And then the daemon set specification.
You can specify the node selector and they can tell type equals modern,
which means now this daemon set will focus on only the nodes that has this label has one copy of this part.
So by that way, N2 will be excluded.
OK, that's the reason it says all or some nodes run a copy of a part.
And the use cases are if you want to run a storage daemon, log collection daemon or node monitoring daemon on every node,
then you can run those components as a daemon set.
Kind of a daemon set. And then here they're running a fluently log collector and then a daemon set.
Typical what we discussed earlier.
On the type is daemon set, this is going to create one part in every node.
If you deploy this yaml file, all we have is only one node.
So in that one node minikube, one daemon set will be running.
Let's see if there are any daemons running in the kib system namespace already.
It's a real.
In the namespace system.
OK, kube proxy component is running as a daemon set.
As all we have is only one node, one is current and it's ready and it's up to date and it's available.
The node sector here is all the node that has the label of the operating system is unix.
Minikube node is unix, so it's used for all that.
Maybe in your infrastructure you can verify because you may have multi node.
You can easily check this.
All right, any questions on the daemon set?
Because it's straightforward and skipping the hands on part of daemon set.
Any questions?
The use case or how it works?
Why we need daemon set?
Why not replicas it at deployment?
Right, I take the silences and all good.
Let's switch to the right place.
OK, in the daemons in the daemon set, it will always be one in every node.
That's it.
There is no scale command is not applicable for daemon set.
OK, so it's not if you want two parts in every node that is not possible with daemons.
Just only one in every node.
So scale command and HPA, all those things are not applicable for daemon set.
Because scale command is not applicable for daemon set, HPA is also not applicable.
Wherever scale command is applicable, in all those spaces you can configure HPA.
But for daemon set, scale is not applicable.
It will always be one.
That's it.
One in every node.
Not two in or three in.
Sorry, is that a question you're asking?
The use case for this?
Yeah, yeah.
So the typical use case is a log collection daemon.
If you remember, OK, as you asked about the use case, let me explain this scenario.
In your cluster, all the applications, let's say these are all the containers that are running and all the applications are going to throw some logs, isn't it?
There are multiple ways you can aggregate the logs that are coming from all those individual containers.
For example, each of your application may directly write to a logging backend.
Like, let's say you have Elasticsearch.
All the application may directly write from its app code to the logging backend.
But this is not the approach that we will do because here we have a tight coupling between logging backend and the app code.
So tomorrow if I switch to Cassandra from Elasticsearch, then that will record code change in every application and new deployment.
So we won't go with this approach.
The standard approach that we follow is if we take one single node, you have multiple containers running.
And in this node, you also have Docker engine installed.
Docker engine.
Kubernetes works with the Docker engine to manage the containers, right?
Kubernetes is not creating the container.
It works with underlying Docker engine to create the contents and managing it.
So what we will advise to the application team is, hey, from your app code, write the logs to standard out.
And standard errors.
All the containers will throw the logs to its standard out and standard errors.
OK, so this Docker is the Docker engine.
We can actually get the logs from standard outputs from all these containers that are running in that node.
So along in the same node, node one, I can run a daemon, a log collector daemon.
Let's say Fluentd and this Fluentd will work with the Docker engine to gather all the logs from all of these containers.
And this will forward to the centralized logging packet.
Similarly, on another node, I will have a log collector daemon running that will collect all the logs from the containers that are running in this node to the log collector bin.
Similarly, another node, log collector packet.
And on top of it, I may run one kibana and user interface with which I can analyze and find some information out of the log.
So this is one use case where I will run the log collection daemon that I want to run in every node.
So I can deploy it as a daemon set.
If not, then you may need to install in a traditional way.
But as we are in the Kubernetes world, even the Kubernetes components are also running as parts.
So here the daemon also we are running as a part.
It runs as like all other application runs as a part.
Similarly, the same goes for monitoring daemon.
If you want to monitor every node that are participating in the cluster to see how it is performing.
So you can run a monitoring daemon that will capture metrics from the nodes and it all will send it to a centralized location.
And then I can have a storage daemon if there is an host machine provision that you want to run in every node.
Right. Does this information helps?
Okay.
No, no, no, no. No, it's...
Okay.
Okay. So first of all, rolling update is not applicable for daemon set.
Rolling update is applicable only for two resources.
One is deployment.
Another one is stateful set that we are yet to discuss. Stateful set.
So you can't do a rolling update for a daemon set.
No, no.
That is with the daemon set.
Later you can try that sample and do get daemon set and then you can explore it.
Now let's move to the next object that is stateful set.
Any idea about stateful set?
Are you already working with the stateful set?
Yes, no. I heard about it.
Okay, fine.
So let me quickly explain the case for stateful set.
Why? Why I already have deployment, replica set, daemon set?
There are many resources. Why I need one another resource?
What is this? What is the requirement that this resource handles?
Right.
You have your Kubernetes cluster that is running all your application workloads.
Let's say node 1, node 2, node 3 is there.
All your backend APIs, frontend, it's all running here.
But think about the data layer, your database.
In general, for the databases itself, we will have a cluster setup.
If it is a Mongo cluster, Mongo database, then we will have a cluster M0, M1, M2.
And it will have some kind of cluster setup between it.
And it will have some kind of synchronization logic that's happening.
Some physical replication, logical replication, right?
And one will be a primary server and two secondary servers will be there.
If primary goes down, one will be elected as primary.
One secondary will be elected as primary.
So already, for the database-like solutions, you will already have some kind of cluster setup.
And if you look at this cluster setup or the way these clusters are formed,
first you will start with the first node.
You will set up something here and then slowly you will join the M1.
You will join by its name, right?
You will go to M1, execute some command, provide the M0 name
so that this will become part of the cluster.
And then M3, this will become part of the cluster.
So that's how you will form the database cluster.
And once you form the cluster, all the replication logic,
all those things that happens between the scene, it relies on the identity of this one.
M1 relies on M0.
I mean, based on the identity only, they are going to send the data to M0 or M3,
which means this identity is fixed throughout.
If you change the identity of the server,
that will break the cluster setup and you need to fix it, right?
So this being the case, and then remember, it's all handling with data.
So back in those days, organizations were completely hesitant to run databases
inside the Kubernetes cluster.
It was OK to run the backend APIs, frontends,
because it was initially meant for, I mean, the entire microservices itself,
it was meant for stateless applications, right?
But these are all going to maintain some data.
And if you run it, of course, you can back up your database with volumes.
But still, if something goes wrong, it will end up with a data loss, right?
That's going to cost your organization a lot.
So organizations were running their database cluster outside of the Kubernetes cluster.
And all the frontend layers, middle layer layers, service layers,
it's all running in the Kubernetes cluster.
OK, that's how it was that 2016, 17 and up.
And then what happened is Kubernetes community started to analyze this part.
OK, what needs to be done in the Kubernetes
so that database like solutions can also run in the Kubernetes cluster?
What are the requirements?
List down the requirement.
And let's see whether we can implement one such resource
with those capabilities.
And that's how straightforward it was born.
So it was not a complex requirement.
It turned out to be a very simple set of requirements.
Number one, if you create a deployment, if you set the instances to five,
then all the parts get some random name, isn't it?
Random name or ran name with random hash ID.
Correct.
And if I delete this, then one another new part created with completely random new names.
So in case of stateful set for the databases, you must have a fixed identity.
And that fixed identity will also be in an with an ordinal index, ordered ordinal index,
which means if you create a stateful set, it's also going to create the parts.
If you set the replicas to five and if the name of your stateful set is Mongo,
then the instance that will get created is Mongo zero.
And the second instance will be Mongo one and then Mongo two, Mongo three and Mongo four.
So if you look at the name, it will be in an ordered index.
And then if I give five, all the five will start up at the same time in the deployment work.
But in stateful set, first Mongo zero will start.
And once it is ready, then it will go for spinning up Mongo one.
Once it is ready, then it will go for Mongo to Mongo three and Mongo four.
Ordered startup.
If I scale down to five to three, only that four and three will get it in.
First four will get deleted.
Three will get deleted.
Deletion will also be in an order from higher order to lower and lower order indexes.
Okay. Fixed identity, which means if I delete Mongo one,
then a replacement will be created and that will also get the same name Mongo.
It is a fixed identity.
This makes sense, right?
For example, if you set three, first M zero needs to initialize Mongo zero.
It needs to set all of the required stuff in it.
And then your primary server is running.
Then you are going to spin up the secondary M one.
And it's going to execute some command and it's going to part of the cluster.
And then M three sets up and then it's part of the cluster.
So that makes sense more from this perspective.
So that's the reason we need to have that identical passion.
And when it comes to scale and also the one that with the higher index
will get first deleted and then go here and then go here.
So far, the stateful set rolling updates are possible.
And if I do version upgrade, it will also happen one by one.
First zero will be updated and then one and then two and then three and then four.
Everything will be ordered.
OK, so this is one requirement and the naming and then the fixed identity.
Second one is you created a stateful set.
Mongo and you have Mongo zero, Mongo one and Mongo two.
And this is the primary and these two are secondary servers, let's say,
for the cluster.
And you have a front end application that's trying to access the front end
or back end that's trying to access the database.
We have three instances.
So generally, in these cases, we create the service.
The same you are going to do it here.
To access this or the stateful set, you are going to create a service.
And once someone calls the service, in general,
we know that services is going to route the records to one of it.
But that is not a valid case here.
Load balancing is not required here because this is the primary server.
The request can correctly go to primary server.
We don't want load balance to secondary service because it's all just doing
some in sync replica logics between them already.
So we don't need load balancing logic by the service in the stateful set world.
So what we will do is while creating the service,
we will explicitly set cluster IP as sender.
Because when a service is created, it will get a cluster IP, correct?
That's the one that load balanced to the endpoints.
If you set cluster IP to none, which means no cluster IP will get assigned to it
because all these instances got a fixed identity.
So this front end can simply directly reach to it like M0.
Let's say the name of the service is Mongo.
M0.mongo.
It can simply directly reach to it because this identity is fixed.
In these cases, all these identities were not fixed.
So we relied on service.
So you can create a service and you can set the cluster IP to none.
If you create a service with cluster IP to none, it's called headless service.
Headless service.
We call that service as headless service, which means for stateful set,
we will create headless service only for stateful set.
Because that's where we don't need that.
Load balancing logic is not applicable there.
This is difference number two.
And then the last difference is if you create a deployment
that great replica said that great part, three replicas.
And in the specification, if you have some volumes,
PVCs and if you have a volume from AzureDisk,
so basically the same volume is what shared by all of these replicas.
It's not that every part will get in different different volume.
It's just one GB, one GB from the AzureDisk for all the three parts that it's using.
But if you are going to have the similar logic for the stateful set,
it makes no sense.
Primary server, secondary servers is all going to do work on one single backend.
Then why we need the replication logic?
Where is the high availability stuff?
Those things, everything doesn't make any sense here.
So for the stateful set, if you create it, every instances will get a copy,
which means every instances will get one GB of Azure,
one GB of Azure, one GB of Azure, different different volumes.
So which means while defining the stateful set,
we won't give PVC instead we will give PVC template.
With that template, every replicas will get a new volume created
dynamically provision is going to be assigned here.
Template, PVC template.
Okay, so to list down ordered index for instances,
ordered scale up and scale down, fixed identity, headless service,
and then this one, PVC template.
So these are all the differences.
Requirements that you have implemented,
and these are the behaviors of an stateful set.
So with this, you can deploy your data-based solutions
also into the Kubernetes cluster.
Okay, it's still evolving.
There are a lot of limitations with this,
but we could see many production implementations for stateful set.
Okay, if you want to manage stateful applications,
then we will use the stateful set.
It provides guarantee about the ordering and uniqueness of the party.
It's not about for database.
Database has those requirements, so we are doing deployment.
For your application also,
if you need some guarantee about the ordering and uniqueness,
then you can deploy it as a stateful set.
Okay, and then the use cases are when you will go for stateful set.
If you are looking for a stable, unique network identifier,
stable persistent storage, ordered graceful deployment and scaling,
ordered automatic rolling updates.
Okay, and example, kind stateful set,
the meanings are same, three replicas,
and look at here, volume claim templates,
because every, all the three individual one by one,
it's going to get their own volumes.
And look at the service cluster database and then headless service.
Okay, so maybe you can just try this one.
Looks simple here.
Create a stateful set and do get parts and see the way it is created.
Try to delete one, see how it is getting created.
Try to scale up, see whether the ordering is maintained.
Try to call one just by its identity.
Okay, just give it a try, please, on the stateful set.
That's it.
That's all I had to cover for stateful set,
which is more than enough for the examination.
Any questions on the stateful set?
If no, please give it a try.
So while I'm explaining,
I would recommend you to have the QBanis documentation
for the respective resources open in your screens.
Parallel refer it, because during the examination,
you are going to heavily rely on only this documentation,
QBanis documentation.
So you should know where to locate,
where to find stuff, and all those things.
For the stateful set,
you can try the sample that is there in the QBanis documentation.
Just copy this .ml file and then apply it
and observe the behavior that will do.
Thank you.
Get SDS.
Sorry if I forget to tell that comment.
You can do QBanis, get stateful set,
or get SDS to view the stateful set resources.
0 out of 3 ready.
Let me look into the screen.
Which example do you use?
What is the application you are deploying from the site?
To get pods, QBanis will get pods.
It will just spin one by one.
Web 0 is in a pending state.
Which means it is still trying to spin them.
You can describe Web 0 and see the event section.
Is that what you are trying?
QBanis will describe.
QBanis will describe pod Web 0.
Let's see.
This is about volumes.
Can you look into your YAML file of your stateful set?
It is not able to bind the volumes.
Look at the volume claim template section.
You may want to down down claim templates.
Here you give storage class name as my storage class.
But I don't think you have that storage class.
So better delete the entire storage class attribute.
So that the default standard storage provision will be used.
What do you think?
And yeah, 1GB.
You are going to get 3GB.
There you have 3GB minikube.
That's the next question.
Let's see.
Delete and recreate it.
OK.
Again, the first pod itself failed scheduling.
0 slash 1 pod as unbound.
Immediate presence or decline.
Preemption 0.
Notes are available.
One preemption is not helpful for scheduling.
I think it's about the about the minikube.
The resource available that we have.
Red ones.
It's trying to preempt the pods to accommodate these.
OK.
Go back.
Go back to the error message.
Preemption 0 slash notes are available.
One preemption is not helpful for scheduling.
One pod has unbound.
Immediate persistent.
Can you get PVC?
OK.
Delete that.
You don't need to delete that.
Storage class is not reflected.
OK.
Delete it.
www web 0.
Delete that PVC.
Now apply.
Delete your stateful set and apply again.
Now it is bounded.
It started.
You can do get pods now.
I think by the time web 1 and web 2 will already be spin up.
Web 0 is running.
How many replicas there?
Three, right?
Stateful set with three.
So to get pods again.
If it is running.
Yeah, if it is running, it should have it should have spin up one more.
Yeah, it's there.
Web 1.
Good job.
I hope others.
No, no, it's what it was not bound to previous deployment.
It was referring a storage class name my storage class.
But we don't have any storage class with that name.
So PVC was unbound.
It started bound to volume.
So pod was not able to start up.
So what we did is we modified our PVC claim template.
To delete the storage class name so that it can use the standard storage class.
So as part of SDS creation, it created a PVC.
And that PVC we deleted and then recreated and that work.
So volume must be mounted, bounded to a PVC so that your pod will start up.
If volume is not bound to PVC, then your pod won't start.
That's what happened in our case.
Is that good?
Okay.
Okay.
Okay.
Now time is two thirty two.
So let's take a quick 15 minutes coffee break and be back by two forty seven.
Forty five.
Let's say thank you.
Thanks for listening so far.
Okay.
Thank you.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
I'm back.
Please raise your hands in the teams.
Just a quick check.
Thank you.
Perfect.
Perfect.
Okay.
We are going to discuss our next object.
Or maybe I will cover this just one or not two objects.
I have two objects to cover.
Let me cover the theory part of it because in some exams they ask about it.
But it is not part of the curriculum.
But I heard in a couple of exams they ask about it.
So having an idea about what those resource and the use case for that will really be helpful for you guys.
Right.
So the next two resources we are going to talk about this jobs and cron jobs.
Any idea on what is this?
And you are already using these resources for your existing applications.
Jobs.
Okay.
Okay.
Let's look into the use case first.
And then we can observe the behavior of this.
Jobs.
So applications that we've seen so far.
The engine X application on the card application that we seen.
Those are some kind of websites or web server.
That's a long running process.
It will be running throughout until you stop or delete the deployment.
It will be running throughout.
Right.
But there are some applications of nature which are shortly shortly to one of task which means they have some set of steps to do.
And once it's it's it's executed to its entirety then that's it.
So to run.
Applications of this nature.
In your cluster we are going to use a resource called jobs resource.
What is the behavioral difference?
I can simply run this as an deployment or replicas.
That will also execute the same logic isn't it.
But the difference here is you have some set of activities to perform.
And you start your application starts from here.
And all the way it executes to its entirety.
It's successfully completed.
So at the end it will exit with some success code.
Let's say zero as a success code.
If your pod exits with an access code zero.
I mean your application exists with an access code zero.
That is.
That means a successfully it's done its job.
Then the pod status will be marked as uncompleted.
Never seen that scenario.
Having this looking at the status as uncompleted.
But while executing something went wrong in step number nine or ten.
And then the process exited.
With some failure code other than zero let's say minus one.
Then this is considered as an.
A failure scenario what job will do is.
I created a job that created one pod.
And this is the pod executing now.
So when I created it will maintain something like this.
Zero slash one completions.
Which means it expects for one successful completion.
So if this happens happy path happens one slash one.
Pod will be marked completed.
Job will be marked completed.
But if this happens then that pod will be resorted again.
It's going to execute all the steps.
Expecting it to complete our exit with access code zero.
If it fails again.
Again restart again restart.
So there are some let's say some six tries it's going to do by default in an exponential fashion.
Even after the six tries if it still fails.
Then.
The pod will be marked failed and the job will be marked.
Which means.
It never met its completion so job is failed.
If on this retry somehow if it worked.
Then it will be one slash one that is job is successful.
OK.
So that's that's the idea.
Only if it is successfully exited then mark completed.
If it is failed then try to restart it.
Until you meet the count.
OK.
Let's say the nature of application that you are going to run here is some kind of.
Database migration script.
If you deploy the same as an replica set with replicas and one.
The pod will run.
It will run to its entirety and then it will exit.
What replica set will do.
When it exits.
Its current state is zero.
So it's immediately restarted or it will create a replacement.
This will again exit.
This will again execute.
Which means you end up replicating the data again and again with the same data.
So it's not a valid case here.
Because no matter if it exists with the success code or failure code replica set will always restart it.
Because it needs to have one copy running always.
That's the nature of the replica set.
But that is not the case with the job.
If you create a job it will also create a pod.
If this pod successfully completed.
What mark successfully completion what mark successful completion from within the application it should exit with them.
Successful then it will be mark completed job is completed.
If it fails then restart only in the failure scenario it's going to restart.
Restart or create a replacement until it meets the successful completion count.
So which means you can actually set the completions count while creating the job.
You can specify two properties one is how many completions you want.
Let's say you want 10 completion successful completions.
Let's say even build one key generated up key generated application.
Every successful run will give you 10 keys.
So you are looking for 100 keys.
So you are looking for 10 completions 10 into 10 10 into 10 it's going to give you 100.
So what job will do when you create it will be marked as something like this.
I want 10 completions and the first part will run successfully completed.
So 1 slash 10 second part will run 2 slash 3 3 slash 10 and then 10 slash 10.
So it will go one by one.
So if you want to speed up this process you can set parallelism.
Parallelism to 5 which means if you get the job at the time you will have five parts running.
So which means in the moment five will be marked completed.
So 5 slash 10 in the next iteration another five will run or at any point in time you will have five parts running towards meeting this successful completion count.
So by the time when you receive 10 completions parts 10 parts that are in completed state and job will be marked completed.
One use case where we will use this job heavily is work queues to fetch items from and centralized work queue.
Let's say you have a work queue multiple producers are producing messages to the queue.
And let's say every day 1 a.m. you want to run a job that's going to read the messages from the queue and process it.
So the consumer application right that you can run it as a job.
It's I can run a job with three and here I can specify parallelism as a three.
And completions it will vary isn't it.
No matter today you have thousand messages yesterday you had 20000 day before yesterday you have only 50 messages.
So completions we don't have.
So if you set only parallelism.
And leave the completion empty.
That is the use case for work queue job.
So which means this job will execute until the queue becomes empty.
Once you become empty then everything will be more completed job will be more completed.
OK. So basically I specified three scenarios for you under the job.
First scenario is excuse me.
First scenario is you are going to create a job that's going to create one part.
So initially when you create it will be zero slash one and one completion is expected zeros.
We didn't receive any completion.
And after a while if it is successfully completed this will become one slash one and all good.
This is marked as uncompleted.
Shatters will be set to complete job is completed.
That is one. Second is the same where we play with parallelism and completions.
You have a fixed completion count to reach with this many parallel.
And the third is you are going to create a job by giving only parallelism.
No completions you will give. So this is the use case for centralized working on and centralized queue.
So three kinds of three variants of job.
OK. So later you can try this.
I'm leaving it up to you to try the job and job is also going to create a part.
As I mentioned you can see the status is getting completed.
These are the three types that I mentioned non-parallel jobs which means only one part is started.
And the job is completed as soon as that part is successful.
Parallel job means you are going to specify the completions.
And parallel jobs with what you means you don't specify completion.
We will specify only parallelism.
OK. There are some other concepts here that you can look at later.
So once a job is completed.
It will be there in the cluster for around let's say five minutes.
And this is a this is also a configurable property time to leave.
So if it is successfully completed it will be around for five minutes.
And then it will be cleaned up automatically which means this will be deleted.
Deleting the job will also delete all the parts that it created.
OK. Any question on the job.
Is it clear the use case and how it behaves.
How it is different from the existing resource we discussed.
Yes. No.
If it is clear I will skip the hands on.
If you want me to try I can show some hands on the job.
OK. Thanks.
OK.
OK.
OK. I think it from technically if it is clear it means all good.
I have hands on on my file as well as a documentation.
I'm leaving it up to you to look into it.
The reason why I'm skipping the job part is because it's not part of CKE.
But I heard from two participants that there was a question related to current job.
So you need to first know what job means so that they will understand current job.
So I covered that part right.
That's why you try it.
And if you have any questions or challenges we can discuss about that tomorrow.
No problem. OK.
So current job it's same as a job.
But this comes with the schedule.
If you are coming from an Linux or an expo we know the cron tabs right.
Schedule something like every Monday everyone hard every once again.
Something like that. So we will schedule.
We want that to execute.
We want we have a piece of logic that we want to execute every Monday morning 8 a.m.
Right. The same way you can define a cron job and you can tell.
Hey I want to run this cron job every 30 seconds.
And the cron job specification you can actually provide a job specification.
So which means after that is again cron job will create a job.
And after that it will create another job after 30 seconds it will get that same another job.
Another job which means these jobs are going to create the parts that's going to do that short lived activities.
And more complete. So every 30 seconds you will have a job created by this.
OK. It's like cron job is sitting on top of the job and then creating the jobs.
Jobs are going to create the parts and that parts are going to execute some short lived activities.
OK. So here you can see that we provide the job template.
Kindness cron job job template and then the schedule which means every minute.
So a job will be created every minute.
That will run a container that will print hello from Gibbons.
OK. It's something that comes with the schedule. It's going to create the job.
OK. So it's even the same scenario that we discussed here.
If you want to spin up a job to run every day 1 a.m. to finish the queue you can create a cron job.
And specify the job specification so that every day 1 a.m. it will create the job object.
That's going to read all the messages from the queue and process and then it will be more complete.
So once a job is more completed there is nothing like restarting the same job.
You need to spin up a new job to do to do the processing for new setup for items.
OK. Job cron job.
All right. So starting from the morning.
The resources that we discussed is we first started with service and then we discussed several types within it.
And then ingress. That is one resource that we discussed.
And then we discussed on HPA, VPA, CA, all related to auto scaling.
And then we discussed on config map, secrets.
And then after the lunch break we started with PV, PVC and storage class.
And then we discussed on DMIT set.
And then and then on stateful set.
And then we just completed job cron job. Good job guys.
We discussed many resources today. Good job. Good job.
So with this for momentarily we are going to stop on the resources perspective.
Because this pretty much covered all the resources that we used to deploy the application and manage it.
Right. So now we are going to focus a bit on a security gate.
Let me repeat that. We are going to talk about a security gate because in your cluster you have three nodes.
And in your master node you have many components running.
And one component which is the important one is APS server that exposes your cluster as an API.
And event, call and everybody is accessing through this only.
Right. So if I zoom in this APS server part, let's say this is the APS server.
Whatever the request that comes in to the APS server, let it be it come from event or call in or from me.
All the requests goes through three security gates.
Gate one, gate two and gate three.
Three checks like how we pass through the airport.
Security check and then custom check, blah, blah, blah.
Similarly, if if if your request fails in one of the gate, you will be rejected.
Your request won't be processed.
So let's say the processing logic resides here.
All within the APS server, all the three things happens within the APS server component only.
So the first security gate is authentication.
Whether he is then valid.
Be the BMW employee.
Second check is BMW or Benz.
Sorry, I'm confused. I was looking for Benz.
That's right. This is the BMW.
Okay. Authentication.
And the second gate is authorization.
Let's say this event.
And he is trying to.
Perform some operation.
Cube CTL.
Get secrets.
He's trying to view the secrets.
His records goes here.
And he's checked whether he's an employee of your organization.
Credential supplied.
All good.
So he first passed us first gate.
Second gate is authorization.
Whether he is entitled to perform the gate operation on secrets.
Whether he can view the secrets or not.
Maybe only managers can view.
Or only operations people can view not the developers.
Maybe you have some kind of those checks.
So that is that will happen at the authorization layer.
And if he has those permissions, let's say he will move to the third layer that is admission controller.
So as a cluster administrator, this is the layer where we can have more control.
So we can do mutation.
And validation.
I'm going to give an example of what it means.
Okay.
Three gates.
Authentication.
Authorization.
Admission controller.
After successfully passing through all these three gates.
The request will be considered for processing by that.
By the cube.
It's okay.
So when it comes to authentication in the in Cuba Nets.
We don't have any user management or group management.
Those things are externalized, which means you can you may already have a system.
You can take it and then integrate with the cube.
And it's for example, your active directory.
Or if you have a book.
Or with the client certificates.
Bootstrap.
Token.
Service account tokens.
Open ID accounts.
Are you aware?
AWS IAM.
Azure AD.
So in Cuba Nets, we don't have the concept of managing the users, creating a new users, nothing like that.
You have an existing system while bootstrapping the API server.
You need to specify which authentication mechanism you are going to use.
And then the configuration is related to that.
So that whenever a request comes in, the API server will use that mechanism.
And the authentication provider is going to give a response back to the API server.
If the authentication is successful.
If it is successful, some data about the user.
Like the group that he is part of.
So also details.
OK, so we don't have much to discuss with respect to authentication because.
All you already have, you're going to just integrate with the Cuba Nets.
OK, so in our case, you integrated your organization active directory, let's say.
And even is a valid user.
So it will pass through the first gate successfully.
And the second gate, the request goes to the second gate.
That is the authorization gate authorization.
So here in this gate, we are going to check whether even can perform get secret operation or not.
In Cuba Nets.
We will use a concept called all back role based access control based access control is just like this.
So this came all the way from the open ship open ship.
They contributed this concept to the Cuban Nets community.
Role based access control.
This is pretty straightforward.
So I'm going to explain and we are going to do a quick hands on because you will see a couple of questions on the exam with our back.
Just list down all the subjects or resources that we discussed and then the verbs that we discussed.
For example, the verbs are get, create.
Labs.
Exact.
Describe.
What are the verbs that we discussed?
Delete.
List down all the verbs.
List down all the resources.
Parts.
Secrets.
Config map.
Deployment.
Replica set.
List down all the resources that we discussed.
That's it.
With this, we are going to do a simple thing.
What is that simple thing?
First, we are going to create.
A role.
Rolled up a email kind as enroll.
And under the specification, here you are going to give a name for your role.
Let's say the name is.
Part reader.
And under the specification, you are going to tell a load verbs.
Get.
Describe.
That's it.
Two verbs on the resource.
Part.
So what it means is you created a role called part reader that if one has that role, he can perform only get and describe operation on the part.
This is just the role.
This role is not at us into event.
Even our call it.
Okay.
Once you have the role defined.
All you are going to do is create one more email file.
Rolled by me.
You are going to bind the troll to a specific user or to a group.
Group information is also not maintained in the cube.
The next authentication provided the group information.
So you can also bind the role to a specific group.
The user is part of the group.
Then the troll will get affected.
So same kind as enroll binding.
Under the specification, you will do something like a.
Apply to user event role.
That can be user.
It can be group.
It's a event.
So which means this is the one that actually binds this role to the user called event.
So which means even can perform only get and describe on the part.
If you try to delete the deployment or do anything, then you won't be able to do it.
Is the request will simply be rejected because he is not authorized to do that.
Okay.
That's how we do the role based access control.
So this role and role binding applies at namespace level.
Only the namespace where you are creating.
But if you want to create something that should appear at an entire cluster level, then it is cluster role.
And cluster roll by which means this role and roll binding applies at the end.
Cluster.
Roll or bag.
Okay.
One sample or bag roll.
For reader part.
Perform only get watch and list.
And another example for cluster role.
The namescape namescope is skipped here because it's it's at the cluster level.
Secrets secret reader secret get watch list.
Only these three operations.
And if I want to bind that role to an user, then roll binding.
User event.
Roll reference part reader.
The same goes for cluster role binding also.
Nothing difference.
So here we are binding it to a group with the name manager instead of user event is group manager.
Okay.
So that's it about the role based access control.
So in our security gate based on the or bag that even has let's say he is allowed to pass because he has the permission.
So his request will go to the.
Pass the second gate and then it will go to the third gate.
That is admission control.
Admission control.
So which means this is just a configuration of the APA server itself.
So by default, kubernetes provides some 30 plus admission controllers.
30 plus admission controllers, which means if you aren't properly enabling set of admission controllers, it means your APA server is not properly configured.
So you need to enable some set of admission controller or your APA server to function properly.
So it's about there are many features that are just disabled.
And you need to enable those admission controllers if you want it.
For example, if even is submitting and request in part specification and in the part specification, he don't he didn't specify resource request and limits.
He just submitting it without resource request and limits in it.
So at the admission control layer level, we have an admission control.
If you enable it, that will simply reject the request, saying, hey, include the resource request and limits.
I can't admit you.
I don't give admission for you in my cluster because you are not giving this required details.
OK, so you can do validation like this if it is found if not rejected.
In some cases, it can it will also mutate, which means assume he submitted and request for them.
But it doesn't have any namespace information in it.
So at the admission control layer level, your admission control can manipulate your request.
It will just include namespace as default.
And then it will be considered for processing.
So mutation also will happen.
So what you submit is not what you are going to see, because in between an administrator can mutate it at the admission control level.
Let me give you one valid example here.
Let's say multiple teams are submitting applications to your cluster and you decided to run a sidecar along with every application.
And this is going to do some kind of helpful things for you to manage the cluster.
So when they submit the application team, they submit a specification with only their container definition.
But here in the admission control layer level, you can include one more container in their specification and then submit for the processing.
OK, so as administrator, you have more control of this.
You can do validation or mutation.
So if you look at the documentation, there are many.
Mission controllers.
I think that is valid for you.
You can simply enable it.
They pay several levels.
So this is how it is.
So we will enable or disable the name of that mission controllers.
If you want, you can also write your own admission controller.
OK, let's say.
You are you observed on behavior, right?
You submitted a PVC without a storage class name and by default, the standard default storage class.
Big did that behavior happens because in your cluster default storage class, administrator, administrator, admission controller is enabled.
If you disable it, then nothing will happen.
If you submit it.
I think will happen.
It will mean no dynamic provision will happen.
Nothing will get assigned to your PC.
So it's the AP server functionality itself.
So you need to enable right set of administration admission controllers for your cluster to behave properly.
OK, you can refer this documentation.
They have definition for every every.
Admission controller, for example, names as exist.
This is an admission controller.
It will check all requests on namespace resources other than namespace itself.
If the namespace reference from a resource doesn't exist, then the request is rejected.
So if you are trying to submit something with the namespace that doesn't exist, then if this is in place, this will simply this admission control is enabled.
This will this will detect your request.
OK, it's in the documentation.
You can search for it.
So three gates.
It is admission, authentication, authorization, admission controller.
But what is more important for you from the exam perspective is our back role based access control.
So now we are going to do one quick hands on for our back.
That's two to three questions you can expect from our back.
You can give some example from documentation.
Our back.
OK, let's go with this bitnames documentation, something that we can trust.
Mm hmm.
OK, let's try this one.
Let me include this in the world.
Give this you are.
First of all, and we are in the minikub.
Don't forget that.
So in the minikub, we need to just stop your minikub minikub stop and then start it again with our back enabled.
Enabled our back in the minikub and directly go to this use case one section use case one.
Just try only use case one.
That page has many use cases, but I only use case one.
So what you're going to do, you are going to create a user.
Employee.
And he's going to be part of a group bignomy.
And you're going to add necessary or back policies so that the user named employee.
Can manage deployments only inside a specific namespace.
Office namespace called office.
If you have another namespace in proc, he won't be able to do anything in that namespace.
So far that you are going to create a user, create a namespace, create a role, create a role binding are going to do it all.
It has multiple steps, getting the namespace, creating the user credentials, creating the role, creating the role binding and then finally verifying it.
Okay, some sort of 10 comments or so.
Let's take some five to 10 minutes and give this a try.
All based access control.
Go ahead, go ahead.
The last topic of the day.
Let's see who is going to get it working first.
If you are already completed, just let me know so that you can share your learnings with others.
Okay, is that any error you are seeing?
Is that an error that you are facing?
Who is this by the way?
So that you can I can look into a screen.
Shahid.
Okay, let me check.
Thanks for that.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Yes, please.
Okay, okay.
It's in.
Yeah, yeah.
Just modify the version.
Look into the documentation and update this one.
Maybe from from the version beta one, maybe the by the time when they documented was in version beta one.
I think right now it will be a different version.
Let me check the version from the documentation for the roll.
Right.
Roller roll value.
It's version one are back authorization q8s.
I will case that I will slash be one more beta.
Okay.
Okay.
Perfect.
Perfect.
You completed that.
Perfect.
Perfect.
Good job.
Would you like to share your learnings with everyone quickly on what you find if they are comfortable and okay.
Okay.
Perfect.
Perfect.
All right.
Last two minutes.
But don't get this activity.
Okay.
Okay.
Okay.
Okay, time for this activity.
For this, let's cover last a little more theory part.
And then we are all set to end the training.
We already did some kind of high level review on the resources that we covered.
Right.
So we sing this HP, VP, so on.
So I'm now put this list.
We just discussed about our back also.
Okay.
So there is last one last thing that I would like to discuss and then we can end the training.
Is that okay?
Are you you guys already feel?
It's already a lot for day two.
What's your feedback?
Shall we end or can we make use of the next 15 minutes?
I'm leaving it up to you.
Okay.
Okay.
Okay.
So by any chance, you are using Helm for packaging your applications.
Help.
Okay.
Okay.
Okay.
Okay.
Everybody in the group already know how to use Helm.
Right.
It's my understanding.
Right.
Okay.
Okay.
No problem.
I'm just asking for the purpose of examination.
What do you need to know?
I will just cover it.
It may be basics for most of you, but can be under pressure also.
Right.
So if I want to just deploy one single service to the Kubernetes, I need to create multiple YAML files.
So based on the discussions that we had on day one and day two, first you need to create an YAML file for deployment.
You need to create one YAML file for a service.
I'll share my screen.
I hope you are seeing it.
Deployment and then service and ingress.
You need to create one YAML.
And if it is using configuration or config map for the secrets.
Right.
So at a minimum, you need to create this many resources.
And if this is for version one point one, if you're going to deploy version one point two.
It is using PV and PVC.
We need to create that.
It is one point two.
Maybe changes is not required in all the YAML files.
Maybe at least it will require here.
And based on some scenarios, it may require somewhere in the config also.
Correct.
So for one single microservice, you need to maintain this many artifacts on different portions.
So think of maintaining some 20 microservices.
So this will become already an headache for you.
Right.
So we use tools like, for example, you might have used package manager like APT or APTK.
And then you simply give APTK install and they give some tool name.
And immediately all of the required things will get installed.
And you can directly start using the tool.
But in my case, if I ask you to install this application YAML in the Kubernetes,
then first you need to create CMN secrets and then PVPVC and then go to deployment and create service in this.
This can be simplified so that I can do something as simple as this install YAML.
That should take care of deploying all of these artifacts and the application should be up and running straight away.
So that's where Helm shines.
So you are going to package your Kubernetes application as Helm charts.
So if I package the output that I'm going to get is a chart.
And this chart will be maintained in the chart repository where all the application charts will be maintained.
So if I execute a command like Helm install YAML, then it's going to download the chart from there.
And then it's going to install all of these components.
I've set up all of these components in the Kubernetes.
So basically Helm is a package manager for Kubernetes.
So what we need to do in examination, you will be asked to quickly create a chart for your application.
And we are going to try the commands tomorrow anyway.
So what we need to do, there is a proper structure.
We will create a folder called template and then move all of these files.
Move all of the files and open file by file.
And you are going to templateize each one of it, which means you are going to open this file.
Right now you are seeing an attribute like nginx 1.2.
You are going to you will template this.
You need to move this, whatever the component that will change.
So similarly in every file you are going to open and templateize it all.
Which means at the end what you all have is a template only.
So in the same directory as template, you will have a values.aml.
So this is the one that's going to have all the values.
For example, in the values.aml, you will see image, node, and this will have the nginx 1.2.
So whatever the values here, it's going to get populated into these templates.
And also we will have chart.aml that will have some information about the version and the name of the application.
In addition to that, we will have some other couple of other things as well.
So once you have this proper folder structure, let's say you are going to execute Helm package command against this.
Then this is going to give you the chart.
This is the one that's already made in the registry repository.
And this is the chart that you are going to search for it and then install it in the registry.
So Helm altogether is a different tool.
It's not part of the core kubriss distribution.
You can refer the site later, but tomorrow we will do a simple example also to package it.
In the exam, they would expect us to package Helm chart from the setup artifacts.
So we should know the basic commands. As long as we know that, then we are all good.
I think it's enough for the Helm high level overview.
Okay, that's it. We successfully completed day two.
And I hope you guys learned a lot of things today.
Do you have any special specific specific feedback that you want me to correct for day three?
How about the base in day two? Any specific feedbacks?
Did you guys enjoy day two?
Thank you.
Welcome again.
Good, good. Thanks, darling.
Glad to hear that feedback and franchise.
Thank you. And Colin.
Okay.
So this was the question that you asked about the morning, right?
About dealing with the certificates.
Am I right?
Okay, okay.
Okay, okay. This is noted.
I will say I will check if I can share something with you tomorrow.
Thank you, Colin. And over to you, Shahid.
Perfect. Perfect. Thank you.
And then Shalangan.
Yep. Over to you, Shalangan. Yep.
Thank you. Thank you so much.
I'm really glad that this day really helped you guys and keep that excitement.
Tomorrow it's going to be full of activity days.
I will explain stuff, but you will have more activity to do more from an exam perspective.
So we will go through the CKA curriculum line by line.
And we are going to try hands on for that.
Okay. So get up for tomorrow and enjoy your rest of the evening.
Thank you.
Bye.                

on 2022-10-26

language: EN

                  WEBVTT
Yes, please go ahead.
It is more than that. It is more than that because every group is trying to address a different set of problems, right?
So by grouping, let's say you have rolling update feature, right?
So making the features available for different groups.
I mean, that categorization is purely done to manage those resources effectively.
So there are commonalities amongst different resources and they wanted to put it in a single group.
So it's not about access permissions or whatsoever.
It's more on how Kubernetes is managing those resources, how functionalities are shared, how the functionalities are reused from those perspectives.
For the RBAC, you can, I mean, API groups is not related to the RBAC that you are going to defend.
This is totally unrelated because if you define a role, it doesn't matter which API group it is part of.
You can define a role referring a resource that is part of any API group.
Okay. All it matters is you are referring that resource. That's it.
The verbs that can that are allowed in that resource.
Okay. If you want something at a cluster level, then you need to create cluster role.
So at the RBAC level, we have two resources, right? Role and cluster role, role binding and cluster role binding.
So that API group does that doesn't determine whether it is at the namespace level or at the cluster level.
It's only the role primitives like role and cluster role determines that.
Is it clear? Okay. Correct. Correct. Correct. Correct. Welcome.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Last
three minutes to complete this activity.                

on 2022-10-26