这篇文章已经一年多了，较旧的文章可能包含过时的内容。请检查从发表以来，页面中的信息是否变得不正确。
Kubernetes v1.31：通过基于缓存的一致性读加速集群性能
Kubernetes 以其强大的容器化应用编排能力而闻名，但随着集群规模扩大，对控制平面的需求可能成为性能瓶颈。其中一个主要挑战是确保从etcd 数据存储进行强一致性读，这通常需要资源密集型仲裁读取操作。
今天，Kubernetes 社区很高兴地宣布一个重大改进：基于缓存的一致性读，已在 Kubernetes v1.31 中晋升至 Beta 阶段。
为什么一致性读如此重要
一致性读是确保 Kubernetes 组件准确了解最新集群状态的关键。保证一致性读对于保持 Kubernetes 操作准确性和可靠性至关重要，使组件能够根据最新信息做出明智决策。在大型集群中，数据的获取和处理往往会成为性能瓶颈，特别是那些需要过滤结果的请求。
虽然 Kubernetes 可以直接在 etcd 中按命名空间过滤数据，但如果按标签或字段选择器过滤，则需要从 etcd 获取整个数据集，然后由 Kubernetes API 服务器在内存中执行过滤操作。这对 Kubelet 等组件的影响尤为显著，因为 Kubelet 现在仅需列出调度到其节点的 Pod，而之前却需要 API 服务器和 etcd 处理集群中所有的 Pod。
突破：自信地缓存
Kubernetes 长期以来一直使用监视缓存来优化读取操作。监视缓存保存集群状态的快照，并通过对 etcd 的监视获取更新。然而，直到现在,它无法直接支持一致性读，因为没有机制保证缓存是最新的。
基于缓存的一致性读 特性通过使用 etcd 的进度通知 机制来解决这一问题。这些通知会向监视缓存说明其数据与 etcd 相比的新旧状态。当发出一致性读请求时，系统会首先检查监视缓存是否为最新状态。
如果缓存未更新到最新状态，系统会通过查询 etcd 的进度通知，直到确认缓存已经足够新。一旦缓存就绪，读取操作就可以直接从缓存中高效地获取数据，这可以显著提升性能，尤其是在需要从 etcd 获取大量数据的场景下。这种方式支持通过缓存处理数据过滤请求，仅需从 etcd 读取少量的元数据。
重要提示： 要享受此特性带来的好处，你的 Kubernetes 集群需运行etcd 版本 3.4.31+ 或 3.5.13+。对于较早版本的 Etcd，Kubernetes将自动回退为直接从 etcd 提供一致性读。
你将注意到的性能提升
这个看似简单的改动，对 Kubernetes 的性能和可扩展性有着深远影响:
- 降低 etcd 负载： Kubernetes v1.31 可以将部分工作从 etcd 分载出去，为其他关键操作释放资源。
- 更低的延迟： 从缓存读取数据的速度显著快于从 etcd 获取并处理数据。这使组件的响应速度更快，提升了集群整体的响应能力。
- 增强的可扩展性： 拥有数千个节点和 Pod 的大型集群将获得最显著的性能增益，因为 etcd 负载的降低使得控制平面可以在不牺牲性能的情况下处理更多请求。
5 千节点扩缩容测试结果： 在最近针对 5,000 节点集群的扩缩容测试中，启用基于缓存的一致性读带来了显著提升：
- kube-apiserver CPU 使用率降低 30%
- etcd CPU 使用率降低 25%
- 第 99 百分位的 Pod 列表请求延迟出现了高至 3 倍的减少（从 5 秒降至 1.5 秒）
下一步是什么？
随着基于缓存的一致性读特性晋升至 Beta 版，该特性已默认启用，为所有使用受支持 etcd版本的 Kubernetes 用户提供了无缝的性能提升。
我们的探索并未止步于此。Kubernetes 社区正积极研究在监视缓存中加入分页支持，未来有望带来更多性能优化。
开始使用
升级到 Kubernetes v1.31 并确保使用 etcd 版本 3.4.31+ 或 3.5.13+，是体验基于缓存的一致性读优势的最简单方法。如果有任何问题或反馈，不要犹豫，随时联系 Kubernetes 社区。
请让我们知道基于缓存的一致性读如何改善了你的 Kubernetes 体验！
特别感谢 @ah8ad3 和 @p0lyn0mial 对这一特性做出的贡献！