本文发布已超过一年。较早的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已发生变化。
Kubernetes 1.3 性能和可伸缩性更新 -- 支持 2,000 节点和 60,000 Pod 集群
我们很荣幸地宣布，随着 1.3 版本的发布，Kubernetes 现在支持 2000 节点集群，并且端到端 Pod 启动时间进一步优化。我们的 API 调用延迟在我们的 1 秒 服务水平目标 (SLO) 内，其中大部分甚至比这还要好一个数量级。可以运行比 2,000 节点集群更大的部署，但性能可能会下降，并且可能无法满足我们严格的 SLO。
在这篇博文中，我们讨论了 Kubernetes 1.3 的详细性能结果以及我们从 1.2 版本开始为实现这些结果所做的更改。我们还介绍了 Kubemark，这款我们集成到持续测试框架中的性能测试工具，用于检测性能和可伸缩性退化。
评估方法
我们在 之前的博文 中描述了我们的测试场景。自 1.2 版本发布以来的最大变化是，在我们的 API 响应性测试中，我们现在创建并使用了多个命名空间。特别是对于 2000 节点/60000 Pod 集群测试，我们创建了 8 个命名空间。之所以做出此更改，是因为我们认为如此大型集群的用户很可能会使用许多命名空间，至少集群中总共会有 8 个。
Kubernetes 1.3 的指标
那么，Kubernetes 1.3 版本的性能如何？下图显示了 2000 节点和 1000 节点集群的端到端 Pod 启动延迟。为了进行比较，我们展示了 Kubernetes 1.2 在 1000 节点集群下的相同指标。
我们是如何实现这些改进的？
我们为 Kubernetes 1.3 中的可伸缩性所做的最大改变是向 API 添加了一种高效的基于 Protocol Buffer 的序列化格式，作为 JSON 的替代方案。它主要用于 Kubernetes 控制平面组件之间的通信，但所有 API 服务器客户端都可以使用这种格式。现在所有 Kubernetes 控制平面组件都使用它进行通信，但系统仍然支持 JSON 以保持向后兼容性。
我们尚未将 etcd 中存储集群状态的格式更改为 Protocol Buffers，因为我们仍在开发升级机制。但我们已经非常接近完成，预计将在 Kubernetes 1.4 中将存储格式切换到 Protocol Buffers。我们的实验表明，这应该能将 Pod 端到端启动延迟再减少 30%。
我们如何大规模测试 Kubernetes？
启动 2000 节点的集群既昂贵又耗时。虽然每个版本至少需要这样做一次来收集真实世界的性能和可伸缩性数据，但我们还需要一种更轻量级的机制，使我们能够快速评估不同性能改进的想法，并可以持续运行以检测性能退化。为了满足这一需求，我们创建了一个名为“Kubemark”的工具。
什么是“Kubemark”？
Kubemark 是一款性能测试工具，允许用户在模拟集群上运行实验。我们用它来测量大型集群的性能。
Kubemark 集群由两部分组成：运行正常主控组件的真实主节点，以及一组“空心（hollow）”节点。“空心”前缀意味着组件的实现/实例化中，某些“活动部件”被模拟（mock）掉了。最好的例子是 hollow-kubelet，它假装是一个普通的 Kubelet，但不启动任何容器或挂载任何卷。它只是声称它做了这些，因此从主控组件的角度来看，它的行为就像一个真实的 Kubelet。
由于我们希望 Kubemark 集群尽可能接近真实集群，因此我们使用了真实的 Kubelet 代码并注入了一个假的 Docker 客户端。类似地，hollow-proxy（相当于 KubeProxy）重用了真实的 KubeProxy 代码，并注入了一个无操作的 Proxier 接口（以避免修改 iptables）。
由于这些变化
- 许多空心节点可以在一台机器上运行，因为它们没有修改运行环境
- 由于没有真实的容器运行，也不需要容器运行时（例如 Docker），我们可以在一台 1 核机器上运行多达 14 个空心节点。
- 然而，空心节点在 API 服务器上产生的负载与其“完整”对应节点大致相同，因此它们为性能测试提供了真实的负载 [唯一的根本区别在于，我们没有模拟现实中可能发生的任何错误（例如，容器故障）——将来为此框架添加支持是一个潜在的扩展方向]
我们如何设置 Kubemark 集群？
为了创建 Kubemark 集群，我们利用了 Kubernetes 本身提供的能力——我们在 Kubernetes 上运行 Kubemark 集群。让我们详细描述一下。
为了创建一个 N 节点的 Kubemark 集群，我们
- 创建一个普通的 Kubernetes 集群，我们可以在其上运行 N 个空心节点 [例如，要创建 2000 节点的 Kubemark 集群，我们创建一个包含 22 个 8 核节点的普通 Kubernetes 集群]
- 创建一个专用虚拟机，我们在其上启动 Kubemark 集群的所有主控组件（etcd、apiserver、controllers、scheduler 等）。
- 在基础 Kubernetes 集群上调度 N 个“空心节点”Pod。这些空心节点配置为与运行在专用虚拟机上的 Kubemark API 服务器通信
- 最后，我们通过在基础集群上调度 addon Pod（目前只有 Heapster）并将其配置为与 Kubemark API 服务器通信来创建 addon Pod。完成后，您就拥有了一个可用的 Kubemark 集群，可以在其上运行您的（性能）测试。我们有在 Google Compute Engine (GCE) 上完成所有这些操作的脚本。欲了解更多详细信息，请参阅我们的指南。
这里值得一提的是，在运行 Kubemark 的同时，我们也在底层测试 Kubernetes 的正确性。显然，如果其下的基础 Kubernetes 集群无法正常工作，您的 Kubemark 集群也无法正常工作。
真实集群与 Kubemark 中测量的性能
至关重要的是，Kubemark 集群的性能与真实集群的性能大体相似。对于 Pod 端到端启动延迟，如下图所示，差异可以忽略不计
对于 API 响应性，差异更大一些，但通常小于 2 倍。然而，趋势是完全相同的：真实集群中的改进/退化在 Kubemark 的指标中表现为相似的百分比下降/增加。
我们不断改进 Kubernetes 的性能和可伸缩性。在这篇博文中，我们
展示了 1.3 版本可以扩展到 2000 个节点，同时满足我们的响应性 SLO
解释了我们为改进 1.2 版本以来的可伸缩性所做的主要更改，以及
描述了 Kubemark，我们的仿真框架，它允许我们快速评估代码更改对性能的影响，无论是在实验性能改进想法时，还是作为持续测试基础设施的一部分来检测退化。
请加入我们的社区，帮助我们构建 Kubernetes 的未来！如果您对可伸缩性特别感兴趣，可以通过以下方式参与：
- 在我们的 Slack 频道与我们交流
- 加入可伸缩性特别兴趣小组 (SIG)，该小组每周四太平洋时间上午 9 点在此 SIG-Scale Hangout 会面
欲了解更多关于 Kubernetes 项目的信息，请访问 kubernetes.io 并在 Twitter @Kubernetesio 上关注我们。