Logging and Monitoring

← Back to CKA Practice Index Viewing logs and monitoring resources are fundamental methods for troubleshooting and understanding cluster status. In the CKA exam, you need to be proficient with kubectl logs, kubectl top, JSONPath, custom-columns, and related commands.

---

1. kubectl logs -- Viewing Pod Logs

Basic Usage

# View Pod logs (current container)
kubectl logs <pod-name>

# View logs with timestamps
kubectl logs <pod-name> --timestamps

# Follow log output (similar to tail -f)
kubectl logs <pod-name> -f

# View logs from the previous crashed instance (useful during CrashLoopBackOff)
kubectl logs <pod-name> --previous

# View only the last N lines
kubectl logs <pod-name> --tail=50

# View logs from the recent time period
kubectl logs <pod-name> --since=5m
kubectl logs <pod-name> --since-time="2026-05-27T10:00:00Z"

Multi-Container Pods

# Specify a container
kubectl logs <pod-name> -c <container-name>

# With follow and previous crash logs
kubectl logs <pod-name> -c <container-name> -f --previous

Label Selectors

# View logs for all Pods matching a label
kubectl logs -l app=nginx --tail=20

# View logs for all Pods under a Deployment
kubectl logs -l app=<deployment-label>

---

2. kubectl logs Quick Reference

Flag	Purpose	Example
-f	Follow log output	kubectl logs -f <pod>
--tail=N	Show only the last N lines	kubectl logs --tail=100 <pod>
--since=5m	Show logs from the last 5 minutes	kubectl logs --since=5m <pod>
--since-time=	Show logs starting from a specific time	kubectl logs --since-time="2026-05-27T00:00:00Z" <pod>
--previous	View logs from the previous container instance	kubectl logs --previous <pod>
--timestamps	Show timestamps	kubectl logs --timestamps <pod>
--prefix	Prefix each line with metadata	kubectl logs --prefix <pod>
-c	Specify container name	kubectl logs <pod> -c <container>
-l	Use label selector	kubectl logs -l app=nginx

---

3. kubectl describe -- Resource Details

# View Pod details (most commonly used)
kubectl describe pod <pod-name>

# View Node details
kubectl describe node <node-name>

# View Service details
kubectl describe svc <service-name>

# View PVC details
kubectl describe pvc <pvc-name>

# View PV details
kubectl describe pv <pv-name>

# View Deployment details
kubectl describe deployment <deployment-name>

# View any resource (by resource type)
kubectl describe <resource-type> <resource-name>

Key areas to focus on:

Resource	Focus Areas
Pod	Status, Conditions, Events
Node	Conditions, Capacity, Allocatable, Events
Service	Type, ClusterIP, Endpoints
Deployment	Replicas, Conditions, Events

---

4. kubectl get events

# View cluster events (sorted by time)
kubectl get events --sort-by='.lastTimestamp'

# View events across all namespaces
kubectl get events --all-namespaces

# View events in a specific namespace
kubectl get events -n <namespace>

# Watch events in real time
kubectl get events --watch

# Filter Warning-level events
kubectl get events --field-selector type=Warning

# View events related to a specific Pod
kubectl get events --field-selector involvedObject.name=<pod-name>

# Custom event output
kubectl get events \
  -o custom-columns=LAST_SEEN:.lastTimestamp,TYPE:.type,REASON:.reason,OBJECT:.involvedObject.name,MESSAGE:.message

---

5. kubectl top -- Resource Monitoring

Requires Metrics Server running in the cluster.

# View node resource usage
kubectl top node
kubectl top node <node-name>

# View Pod resource usage
kubectl top pod
kubectl top pod <pod-name>
kubectl top pod -n <namespace>

# View Pods across all namespaces
kubectl top pod --all-namespaces

# Sort by CPU or memory
kubectl top pod --sort-by=cpu
kubectl top pod --sort-by=memory
kubectl top pod -n kube-system --sort-by=memory

# View Pods with a specific label
kubectl top pod -l app=nginx

---

6. JSONPath Custom Output

JSONPath is used to extract specific fields from the JSON data returned by the Kubernetes API. It is very powerful.

Basic Usage

# Get all Pod names
kubectl get pods -o jsonpath='{.items[*].metadata.name}'

# Get Pod IPs
kubectl get pods -o jsonpath='{.items[*].status.podIP}'

# Get node IPs
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}'

Formatted Output

