为何Kubernetes监听器返回旧资源的ADDED事件？

为什么会看到多年前创建的命名空间的ADDED事件？ #

你通过Python客户端的watch.stream监听命名空间时，触发的不是历史创建事件，而是Kubernetes watch机制的初始同步逻辑：

• 启动watch会话后，Kubernetes会先将当前集群中所有存在的命名空间，以ADDED事件的形式推送给你——这相当于给你发送一份当前资源的完整快照，用于同步本地状态。
• 只有在初始同步完成后，后续收到的ADDED事件才是真正新创建的命名空间，DELETED/UPDATED事件也都是资源后续发生变化时的增量推送。
• 那些多年前的命名空间之所以会触发ADDED，是因为它们至今仍存在于集群中，并非Kubernetes保留了多年前的创建事件。

Kubernetes会永久保留资源发送的最后一个事件吗？ #

需要区分两种“事件”的概念：

• Watch机制中的状态事件（ADDED/UPDATED/DELETED等）：这类事件是实时推送的，Kubernetes不会存储它们。初始同步的ADDED是当前资源的快照，后续增量事件仅在发生时推送，不会被持久化保留。
• Kubernetes的Event资源对象：也就是通过kubectl get events能看到的日志类事件（比如Pod启动失败、资源被删除的记录），默认由kube-controller-manager的--event-ttl参数控制保留时间，默认值为1小时，超时后会被自动清理，不会永久保留。

Kubernetes会保留已删除资源的DELETE事件多久？ #

分三种场景说明：

• Watch会话中的实时DELETE事件：当资源被删除时，watch会即时推送DELETE事件，但这个事件不会被存储，一旦watch会话断开或错过推送，就无法再获取。
• Event资源中的删除记录：比如命名空间被删除时生成的日志事件，同样受--event-ttl参数控制，默认1小时后被清理。
• etcd中的墓碑记录：已删除的资源会在etcd中留下墓碑（tombstone），默认由etcd的--auto-compaction-retention参数控制保留时间（默认1小时），超时后墓碑会被压缩清理，之后重启watch也无法再获取到该资源的DELETE事件。

内容的提问来源于stack exchange，提问作者red888