kubectl describe 是干什么的
kubectl describe 输出某个资源的完整配置、状态条件与相关事件，是集群排障的第一现场：实例为什么调度不上去、镜像拉取报了什么错、探针是否失败、卷为什么挂不上，答案通常就在输出最后的事件列表里。事件有保留窗口，出问题时越早抓越完整。
基本信息
| 基本用法 | kubectl describe 资源类型 名称 -n 命名空间 |
|---|---|
| 关键区块 | 状态条件、卷挂载、环境来源、最后是事件列表 |
| 事件内容 | 调度失败、拉镜像失败、探针失败、挂载失败的原始说明 |
| 节点视角 | 查看节点时可看到资源分配情况与污点，判断能否调度 |
| 保留窗口 | 事件有保存时限，忙时尽早执行并保存输出 |
| 可查对象 | 实例、服务、节点、存储声明、入口等大多数资源都支持 |
典型使用场景
- 排查一直处于等待状态的实例：事件里会写明是资源不足、选择器不匹配还是污点未被容忍
- 排查镜像拉取失败：事件给出认证失败、标签不存在还是网络超时
- 排查探针失败：能看到存活或就绪检查失败的时间与次数
- 核对服务后端：查看服务的后端列表与选择器，判断为何流量进不来
- 评估节点还能不能放实例：查看已分配资源与实例数量上限
- 排查存储问题：确认存储声明是否绑定、卷是否挂载成功
输出重点区块
| 区块 | 内容 | 判读要点 |
|---|---|---|
| 状态条件 | 就绪、调度、初始化等条件 | 条件为假时通常紧跟原因 |
| 卷与挂载 | 挂载来源与只读属性 | 挂载失败多半出在存储声明 |
| 环境与端口 | 环境变量来源与容器端口 | 端口与实际监听不一致会导致访问失败 |
| 事件列表 | 最近的事件流 | 越靠下越新，先看最后几条 |
| 节点资源 | 已分配资源与上限 | 余量不足时实例会一直等待 |
使用示例
使用示例
kubectl describe pod web-1 -n dev | tail -30 # 直接看尾部事件
kubectl describe node node-1 | grep -A5 "Allocated resources" # 节点余量
kubectl describe svc web | grep -E "Endpoints|Selector" # 后端与选择器
kubectl describe pod web-1 > /tmp/web-1.desc # 保存现场，便于对比
# 事件有保留时限，出问题先抓一次再说事件有保留窗口：默认保存时间有限，出问题时先执行一次并把输出保存下来，过期后 describe 就不再显示，只能去日志系统里翻。
只看状态不读事件是最常见的弯路：状态只告诉结果，事件才说明原因，两者一起看能省下大量试错时间。
描述服务时重点看后端列表：列表为空说明选择器没匹配到实例，或有实例但没通过就绪检查，这是访问不通的首要排查点。
节点视角同样重要：实例一直等待时，除了看实例自身，也要看目标节点的资源余量与污点设置。
输出阅读顺序
- 从最后的事件开始读，最新的事件通常信息量最大
- 先看状态条件，条件为假时紧跟着就是原因说明
- 服务类资源重点看选择器与后端列表
- 节点类资源重点看已分配资源与污点设置
- 把输出保存成文件，便于与正常实例逐项对比
把异常实例的详情与同一命名空间里的正常实例对比，能快速发现配置差异，比逐条读配置更有效。