kubectl logsRead and follow container logs
kubectl logs prints what a container wrote to stdout and stderr. Follow it live with -f, read the run that crashed with --previous, pick a container with -c, or read every pod behind a label at once.
kubectl logs (POD | TYPE/NAME | -l SELECTOR) [-c CONTAINER] [-f] [-p] [--since=10m] [--tail=N] [--timestamps]Check that the api pods are serving requests normally after this morning's deploy.
kubectlThe Kubernetes CLI.
Containers don't send logs to the API server. The container runtime (containerd) captures each container's stdout and stderr and writes them to files on the node under /var/log/pods/<namespace>_<pod>_<uid>/<container>/0.log (symlinked from /var/log/containers). kubectl logs calls GET /api/v1/namespaces/prod/pods/NAME/log?container=worker&previous=true; the API server proxies that to the kubelet on the pod's node (port 10250), and the kubelet reads the file and streams it back. -f keeps the HTTP response open. Only the current and the one previous container instance are kept, files are rotated at 10Mi by default, and everything is deleted with the pod. That is why clusters ship logs to CloudWatch, Loki or OpenSearch with a DaemonSet such as Fluent Bit. Logs written to files inside the container are invisible to kubectl logs.
-f, --followKeep streaming new lines (Ctrl+C to stop)-p, --previousLogs from the previous, crashed container instance-c NAMEContainer to read in a multi-container pod--all-containersEvery container in the pod, init containers included-l SELECTORLogs from all pods matching a label (default 10 lines each)--prefixPrefix each line with [pod/NAME/container]--tail=NOnly the last N lines--since=10m / --since-timeOnly lines newer than a duration or a timestamp--timestampsPrepend the runtime's RFC3339 timestamp to each line--max-log-requests=NConcurrent streams with -l -f (default 5)kubectl logs on a crash-looping pod and seeing only startup linesYou read the fresh instance; the one that crashed is the previous one.
kubectl logs POD --previouskubectl logs deploy/api to investigate an intermittent errorIt reads one pod only; the failing request may have hit another replica.
kubectl logs -l app=api --prefix --since=15m | grep -i errorWriting app logs to /var/log/app.log inside the containerkubectl logs only sees stdout and stderr; files inside the container are lost with the pod.
Log to stdout/stderr and let a node agent (Fluent Bit) ship themRelying on kubectl logs for last week's incidentLogs live on the node, rotate at about 10Mi and vanish when the pod is deleted or rescheduled.
Query your central log store (CloudWatch Logs, Loki, OpenSearch)Try these on a Linux machine of your own. Each task has a hint and a solution.
Write the command to follow the logs of the container named nginx in pod web-5c7b9d6f4-q2x7z in namespace shop, starting from the last 20 lines.
Write a command that shows only error lines from all pods labelled app=checkout in the last 30 minutes, with the pod name on each line.
The worker pod in prod keeps restarting. Show the last 5 lines its previous container wrote before it died, then say why it stopped.
For real practice, open AWS Lab > EKS > your cluster > Run kubectl (lab), deploy the sample app, and read the last 10 lines of one of its pods.
kubectl logsRead and follow container logs
kubectl logs prints what a container wrote to stdout and stderr. Follow it live with -f, read the run that crashed with --previous, pick a container with -c, or read every pod behind a label at once.
kubectl logs (POD | TYPE/NAME | -l SELECTOR) [-c CONTAINER] [-f] [-p] [--since=10m] [--tail=N] [--timestamps]Check that the api pods are serving requests normally after this morning's deploy.
kubectlThe Kubernetes CLI.
Containers don't send logs to the API server. The container runtime (containerd) captures each container's stdout and stderr and writes them to files on the node under /var/log/pods/<namespace>_<pod>_<uid>/<container>/0.log (symlinked from /var/log/containers). kubectl logs calls GET /api/v1/namespaces/prod/pods/NAME/log?container=worker&previous=true; the API server proxies that to the kubelet on the pod's node (port 10250), and the kubelet reads the file and streams it back. -f keeps the HTTP response open. Only the current and the one previous container instance are kept, files are rotated at 10Mi by default, and everything is deleted with the pod. That is why clusters ship logs to CloudWatch, Loki or OpenSearch with a DaemonSet such as Fluent Bit. Logs written to files inside the container are invisible to kubectl logs.
-f, --followKeep streaming new lines (Ctrl+C to stop)-p, --previousLogs from the previous, crashed container instance-c NAMEContainer to read in a multi-container pod--all-containersEvery container in the pod, init containers included-l SELECTORLogs from all pods matching a label (default 10 lines each)--prefixPrefix each line with [pod/NAME/container]--tail=NOnly the last N lines--since=10m / --since-timeOnly lines newer than a duration or a timestamp--timestampsPrepend the runtime's RFC3339 timestamp to each line--max-log-requests=NConcurrent streams with -l -f (default 5)kubectl logs on a crash-looping pod and seeing only startup linesYou read the fresh instance; the one that crashed is the previous one.
kubectl logs POD --previouskubectl logs deploy/api to investigate an intermittent errorIt reads one pod only; the failing request may have hit another replica.
kubectl logs -l app=api --prefix --since=15m | grep -i errorWriting app logs to /var/log/app.log inside the containerkubectl logs only sees stdout and stderr; files inside the container are lost with the pod.
Log to stdout/stderr and let a node agent (Fluent Bit) ship themRelying on kubectl logs for last week's incidentLogs live on the node, rotate at about 10Mi and vanish when the pod is deleted or rescheduled.
Query your central log store (CloudWatch Logs, Loki, OpenSearch)Try these on a Linux machine of your own. Each task has a hint and a solution.
Write the command to follow the logs of the container named nginx in pod web-5c7b9d6f4-q2x7z in namespace shop, starting from the last 20 lines.
Write a command that shows only error lines from all pods labelled app=checkout in the last 30 minutes, with the pod name on each line.
The worker pod in prod keeps restarting. Show the last 5 lines its previous container wrote before it died, then say why it stopped.
For real practice, open AWS Lab > EKS > your cluster > Run kubectl (lab), deploy the sample app, and read the last 10 lines of one of its pods.