本文发表时间已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

Kubernetes 1.6 中的可扩展性更新：5,000 个节点和 150,000 个 pod 集群

作者：Wojciech Tyczynski (Google) |

编者注：这篇文章是关于 Kubernetes 1.6 新功能的一系列深入文章的一部分

去年夏天，我们分享了关于 Kubernetes 可扩展性的更新。此后，我们一直在努力工作，并且很自豪地宣布Kubernetes 1.6可以处理具有多达 150,000 个 pod 的 5,000 节点集群。此外，这些集群的端到端 pod 启动时间甚至比 1.3 版本中之前的 2,000 节点集群更好；并且 API 调用的延迟在 1 秒 SLO 内。

在这篇博客文章中，我们将回顾我们在测试中监控的指标，并描述 Kubernetes 1.6 的性能结果。我们还将讨论我们为实现改进所做的更改，以及我们在系统可扩展性方面即将发布的版本的计划。

X 节点集群 - 它是什么意思？

现在 Kubernetes 1.6 已发布，是时候回顾一下当我们说我们“支持” X 节点集群时意味着什么了。正如之前的博客文章中详细描述的那样，我们目前有两个与性能相关的服务级别目标 (SLO)

  • API 响应速度：99% 的 API 调用在 1 秒内返回
  • Pod 启动时间：99% 的 pod 及其容器（带有预先拉取的镜像）在 5 秒内启动。和以前一样，可以运行比声明支持的 5,000 节点集群更大的部署（用户已经这样做了），但性能可能会下降，并且可能不符合我们上面定义的严格 SLO。

我们知道这些 SLO 的范围有限。它们没有涵盖系统的许多方面。例如，我们不衡量在 pod 启动后，属于服务的新的 pod 将通过服务 IP 地址可访问的速度。如果您正在考虑使用大型 Kubernetes 集群并且有我们的 SLO 未涵盖的性能要求，请联系 Kubernetes Scalability SIG，以便我们帮助您了解 Kubernetes 是否已准备好立即处理您的工作负载。

即将发布的 Kubernetes 版本的与可扩展性相关的首要优先级是通过以下方式增强我们对支持 X 节点集群的定义的

  • 改进当前现有的 SLO
  • 添加更多 SLO（这将涵盖 Kubernetes 的各个领域，包括网络）

大规模 Kubernetes 1.6 性能指标

那么，Kubernetes 1.6 中大型集群的性能如何呢？下图显示了 2000 节点和 5000 节点集群的端到端 pod 启动延迟。为了进行比较，我们还显示了 Kubernetes 1.3 的相同指标，我们在之前的可扩展性博客文章中发布了该指标，该文章描述了对 2000 节点集群的支持。正如你所看到的，与 Kubernetes 1.3 的 2000 个节点相比，Kubernetes 1.6 在 2000 个和 5000 个节点上都具有更好的 pod 启动延迟 [1]。

下一个图表显示了 5000 节点 Kubernetes 1.6 集群的 API 响应延迟。所有百分位数的延迟均小于 500 毫秒，即使是第 90 个百分位数也小于约 100 毫秒。

我们是如何走到这一步的？

在过去的九个月（自从上一篇可扩展性博客文章发布以来），Kubernetes 中发生了大量与性能和可扩展性相关的更改。在这篇文章中，我们将重点介绍其中两个最大的更改，并简要列举一些其他更改。

