kubectl命令要按排障路径组合使用：先看范围，再看状态和事件，然后进入日志、配置和网络。
kubectl get适合快速查看对象是否存在、状态是否异常、分布在哪些节点。排障起点应先确认是单个Pod、单个命名空间还是集群范围问题。
相关主题可以结合 Kubernetes、AI基础设施、云原生安全 和 GPU调度 等站内内容一起阅读。
1. 先用get确认影响范围
kubectl get适合快速查看对象是否存在、状态是否异常、分布在哪些节点。排障起点应先确认是单个Pod、单个命名空间还是集群范围问题。
速查内容要让读者看到结果后知道下一步。
2. describe用于看事件和调度原因
Pending、ImagePullBackOff、CrashLoopBackOff等状态都能在describe中找到事件线索。它通常比直接进入容器更快。
速查内容要让读者看到结果后知道下一步。
3. logs要区分当前和上一次实例
容器重启后，当前日志可能没有错误现场。CrashLoopBackOff场景下要使用–previous查看上一次容器退出前输出。
速查内容要让读者看到结果后知道下一步。
4. exec和debug要谨慎使用
进入容器可能改变现场，debug容器也可能引入额外变量。生产环境使用前要确认是否会影响业务和证据保留。
速查内容要让读者看到结果后知道下一步。
常用命令可以按下面顺序组合：
kubectl get pods -n <namespace> -o wide
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --previous
kubectl get events -n <namespace> --sort-by=.lastTimestamp5. 常见状态对应命令组合
Pending看describe、events、quota和PVC；CrashLoopBackOff看logs –previous、退出码和探针；访问失败看Service、EndpointSlice、标签和网络策略。
速查内容要让读者看到结果后知道下一步。
6. 保存现场比临时修好更重要
关键日志、事件和YAML要先保存。否则临时修复后现场消失，复盘很难还原根因。
速查内容要让读者看到结果后知道下一步。
深入落地说明
1. 命令清单按场景记
kubectl命令不要按字母顺序记，而要按排障场景记。Pod异常、服务不可达、配置错误、资源不足和节点问题，各自有不同的命令组合。
这种组织方式能帮助读者在压力下快速选择下一步，而不是在命令列表里反复查找。
2. get用于确认范围
kubectl get适合快速回答资源是否存在、状态是否异常、分布在哪些节点。加上-o wide可以看到节点、IP和更多调度信息。
如果get阶段已经发现只有单个Pod异常，后续排查范围就可以缩小；如果多个命名空间异常，则要考虑集群级问题。
3. describe用于解释状态
describe能看到事件、调度结果、探针失败、镜像拉取和卷挂载信息。Pending、ImagePullBackOff和CrashLoopBackOff都应优先看describe。
事件要按时间顺序读，最后一条不一定就是根因，前面的调度或挂载失败可能更关键。
4. logs用于看应用现场
日志要区分当前实例和上一次实例。容器重启时，–previous经常能看到真正的启动错误。多容器Pod则必须用-c指定容器。
如果日志为空，不代表应用没问题，可能是进程还没来得及输出就退出，也可能日志路径没有接到标准输出。
5. 高风险命令要留痕
exec、debug、delete和patch都会改变现场或资源状态。生产环境使用前要确认影响范围，并保存操作前的YAML、事件和日志。
速查清单里必须提醒这些边界，否则读者可能为了快速恢复而破坏排障证据。
速查步骤：按状态选择命令组合
- Unknown或Pending：先get再describe，重点看调度事件、资源配额、PVC和节点条件。
- CrashLoopBackOff：先logs –previous，再看退出码、探针和最近配置变更。
- ImagePullBackOff：检查镜像名、tag、仓库凭证、节点网络和镜像拉取策略。
- 服务不可达：检查Service、EndpointSlice、标签选择器、Pod Ready状态和NetworkPolicy。
- 现场保留：执行delete、patch、debug前先保存YAML、事件和关键日志。
工具速查类内容的价值是减少排障时的选择成本。读者看到状态后，应该马上知道下一组命令是什么。
场景化展开：kubectl速查要按状态组合命令
1. Pending状态先看调度链路
Pod处于Pending时，不要直接看应用日志，因为容器可能还没有启动。更合适的命令组合是先get确认状态，再describe看事件，重点关注资源不足、污点、亲和性、PVC绑定、节点选择器和配额限制。如果事件里没有Successfully assigned，问题通常还在调度阶段。
这类问题的命令顺序可以固定为：查看Pod状态，查看事件，查看命名空间配额，查看PVC，查看节点条件。顺序固定后，排障时不容易遗漏关键分支。
2. CrashLoopBackOff要结合previous日志
CrashLoopBackOff表示容器启动后反复退出。此时当前日志可能只包含新一轮启动输出，previous日志更有价值。命令组合应包括logs –previous、describe、查看退出码、查看探针配置和对比最近配置变更。
如果退出码指向OOM，还要查看资源限制和节点事件；如果日志显示配置缺失，要继续检查ConfigMap、Secret、环境变量和挂载路径。速查表的价值不是列出很多命令，而是告诉读者当前状态下先用哪一组命令。
3. 服务不可达要从Service走到Endpoint
服务不可达时，先确认Service是否存在，再看selector是否匹配Pod标签，然后检查EndpointSlice是否有Ready地址。如果Endpoint为空，说明流量还没有可用后端；如果Endpoint存在但访问失败，再继续看NetworkPolicy、DNS、Ingress或应用监听端口。
排查过程中要避免过早重启服务。很多不可达问题来自标签不匹配、readinessProbe失败或网络策略限制，重启并不能改变根因。保留现场、按链路向下查，通常更快。
4. 命令速查要提醒副作用
kubectl命令很多都看似简单，但部分操作会改变现场。例如delete会触发重建，patch会修改资源状态，debug可能拉起临时容器，scale会改变副本数。速查清单应把只读命令和修改命令分开，避免排障时无意破坏证据。
建议先使用get、describe、logs、events、top这类只读命令收集信息，再决定是否进入修改动作。需要修改时，先保存YAML和关键日志，并记录变更原因。
5. 速查表要和团队常见故障同步更新
kubectl命令速查不是一次写完就结束。随着团队常见问题变化，速查表也要更新。例如最近频繁出现镜像拉取失败，就应补充仓库凭证、节点网络和镜像策略检查；如果经常遇到服务不可达，就应强化Service、EndpointSlice和NetworkPolicy链路。
建议在每次故障复盘后更新速查表，把真实事件中的命令顺序、关键输出和误区补进去。这样速查表会越来越贴近团队环境，而不是停留在通用命令列表。
6. 常见误区：把命令输出当成最终答案
kubectl输出只能说明某一刻的集群状态，不能自动给出根因。比如Pod事件显示探针失败，真正原因可能是应用启动慢、依赖服务不可达、端口配置错误或资源不足。命令速查表应引导读者继续验证，而不是看到一个关键词就结束排查。
使用速查表时，可以把每次命令输出写成“观察、判断、下一步”。观察是原始信息，判断是当前假设，下一步是验证动作。这个小习惯能减少误判，也方便多人协作。
补充提醒：命令速查适合放在值班入口页，并标注只读命令和会修改现场的命令。这样紧急场景下，值班人员能先收集证据，再执行有副作用的恢复动作。
另外，速查表要避免把所有命令堆在一起。可以按“状态、只读检查、可能原因、下一步动作”四列维护，这样读者看到Unknown、Pending、CrashLoopBackOff或服务不可达时，能直接进入对应分支。对于生产集群，任何会改变资源状态的命令都应附带保存现场和回滚提醒。
最后，速查表要和权限边界配合。生产环境中，不是所有值班人员都应拥有修改权限。只读排查、临时调试和恢复操作可以分级授权，既提高排障效率，也避免紧急场景下误操作扩大影响。
落地检查清单
- 先确认本文讨论的问题是否就是当前团队的主要矛盾。
- 再检查现有平台、流程和人员职责是否支持这些动作。
- 最后用小范围验证替代一次性大改，保留回滚窗口和复盘记录。
小结
kubectl命令速查：Pod、日志与事件排查清单 的重点，是把读者正在搜索的问题落到真实场景、判断口径和执行顺序中。内容不应该停留在概念解释，也不应该把所有场景压成同一种答案。
发布和复盘时，可以重点检查三件事：标题承诺是否被正文兑现，图表是否帮助读者理解关键链路，FAQ是否回答了真实疑问。
常见问题
1. 这类问题应该先看工具还是先看场景？
建议先看场景。工具能力只有放到团队规模、业务风险、现有平台和运维流程中，才知道是否真的适合。
2. 如果测试环境能跑通，是否可以直接上生产？
不建议。生产环境还要验证权限、观测、告警、回滚、容量和多人协作流程，否则上线后问题会集中暴露。
3. 如何判断这篇文章中的方法是否适合自己的团队？
可以从目标、约束和验证成本三方面判断：目标是否一致，约束是否相近，是否能用小范围实验验证结论。
