简介
部署并不总是按计划进行。发生故障时，你需要一套可重复的排查方法。
在本实验中，你将解决「丢失镜像之谜」。
在 Kubernetes 中，排查问题通常从对象状态开始，然后查看事件，最后进行更详细的检查。本实验重点介绍这种以证据为基础的排查流程。
你将完成以下任务：
- 创建案发现场：故意部署一个损坏的 Pod。
- 展开调查：使用「望远镜」（
get）查看异常情况。 - 收集证据：使用「放大镜」（
describe）查找根本原因。 - 解决案件：修复配置，并观察应用恢复正常。
创建损坏的 Pod
首先部署一个包含拼写错误的 Pod。这样可以模拟一种常见错误：指定不存在的镜像。
这也提醒我们，Kubernetes 可以接受许多问题会在之后才暴露的清单文件。YAML 文件在语法上可能完全正确，但在实际运行时仍然可能配置错误。因此，排查问题时必须区分「对象是否被接受」和「工作负载是否真正成功启动」。
创建名为 broken-pod.yaml 的文件：
nano broken-pod.yaml
粘贴以下内容。注意其中可疑的镜像标签 wrongtag123。
apiVersion: v1
kind: Pod
metadata:
name: broken-pod
spec:
containers:
- name: nginx
image: nginx:wrongtag123
保存并退出（Ctrl+X、Y、Enter）。
部署 Pod：
kubectl apply -f broken-pod.yaml
由于 YAML 格式正确，Kubernetes 会接受该文件。此时，「案件」还没有被发现。
观察故障
现在查看这个部署的状态，就像用望远镜观察现场一样。
ErrImagePull 和 ImagePullBackOff 等状态是故障表现，而不是最终原因。它们会告诉你下一步应该调查什么。良好的排查方式是把状态输出当作第一个线索，而不是完整的诊断结论。
检查 default 命名空间中的 Pod：
kubectl get pods
刚开始你可能会看到 ContainerCreating，但几秒钟后，状态通常会变为 ImagePullBackOff 或 **ErrImagePull**。
ImagePullBackOff 是 Kubernetes 对以下情况的说法：「我尝试拉取这个镜像，但失败了。我会暂时退避（等待）一段时间，稍后再试。」
这说明受影响的 Pod 当前不健康。
检查事件
我们知道它失败了，但还不知道为什么失败。要查明原因，需要进一步检查。
kubectl describe 命令就是你的放大镜。它会显示特定资源的内部事件和日志。
其中，Events 部分尤其重要，因为它保留了来自调度器和 kubelet 等 Kubernetes 组件的简短过程记录。初学者如果不读取事件就直接随意修复，往往会浪费时间去解决错误的问题。
检查损坏的 Pod：
kubectl describe pod broken-pod
该命令会输出大量信息。向下滚动到最底部，找到 Events 部分。
你应该会看到类似下面的内容：
Type Reason Message
---- ------ -------
Normal Pulling Pulling image "nginx:wrongtag123"
Warning Failed Failed to pull image "nginx:wrongtag123": manifest unknown
Warning Failed Error: ErrImagePull
消息 manifest unknown 就是关键证据。这表示 Docker registry（存放镜像的位置）中没有 nginx:wrongtag123 的记录。
案件告破：镜像标签无效。
修复 Pod
现在已经找到根本原因，可以开始修复。
这一步还体现了一个更广泛的排查模式：先观察，根据证据提出假设，进行一次有针对性的修改，然后验证是否恢复。相比一次性进行多项猜测性修改，这种有纪律的循环更加可靠。
再次打开 broken-pod.yaml 文件：
nano broken-pod.yaml
修正这个「拼写错误」。将 nginx:wrongtag123 改为 nginx。nginx 默认对应 nginx:latest，这是一个有效的镜像。
apiVersion: v1
kind: Pod
metadata:
name: broken-pod
spec:
containers:
- name: nginx
image: nginx
保存并退出。
应用修复。Kubernetes 会根据新信息更新现有 Pod。
kubectl apply -f broken-pod.yaml
现在观察恢复过程：
kubectl get pods -w
你应该会看到状态从 ImagePullBackOff 变为 Running。
按 Ctrl+C 停止观察。
做得很好，侦探！你已经找到了错误，并成功恢复了服务。
总结
在本实验中，你学习了 Kubernetes 的基本排查流程：
- 观察：检查
kubectl get pods，找出故障工作负载。 - 检查：使用
kubectl describe pod查看事件日志并查找错误消息。 - 修复：更新 YAML 清单文件并应用修正。
这套「Get、Describe、Fix」流程可以解决你在 Kubernetes 职业生涯中遇到的 90% 的部署问题。
