1:04:49
2022-11-21 11:28:21
44:16
2022-11-21 13:36:53
44:08
2022-11-21 14:41:53
10:27
2022-11-21 15:56:25
Visit the Certified Kubernetes Administrator - Exam Preparation course recordings page
United Arab Emirates - Certified Kubernetes Administrator (CKA) - exam preparation
WEBVTT
-->
have an unified view of all participant machines if in case if you're facing any
-->
challenges it will be easy for us to troubleshoot together that's the whole
-->
idea so that if I'm not seeing any busy hands here I will simply proceed to
-->
the next set of topic instead of just asking everyone right it's going
-->
to help us a lot by this way yeah you will see multiple tabs here home
-->
desktop and training room click on this tab and then click on join
-->
training room correct okay first of all yes it it is possible provided for
-->
example my container already has a bash installed in it which means as part of
-->
the image the base libraries that you have chosen you have a bash if not at
-->
this you will have some kind of basic shell so you can get into it and yes it
-->
is possible you can modify any files configuration files but it is not
-->
recommended for production for production it should happen through
-->
config map you need to first modify the config map and then restart the
-->
part so that the restart will pick the latest configurations but for
-->
some urgent fixed purposes you can do it but by all means in kubernetes
-->
it's not recommended because it's completely dynamic with respect to part
-->
anytime kubernetes can kill the part for which you just modified the
-->
configuration and they may create a recreate it may recreate and
-->
replacement part so the best practice is modify the config map restart your
-->
deployment at the part then it will fix the latest configuration but then
-->
nothing will stop you if you are going to get a shell inside and
-->
modify it provided you have root permissions and all those stuff or the
-->
file modification permissions for those file and all the stuff yep welcome
-->
four more minutes to complete this activity
-->
cube CTL config get context one main constraint with respect to
-->
examination is the time so you will really have a limited time to to
-->
solve all the questions that they pose so we need to be really fast when
-->
it comes to executing the commands and so on so on so right so keep that in
-->
mind so for that we need to have these basic commands to be part of our
-->
muscle memory then only we can easily have the commands where to go how to
-->
see all those problems will be kind of easy only during examination but
-->
whether you will be able to do it within the specified time that's what
-->
most of the student fails during the examination time constraint time
-->
constraint so during my hands on time also I will put you in and time
-->
constraint right so that we can do it bit faster last two minutes please to
-->
complete this activity okay that's and good question that's what we are
-->
going to write the part specification using an declarative eml file and
-->
wherein you can you can put specification for more containers
-->
imperatively it's I mean using CLA it's bit complex we are going to
-->
achieve it with an eml file yeah we are we are going to discuss that now
-->
discuss that now right yeah yeah yeah no problem no problem
-->
all right you can stop here because there's already time that we allocated
-->
for that hands on so let's continue on the part topic right part is not it
-->
over so we are yet to discuss many things within the part so what we
-->
did we created a part using an run command and we learned the life
-->
cycle commands right so same if I go back to the command where I created the
-->
part using the run command in general we will submit this is this is
-->
posting this to the API server right kubernetes API server so the cube CTL
-->
is generating an eml file and then it's posting it to this rest API for this
-->
for this command and equivalent eml file is generated so you can actually
-->
write your own eml file putting together all the specifications because
-->
here we are specifying image maybe there are some other flags like name
-->
you can specify there are many configurations that you can specify
-->
but you are limited to provide some configurations via CLA but if you are
-->
going to write an eml file you can actually configure many properties and
-->
then once you are done with your eml file you can apply this
-->
configuration to the cluster on your own okay so for that you can start
-->
start writing the eml file from scratch that is one way but you don't
-->
want to start from scratch and instead you if you have some base you can just
-->
build on top of it yes you can do that all you need to do is to the same
-->
command just include dry run flag I want to dry run this and client and
-->
output me the eml file you cannot put also in JSON file that doesn't going
-->
to make difference output is going to be the same so what it means is you
-->
are requesting the kubectl client to generate the eml file for equivalent for
-->
this commands and then the options that you provided basically kubectl
-->
won't submit this request to the server this will run in the client
-->
side and then the eml will be printed for you so you can copy this and
-->
then put it into your file you can put additional configurations and then
-->
you can apply it on your own for example I can write this output to an
-->
file my first pod dot eml okay so that file already has this contents
-->
right so you can simply open the file and you can do the
-->
modifications whatever you want so this is the place if you want to add
-->
more container then continuous is an array I hope you are all familiar with
-->
the eml formatting right two spaces two spaces two spaces under the label we
-->
have two spaces and then its specifications so same way if it is an
-->
array it will start with I fun so this is first con first entry of the
-->
array you can define one more one more one more one more and each entry
-->
is going to be a specification for each and individual containers right so once
-->
you have the eml file ready and if you want you can make some updates and
-->
after the update you can simply apply to the cluster so in the eml file you
-->
can see API version is the top and the kind is specified as part because
-->
you are going to create a pod resource and some metadata information
-->
about the pod the name the label and then the spec specification and under
-->
the containers your specification for your own container and then some
-->
defaults that it included okay so with this file you can apply this by using
-->
create command and specify the name of the file my first part dot eml that's
-->
it if I press enter this is going to create the part with that one
-->
because this is the first time we are creating the resource we are using
-->
create command if the resource already exists and if you are modifying some
-->
property then you can use apply command there are some properties that
-->
you can modify and apply that will take effect but there are many
-->
properties that if you are modifying you need to delete and recreate that
-->
okay so apply will also create in this case there is no part with the name my
-->
pod is running let's say then it will also do the create okay so let me
-->
delete that part I think I have the part in the same name already no I
-->
the name of the file and the same part that you created earlier with
-->
imperatively okay so defining and creating an part from an from an eml
-->
okay that is number one number two now if you go to the document cka kubernetes
-->
working files just we are going to demonstrate couple of concept with this
-->
with the file in this directory let me open a shell from here
-->
come on
-->
okay a lot better now so now for this demo sake we are going to use one
-->
application this eml file this the eml file similar to what we just created
-->
for our nginx application okay as you can see the kind is part and the name
-->
of the part is card and this time it's based on one one one another
-->
image and it has the specifications name as a card and the port inside
-->
the container is 8080 and the protocol is TCP the name that we are getting
-->
HTTP that doesn't matter even if you are going to keep this that's going to
-->
work but a minimal part configuration as like how we created one for our
-->
engine next right so if we want to apply this we know how to do this
-->
apply the file and if you want to check whether it is created and
-->
running to get parts and the part is running and if you want to access it
-->
you know how to do it kubectl port forward the name of the part any port
-->
number in the host machine and then the port within the container go to
-->
okay yes in a simple react web application that we will use for demo
-->
purposes right fine we deploy this application now on top of this
-->
specification we are going to add more configurations or more specifications
-->
okay the first one that we are going to add is related to health check
-->
health check what it means let's say I have a container and this container is
-->
running my application process and there are a lot of records that are
-->
coming in and your application is processing it and it is sending some
-->
success response back to the callers now here comes one request while
-->
processing this request something went wrong in your application code and then
-->
the application process exited process exited because it is the only process
-->
that is running inside the container or the parent process that is
-->
exited container has nothing to execute so this will also exit
-->
container will also move to exit exist process move to exited state
-->
container most exited state so for scenarios like this platform that is
-->
let's say kubelet kubelet component or the kubernetes will react to it
-->
because container status is exited kubernetes will try to restart restart
-->
the pod or sometime it will try to create a replacement part so basically a
-->
platform is taking an action when if the container is exited okay but the
-->
same scenario it was it was working until a request came and this while
-->
processing this request your application went into some kind of
-->
stalled mode or it went into some kind of deadlock situation so which
-->
the process is not exited because the process is not exited and running the
-->
container status is shown as and running and kubernetes of course won't
-->
take any action because it's already in running state but all the request
-->
that goes after this request it's all getting some kind of error
-->
responses to the user is a surfacing error because this service is no
-->
longer returning any responses all the requests are getting timed out because
-->
one of the previous requests put the application into an some kind of
-->
stalled mode right we really want kubernetes to take an action in this
-->
scenario but kubernetes doesn't care about this scenario because it
-->
refers only the container status it is running the reason why it is show
-->
is running showing running because the process is running the parent
-->
running state but in reality the application is unhealthy it's not in a
-->
position to serve requests so we want kubernetes to take an action if a
-->
scenario like this happens so that's where the concept of health check
-->
comes into picture so what we are going to do instead of relying only
-->
on the container status we are going to take the health check close to
-->
business code which means if this is your application that is exposing many
-->
business endpoints let's say product endpoint search endpoint there are many
-->
business endpoints that this application exposes correct in addition
-->
to that you are going to write your developer will write a code to expose
-->
a endpoint called health and calling this endpoint will simply return and
-->
some sort of success code that's it nothing other than that if if it if
-->
the request made to here then the response will be sent as an 200 okay
-->
as simple as that so what Lewis will do is now while submitting the pod
-->
yaml file Lewis will include a section called liveness probe wherein
-->
he will specify this information here kubernetes this is the endpoint call
-->
this endpoint every 30 seconds and expect a successful response if you are
-->
getting an failure response for three consequent times that is a failure
-->
threshold then consider that this application is unhealthy and consider
-->
that the liveness probe is failed which means if a scenario like this
-->
happens kubernetes already calling your health endpoint every 30 seconds if
-->
a scenario like this happens then for the next 30 30 seconds kubernetes will
-->
get an error response so threshold will meet so that time kubernetes will
-->
understand that okay this particular container is become unhealthy so it
-->
liveness probe fails the action that kubernetes takes is restarting the pod
-->
assuming restart is going to be the fresh start of the application
-->
everything should be work fine should be working fine after the restart
-->
okay so this is the exact scenario where we want to address with the
-->
health check and we are going to configure it as part of your pod
-->
specification with the liveness probe and then you will specify all these
-->
inputs once you specify it kubernetes is going to perform that probe okay so
-->
if I open the file where we have the liveness probe configured okay I
-->
think it will be better if I increase this font size font size okay so the
-->
only new addition is this section compared to the previous yaml file the
-->
new addition is this part live does probe it's for an HTTP endpoint healthy
-->
and periods against is 10 which means every 10 seconds kubernetes is going to
-->
call this endpoint and it will expect an success response and the failure
-->
threshold is 3 which means for the consequent three atoms if kubernetes
-->
receives an failure response from this endpoint then that's the time
-->
it's going to declare or assume that this part is unhealthy okay we have
-->
some timeouts against configurations also which means if the call to the
-->
endpoint timeouts it takes more than one second that is also kubernetes and
-->
failure initial delays again means what's the container spins up it's
-->
going to wait for some five seconds before it starts with that health
-->
check after five seconds every ten seconds it's going to call the
-->
endpoint right so those configurations right so now you can see this in
-->
action also let's say I'm going to delete the part that I created
-->
earlier because the part that I'm going to create now it's with the
-->
same name one two card board health cube CTL get parts you can see this
-->
so now I'm going to do the port forward to access the application let me
-->
refresh this okay we're already here just to demonstrate we are going to
-->
simulate the scenario if liveness profiles how kubernetes is going to
-->
act on that scenario right so let's say kubernetes is already calling this
-->
application in this healthy endpoint every ten seconds right every ten
-->
second if it calls this application is printing it in on a table okay you can
-->
see already it's called and this application cell sent 200 response back
-->
to the kubernetes right now we are going to intentionally send and
-->
failure response to kubernetes fail for next three calls because three is
-->
threshold that we set so if I click on three then we are going to send five
-->
hundred and for the next call again an error code or a failure code the
-->
third time it's going to send the threshold will hit and it's going to
-->
be restarted okay as you can see already the part is restarted it's
-->
waiting for the initial delay second of five and after that you will see again
-->
the call happen from kubernetes it's going to continue for every ten
-->
seconds so in this case if we simulated this behavior where the call
-->
to the health endpoint failed let's say if this happened if all the
-->
business endpoints are not accessible then the kubernetes will also be won't
-->
be able to access the health endpoint also so which means we are taking that
-->
liveness check near to your application code instead of relying
-->
only on the container status or the process status we are taking it near to
-->
the app code so that's the whole logic right so if I go back here you
-->
can even see those informations in the describe command if I do keeps it
-->
in get parts you can see the part is already restarted one time because it
-->
liveness probe if you want to see those information you can look at the
-->
event section
-->
I think this is the card part right or the my part okay so here you can see
-->
liveness probe failed with the status code 500 warning unhealthy and then the
-->
part is restarted
-->
okay so liveness profile sorry started so the learning from here is what is
-->
liveness probe and why we need liveness probe this concept explains
-->
that how to configure it you already seen an aml file if the liveness
-->
probe fails the action is restarted that's it no complex access just a plain
-->
restart of the container okay so this liveness probe as you can see here
-->
from our application we exposed an API slash health endpoint isn't it what if
-->
your application is an is an is not an API it's some kind of worker process
-->
that doesn't exposes any API for those purposes we have different options
-->
under the liveness probe we have HTTP probe that is the one that we just
-->
seen we will expose an endpoint we also have TCP probe and we also have
-->
TCP means you are going to probe to and specific port number as long as the
-->
port is reachable it will be healthy healthy healthy port is not reachable
-->
then it is an it will hit the unhealthy scenario exact probe means
-->
you want to execute some command and that command execution should return
-->
a success or failure code let's say 0 is a success code minus 1 is a
-->
failure code after execution of the command every 10 seconds as long as you
-->
the success code then healthy if it is a failure code then unhealthy right
-->
so you will go for using this kind of probes where exposing an HTTP rest
-->
API endpoint is not possible okay so you can see here this is using an
-->
exact probe basically what this is going to do every five second it's
-->
going to open this file temp healthy okay so as part of this file this is
-->
creating that file and then slips for 30 seconds and then remove that file
-->
sleep for five minutes right if you try this you can see also if it is not
-->
able to find the file then it's going to be the failure scenario cat temp
-->
health returns and failure code then the pod will be restarted as long as if
-->
it is able to find the file then the thing will happen which means
-->
application is healthy so a simple command so this is purely depends your
-->
application team should know when we should tell that application is
-->
unhealthy when we should tell that it is healthy based on that they are
-->
going to write some exact commands here okay that is the exact probe this
-->
is something that we just seen that is HTTP probe and the last one is TCP probe
-->
will just specify the port number okay so which means the cubelet will
-->
attempt to open a socket to your container on the specified part if if
-->
it can establish a connection then they can consider containers healthy if
-->
not consider the container is unhealthy okay three types based on the
-->
application you can configure HTTP probe exact probe or TCP probe okay so this
-->
is for liveness probe and if the linus probe phase the action is restarting
-->
the container so similar to liveness probe we have one more called
-->
readiness this serves a different purpose what is the purpose let's say
-->
deploying nginx with five replicas five replicas which means five parts will be
-->
running and here you have one another service that wants to call nginx
-->
application your application my nginx application so which means you have
-->
five instances the request needs to be load balanced to one of these five
-->
so that one part will process it and send the response back to the
-->
isn't it so for that we are going to create services resource in kubernetes
-->
that we will discuss in a moment and this is the one that's going to load
-->
balance to one of these five so in the readiness probe you are going to
-->
specify the same config similar configuration as how we will specify
-->
by linus probe maybe we will expose an endpoint called ready and you will
-->
specify every 10 seconds that should be executed so based on that let's say
-->
this container passes the readiness probe then this will be set to ready
-->
ready state in this process ready state ready state ready state let's say
-->
if this fails readiness probe it will be set to not ready state so by
-->
the time when a request comes in this service component will consider only
-->
the replicas that are in ready state that is one two three four and then
-->
it will load balance to only these four this will simply be excluded because it
-->
failed the readiness probe because it failed it is in not ready state so it
-->
won't be considered for the load balancing maybe after a moment it will
-->
turn to the next next calls it it may succeed it will success succeed the
-->
readiness probe so that time another request comes in this time this will
-->
also be considered because it's already transitioned to ready state okay so you
-->
can have some kind of logic here to determine when your application is
-->
ready maybe it's still processing the previous request or you don't have
-->
enough sufficient thread pool to process the request so you may want
-->
to fail the readiness probe so that you won't get any new request process
-->
the one that that are already in in it and then once you complete it
-->
then maybe the readiness probe will succeed and then it will get more
-->
requests so when a liveness probe fails that is for a different case and a
-->
part will be restarted if a readiness probe fails it just that that part
-->
won't be considered for load balancing that's it once it transition to ready
-->
it will be considered okay so that's what you can see under the readiness
-->
probe I can show it yeah this one the same for the readiness also you can
-->
specify the exact HTTP probe here it is an exact proof configured similar to
-->
the liveness probe okay the only difference is instead of liveness you
-->
are using the readiness so in our example if you go to the maybe the
-->
you can see the readiness probe here same configuration is just that we are
-->
calling another endpoint this may have a logic to tell whether their
-->
application is in a position to accept the request new request or is
-->
it still busy with processing the existing request good thing is for the
-->
both liveness and readiness probe already the framework there are
-->
some libraries that will take care of exposing these endpoints that will
-->
determine or that will take care of exposing the endpoints with the
-->
logics to say whether ready or not ready or your developer can take more
-->
control and they can write their own logic by implementing this endpoint
-->
okay but by all means now we are clear with this two probes and the purpose
-->
of it and what will happen if these profiles any questions so far on this
-->
any question or is it clear okay good so before trying the hands-on for
-->
that part so in the in the in the simple part specification now we learned
-->
how to add the two probes that is readiness and liveness probe now for
-->
the same part specification we are going to add few more configurations
-->
which are very very important right one is let's say I have Lewis and let's say
-->
he is a beginner or he is a trainee he wrote on application and he deployed
-->
the application into the kubernetes cluster have three nodes n1 n2 and
-->
n3 and his application is running somewhere here in the node 1 and as
-->
administrator hemos is already watching this application and he founds out that
-->
this application has some a problem which means before an hour it was
-->
using 0.5 CPU and 256 MB of memory now this application is using 1 CPU and
-->
512 MB of memory and over the period it seems it's it started to use more
-->
resources even though this application is sitting idle or it's receiving or
-->
processing only few requests but then it keeps consuming more resources but
-->
then it never releases the resources back to the pool once it's done with
-->
the processing which means this application has some serious memory
-->
leak issues and it's not releasing the resources so which means over the
-->
period this guy may eat all the resources leaving all other containers
-->
or parts to stow for the resources this was starving right so clearly as
-->
administrator I don't want this scenario to happen if something seems
-->
to happen like this then I want kubernetes to take some action so for
-->
that you need to educate the kubernetes with some informations while
-->
submitting the part specification you need to provide some information to
-->
kubernetes ok what kind of information you need to provide resource
-->
information resource limits you need to set the limits for CPU and then the
-->
memory as a developer of this application you must know because you
-->
must thoroughly performance test load test your application and then you
-->
need to benchmark and come up with the values for CPU and memory limit maximum
-->
CPU and memory your application will continue because you already load
-->
tested performance tested and you should benchmark that value let's say
-->
my application won't consume more than 1.5 CPU and memory more than 516 MB
-->
let's say this is the limit you need to put it in the part
-->
specification and if you apply to the kubernetes now kubernetes has this
-->
information and it's going to keep an eye on your container so if your
-->
container starts to consume more than what is specified on the limit then
-->
kubernetes will decide that there is something going wrong with this guy
-->
and kubernetes will take an action the action can be in restart or
-->
sometimes it will delete and it will create a replacement container okay so
-->
you will never get into a scenario of this guy eating all the resources
-->
leaving others starving for the resources that is the limit resource
-->
limit maximum so this is the case with Lewis who is a beginner he did
-->
something and he ended up getting this advice from the Hermos who is the
-->
cluster administrator and now he had deployed the application with this
-->
input all good Hermos is happy Lewis is happy now we have another case
-->
this time we have we have Jasper and what he did this he is an expert and
-->
he wrote some kind of machine learning algorithm and he want to run the
-->
application in the cluster node 1 node 2 and node 3 and he submits the
-->
request and the application the container or the part scheduled to run
-->
in the node 1 but then this part is not starting up it's still not showing
-->
running status it's in some error status and upon analysis Jasper found
-->
out that for this container to start up and work it minimum requires 0.5
-->
CPU and 256 MB of memory but then in this node you don't have that
-->
resource let's say you have only 100 MB of memory or you don't have you have
-->
only point to CPU okay so which means and this particular application has
-->
some minimum resource requirement for it to work minimum resource
-->
requirement both on CPU and memory that how kubernetes will know there is
-->
no way that kubernetes will know that unless you provide that
-->
information to kubernetes as a developer you should know it and you
-->
provide that information to kubernetes so that while scheduling scheduler will
-->
consider that while scheduling scheduler will look into your part
-->
specification and it will understand that okay this is the minimum
-->
requirement and it won't consider the n1 because n1 doesn't have that
-->
resource so maybe it will consider the end to entry that will have
-->
enough resources to to run that container okay so that is the
-->
minimum resource requirement that that that is required for your application
-->
to work so that you can specify it under resource request CPU limit 0.5
-->
CPU 256 MB of memory so resource requests resource limits now you know
-->
why we need those two so here you can see resource request and resource
-->
limit okay so as I mentioned this is an time-consuming activity you need to
-->
perform developers need to perform load balancing and then they need to
-->
load testing performance testing and they need to come up with these
-->
values but then if you are running the applications on the cloud we have
-->
something called VPA vertical part auto scale what it means if you
-->
configure VPA for your application part then the VPA will observe the CPU and
-->
memory utilization of your of your application container it will observe
-->
the values past values and it will recommend the request and limit for
-->
CPU and memory this VPA component will recommend what to put here instead of
-->
you are performing a manual benchmarking activity it will observe
-->
your application over a period of time and based on that hey just set this to
-->
this this to this this to this value limits and requests it also provides
-->
an capability where it can automatically set the values also it
-->
can it can recommend and if you needed you can update it if you configure it
-->
bit more then this VPA will automatically set the request and
-->
limits for both CPU and memory time to time both options are possible with
-->
VPA why I need to do this because it's very important for you to
-->
right size your application you need to right size your application it
-->
shouldn't be it should have enough resources for it to work and it
-->
didn't be eating more resources than what it is required for it right so we
-->
need to right size the application right size our application in the
-->
cluster that is more important okay so every specifications that are submitted
-->
to the cluster you can demand or you can mandate their applications team
-->
to have this information if not you can simply reject the request as a
-->
admission controller layer level where you can simply reject the request that
-->
comes to the cluster without resource request and limits okay and you can
-->
even automate this if you are in the cloud you can make use of VPA where in
-->
it will recommend or you can configure it in such a way it will
-->
automatically set the values how it does it it has access to the matrix
-->
of your application based on that based on the historical values it
-->
okay I hope it is clear please let me know if you have any questions before we
-->
go for a lunch break I'm going to stop here if you have any questions I will
-->
address it if no then we can go for a lunch break okay after the lunch
-->
break I will give some time for you to try this no worries is it clear so
-->
any questions perfect vertical part of scaling up all right time is now 12 20
-->
so let's take a 45 minutes lunch break and be back by 1 5 p.m. thank you thank
-->
you for listening
-->
welcome back welcome back please raise your hands in the teams if you are
-->
back to a desk just a quick attendance check okay since we are ready to okay
-->
perfect perfect good we got everyone back I hope you had an great lunch
-->
time so now it's time to continue our discussion right so I'm going to
-->
increase the pace of the course a little bit faster right so fine so what
-->
we completed before the lunch break is we know we now know how to create
-->
and part using and declarative ml5 creating and part from ml and we
-->
also learned a couple of probes we have different ways to implement it one is
-->
using HTTP I think I'm using a wrong pen it should be the pen from me know
-->
under the parts we learned how to create it with an email under the
-->
probes we covered different types that is HTTP probe exact probe TCP probe
-->
there are two different probes that we discussed one is liveness second one is
-->
readiness if liveness probe fails action is restart if readiness probe
-->
fails action is don't consider that specific part for load balancing right
-->
and then from the resources perspective we learn the importance of
-->
both limit and request this applies for both CPU and memory and in align with
-->
that we also learned vertical part auto scaling right to automatically set
-->
values for this or get a recommendation for for the values to be
-->
set on this limit and request correct so these are all the things
-->
that we discussed just before our lunch break right so there are a couple of
-->
other configurations let's talk about that and then I will give some time
-->
for the hands-on so that you can try it all once in one single example
-->
right so we know we create an container from the images we have
-->
images this access and template which means if you create a container this is
-->
going to get its own file system which means every container will have
-->
its own file system if you have container to it has its own file
-->
system isn't it so let's say we have velocity and she tried to spin up a
-->
for customer database so she choose and postgres image and she is running and
-->
container are a part based on the postgres image and it's running a
-->
database and there are many applications that are writing or
-->
reading the data from this database so this postgres process is going to
-->
all the data in its file system let's say we have a directory called data
-->
within the container in a specific folder data you have all those
-->
millions customer records information about the customers let's say and this
-->
is working fine what happens is here we have hair moves and he is an
-->
so what he does is he simply deletes this container let's say mistakenly he
-->
deleted it so the moment when he deleted the container there is no undo
-->
for that which means if you delete a container then the file system
-->
associated with the container it all will also get deleted which means
-->
you will lose all those million customer records that were in the data
-->
folder because you deleted the container it goes to any country doesn't need
-->
to be a database let's say you have an in backend API that generates some
-->
kind of XML file in a directory for every requested process and if it is
-->
going to store all those data in this XML directory then if someone
-->
deletes the container you will lose everything that is there in the
-->
right so clearly this is not the scenario that we want to face
-->
basically here the requirement is I have something inside the container
-->
that I want to possess outside of container lifecycle even if the
-->
container is deleted I want the data in this directories to be safe okay
-->
so that is the use case for volumes that's the use case for volumes this is
-->
the problem that volume concept tries to address so the idea here is simple
-->
you have your velocities postgres container and all the data is returned
-->
to the data directory this is the directory you want to possess so what
-->
I can do is I can choose any location remote location or a local location
-->
let's say this postgres is running in an host machine host one I can choose a
-->
path from the host machine let's say there is a path called lax or there is
-->
a network file share I have a directory here or I have a GC
-->
persistent disk some some some storage from a cloud or I have azure this
-->
it can be anywhere so what you can do is you can mount this folders or this
-->
directories are these volumes you can create a volume in an in an host
-->
machine path or you can create a volume in an azure disk or you can create a
-->
volume in a GC persistent disk or create a volume in a network file
-->
share once the volume is created then you can mount that volume to an
-->
specific location inside the container so let's say here I am mounting this
-->
host machine path to the data directory within the container so which means
-->
whatever the process writes to the data directory it's actually getting
-->
stored in the lax directory in the host machine so which means if this
-->
container is deleted the data is still safe in the lax directory okay
-->
so that I can spin one more new container with the same volume mapping
-->
so that the new container can see all the data that is left by the previous
-->
container okay so by this way we are persisting something outside of
-->
container lifecycle it can be one directly or you may have multiple
-->
directories that you want to purchase this directory to an NFS this
-->
doesn't matter based on your requirement you are going to store it in some some
-->
remote data center or in cloud storage okay so now we know the use case for
-->
volume and then the problem it addresses correct how to specify that
-->
volume in your part specification that is our next question in the part
-->
you have multiple containers at the container level you are going to
-->
specify all this liveness probe resource request limits even the volumes okay so
-->
using the volumes is a two-step process first step is you need to define the
-->
volume and I say define you are going to give a name to the volume and then
-->
you need to specify the target destination or location where you want
-->
to create the volume in the host part RNN cloud provider storages so
-->
that type provider type you need to specify right once the volume is
-->
defined you need to mount the volume inside the container okay so how to do
-->
that the step number one is defining the volume isn't it so in the same
-->
intention as containers you can see we define the volume the name of the
-->
volume and then where you are going to create the volume in a network
-->
file share this is the server name this is the part in that NFS you can
-->
even provide more configurations like how much space you want to block and so
-->
on so details but keeping it simple this is how it's going to be in a
-->
network file share you are going to create a volume with the name as an
-->
core data remaining properties are defaults that's going to get applied
-->
right so step one is defining defining the volume and step two is
-->
mounting this volume inside the container path or a directory so that
-->
you can see it under container specification under containers we have
-->
volume mounts and here you are specifying the name of the volume and
-->
then the mount path this is the path inside this container that is in this
-->
data directory it will get mounted with this volume so which means whatever
-->
the application writes to the data directory it will go all the way to
-->
this network file share export directory okay defining the volume is
-->
part one and using or mounting that volume to a path inside the
-->
using volume mounts is the step number two okay so later on day two we are
-->
going to see how we are going to refactor this logic to move to
-->
persistent volume and persistent volume claims what is the what is the
-->
problem or the challenge with this way of defining the volume compared to
-->
using PV and PVC right but pretty much this does the job using volume and
-->
okay so if you look at and production grade what specification these are all
-->
the things that you will always see one is the the image specifications the
-->
application specific things and then resource request and limits liveness
-->
probe readiness probe volume mounts we are yet to see secret mass and
-->
you will also see many specifications related to injecting some
-->
configurations right that's it so this is for the NFS I don't think I have a
-->
server with this name you can also replace it with the host path let's
-->
say you want to mount a path from a host machine then there is one type
-->
called host path and then to the type you are going to specify the path in the
-->
host machine let me open this file yep as you can see here it uses and type
-->
as an host path the path in the host machine and then mounting that volume
-->
to the data directory okay there are many supported storage provided types
-->
that again we will discuss while we talk about persistent volumes right but
-->
now we are clear with the workflow what it all takes to create a volume and
-->
then mount it inside a folder okay so with this we now know in addition to
-->
this resource request and limit what it all takes to configure the
-->
volumes defining the volume and then mounting that volume inside a container
-->
those two steps okay please feel free to stop if you have any questions so
-->
now I think now we are getting more clarity on what all the things that
-->
we can do at the pod level itself isn't it so if you still remember I
-->
mentioned about multi container part there are some use cases for
-->
multi container part so let me talk about a bit here right so the first
-->
scenario that I'm going to talk about is unit containers this is there to
-->
serve a specific purpose for example this is your main container a
-->
container that runs your business application and we will also run one
-->
or more unit containers the purpose of the unit container is as the names
-->
it's for executing some initialization logics or in other terms setting the
-->
stage for the main container to run so based on your application you may have
-->
some complex initialization logic like mounting and volume or creating
-->
checking some dependencies there are a lot of initialization logic that you
-->
want to check so instead of having those initialization logic as part of
-->
main container you can have it in the unit containers you can have one or more
-->
unit containers and for the containers we define like containers and
-->
then we define the first container right similarly for the unit
-->
containers we have and separate attribute like the same indentation as
-->
continuous you will defend any containers and you will give the first
-->
unit container second unit container third unit container like this so it's
-->
not like you will put it here that's that's that's meant for different pattern
-->
that we are going to discuss like sidecar you will run it but in it
-->
containers it has its own life cycle which means if you have it in it
-->
container defined it will execute in the same order that you defined here
-->
one by one first this container will execute it will run to its entirety
-->
and then it should exit with an success code completely it should execute
-->
successfully maybe it has some set of commands to execute and then the
-->
second unit continuous but must execute successfully third unit
-->
container must execute successfully if all the unit containers completed
-->
basically is going to have some short lived set of commands to perform if
-->
it all successfully executed that's the time the main container will start
-->
because the stage is ready now the hero can enter right so if it's one of the
-->
initialization container fails then the entire part will be restarted again
-->
from first container second category third category execute so that's the
-->
behavior of unit containers let me include this links in the etherpad so
-->
that it will be easy for you to refer in it containers eight containers
-->
always runs to completion each unit container must complete successfully
-->
before the next one starts and this unit containers it doesn't support
-->
liveness probe readiness probe bar so on so because it's it's not the long
-->
running process this is that to just set the stage for the main guy and
-->
the way to define it as you can see here as like containers we have any
-->
section this application has two unit containers and here it you can see
-->
here it checks whether the my service my service is already available in the
-->
cluster so it's going to wait it's just checking one of the dependent
-->
service is already up and running or not this is checking for the database
-->
this is checking for a service if it is already available then this will
-->
succeed this will succeed then the main container will start maybe the
-->
main container is as part of his initialization logic it may want to
-->
communicate with my service and my DB so if these two are not up then if it
-->
spins up it may fail so in this case they are using the unit containers to
-->
make sure those two services are available and then it does right so
-->
this happens only during the startup time once unit containers are
-->
executed and started up and the main category started up then it
-->
won't execute again maybe in the next to start it will execute okay so which
-->
means after main container is up and running if the my service container
-->
goes down then this this this is not responsible for that okay I think you
-->
got that idea right so this is just for the initialization logic as
-->
okay so I also mentioned about sidecar patterns right car sidecar cycle that
-->
is the given as documentation okay that's fine I can explain it from here
-->
so this is one case for multi-container part other cases in the
-->
containers array you are going to define the first container and then the
-->
second container here there is nothing like an order like this should execute
-->
and this should execute both will run parallel this is going to be a long
-->
running process this is also going to be a long running process this is the
-->
specification for main container this is the specification for a sidecar
-->
and this is here to provide some helper functionality one of the
-->
functionalities you have a main container and you have let's say and
-->
logging back in and your application is generating a logs in an ABC format
-->
but you are logging back and expects the log in an XYZ format so what I
-->
can do is I can run a sidecar maybe the main application is writing to an
-->
volume and this sidecar can read the log from the volume transform the
-->
ABC format to XYZ format and it can even forward the log to the logging
-->
packet so in this case this sidecar does two operation one transforming the
-->
logging from ABC to XYZ format and then forwarding the log to the logging
-->
packet so this is just one helper functionality so in this case what
-->
does is an adapter pattern so this is an adapter sidecar because the target
-->
system experts in a different format the source generates in a different
-->
format so this access and kind of adapter between these two okay one case
-->
where we will use the sidecar and there is another case let's say the
-->
same main I have and here I have an external and web service from my
-->
party vendor and dealing with the external web service which means there
-->
is a separate authentication mechanism if service is not available retry
-->
patterns circuit breaker patterns and implementing some kind of fallback
-->
mechanisms there are a lot of things that I need to handle at the main
-->
container to call this service and working with this external service so
-->
instead of having all those logics in the main container how about creating
-->
an sidecar and offloading all the responsibilities to here so that as a
-->
main container I will simply call it as an local host as like any local
-->
method I will call this method and this is going to take care of dealing
-->
with this external service all the authentication retry circuit breaker
-->
logic it's all resides here so in this case this is kind of acts as an
-->
proxy this sidecar acts as a proxy for this external web service so this
-->
pattern we call it as an ambassador pattern this is also providing a
-->
helper functionality but the cases are different for these two scenarios
-->
okay and always keep in mind that if you are going to schedule a part let
-->
say velocity she is going to schedule a part with two containers or
-->
containers one main and two sidecar and in the kubernetes cluster if if this
-->
part is scheduled to run in a node number two then all the containers
-->
will run in the same node only that is the characteristics of part right
-->
because all these containers can reach to one another via IPC inter process
-->
communication which means as can call this as an local host and then hit
-->
the port number dish to it this can call this as a local host right so
-->
which means all the containers in that part will always land in the same
-->
node it not like see one will run here see two will run here see three
-->
will run here that is not the case all the containers within the part
-->
specification will always land in the same node okay just keep that in
-->
mind all right so fit these discussions are part topic comes to an end we deep
-->
dived into the part we we learned the part lifecycle commands different things
-->
that will be there in the part specification and then the use cases
-->
for multi-container parts with this I am going to give a quick pass you can
-->
directly try the 1 6 part fully aml file that has all the concepts in it
-->
you can try it or you can spend some time to go through the specifications go
-->
through the documentations I'm going to give you here a 10 to 15 minutes let's
-->
say after that you will move to the next resource that is replica set and
-->
deployments is this clear guys are you good with the pace is it all
-->
clear I need few confirmations please okay thank you please okay go ahead
-->
please