# Tabular output: Pod name and IP
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.podIP}{"\n"}{end}'

# Output: Pod name, node name, status
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.nodeName}{"\t"}{.status.phase}{"\n"}{end}'

# Output all namespaces + Pod names
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'

# Get node allocatable CPU and memory
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.allocatable.cpu}{"\t"}{.status.allocatable.memory}{"\n"}{end}'

Commonly Used JSONPath Expressions

Expression	Description	Example
$	Root node	{$}
.	Child node	.metadata.name
..	Recursive search	$..metadata.name
[n]	Array index	.items[0]
[*]	All elements	.items[*]
?()	Filter	?(@.status.phase=="Running")
range	Iteration	{range .items[*]}...{end}
"\t"	Tab character	Used for table formatting
"\n"	Newline character	Used for table formatting

Advanced Filtering

# Get Pods with a specific status
kubectl get pods -o jsonpath='{range .items[?(@.status.phase=="Running")]}{.metadata.name}{"\n"}{end}'

# Get Pods on a specific node
kubectl get pods -o jsonpath='{range .items[?(@.spec.nodeName=="node1")]}{.metadata.name}{"\n"}{end}'

# Get nodes in Ready state
kubectl get nodes -o jsonpath='{range .items[?(@.status.conditions[?(@.type=="Ready")].status=="True")]}{.metadata.name}{"\n"}{end}'

# Get image names (deduplicated)
kubectl get pods -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u

---

7. Custom Columns Output

# Define custom columns: NAME, NODE, STATUS
kubectl get pods -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,STATUS:.status.phase

# More complex custom columns
kubectl get pods -o custom-columns=\
  NAME:.metadata.name,\
  NODE:.spec.nodeName,\
  STATUS:.status.phase,\
  IP:.status.podIP,\
  NAMESPACE:.metadata.namespace

