etcd improvements

---

为了解决这些问题，阿里云容器平台在各方面都做了很大的努力，改进 Kubernetes 在大规模场景下的性能。

首先是 etcd 层面，作为 Kubernetes 存储对象的数据库，其对 Kubernetes 集群的性能影响至关重要。

• 第一版本的改进，我们通过将 etcd 的数据转存到 tair 集群中，提高了 etcd 存储的数据总量。但这个方式有一个显著的弊端是额外增加的 tair 集群，增加的运维复杂性对集群中的数据安全性带来了很大的挑战，同时其数据一致性模型也并非基于 raft 复制组，牺牲了数据的安全性。

• 第二版本的改进，我们通过将 API Server 中不同类型的对象存储到不同的 etcd 集群中。从 etcd 内部看，也就对应了不同的数据目录，通过将不同目录的数据路由到不同的后端 etcd 中，从而降低了单个 etcd 集群中存储的数据总量，提高了扩展性。

• 第三版本的改进，我们深入研究了 etcd 内部的实现原理，并发现了影响 etcd 扩展性的一个关键问题在底层 bbolt db 的 page 页面分配算法上：随着 etcd 中存储的数据量的增长，bbolt db 中线性查找“连续长度为 n 的 page 存储页面”的性能显著下降。

为了解决该问题，我们设计了基于 segregrated hashmap 的空闲页面管理算法，hashmap 以连续 page 大小为 key, 连续页面起始 page id 为 value。通过查这个 segregrated hashmap 实现 O(1) 的空闲 page 查找，极大地提高了性能。在释放块时，新算法尝试和地址相邻的 page 合并，并更新 segregrated hashmap。更详细的算法分析可以见已发表在 CNCF 博客的博文：

https://www.cncf.io/blog/2019/05/09/performance-optimization-of-etcd-in-web-scale-data-scenario/

通过这个算法改进，我们可以将 etcd 的存储空间从推荐的 2GB 扩展到 100GB，极大的提高了 etcd 存储数据的规模，并且读写无显著延迟增长。除此之外，我们也和谷歌工程师协作开发了 etcd raft learner（类 zookeeper observer）/fully concurrent read 等特性，在数据的安全性和读写性能上进行增强。这些改进已贡献开源，将在社区 etcd 3.4 版本中发布。

API Server improvements

---

Efficient node heartbeats

在 Kubernetes 集群中，影响其扩展到更大规模的一个核心问题是如何有效的处理节点的心跳。在一个典型的生产环境中 (non-trival)，kubelet 每 10s 汇报一次心跳，每次心跳请求的内容达到 15kb（包含节点上数十计的镜像，和若干的卷信息），这会带来两大问题：

1. 心跳请求触发 etcd 中 node 对象的更新，在 10k nodes 的集群中，这些更新将产生近 1GB/min 的 transaction logs（etcd 会记录变更历史）；

2. API Server 很高的 CPU 消耗，node 节点非常庞大，序列化/反序列化开销很大，处理心跳请求的 CPU 开销超过 API Server CPU 时间占用的 80%。

为了解决这个问题，Kubernetes 引入了一个新的 build-in Lease API ，将与心跳密切相关的信息从 node 对象中剥离出来，也就是上图中的 Lease 。原本 kubelet 每 10s 更新一次 node 对象升级为：

1. 每 10s 更新一次 Lease 对象，表明该节点的存活状态，Node Controller 根据该 Lease 对象的状态来判断节点是否存活；

2. 处于兼容性的考虑，降低为每 60s 更新一次 node 对象，使得 Eviction_ _Manager 等可以继续按照原有的逻辑工作。

因为 Lease 对象非常小，因此其更新的代价远小于更新 node 对象。kubernetes 通过这个机制，显著的降低了 API Server 的 CPU 开销，同时也大幅减小了 etcd 中大量的 transaction logs，成功将其规模从 1000 扩展到了几千个节点的规模，该功能在社区 Kubernetes-1.14 中已经默认启用。

API Server load balancing

