历史文章 k8s stale read ListWatch 到 WatchList 原理 一致性读按严格程度划分，k8s 支持的顺序一致性，而 etcd 支持的是更严格的线性一致性。详情可以参考这篇文章 https://

不定期分享 k8s 里面各种坑，Just 避雷 结论 太长不看版：在拦截 pod 创建请求时，在业务逻辑中不要直接依赖 admission request 的 pod namespace 属性。可以使用 adminssion request 的 namespa

现象 v1.27 的 K8s，在 kube-apiserver 的日志中会看到 “etcd event received with PrevKv=nil” 的字样，资源对象被删除后在 Etcd 中已经不存在了但在 Reflector store 中仍然存在，可以在 Informer 或者 watchCache 中看到对应的对象，依

前一篇已经描述了较老版本中存在的丢事件的问题，本篇继续描述另外一种。 现象 v1.27 的 K8s，在 kube-apiserver 的日志中会看到 “etcd event received with PrevKv=nil” 的字样，资源对象被删除后在 Etcd

Kube-apiserver 提供了 Watch API 来支持实时接收资源对象变化的功能，也是 Informer 实现的基础，那么我们通过 Watch 或者 Informer 本地缓存拿到的数据是否真的和 Etcd 中的数据一致呢？ 先说结论：

Kube-apiserver 不止 OOM，还可能 Panic。 现象 Kube-apiserver 在处理外部请求时发生不可恢复的报错，直接 Fatal 退出运行。看日志调用堆栈，会发现 concurrent map iteration and map write 的字样。这是 golang 检