# Custom columns for nodes
kubectl get nodes -o custom-columns=\
  NAME:.metadata.name,\
  INTERNAL-IP:.status.addresses[?\(@.type==\"InternalIP\"\)].address,\
  CPU:.status.allocatable.cpu,\
  MEMORY:.status.allocatable.memory

# Deployment replicas across all namespaces
kubectl get deployments --all-namespaces -o custom-columns=\
  NAMESPACE:.metadata.namespace,\
  NAME:.metadata.name,\
  READY:.status.readyReplicas,\
  DESIRED:.spec.replicas

Note: In custom-columns JSONPath expressions, double quotes within ?(@.type=="InternalIP") must be escaped with backslashes.

---

8. High-Frequency Exam Command Combinations

# 1. Quickly find abnormal Pods
kubectl get pods --all-namespaces | grep -v Running | grep -v Completed

# 2. View Pod logs
kubectl logs <pod-name> --tail=20

# 3. View previous logs of a crashed Pod
kubectl logs <pod-name> --previous

# 4. Watch events across all namespaces in real time
kubectl get events -A -w

# 5. Pod and node resource ranking
kubectl top pod --sort-by=memory
kubectl top node --sort-by=cpu

# 6. Custom Pod list (including node and IP)
kubectl get pods -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,IP:.status.podIP,STATUS:.status.phase

# 7. Node allocatable resources
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}CPU: {.status.allocatable.cpu}{"\t"}MEM: {.status.allocatable.memory}{"\n"}{end}'

# 8. Check image pull policy
kubectl get pods -o custom-columns=NAME:.metadata.name,IMAGEPULLPOLICY:.spec.containers[*].imagePullPolicy

---

9. Exam Key Points

• kubectl logs --previous is critical for viewing crashed container logs
• kubectl get events --sort-by='.lastTimestamp' sorts events by time
• kubectl top requires Metrics Server, which is usually installed in the exam
• JSONPath and custom-columns are high-frequency CKA topics -- must be proficient
• --all-namespaces shorthand is -A
• The Events section of kubectl describe is the most important diagnostic information

---

🧪 Complete Hands-on Example: Multi-Container Pod Log Collection and Resource Monitoring

Scenario

In a multi-container Pod with a main container and a sidecar container, view each container's logs, monitor resource usage, and use JSONPath and events commands for advanced troubleshooting.

Prerequisites

• Metrics Server installed in the cluster
• Permission to create Pods and view logs

Steps

Step 1: Create a Multi-Container Pod

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
  labels:
    app: web-app
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - containerPort: 80
    - name: sidecar
      image: busybox
      command: ["sh", "-c", "while true; do echo \"[sidecar] Log entry at \$(date)\"; sleep 5; done"]
EOF

kubectl get pods -w
# NAME                  READY   STATUS    RESTARTS   AGE
# multi-container-pod   2/2     Running   0          30s

Step 2: View the Main Container (nginx) Logs

kubectl logs multi-container-pod -c nginx
# By default, nginx logs are written to files; stdout inside the container may be empty
# Or use --tail to view recent logs
kubectl logs multi-container-pod -c nginx --tail=10

Step 3: View the Sidecar Container Logs

kubectl logs multi-container-pod -c sidecar
# [sidecar] Log entry at Wed May 27 10:00:05 UTC 2026
# [sidecar] Log entry at Wed May 27 10:00:10 UTC 2026
# [sidecar] Log entry at Wed May 27 10:00:15 UTC 2026
# ...

# Use -f to follow live logs
kubectl logs multi-container-pod -c sidecar -f --tail=5
# Outputs the latest 5 lines and continues following

Step 4: Simulate a Container Crash and View Previous Logs

# Assuming the sidecar has crashed before, view its previous logs
kubectl logs multi-container-pod -c sidecar --previous
# (If a previous instance exists, its logs will be shown)

Step 5: Monitor Resource Usage with kubectl top

# View node resource usage
kubectl top node
# NAME           CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
# master-node    350m         17%    1200Mi           31%
# worker-node1   280m         14%    980Mi            25%

# View Pod resource usage
kubectl top pod multi-container-pod
# NAME                   CPU(cores)   MEMORY(bytes)
# multi-container-pod   12m          45Mi

# View all Pods sorted by CPU
kubectl top pod --sort-by=cpu --all-namespaces
# NAMESPACE     NAME                                     CPU(cores)   MEMORY(bytes)
# kube-system   kube-apiserver-master-node               150m         512Mi
# default       multi-container-pod                      12m          45Mi
# ...

Step 6: View Cluster Events

# View all events sorted by time
kubectl get events --sort-by='.lastTimestamp'
# LAST SEEN   TYPE      REASON              OBJECT                                MESSAGE
# 5m          Normal    Scheduled           pod/multi-container-pod               Successfully assigned default/multi-container-pod to worker-node1
# 5m          Normal    Pulling             pod/multi-container-pod               Pulling image "nginx:latest"
# 5m          Normal    Pulled              pod/multi-container-pod               Successfully pulled image "nginx:latest"
# 5m          Normal    Created             pod/multi-container-pod               Created container nginx
# 5m          Normal    Started             pod/multi-container-pod               Started container nginx

# View only Warning-level events
kubectl get events --field-selector type=Warning

Step 7: Extract Pod Information Using JSONPath

# Get all Pod names
kubectl get pods -o jsonpath='{.items[*].metadata.name}'
# multi-container-pod

# Formatted output: Pod name, node, IP, status
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.nodeName}{"\t"}{.status.podIP}{"\t"}{.status.phase}{"\n"}{end}'
# multi-container-pod    worker-node1    10.244.1.5      Running

# Get container image names (multi-container)
kubectl get pod multi-container-pod -o jsonpath='{range .spec.containers[*]}{.name}{"\t"}{.image}{"\n"}{end}'
# nginx       nginx:latest
# sidecar     busybox:latest

Verification

# Verify all container logs can be viewed normally
kubectl logs multi-container-pod -c nginx --tail=3
kubectl logs multi-container-pod -c sidecar --tail=3

# Verify resource monitoring is available
kubectl top pod multi-container-pod

# Verify JSONPath queries
kubectl get pods -o jsonpath='{.items[0].status.containerStatuses[*].ready}'
# true true

Exam Tips

• For multi-container Pods, use -c <container-name> to specify the container for log viewing
• --tail=N limits log lines, -f follows in real time, --previous views pre-crash logs
• kubectl top node/pod requires Metrics Server to be installed
• kubectl get events --sort-by='.lastTimestamp' is the key command for time-sorted event viewing
• JSONPath and custom-columns are high-frequency CKA topics, especially the {range .items[*]}...{end} iteration syntax
• If kubectl top reports an error during the exam, it usually means Metrics Server is not installed

---

Official Documentation

• kubectl logs
• kubectl describe
• kubectl get
• JSONPath Support
• Custom Columns
• Metrics Server
• Resource Metrics Pipeline