在生产集群中，出于性能和可用性的考虑，通常会部署多个节点组成高可用 Kubernetes 集群。但在高可用集群实际的运行中，可能会出现多个 API Server 之间的负载不均衡，尤其是在集群升级或部分节点发生故障重启的时候。这给集群的稳定性带来了很大的压力，原本计划通过高可用的方式分摊 API Server 面临的压力，但在极端情况下所有压力又回到了一个节点，导致系统响应时间变长，甚至击垮该节点继而导致雪崩。

下图为压测集群中模拟的一个 case，在三个节点的集群，API Server 升级后所有的压力均打到了其中一个 API Server 上，其 CPU 开销远高于其他两个节点。

解决负载均衡问题，一个自然的思路就是增加 load balancer。前文的描述中提到，集群中主要的负载是处理节点的心跳，那我们就在 API Server 与 kubelet 中间增加 lb，有两个典型的思路：

1. API Server 测增加 lb，所有的 kubelets 连接 lb，典型的云厂商交付的 Kubernetes 集群，就是这一模式；

2. kubelet 测增加 lb，由 lb 来选择 API Server。

通过压测环境验证发现，增加 lb 并不能很好的解决上面提到的问题，我们必须要深入理解 Kubernetes 内部的通信机制。深入到 Kubernetes 中研究发现，为了解决 tls 连接认证的开销，Kubernetes 客户端做了很多的努力确保“尽量复用同样的 tls 连接”，大多数情况下客户端 watcher 均工作在下层的同一个 tls 连接上，仅当这个连接发生异常时，才可能会触发重连继而发生 API Server 的切换。其结果就是我们看到的，当 kubelet 连接到其中一个 API Server 后，基本上是不会发生负载切换。为了解决这个问题，我们进行了三个方面的优化：

1. API Server：认为客户端是不可信的，需要保护自己不被过载的请求击溃。当自身负载超过一个阈值时，发送 409 - too many requests 提醒客户端退避；当自身负载超过一个更高的阈值时，通过关闭客户端连接拒绝请求；

2. Client：在一个时间段内频繁的收到 409 时，尝试重建连接切换 API Server；定期地重建连接切换 API Server 完成洗牌；

3. 运维层面，我们通过设置 maxSurge=3 的方式升级 API Server，避免升级过程带来的性能抖动。

如上图左下角监控图所示，增强后的版本可以做到 API Server 负载基本均衡，同时在显示重启两个节点（图中抖动）时，能够快速的自动恢复到均衡状态。

List-Watch & Cacher

List-Watch 是 Kubernetes 中 Server 与 Client 通信最核心一个机制，etcd 中所有对象及其更新的信息，API Server 内部通过 Reflector 去 watch etcd 的数据变化并存储到内存中，controller/kubelets 中的客户端也通过类似的机制去订阅数据的变化。

在 List-Watch 机制中面临的一个核心问题是，当 Client 与 Server 之间的通信断开时，如何确保重连期间的数据不丢，这在 Kubernetes 中通过了一个全局递增的版本号 resourceVersion 来实现。如下图所示 Reflector 中保存这当前已经同步到的数据版本，重连时 Reflector 告知 Server 自己当前的版本（5），Server 根据内存中记录的最近变更历史计算客户端需要的数据起始位置（7）。

这一切看起来十分简单可靠，但是…

在 API Server 内部，每个类型的对象会存储在一个叫做 storage 的对象中，比如会有:

1. Pod Storage

2. Node Storage

3. Configmap Storage

4. …

