上一篇【第68篇】CSI深度解析——容器存储接口让K8s能“插“任何存储的万能插座下一篇【第70篇】K8s垃圾回收机制——打扫卫生的艺术摘要你肯定有过这种经历Pod起不来kubectl get pod只显示一个CrashLoopBackOff或者Pending一脸懵。然后你敲了kubectl describe pod翻到底部的Events一下就看到FailedScheduling: insufficient cpu或者Failed to pull image——真相大白。这个Events就是K8s的Event机制——集群的黑匣子。任何重要的事调度结果、镜像拉取、探针失败、节点压力发生时相关组件都会吼一嗓子记成Event。这篇文章讲清Event的数据结构、生命周期、怎么读以及怎么用Event快速排障。一、Event是什么1.1 它不是日志是发生了什么【Event vs 日志 vs 指标】 • 日志(Logs): 应用自己打的流水账(处理了订单123) • 指标(Metrics): 数值时序(CPU 50%、QPS 100) • 事件(Event): 系统发生的重要事情(Pod被调度到node-2 镜像拉取失败 Liveness探针失败) Event是K8s组件(调度器/控制器/kubelet)主动上报的 值得注意的状态变化1.2 Event的数据结构【一个Event对象的字段】 type: Normal / Warning ← 正常事件 还是 警告 reason: FailedScheduling ← 简短原因码(机器可读) message: 0/3 nodes..., insufficient cpu ← 人读详情 involvedObject: Pod/my-pod ← 和谁相关 source: default-scheduler ← 谁报的 count: 5 ← 同样事件发生了几次 firstTimestamp / lastTimestamp ← 首次/最近发生时间 type例子: Normal Scheduled Successfully assigned ... to node-2 Warning BackOff Back-off restarting failed container Warning FailedScheduling 0/3 nodes are available...要点Event的三个最有用字段是typeNormal还是Warning排障先看Warning、reason简短码可程序匹配、message人读详情。involvedObject告诉你事件和哪个资源相关——这让你能用kubectl describe 资源直接看到它的事件。count避免了同一事件刷屏重复事件合并计数。二、Event的生命周期2.1 谁产生、存哪、活多久【Event 的一生】 1. 某组件(如scheduler)产生的事件: scheduler发现Pod无法调度 → 调API Server创建Event对象 2. API Server 存进 etcd (Event也是个K8s对象!) 3. 事件保留时间有限: • 默认保留 1小时 (Event TTL, 旧版) • 新版用 EventRectention 控制(默认 1h) • 之后被垃圾回收(见第070篇) ⚠️ 所以Event不是永久审计日志! 长期留存要接外部系统(Loki/Elastic/监控)# 看Event的保留配置kube-apiserver--help|grepevent-ttl# --event-ttl duration 默认值: 1h0m0s三、怎么读Event3.1 kubectl describe【kubectl describe —— 最常用的Event查看方式】 kubectl describe pod my-pod ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m default Successfully assigned default/my-pod to node-2 Normal Pulling 2m kubelet Pulling image nginx:1.25 Normal Pulled 90s kubelet Successfully pulled image Normal Created 90s kubelet Created container app Normal Started 90s kubelet Started container app → 按时间顺序从下往上看就是Pod的成长史3.2 kubectl get events# 看整个namespace的事件(按时间)kubectl get events --sort-by.lastTimestamp# 只看Warning(排障最有用!)kubectl get events --field-selectortypeWarning# 看某资源的事件kubectl get events --field-selectorinvolvedObject.namemy-pod# 看调度失败事件kubectl get events --field-selectorreasonFailedScheduling四、实战用Event定位调度失败4.1 经典场景# 现象Pod一直Pendingkubectl get pod my-pod# NAME READY STATUS RESTARTS AGE# my-pod 0/1 Pending 0 5m# 看Eventkubectl describe pod my-pod|tail-20# Events:# Type Reason Age From Message# Warning FailedScheduling 5m default 0/3 nodes are available:# 1 node(s) had untolerated taint {gpu: true},# 2 node(s) didnt match PodFitsResources# (insufficient cpu, insufficient memory)# 解读# 1. 有1个节点有gpu污点Pod没容忍 → 排除# 2. 有2个节点资源不够(CPU/内存不足) → 排除# 3. 所以0个节点可用 → 一直Pending# 解法要么加资源、要么加节点、要么改requests4.2 常见Event Reason速查Reason含义常见原因FailedScheduling调度失败资源不够/污点/亲和FailedSynchronization同步失败卷挂载问题BackOff容器反复重启应用崩溃/配置错Unhealthy探针失败应用没就绪/挂了FailedKillPod删Pod失败节点失联NodeNotReady节点失联kubelet挂/网络断Rebooted节点重启节点重启了要点排障时Event是第一现场。Pod异常先kubectl describe看EventsWarning级别的事件直接告诉你根因资源不够、污点不匹配、镜像拉不下来、探针失败。配合--field-selector能精准过滤。但要记住Event只保留1小时——要做长期审计得接Loki/ES第076篇。下篇讲垃圾回收——K8s怎么打扫卫生。五、Event的扩展Event v1beta1【新Event API —— 更省的存储】 旧: 每次事件都建新Event对象(重复事件也建) → etcd里一堆几乎相同的Event浪费 新(v1beta1, 1.19): • Event (聚合后的给用户看) • EventSeries (记录发生了几次) • 相同事件合并只更新count和lastTimestamp → 大幅减少etcd写入和存储本篇小结K8s Event是集群的黑匣子——系统重要状态变化调度结果、镜像拉取、探针失败、节点压力都由相关组件上报成Event对象存进etcd。关键字段typeNormal/Warning、reason短码、message详情、involvedObject关联资源。排障时Event是第一现场——kubectl describe 资源看EventsWarning级别直接指向根因--field-selector能精准过滤。但Event只保留1小时event-ttl长期审计要接外部系统。下篇讲K8s的垃圾回收机制——级联删除和清理的艺术。上一篇【第68篇】CSI深度解析——容器存储接口让K8s能“插“任何存储的万能插座下一篇【第70篇】K8s垃圾回收机制——打扫卫生的艺术