kubectl 事件是什么
事件是集群组件对关键动作的记录：调度器写下调度结果、kubelet 写下拉镜像与挂载结果、控制器写下创建与失败原因、节点写下驱逐与资源压力。它回答的是「为什么不行」——对象状态只告诉你结果，事件里才有具体约束、阈值与错误文本。按时间排序读事件，是排查任何异常对象的第一跳。
事件的时效与重复
事件不是审计日志：默认只保留很短一段时间（常见约一小时），过期即被清理。同一个对象反复失败时，事件对象不会被无限创建，而是累加计数并更新最后出现时间，例如同一原因的多次重启合并成一条带次数的事件。这意味着两个结论：故障要尽快取现场，计数暴涨本身就是「在持续失败」的信号。
基本信息
| 适用环境 | 任何 Kubernetes 发行版，事件属于命名空间级对象 |
|---|---|
| 语法 | kubectl get events [-A] [--field-selector ...] [--sort-by=...] |
| 保留时间 | 由集群配置决定，常见约一小时，过夜后通常已清理 |
| 关键字段 | 类型、原因、涉及对象、消息、首次与最后出现时间、次数 |
| 筛选方式 | 按类型筛 Warning，或按涉及对象名精确筛 |
| 权限要求 | 对事件资源有 get 与 list 权限 |
典型使用场景
- Pod 调度不上去：看调度失败的具体约束是资源、标签、污点还是卷
- 容器反复重启：看重启原因与退避节奏，判断是应用退出还是探针杀进程
- 镜像拉不下来：看拉取失败的完整错误文本，区分凭据、名称与网络问题
- 服务不通：确认后端端点是否生成失败，检查选择器与就绪状态
- 节点异常：看驱逐与资源压力事件，确定是磁盘、内存还是进程数触顶
- 发布卡住：结合发布对象的状态条件与事件，找到是配额还是准入策略拦截
常用示例
常用示例
kubectl get events -n prod --sort-by=.lastTimestamp # 按时间顺序读
kubectl get events -A --field-selector type=Warning # 只看告警类事件
kubectl get events -n prod --field-selector involvedObject.name=web-7d9c8b6f5c-abcde
kubectl get events -A --field-selector type=Warning --sort-by=.lastTimestamp | tail -20
kubectl get events --field-selector reason=FailedScheduling
kubectl describe pod web-x | sed -n '/Events:/,$p' # 单对象的事件只看末尾输出逐列读法
| 列 | 含义 | 怎么用 |
|---|---|---|
| LAST SEEN | 事件最后一次出现的时间 | 看是否还在持续发生 |
| TYPE | Normal 或 Warning | 排查先只看 Warning |
| REASON | 机器可读的原因短名 | 用来做筛选条件 |
| OBJECT | 涉及的对象及其类型 | 确认事件属于哪个资源 |
| MESSAGE | 人工可读的细节说明 | 约束、阈值、错误文本都在这里 |
| COUNT | 同一原因出现的累计次数 | 数值很大说明持续失败未被解决 |
常见原因对应的动作
- 调度失败：核对节点的资源余量、标签与污点，以及 Pod 的亲和与卷约束
- 挂载失败：确认引用的配置对象或存储卷是否存在、是否在正确命名空间
- 探针失败：检查探针路径、端口与超时参数，确认不是启动时间不够
- 驱逐：查看节点压力信号与阈值，先修节点再谈应用
事件属于命名空间，跨命名空间问题要加 -A 或逐个命名空间查看，漏掉命名空间会得出「什么都没有发生」的错误结论。
事件用于即时排查，长期留存要靠日志与监控系统；重要的故障现场应在处理前先导出事件内容备查。
较新版本提供专门的事件子命令，可按对象过滤并支持更友好的时间展示；老版本用带字段筛选的列表命令即可达到目的。