- [Instructor] Let's figure out how we can add
application health checks
to our existing hello world application.
Let's pull it up and do a cat
of helloworld
with-probes.yaml,
and we notice that this is our hello world.
It's still Deployment.
In the spec section, we notice with the containers,
we have a couple of probes here.
We have the readinessProbe,
and we have the livenessProbe.
The readinessProbe is used to know
when a container is ready to start accepting traffic.
So we'll give it some amount of initialDelaySeconds.
In this case, we'll do five.
And then we have timeoutSeconds,
which is the amount of time to wait before timing out.
We'll use it as one.
In this case, because this is a little web app, we'll use
the httpGet, you know, the path to probe here will be slash.
So the endpoint it will look at is the slash endpoint
on port 80, which is the same as the container port
for which the application is configured.
The livenessProbe here will use the initialDelaySeconds
of five and then timeout of one,
and then do something similar with httpGet.
Once again, path of slash on port 80.
So let's go ahead and run this.
Clear out of here.
kubectl
create -f
helloworld-with-probes.
We'll notice that the deployment was created.
Let's take a look at the deployment.
It's not quite ready yet
because it'll sometimes take a little bit of time
to start up the container.
Remember how we said wait for five seconds
before you start up?
Let's take a look at this again.
And in this case we see ready, one of one.
It's up to date, it's also available.
Let's make sure the pods are online
as well as the replica sets.
So let's take a look at that replica sets first.
Desired, Current, Ready state, all of one.
It's looking good.
As well as kubectl get pods.
We expect everything to be running,
ready state running with no restarts.
All right, it looks good.
In this scenario, we configured everything correctly
and the application is working as expected.
But what happens when we're trying to simulate this
in a scenario where things might not work?
So we'll pull up another example that I have created, cat
helloworld-with-bad.
Let's do readiness first.
So in this case, it's the same application as before.
And in the readinessProbe section,
we have an initialDelaySeconds of five, timeout of one,
and we're still using an httpGet probe on the path of slash,
but we're looking at port 90.
And per the application in this case, you know,
it's going to be running on port 80,
so this is not actually going to come back.
So what happens when we actually run this application?
Clear out of here,
kubectl
create -f
helloworld-with-bad
readiness-probe.
So deployment set is created.
Deployments.
We notice that it's not in a ready state yet.
Let's wait for just a little bit and try this again.
We notice once again that the deployment
is not quite ready, age is 17 seconds.
If we decide to introspect here a little bit,
kubectl get pods, for example,
we notice that with the bad-readiness-probe,
this is not in a ready state,
but it has showed that the pods are running.
So if we end up going to describe this pod,
actually clear the screen,
it has some pod pre-information,
but what we're really looking for is the events.
And here underneath Events, we have a warning,
and it says the reason unhealthy, and kubelet, minikube,
and it says readiness probe failed,
the Get of http on port 90,
and then the error here is, you know, connection refused.
So in this case, the readinessProbe fails.
So as a result, the pod
is not actually ready to accept traffic.
So that was readinessProbes.
Let's take a look at livenessProbes.
So I have an example of cat helloworld
with-bad-liveness-probe.
Similar stuff from before.
We have livelinessProbe,
initialDelaySeconds, and periodSeconds,
as well as a timeoutSeconds with one.
And we set a failureThreshold here.
So this is the number of times it'll try to restart
until it starts giving up trying to restart the pod
and go into a CrashLoopBackOff status.
So similar scenario.
We have a path of slash, port of 90,
but the container is actually running on port 80.
So what happens over here?
kubectl create -f
helloworld-with-bad
liveness-probe.
It's created.
Get the deployments.
So we notice here that the livenessProbe,
it looks like it's ready to go.
It's in the up-to-date state, and it's available.
We'll look at this again.
Still ready, but what happens
when we take a look at the pods?
We notice the pods running with the livenessProbe
in a ready state, but it's restarted once.
Now we notice, you know, it's been a little bit of time,
so 20 seconds, 30 seconds, 40 seconds.
So we started again
'cause we have that five-second threshold.
Do this again, we'll notice
that it's restarted three times.
Pretty soon, this will start to go
into a CrashLoopBackOff status.
Try this one last time.
So we notice here that this has gone
to a CrashLoopBackOff status,
and it's not ready anymore.
And what happens when we actually describe this pod?
Clear screen,
describe po/,
bad livenessProbe.
So we notice here
that
kubelet mini, this is the unhealthy reason,
and minikube livenessProbe failed,
the Get on this endpoint.
The dial with connection was refused.
So as a result, the container with livenessProbe failed,
and it will be restarted.
So we kind of see it in the events for the actual pod.
Now if you look at the deployments as well,
get deployments, we'll notice that, you know,
the livenessProbe deployment, which initially it was ready,
went into a not ready state, and it has zero available.
And we also simulated a bad-liveness-probe
as well as a bad-readiness-probe, too.