kubectl describe 是什么
kubectl describe 把一个资源的完整状态展开成人可读的多段文本：对象定义、当前 status、Conditions 条件、各容器状态与探针配置、卷与挂载、所在节点与资源请求，末尾还按时间附上关联事件。它比 get 的摘要列详细，也比 -o yaml 更贴合排查视角，是回答「为什么调度不上、为什么没就绪」的主要入口。
为什么不能替代日志
describe 的内容全部来自对象自身的状态字段与事件，它不包含容器进程写的任何输出。事件里的 BackOff 只能告诉你容器在反复重启，不会告诉你为什么重启。因此标准动作是 describe 定范围，再顺着结论去 logs 或 -o yaml 取细节。
基本信息
| 适用环境 | 任何 Kubernetes 发行版，主流资源类型都支持 |
|---|---|
| 语法 | kubectl describe <资源类型> <名称> [-n 命名空间] |
| 输出内容 | 对象定义、运行状态、条件、探针、事件列表 |
| 事件范围 | 只含当前命名空间内与该对象相关的事件 |
| 与 yaml 的区别 | describe 是给人读的聚合视图，yaml 是原始对象结构 |
| 权限要求 | 对目标资源具备 get 权限 |
典型使用场景
- Pod 卡在 Pending：看 Conditions 说明与 FailedScheduling 事件里的具体约束
- 容器反复重启：看 State 与 Last State 的退出码与原因，确认是内存不足还是探针杀进程
- 服务不通：查 Service 的选择器与端点段，确认后端列表是否为空
- 卷挂载失败：看卷小节里的定义与挂载两段，区分是对象缺失还是挂载超时
- 节点写入受阻：查看节点的污点、条件与已分配资源，判断是否已被占满
- 存储异常：查看 PVC 绑定的 PV 与状态是否停在 Pending
- 发布卡住：查看 Deployment 的条件与事件，找到是配额、探针还是镜像拉取的问题
常用示例
常用示例
kubectl describe pod web-7d9c8b6f5c-abcde -n prod # Pod 全貌，排障第一站
kubectl describe pod web-x | sed -n '/Events:/,$p' # 只截取末尾事件段
kubectl describe node node-1 | grep -A6 Conditions # 节点健康条件
kubectl describe svc web | grep -A8 Endpoints # 后端端点列表
kubectl describe pvc data-db-0 -n prod # 存储绑定是否完成
kubectl describe deploy web -n prod | head -40 # 发布相关条件与策略Events 常见原因
| 原因 | 指向的问题 |
|---|---|
| FailedScheduling | 没有节点满足资源、标签、亲和、污点或卷约束 |
| FailedMount | 挂载失败，常见于 Secret、ConfigMap 或 PV 不可用 |
| FailedAttachVolume | 云盘或 CSI 卷附加未完成、跨节点冲突 |
| BackOff | 容器反复重启，kubelet 按退避节奏再拉，计数增长说明持续失败 |
| Unhealthy | 探针失败，文本里会写明是存活探针还是就绪探针 |
| FailedCreate | 控制器创建下级对象失败，如配额不足或被准入策略拦截 |
| Killing 与 Preempting | 资源紧张触发的终止或抢占，说明节点容量已经不够 |
读输出的小技巧
- Conditions 里的 LastTransitionTime 能定位问题开始时间，与发布时间线对齐
- 容器状态分 Current 与 Last 两段，Last State 才是上一次失败的原因
- 节点输出里的已分配资源段汇总了各 Pod 的请求值，判断是否会调度失败看这里
describe 不显示容器的标准输出与标准错误，日志要用 kubectl logs，容器已重启时加 --previous 读取上一个实例。
事件默认只保留一段时间（常见约一小时），重要故障要尽快取；事件属于命名空间，排查前先确认 -n 是否正确。
和相邻命令的取舍
- 现象级判断用 get：对象在不在、状态是什么、重启过几次
- 原因级判断用 describe：条件、事件、探针、卷、节点约束
- 应用级判断用 logs：进程自己报了什么错，上一个实例是怎么退出的