大家好！很高兴与各位一同向着“黄金Kubernetes宇航员”的目标迈进。👋

今天，我们将深入探讨 CKAD (Certified Kubernetes Application Developer) 考试范围中，实践中使用最频繁的主题：“用于应用程序监控的 k8s 内置 CLI 工具”。🕵️‍♂️

我将为您整理仅使用 kubectl 即可诊断集群和应用程序状态的核心技术，无需额外的重量级监控解决方案（如 Prometheus、Grafana 等）。

---

🚀 使用 k8s 内置 CLI 工具监控应用程序

在 Kubernetes 环境中，确认应用程序是否“运行良好”不仅仅是查看其 Running 状态。您应该能够通过 CLI 完美地控制资源使用、日志分析以及内部状态诊断。

1. 资源监控的基础：kubectl top 📊

首先要检查的是 CPU 和内存。如果应用程序运行缓慢或无故崩溃，很可能是由于资源不足（例如 OOM）。

💡 注意：要使用 kubectl top 命令，集群中必须安装 Metrics Server。

• 查看每个 Pod 的资源使用情况

查看当前命名空间中所有 Pod 的资源

kubectl top pod

查看特定 Pod 的每个容器使用情况（多容器 Pod 时非常有用！）

kubectl top pod --containers

• 查看每个节点的负载 用于检查整个基础设施的健康状况，而不仅仅是应用程序。

kubectl top node

---

2. 获取实时证据：kubectl logs 📝

了解应用程序内部发生情况最直接的方法是查看其标准输出 (stdout/stderr) 日志。

• 实时日志流 (-f)

实时跟踪日志

kubectl logs -f

• 多容器 Pod 日志 如果 Pod 中有 sidecar 容器，则必须指定容器名称。

kubectl logs -c

• 查看上一个容器的日志 (-p) 如果应用程序崩溃并重新启动，您需要查看崩溃前的日志，而不是当前日志，才能找到原因。这是 CKAD 考试中非常重要的一点！

kubectl logs --previous

---

3. 详细信息和事件诊断：kubectl describe 🔍

如果 Pod 处于 Pending 状态或发生 ImagePullBackOff 错误，日志中将不会有任何记录。此时，您需要查看 Kubernetes 系统记录的事件 (Event)。

kubectl describe pod

执行此命令后，请首先查看底部的 Events 部分。

• FailedScheduling: 节点资源不足
• FailedMount: ConfigMap/Secret/PV 连接失败
• Back-off restarting failed container: 应用程序运行时错误

---

4. 实时状态监控：–watch 标志 ⏳

您是否在部署后每秒输入一次命令来检查应用程序是否正常运行，或者滚动更新是否顺利进行？请使用 –watch（或 -w）。

kubectl get pod -w

---

5. 直接进入：kubectl exec & debug 🛠️

当您需要直接检查网络连接问题或内部配置文件时，必须进入容器内部。

• 交互式终端访问

kubectl exec -it -- /bin/sh

• 运行临时调试容器 (v1.18+) 如果镜像过于轻量（例如 distroless）甚至没有 `sh`，您可以通过 `kubectl debug` 附加一个包含调试工具的临时容器。

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

---

🎯 CKAD 考试通过的实战技巧

在考试中，不仅仅是了解命令，更重要的是您决定“在何种情况下使用何种工具”的速度。

1. 当 Pod 状态不是 Running 时： 检查 describe -> Events。
2. 当 Running 但无法访问时： 检查 logs。
3. 当发生 CrashLoopBackOff 时：： 使用 logs –previous 检查之前的日志。
4. 当怀疑性能下降时： 使用 top pod 检查资源分配（Limit/Request）与使用量。

---

💡 总结

仅凭熟练使用 Kubernetes 内置工具，您就能诊断出 80% 以上的应用程序故障。特别是 top、logs 和 describe 这“三剑客”，请务必练习到手指都能记住的程度。⌨️