1:21
2022-10-26 10:40:47
48:29
2022-10-26 11:22:27
1:32
2022-10-26 14:03:58
22:02
2022-10-26 14:09:12
18:32
2022-10-26 14:38:39
1:26:59
2022-10-27 09:43:27
2:08:07
2022-10-27 13:00:05
5:19
2022-10-28 09:57:45
Visit the Certified Kubernetes Administrator Exam Preparation course recordings page
United Arab Emirates - Certified Kubernetes Administrator (CKA) - exam preparation
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