将 Kubernetes 扩展到超越 4k 个节点和 200k个Pod
发布时间：2022-03-04 20:09:43 所属栏目：大数据 来源：互联网
导读：在 PayPal，我们最近开始试水 Kubernetes。我们大部分的工作负载都运行在 Apache Mesos 上，而作为迁移的一部分，我们需要从性能方面了解下运行 Kubernetes 集群以及 PayPal 特有的控制平面。其中最主要的是了解平台的可扩展性，以及通过调整集群找出可以改
|
在 PayPal，我们最近开始试水 Kubernetes。我们大部分的工作负载都运行在 Apache Mesos 上，而作为迁移的一部分，我们需要从性能方面了解下运行 Kubernetes 集群以及 PayPal 特有的控制平面。其中最主要的是了解平台的可扩展性，以及通过调整集群找出可以改进的地方。 在 PayPal，我们最近开始试水 Kubernetes。我们大部分的工作负载都运行在 Apache Mesos 上，而作为迁移的一部分，我们需要从性能方面了解下运行 Kubernetes 集群以及 PayPal 特有的控制平面。其中最主要的是了解平台的可扩展性，以及通过调整集群找出可以改进的地方。 与 Apache Mesos 不同的是，前者无需任何修改即可扩展到 10,000 个节点，而扩展 Kubernetes 则非常具有挑战性。Kubernetes 的可扩展性不仅仅体现在节点和 Pod 的数量上，还有其他多个方面，如创建的资源数量、每个 Pod 的容器数量、服务总数和 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://:443/api/v1/namespaces/kbench-deployment-namespace-13/Pods.. I0504 17:55:15.749891 1 request.go:655] Throttling request took 13.522138087s, request: POST:https://:443/api/v1/namespaces/kbench-deployment-namespace-13/Pods.. I0504 17:55:25.759662 1 request.go:655] Throttling request took 19.202229311s, request: POST:https://:443/api/v1/namespaces/kbench-deployment-namespace-20/Pods.. I0504 17:55:35.760088 1 request.go:655] Throttling request took 25.409325008s, request: POST:https://:443/api/v1/namespaces/kbench-deployment-namespace-13/Pods.. I0504 17:55:45.769922 1 request.go:655] Throttling request took 31.613720059s, request: POST:https://:443/api/v1/namespaces/kbench-deployment-namespace-6/Pods.. API 服务器上限制速率的队列的大小是通过 max-mutating-requests-inflight 和 max-requests-inflight 更新的。1.20 版本中引入的优先级和公平性特性测试版，就是在 API 服务器上这两个标记的控制下将队列的总大小在不同的队列类别之间进行划分。例如，群首选举请求的优先级比 Pod 请求高。在每个优先级中，都有可配置队列的公平性。未来还可以通过 PriorityLevelConfiguration&FlowSchema API 对象做进一步调优。 控制器管理器 控制器管理器负责为副本集、命名空间等本地资源以及数量众多的部署（由副本集管理）提供控制器。控制器管理器与 API 服务器同步其状态的速度是有限的。有多个调节器用于调整这一行为： kube-api-qps—— 控制器管理器在一秒钟内可以向 API 服务器进行查询的次数。 kube-api-burst—— 控制器管理器突发流量峰值，是kube-api-qps之上另一个并发调用数。 concurrent-deployment-syncs—— 部署、复制集等对象同步调用的并发性。 调度器 当作为一个独立的组件单独测试时，调度器可以支持每秒 1000 个 Pod 的高吞吐率。然而，在将调度器部署到一个在线集群中时，我们注意到，实际的吞吐量有所降低。etcd 实例速度慢导致调度器的绑定延迟增加，使得待处理队列的大小增加到数千个 Pod 的程度。我们的想法是在测试运行期间将这个数值保持在 100 以下，因为数量比较大的话会影响 Pod 的启动延迟。此外，我们最后还调整了群首选举参数，以应对短暂的网络分区或网络拥堵引发的虚假重启。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
