Introspection

Exam guide§2.1

Introspection is the act of gathering information about the containers, pods, services, and other objects running inside a cluster - the first thing you do to debug a running application. Four kubectl commands cover most of it: get, describe, exec, and logs. This page is the concept layer; for the hands-on command sequence (kubeconfig, deploy, expose, port-forward) see Working with clusters (kubectl).

The four commands

Command	What it gathers
kubectl get pods	High-level: is the Pod running? Shows each Pod's phase status.
kubectl describe pod POD_NAME	Full detail about a Pod and its containers - labels, resource requirements, volumes, status.
kubectl exec POD_NAME -- CMD	Run a single command inside a container and see the result in your own shell.
kubectl logs POD_NAME	What's happening inside a Pod - stdout + stderr from the apps in it.

get pods - is it running?

kubectl get pods reports each Pod's phase, a high-level summary of where the Pod is in its lifecycle. It is a summary, not the comprehensive detail about a Pod or its containers (that's what describe is for).

kubectl get pods reports each Pod’s phase - the six possible high-level lifecycle states.

The six high-level Pod phases reported by kubectl get pods.

⚠GotchaCrashLoopBackOff usually means misconfiguration

CrashLoopBackOff is a common error, and it almost always means the Pod isn't configured correctly - the container keeps starting, crashing, and getting restarted. Reach for describe pod and logs next to find out why it's exiting.

describe pod - full detail

kubectl describe pod POD_NAME provides detailed status for both the Pod and each container inside it. The fields split cleanly into two levels:

kubectl describe pod reports two levels of detail: Pod-level fields (name, namespace, node, labels, status, IP) and per-container fields (state, images, ports, commands, restart counts).

The State field is one of waiting, running, or terminated.

exec - run a command in a container

kubectl exec runs a command inside a container. There are two modes:

• Single command - kubectl exec POD -- ping ... runs one command and returns its output to your shell. Useful when a single command (like ping) will do.
• Interactive shell - add the -it switch to attach your shell to the container and work inside it, e.g. to install a network tool or text editor while troubleshooting.

kubectl exec runs a single command inside a container and returns the result to your own shell - here listing the container root with ls /.

≡FactsThe `-it` switch

• -i - pass the terminal's standard input through to the container.
• -t - tell kubectl the input is a TTY.
• Together, -it attaches your terminal's stdin/stdout to the container.

⚠GotchaWithout `-it`, exec returns immediately

If you leave off -i and -t, the command runs in the remote container and returns immediately to your local shell - you don't get an interactive session. Use -it only when you need to stay inside the container.

⚠GotchaDon't install software into a live container

Changes a container makes to its own filesystem are usually ephemeral. Use the interactive shell to figure out what needs to change, then bake that change into a new container image and redeploy - don't temporarily repair a running container. This is the same rule as live pod edits don't persist to replicas.

logs - what's happening inside

kubectl logs POD_NAME reveals errors and debugging messages written by the apps running in the Pod, so it's the go-to for containers failing to run successfully.

kubectl logs streams what an app writes inside a Pod: standard output (stdout) and error messages (stderr).

≡FactsReading logs

• Logs carry both standard output and standard error from the apps in the container.
• Most useful when a container is failing to start - the logs usually say why.
• For a multi-container Pod, add -c CONTAINER to show one specific container's logs.