【kube-apiserver】选型收束与开放问题：排除树、Kine 与 events 分集群
内容提要
本文总结kube-apiserver排障系列终章，提出机制排除树，按症状（401/403、webhook 503、APF 429、etcd延迟、Watch错误等）定位至Auth、Admission、APF、Storage或Watch轴。回收etcd系列停损线，明确Kine SQL后端Watch语义差异及events分集群边界。列出三个开放问题（watch cache SLO、线性读一致性、Lease fencing），强调以实测关闭，并给出ADR友好收束建议。
延伸解读
排除树的价值：从“看情况”到可证伪判断
本文提出的机制排除树，将排障从“都有可能看情况”的模糊状态，收束为按症状逐层下钻的决策流程。每个分支都对应一个可证伪的机制问题，例如“401/403 全请求？”指向 Auth 轴，“webhook 503”指向 Admission 轴。这种结构化的方法，有助于运维人员快速定位根因，避免在多层组件间盲目排查。尤其值得注意的是“苦区”场景：etcd 写慢导致 apiserver 请求挂起，进而引发 APF 队列积压，最终表现为 504。此时需要对齐两套日志的时间戳，判断哪一层先劣化，这正是排除树所强调的“机制”而非“场
Kine 的 Watch 语义差异：选型前必须评估的风险
文章明确指出，Kine 作为 etcd 的兼容层，在 Watch 语义上与原生 etcd 存在显著差异。etcd 基于 revision 有序日志，支持从任意历史 revision 追赶，且 ErrCompacted 语义明确；而 Kine 依赖 SQL 轮询或变更事件，历史窗口可能有限，ErrCompacted 可能静默丢弃，背压语义也不同。此外，Kine 缺乏 Jepsen 测试覆盖。因此，在生产多节点 Kubernetes 集群中，Kine 在大规模 informer 负载下的风险未被系统性测试，选型需谨慎。
events 分集群：隔离 churn，降低核心资源风险
将 Events 资源通过 --etcd-servers-overrides 路由到独立 etcd 集群，是一种有效的运维策略。Events 写入频率高、TTL 短，若与核心资源共用 etcd，会加速 MVCC revision 增长、提高 compaction 频率、占用 quota，并增加 Watch 轴 ErrCompacted 的风险。分集群后，核心资源的 compaction 压力与 Events churn 物理隔离，且 Events etcd 可配置更激进的 retention，备份策略也可放宽。但需
Q&A
kube-apiserver 排障时，如何根据症状快速定位到具体组件？
根据机制排除树，按症状判断：401/403 全请求指向 Auth 问题；webhook 503 或写入拒绝指向 Admission；APF 队列积压或 429 指向流控；etcd_request_duration_seconds 升高指向 etcd 侧；410 Gone 或 Watch 断流且 etcd 健康指向 cacher bookmark 落后；storage.Interface 报错但 etcd 健康指向 codec/encrypt/prefix 问题。若两层均无明显信号，则需联查 apiserver 和 etcd 日志。
Kine 作为 etcd 兼容层，在 Watch 语义上与 etcd 有哪些差异？
Kine 将 Watch 映射到 SQL 轮询或变更事件，与 etcd 的 revision-ordered append-only log 不同。差异包括：从历史 revision 追赶时，etcd 持久有序，Kine 依赖 SQL 实现且历史窗口可能有限；ErrCompacted 语义在 etcd 明确，Kine 可能 silent drop；Watch 背压方面，etcd 有 gRPC flow control，Kine 是 SQL 轮询间隔；Jepsen 覆盖上，etcd 有多轮测试，Kine 无等同覆盖。
为什么建议将 Kubernetes Events 分集群存储？
Events 写入频率高、TTL 短，与核心资源共用 etcd 会加速 MVCC revision 增长、提高 compaction 频率、占用 quota，并增加 Watch 轴 ErrCompacted 风险。通过 --etcd-servers-overrides 将 Events 路由到独立 etcd 集群，可物理隔离 churn，保护核心资源。
kube-apiserver 排障中，哪些场景属于“甜区”（apiserver 五轴内）？
甜区包括：Admission webhook 超时、APF FlowSchema 配置不当、cacher 未命中引发 List 穿透、consistent list 风暴、Auth 配置变更后 401、audit webhook failurePolicy Block 阻塞写入。这些场景根因在 apiserver 五轴内。
kube-apiserver 排障中，哪些场景属于“苦区”（混因高风险）？
苦区指 etcd 写慢导致 apiserver 请求挂起，进而 APF seats 耗尽，后续请求 504。此时 etcd 轴 1–2 与 apiserver 轴 5 同时亮，需按时间戳对齐两套日志，判定哪层先劣化。
文章提出了哪三个开放问题？
三个开放问题：1. watch cache SLO 与 compaction 联合模型，即 cacher 命中率与 etcd compaction retention 的定量关系；2. 线性读期望，即通过 apiserver 读与直连 etcd ReadIndex 的一致性级别差异；3. Lease + fencing 全链路 formal spec，即 Node Lease 从 apiserver 到 etcd 再到驱逐的完整形式化规范。
对于 Kine 作为存储后端，文章给出的选型建议是什么？
文章建议：K3s/边缘/单节点开发场景，Kine + SQLite 是合理权衡；生产多节点 Kubernetes 仍以 etcd 原生栈为主，因为 Kine 的 Watch 语义差在大规模 informer 负载下风险未被系统性测试。文章不给出“可用”或“不可用”的绝对结论。
文章对 kube-apiserver 排障的最终立场是什么？
文章强调失败可命名：401（AuthN）、403（AuthZ）、503/timeout（Admission webhook）、504/429（APF）、410 Gone（cacher bookmark）、etcd request failed（Storage 轴）。选型若离开这些名字，讨论会退回“apiserver 是 etcd 的代理”。
