- [Instructor] Sometimes things don't work as you expect,
and you have to take a closer look to debug issues
or understand what's going on.
There are three techniques I use from a day to day basis
when I work with Kubernetes,
so let me show you what these are.
Let's look at this example scenario
where we have a bad helloworld deployment
which has zero available pods,
and running a kubectl get pods command returns the bad pod
with zero pods in ready status where the status
of error pull image.
What do you do in this scenario
or how do you debug the situation?
I clear my screen.
You can do a kubectl describe deployment
bad-helloworld-deployment,
and this gives you the description of the entire deployment.
As you can see over here, we have information about
the specific deployment, pod template, conditions,
replica set information, and under events it says,
"Scaled up replica set bad-helloworld-deployment to 1."
So from a deployment perspective,
there doesn't seem to be anything going on.
Let's look at it from a pod perspective.
Clear my screen, kubectl get pods.
Looks like we have a pod and image back off state,
so let's introspect on the pod end.
We can do a describe on the pod,
except I have to mention that it's a pod.
This returns all the information for this specific pod.
There's name information and whatnot.
The stuff we're really interested in
from a debugging perspective is the events.
So as you can see, it was scheduled five minutes ago,
but it looks like we started to see a warning,
but if you look at the type,
the very first event that looks a little bit suspicious
is this warning and the reason is failure for kubelet,
minikube, failed to pull image
karthequian/unknown-pod:latest,
and we get a specific error associated with that.
This gives us some indication that there's actually
something going on with the pod with respect to the image,
so it forces you to check whether this image is correct
or whether you don't have access to the repository
that it's sitting in.
That's one debugging technique.
The other technique that I use a lot is
I end up looking at log files for specific pods.
So if I do a kubectl get deployments,
I have two deployments running.
Specifically, I'm going to introspect
the helloworld deployment and look at the pods
associated with that.
So let me do a get pods for all.
So helloworld-deployment.
This is the pod associated with the helloworld-deployment.
I'm going to copy this guy, and I'm going to type
kubectl logs, except I don't want the kubectl part,
and this command returns all the logs for that specific pod.
So in this case, it was a simple web application,
so this is the nginx logs coming out from the pod.
That's another technique.
The third thing I typically do is sometimes you have to
actually exec into the pod to see what's going on.
To exec into a pod, we use the kubectl
exec command minus it.
Once again we need the pod name,
so I'm going to paste that out.
Don't need the kubectl logs stuff here.
Delete,
and we want to pipe this to a specific shell.
I can use bin/bash and run that,
and once we run this command,
you'll notice that this says route@helloworld-deployment
and the actually pod name, so we're actually running
inside of the pod right now.
We can see all the processes in the pod,
so we know this is an nginx master process,
nginx worker process, et cetera,
and a lot of times you end up having to exec into the pod
to make sure that your configuration files are correct,
or all the information that you're expecting,
environment variables, et cetera, are actually in the pod
that you're looking for.
One last thing to talk about is
occasionally you might have multiple containers
in your pod, so the flag to do that is minus c,
and in this case our pod name was helloworld,
and where we get dropped back into the same container
as we expect.
Typically, you don't use the minus c
if you just have a single pod with a single container
running in it, but it's useful when you have
multiple containers that comprise of the pod.