评估 Kubernetes 性能和可扩展性,使用自动化流水线

自动化流水线和工具使 Kubernetes 用户能够测试集群的可扩展性和性能。
231 位读者喜欢这个。
Performance made easy with Linux containers

CC0 公共领域

Kubernetes 是一个开源的容器编排系统,用于自动化容器化应用程序的部署、扩展和管理。如果您尝试过它或 OpenShift(它是 Kubernetes 的企业就绪生产版本),您可能已经想到以下问题

  • OpenShift 是否支持大规模运行应用程序?

  • 集群限制是什么?

  • 我们如何调整集群以获得最佳性能?

  • 运行和维护大型和/或密集集群的挑战是什么?

红帽的性能和可扩展性团队创建了一个自动化流水线和工具,以帮助回答这些问题以及其他问题。

基础设施

这是大规模测试任何产品的关键要素之一。我们的规模实验室包括 350 多台机器和 8,000 多个内核,使我们能够在产品的上限进行测试。即使我们的实验室已经有很多资源,我们每年仍在不断增加机器。所有资源都是共享的,并且按需提供。

集群可用性

我们通常为每个 OpenShift 版本安装(至少)一个 2,000 节点的集群。这支持了我们流水线中的集群限制测试,并使我们能够推动可扩展性以找到新的限制。

我们持续维护一个 250 节点的集群,以解决客户问题、为新的上游功能设计新测试以及进行研发。

自动化流水线和工具

Kubernetes scalability testing pipeline

我们的流水线分阶段运行;每个阶段都是一个独立的 Jenkins 作业,所有阶段都由流水线控制器连接在一起。流水线中的组件包括

  • Jenkinsfile: 加载分阶段的流水线构建脚本

  • Jenkins Job Builder (JJB) 模板: Jenkins 作业的 YAML 定义

  • Watcher: 查找新的 JJB 模板或现有模板的更新,并在 Jenkins 中创建/更新作业

  • 流水线控制器: 将所有作业连接在一起,包括集群安装/配置和运行各种性能和规模测试

  • 属性文件: 作业参数的占位符

  • 构建脚本: 读取属性文件,并使用参数调用流水线中负责的作业

流水线作业

给定一个包含在流水线中构建作业所需参数的属性文件,流水线控制器将运行以下作业

镜像供应器

镜像供应器作业监视新的 OpenShift 代码位,并使用我们的工具以及各种软件包、配置和容器镜像构建 Amazon 机器镜像 (AMI) 和 qcow 镜像。这减少了安装程序构建 OpenShift 集群所需的时间,因为它无需通过网络获取软件包或镜像。

镜像验证器

一旦镜像准备就绪,镜像验证器将通过安装一个一体化节点 OpenShift 集群来检查镜像是否有效。这用作 OpenShift 集群的基础镜像。

OpenStack

此作业在硬件上安装 OpenStack。OpenStack 为扩展 OpenShift 集群到更高的节点计数提供了虚拟化平台。通过使用虚拟机,我们可以节省实验室资源,并在较小的硬件占用空间上运行大规模测试。

OpenShift

此作业在 OpenStack 之上安装 OpenShift。它构建了我们称之为核心集群的集群:一个最小化的集群,包含三个 Master/etcd 节点、三个 Infra 节点、三个 Storage 节点和两个 Application/Worker 节点。我们确保核心节点不会落在同一个虚拟机监控程序上,以使集群成为真正的高可用性 (HA),并使性能和规模测试结果有效。我们为大多数核心节点使用 NVMe 直通,因为在 Master 节点上运行的 etcd、在 Infra 节点上运行的 Elasticsearch 以及在 Storage 节点上运行的 Red Hat OpenShift Container Storage 需要高吞吐量和低延迟才能获得更好的性能。

一致性

此作业运行 Kubernetes 端到端测试,以检查集群的健全性。

扩容

一旦从一致性作业获得绿色信号,此作业会将集群扩展到所需的节点计数。我们不让 OpenShift 作业一次性创建 2,000 节点的集群,以防我们在运行端到端测试后发现功能问题;这将需要我们拆除整个集群并重新构建它——这比拆除一个 11 节点的集群要耗时得多。OpenShift 安装程序是基于 Ansible 的,因此建议适当设置 fork 数量,以使扩容过程更快,因为它并行运行任务。

性能和规模测试

我们设计了测试来查看控制平面、kubelet、网络、HAProxy 和存储的性能。流水线包括许多测试,以验证和推动更高的集群限制。我们每个 sprint 使用最新的 OpenShift 版本运行一次流水线,并查看性能回归。

流水线的目的

我们构建此流水线是为了使红帽的各个团队能够大规模测试应用程序工作负载。使用我们的自动化流水线和工具的优势包括

  • 无需拥有大型基础设施

  • 使团队能够重用我们的工具来分析 OpenShift 的性能和可扩展性,而不是花费资源开发新工具

  • 避免需要构建和维护具有最新和最出色版本的 OpenShift 大型集群

如何将工作负载加入流水线

我们将所有作业模板和脚本存储在公共 GitHub 仓库中,添加新的工作负载就像提交包含正确模板的拉取请求一样简单。Watcher 组件负责创建作业并将其添加到流水线;然后我们连同流水线的测试阶段一起测试工作负载。用户可以期望在 sprint 完成后收到测试结果,之后我们将使用新的 OpenShift 版本刷新集群。


Sebastian Jug 和 Naga Ravi Chaitanya Elluri 在西雅图 12 月 10 日至 13 日举行的 KubeCon + CloudNativeCon North America 大会上介绍了 自动化 Kubernetes 可扩展性测试

User profile image.
Naga Ravi Chaitanya Elluri 是红帽公司的软件工程师,致力于 OpenShift 可扩展性、自动化和工具。他还参与维护和推动 OpenShift 的集群限制。他的兴趣在于云计算领域,并为各种开源项目做出了贡献。
User profile image.
Sebastian Jug 是红帽公司的软件工程师,致力于 OpenShift 和容器运行时性能。作为 SIG-Scale 的成员,他创建工具(集群加载器)并实现大规模性能测试。作为“互联网”的守护者、master 分支的居民和 FOSS 爱好者,他致力于优化从硬件层到堆栈顶部的性能。

评论已关闭。

© . All rights reserved.