Kubernetes 4000 节点运维经验分享

在 PayPal，我们最近开始试水 Kubernetes。我们大部分的工作负载都运行在 Apache Mesos 上，而作为迁移的一部分，我们需要从性能方面了解下运行 Kubernetes 集群以及 PayPal 特有的控制平面。其中最主要的是了解平台的可扩展性，以及通过调整集群找出可以改进的地方。

与 Apache Mesos 不同的是，前者无需任何修改即可扩展到 10,000 个节点，而扩展 Kubernetes 则非常具有挑战性。Kubernetes 的可扩展性不仅仅体现在节点和 Pod 的数量上，还有其他多个方面，如创建的资源数量、每个 Pod 的容器数量、服务总数和 Pod 部署的吞吐量。本文描述了我们在扩展过程中遇到的一些挑战，以及我们如何解决这些问题。

集群拓扑

我们的生产环境中有各种不同规模的集群，包含数千个节点。我们的设置包括三个主节点和一个外部的三节点 etcd 集群，所有这些都运行在谷歌云平台（GCP）上。控制平面前面有一个负载平衡器，所有数据节点都与控制平面属于相同的区域。

工作负载

为了进行性能测试，我们使用了一个开源的工作负载生成器 k-bench，并针对我们的场景做了修改。我们使用的资源对象是简单的 Pod 和部署。我们按不同的批次大小和部署间隔时间，分批次连续对它们进行部署。

扩展

开始时，Pod 和节点数量都比较少。通过压力测试，我们发现可以改进的地方，并继续扩大集群的规模，因为我们观察到性能有所改善。每个工作节点有四个 CPU 内核，最多可容纳 40 个 Pod。我们扩展到大约 4100 个节点。用于基准测试的应用程序是一个无状态的服务，运行在 100 个服务质量（QoS）有保证的毫核（millicores ）上。

我们从 1000 个节点、2000 个 Pod 开始，接着是 16000 个 Pod，然后是 32000 个 Pod。之后，我们跃升到 4100 个节点、15 万个 Pod，接着是 20 万个 Pod。我们不得不增加每个节点的核数，以容纳更多的 Pod。

API 服务器

事实证明，API 服务器是一个瓶颈，有几个到 API 服务器的连接返回 504 网关超时，此外还有本地客户端限流（指数退避）。这些问题在扩展过程中 呈指数级 增长：

I0504 17:54:55.731559 1 request.go:655] Throttling request took 1.005397106s, request: POST:https://<>:443/api/v1/namespaces/kbench-deployment-namespace-14/Pods..
I0504 17:55:05.741655 1 request.go:655] Throttling request took 7.38390786s, request: POST:https:/