每个类型的 storage 会有一个有限的队列，存储对象最近的变更，用于支持 watcher 一定的滞后（重试等场景）。一般来说，所有类型的类型共享一个递增版本号空间（1, 2, 3, …, n)，也就是如上图所示，pod 对象的版本号仅保证递增不保证连续。Client 使用 List-Watch 机制同步数据时，可能仅关注 pods 中的一部分，最典型的 kubelet 仅关注和自己节点相关的 pods，如上图所示，某个 kubelet 仅关注绿色的 pods (2, 5）。

因为 storage 队列是有限的（FIFO），当 pods 的更新时队列，旧的变更就会从队列中淘汰。如上图所示，当队列中的更新与某个 Client 无关时，Client 进度仍然保持在 rv=5，如果 Client 在 5 被淘汰后重连，这时候 API Server 无法判断 5 与当前队列最小值（7）之间是否存在客户端需要感知的变更，因此返回 Client too old version err 触发 Client 重新 list 所有的数据。为了解决这个问题，Kubernetes 引入 Watch bookmark 机制：

bookmark 的核心思想概括起来就是在 Client 与 Server 之间保持一个“心跳”，即使队列中无 Client 需要感知的更新，Reflector 内部的版本号也需要及时的更新。如上图所示，Server 会在合适的适合推送当前最新的 rv=12 版本号给 Client，使得 Client 版本号跟上 Server 的进展。bookmark 可以将 API Server 重启时需要重新同步的事件降低为原来的 3%（性能提高了几十倍），该功能有阿里云容器平台开发，已经发布到社区 Kubernetes-1.15 版本中。

Cacher & Indexing

除 List-Watch 之外，另外一种客户端的访问模式是直接查询 API Server，如下图所示。为了保证客户端在多个 API Server 节点间读到一致的数据，API Server 会通过获取 etcd 中的数据来支持 Client 的查询请求。从性能角度看，这带来了几个问题：

1. 无法支持索引，查询节点的 pod 需要先获取集群中所有的 pod，这个开销是巨大的；

2. 因为 etcd 的 request-response 模型，单次请求查询过大的数据会消耗大量的内存，通常情况下 API Server 与 etcd 之间的查询会限制请求的数据量，并通过分页的方式来完成大量的数据查询，分页带来的多次的 round trip 显著降低了性能；

3. 为了确保一致性，API Server 查询 etcd 均采用了 Quorum read ，这个查询开销是集群级别，无法扩展的。

为了解决这个问题，我们设计了 API Server 与 etcd 的数据协同机制，确保 Client 能够通过 API Server 的 cache 获取到一致的数据，其原理如下图所示，整体工作流程如下：

1. t0 时刻 Client 查询 API Server；

2. API Server 请求 etcd 获取当前的数据版本 rv@t0；

3. API Server 请求进度的更新，并等待 Reflector 数据版本达到 rv@t0；

4. 通过 cache 响应用户的请求。

这个方式并未打破 Client 的一致性模型（感兴趣的可以自己论证一下），同时通过 cache 响应用户请求时我们可以灵活的增强查询能力，比如支持 namespace nodename/labels 索引。该增强大幅提高了 API Server 的读请求处理能力，在万台规模集群中典型的 describe node 的时间从原来的 5s 降低到 0.3s（触发了 node name 索引），其他如 get nodes 等查询操作的效率也获得了成倍的增长。

Controller failover

---

在 10k node 的生产集群中，Controller 中存储着近百万的对象，从 API Server 获取这些对象并反序列化的开销是无法忽略的，重启 Controller 恢复时可能需要花费几分钟才能完成这项工作，这对于阿里巴巴规模的企业来说是不可接受的。为了减小组件升级对系统可用性的影响，我们需要尽量的减小 controller 单次升级对系统的中断时间，这里通过如下图所示的方案来解决这个问题：

1. 预启动备 controller informer ，提前加载 controller 需要的数据；

2. 主 controller 升级时，会主动释放 Leader Lease，触发备立即接管工作。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

文末

我将这三次阿里面试的题目全部分专题整理出来，并附带上详细的答案解析，生成了一份PDF文档

• 第一个要分享给大家的就是算法和数据结构

• 第二个就是数据库的高频知识点与性能优化

• 第三个则是并发编程（72个知识点学习）

• 最后一个是各大JAVA架构专题的面试点+解析+我的一些学习的书籍资料

还有更多的Redis、MySQL、JVM、Kafka、微服务、Spring全家桶等学习笔记这里就不一一列举出来

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
R2otnK-1713679483508)]

• 最后一个是各大JAVA架构专题的面试点+解析+我的一些学习的书籍资料

[外链图片转存中…(img-MYLakFma-1713679483508)]

还有更多的Redis、MySQL、JVM、Kafka、微服务、Spring全家桶等学习笔记这里就不一一列举出来

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！