本文已超过一年。较旧的文章可能包含过时的内容。请检查页面上的信息自发布以来是否已变得不正确。
Kubernetes 1.3 中性能和可扩展性的更新 - 2,000 个节点 60,000 个 Pod 集群
我们很自豪地宣布，随着 1.3 版本的发布，Kubernetes 现在支持 2000 节点集群，并且端到端 pod 启动时间甚至更好。我们的 API 调用的延迟在我们的一秒 服务级别目标 (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 集群由两部分组成：一个运行正常主组件的真实主节点和一组“空心”节点。“空心”前缀表示组件的实现/实例化，其中某些“运动部件”被模拟出来。最好的例子是空心 kubelet，它假装是普通的 Kubelet，但不会启动任何容器或挂载任何卷。它只是声称它做了，所以从主组件的角度来看，它的行为就像一个真正的 Kubelet。
由于我们希望 Kubemark 集群尽可能类似于真实集群，因此我们使用真实 Kubelet 代码并注入一个假的 Docker 客户端。同样，空心代理（KubeProxy 等效项）重用真实 KubeProxy 代码，并注入 no-op Proxier 接口（以避免修改 iptables）。
由于这些更改
- 许多空心节点可以在一台机器上运行，因为它们不会修改它们运行的环境
- 在没有实际容器运行和容器运行时（例如 Docker）的需求的情况下，我们可以在 1 核机器上运行多达 14 个空心节点。
- 但是，空心节点在 API 服务器上生成的负载与它们的“完整”副本大致相同，因此它们为性能测试提供了真实的负载 [唯一的根本区别是，我们没有模拟实际中可能发生的任何错误（例如，容器失败） - 添加对此的支持是该框架未来的一种潜在扩展]
我们如何设置 Kubemark 集群？
为了创建一个 Kubemark 集群，我们使用 Kubernetes 本身赋予我们的力量 - 我们在 Kubernetes 上运行 Kubemark 集群。让我们详细描述一下。
为了创建一个 N 节点 Kubemark 集群，我们
- 创建一个常规的 Kubernetes 集群，我们可以在其中运行 N 个空心节点 [例如，要创建一个 2000 节点的 Kubemark 集群，我们创建一个具有 22 个 8 核节点的常规 Kubernetes 集群]
- 创建一个专用 VM，我们在其中启动 Kubemark 集群的所有主组件（etcd、apiserver、控制器、调度程序等）。
- 在基础 Kubernetes 集群上调度 N 个“空心节点”pod。这些空心节点配置为与专用 VM 上运行的 Kubemark API 服务器通信
- 最后，我们通过在基础集群上调度并配置它们与 Kubemark API 服务器通信来创建附加 pod（目前仅为 Heapster）。完成此操作后，您将拥有一个可用的 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 频道上与我们聊天
- 加入可扩展性特别兴趣小组，该小组每周四太平洋时间上午 9 点在此 SIG-Scale Hangout 上举行会议
有关 Kubernetes 项目的更多信息，请访问 kubernetes.io 并在 Twitter 上关注我们 @Kubernetesio。