etcd v3
在 Kubernetes 1.6 中，我们将默认存储后端（存储整个集群状态的键值存储）从 etcd v2 切换到 etcd v3。在 1.3 发布周期中，已经开始了向这种转换的初步工作。你可能会想知道为什么我们花了这么长时间，考虑到

  • 第一个支持 v3 API 的 etcd 稳定版本于 2016 年 6 月 30 日宣布

  • 新 API 是与 Kubernetes 团队共同设计的，以支持我们的需求（从功能和可扩展性角度来看）

  • 当宣布 etcd v3 时，etcd v3 与 Kubernetes 的集成已经基本完成（实际上，CoreOS 将 Kubernetes 用作新 etcd v3 API 的概念验证）事实证明，有很多原因。我们将在下面描述最重要的原因。

  • 像 etcd v2 到 v3 迁移一样，以向后不兼容的方式更改存储是一项重大更改，因此我们需要一个强有力的理由。我们在 9 月份找到了这个理由，当时我们确定如果我们继续使用 etcd v2，我们将无法扩展到 5000 节点集群（kubernetes/32361包含一些关于它的讨论）。特别是，etcd v2 中的 watch 实现无法扩展。在 5000 节点集群中，我们需要能够每秒至少向单个 watcher 发送 500 个 watch 事件，这在 etcd v2 中是不可能的。

  • 一旦我们有了实际更新到 etcd v3 的强烈动机，我们就开始彻底测试它。正如你可能预料的那样，我们发现了一些问题。Kubernetes 中存在一些小错误，此外，我们还要求改进 etcd v3 的 watch 实现的性能（对于我们来说，watch 是 etcd v2 中的主要瓶颈）。这导致了 3.0.10 etcd 补丁版本的发布。

  • 一旦这些更改完成，我们确信新的 Kubernetes 集群将与 etcd v3 一起工作。但是，迁移现有集群的巨大挑战仍然存在。为此，我们需要自动化迁移过程，彻底测试底层 CoreOS etcd 升级工具，并制定从 v3 回滚到 v2 的应急计划。但最后，我们相信它应该有效。

将存储数据格式切换为 protobuf
在 Kubernetes 1.3 版本中，我们启用了 protobufs 作为 Kubernetes 组件与 API 服务器通信的数据格式（除了保持对 JSON 的支持）。这给我们带来了巨大的性能提升。

但是，我们仍然使用 JSON 作为数据存储在 etcd 中的格式，即使从技术上讲我们已经准备好进行更改。延迟此迁移的原因与我们迁移到 etcd v3 的计划有关。现在你可能想知道此更改如何依赖于迁移到 etcd v3。原因是，使用 etcd v2 我们无法真正以二进制格式存储数据（为了解决这个问题，我们还对数据进行了 base64 编码），而使用 etcd v3 它就可以工作了。因此，为了简化向 etcd v3 的过渡并避免在其中对存储在 etcd 中的数据进行一些非平凡的转换，我们决定等到迁移到 etcd v3 存储后端完成后再将存储数据格式切换到 protobufs。

其他优化
在过去的三个版本中，我们在整个 Kubernetes 代码库中进行了数十项优化，包括

  • 优化调度器（这导致调度吞吐量提高了 5-10 倍）
  • 将所有控制器切换到使用共享 informers 的新的推荐设计，这减少了 controller-manager 的资源消耗 - 有关参考，请参阅 此文档
  • 优化 API 服务器中的各个操作（转换、深度复制、补丁）
  • 减少 API 服务器中的内存分配（这会显著影响 API 调用的延迟） 我们想强调的是，我们在过去几个版本中，以及实际上在整个项目的历史中所做的优化工作，是整个 Kubernetes 社区中许多不同公司和个人的共同努力。

下一步是什么？

人们经常问我们将在改进 Kubernetes 可扩展性方面走多远。目前，我们没有计划在未来几个版本中将可扩展性提高到 5000 节点集群以上（在我们的 SLO 内）。如果您需要大于 5000 个节点的集群，我们建议使用联邦来聚合多个 Kubernetes 集群。

但是，这并不意味着我们将停止研究可扩展性和性能。正如我们在本文开头提到的，我们的首要任务是改进我们现有的两个 SLO 并引入新的 SLO，这将涵盖系统的更多部分，例如网络。这项工作已经在 Scalability SIG 中开始。我们在如何定义性能 SLO 方面取得了重大进展，这项工作应该会在下个月完成。

加入努力
如果您对可扩展性和性能感兴趣，请加入我们的社区并帮助我们塑造 Kubernetes。有很多参与方式，包括

  • 在 Kubernetes Slack 可扩展性频道中与我们聊天：
  • 加入我们的特别兴趣小组 SIG-Scalability，该小组每周四太平洋标准时间上午 9:00 开会。感谢您的支持和贡献！在此处阅读有关 Kubernetes 1.6 新功能的更多深入文章 here。

[1] 我们正在调查为什么 5000 节点集群的启动时间比 2000 节点集群更好。目前的理论是它与使用 64 核主机的 5000 节点实验和使用 32 核主机的 2000 节点实验有关。