Hello everyone! Welcome to all of you running together towards becoming a ‘Golden Kuberstronaut’. 👋

Today, we’re going to dive deep into a topic that is most frequently used in practice among the CKAD (Certified Kubernetes Application Developer) exam scope: “k8s built-in CLI tools for application monitoring”. 🕵️‍♂️

I’ll summarize the core techniques for diagnosing the status of your cluster and applications using only kubectl, without the need for separate heavy monitoring solutions (like Prometheus, Grafana, etc.).

---

🚀 Monitoring Applications with k8s Built-in CLI Tools

In a Kubernetes environment, checking if an application is “running well” means more than just seeing its Running status. You should be able to fully control resource usage, log analysis, and internal state diagnosis through the CLI.

1. Basics of Resource Monitoring: kubectl top 📊

The first thing to check is CPU and Memory. If an application is sluggish or crashes without reason, it’s highly likely due to resource shortage (e.g., OOM).

💡 Note: To use the kubectl top command, Metrics Server must be installed on your cluster.

• Check resource usage per Pod

Check all Pod resources in the current namespace

kubectl top pod

Check usage per container for a specific Pod (Useful for multi-container Pods!)

kubectl top pod --containers

• Check load per Node Used to check the health of the entire infrastructure, not just applications.

kubectl top node

---

2. Securing Live Evidence: kubectl logs 📝

The most direct way to find out what’s happening inside an application is to view its standard output (stdout/stderr) logs.

• Real-time log streaming (-f)

Stream logs in real-time

kubectl logs -f

• Multi-container Pod logs If there’s a sidecar container within the Pod, you must specify the container name.

kubectl logs -c

• Check previous container logs (-p) If an application has crashed and restarted, you need to look at the logs just before it died, not the current logs, to find the cause. This is a very important point for the CKAD exam!

kubectl logs --previous

---

3. Detailed Information and Event Diagnosis: kubectl describe 🔍

If a Pod is in a Pending state or an ImagePullBackOff error occurs, nothing will be logged. In such cases, you need to look at the Events recorded by the Kubernetes system.

kubectl describe pod

When you run this command, check the Events section at the bottom first.

• FailedScheduling: Node resource shortage
• FailedMount: ConfigMap/Secret/PV connection failure
• Back-off restarting failed container: Application runtime error

---

4. Real-time Status Monitoring: –watch Flag ⏳

Are you typing commands every second to check if your application is running normally right after deployment, or if a Rolling Update is progressing well? Use –watch (or -w).

kubectl get pod -w

---

5. Direct Intrusion: kubectl exec & debug 🛠️

When you need to check network connectivity issues or internal configuration files directly, you must enter the container.

• Interactive terminal access

kubectl exec -it -- /bin/sh

• Run a temporary debug container (v1.18+) If the image is too lightweight (e.g., distroless) and doesn’t even have `sh`, you can attach a temporary container with debugging tools using `kubectl debug`.

kubectl debug -it --image=busybox --target=

---

🎯 Practical Tips for CKAD Success

In the exam, beyond simply knowing commands, the speed at which you decide “which tool to use in which situation” is crucial.

1. When Pod status is not Running: Check describe -> Events.
2. When Running but inaccessible: Check logs.
3. When CrashLoopBackOff occurs: Check previous logs with logs –previous.
4. When performance degradation is suspected: Check usage against resource allocation (Limit/Request) with top pod.

---

💡 In Conclusion

By effectively utilizing Kubernetes’ built-in tools alone, you can diagnose over 80% of application failures. Especially practice these ‘three musketeers’ – top, logs, and describe – until your fingers remember them. ⌨️