Kubernetes性能测试实践

本文由  网易云 发布。

 

概述

随着容器技术的发展，容器服务已经成为行业主流，然而想要在生产环境中成功部署和操做容器，关键仍是容器编排技术。市场上有各类各样的容器编排工具，如Docker原生的Swarm、Mesos、Kubernetes等，其中Google开发的Kubernetes由于业界各大巨头的加入和开源社区的全力支撑，成为了容器编排的首选。

简单来说，Kubernetes是容器集群管理系统，为容器化的应用提供资源调度、部署运行、滚动升级、扩容缩容等功能。容器集群管理给业务带来了便利，可是随着业务的不断增加，应用数量可能会发生爆发式的增加。那在这种状况下，Kubernetes可否快速地完成扩容、扩容到大规模时Kubernetes管理能力是否稳定成了挑战。

所以，结合近期对社区Kubernetes性能测试的调研和咱们平时进行的kubernetes性能测试实践，和你们探讨下Kubernetes性能测试的一些要点，不足之处还望你们多多指正！

测试目的

如上Kubernetes架构图所示，不管外部客户端，仍是Kubernetes集群内部组件，其通讯都须要通过Kubernetes的apiserver，API的响应性决定着集群性能的好坏。

其次，对于外部客户而言，他只关注建立容器服务所用的时间，所以，pod的启动时间也是影响集群性能的另一个因素。

目前，业内广泛采用的性能标准是：

• API响应性：99%的API调用响应时间小于1s。
• Pod启动时间：99%的pods（已经拉取好镜像）启动时间在5s之内。

“pod启动时间”包括了ReplicationController的建立，RC依次建立pod，调度器调度pod，Kubernetes为pod设置网络，启动容器，等待容器成功响应健康检查，并最终等待容器将其状态上报回API服务器，最后API服务器将pod的状态报告给正在监听中的客户端。

除此以外，网络吞吐量、镜像大小（须要拉取）都会影响Kubernetes的总体性能。

测试要点

1、社区测试Kubernetes性能的关键点

1. 当集群资源使用率是X%（50%、90% 、99%等不一样规模下）的时候，建立新的pod所需的时间（这种场景须要提早铺底，而后在铺底基础上用不一样的并发梯度建立pod，测试pod建立耗时，评估集群性能）。在测试kubernetes新版本时，通常是以老版本稳定水位（node、pod等）铺底，而后梯度增长进行测试。
2. 当集群使用率高于90%时，容器启动时延的增大（系统会经历一个异常的减速）还有etcd测试的线性性质和“模型创建”的因素。调优方法是：调研etcd新版本是否有解决该问题。
3. 测试的过程当中要找出集群的一个最高点，低于和高于这个阈值点，集群性能都不是最优的。
4. 组件负载会消耗master节点的资源，资源消耗所产生的不稳定性和性能问题，会致使集群不可用。因此，在测试过程当中要时刻关注资源状况。
5. 客户端建立资源对象的格式 —— API服务对编码和解码JSON对象也须要花费大量的时间 —— 这也能够做为一个优化点。

2、网易云容器服务Kubernetes集群性能测试关键点总结

集群总体

1. 不一样的集群使用水位线（0%，50%， 90%）上，pod/deployment(rs 等资源)建立、扩缩容等核心操做的性能。能够经过预先建立出一批dp（副本数默认设置为3）来填充集群，达到预期的水位，即铺底。
2. 不一样水位对系统性能的影响——安全水位，极限水位
3. 容器有无挂载数据盘对容器建立性能的影响。例如，挂载数据盘增长了kubelet挂载磁盘的耗时，会增长pod的启动时长。

测试kubernetes集群的性能时，重点关注在不一样水位、不一样并发数下，长时间执行压力测试时，系统的稳定性，包括：

• 系统性能表现，在较长时间范围内的变化趋势
• 系统资源使用状况，在较长时间范围内的变化趋势
• 各个服务组件的TPS、响应时间、错误率
• 内部模块间访问次数、耗时、错误率等内部性能数据
• 各个模块资源使用状况
• 各个服务端组件长时间运行时，是否出现进程意外退出、重启等状况
• 服务端日志是否有未知错误
• 系统日志是否报错

apiserver

1. 关注api的响应时间。数据写到etcd便可，而后根据状况关注异步操做是否真正执行完成。
2. 关注apiserver缓存的存储设备对性能的影响。例如，master端节点的磁盘io。
3. 流控对系统、系统性能的影响。
4. apiserver 日志中的错误响应码。
5. apiserver 重启恢复的时间。须要考虑该时间用户是否可接受，重启后请求或者资源使用是否有异常。
6. 关注apiserver在压力测试状况下，响应时间和资源使用状况。

scheduler

1. 压测scheduler处理能力

• 并发建立大量pod，测试各个pod被调度器调度的耗时（从Pod建立到其被bind到host）
• 不断加大新建的pod数量来增长调度器的负载
• 关注不一样pod数量级下，调度器的平均耗时、最大时间、最大QPS（吞吐量）

    2. scheduler 重启恢复的时间（从重启开始到重启后系统恢复稳定）。须要考虑该时间用户是否可接受，重启后请求或者资源使用是否有异常。

    3. 关注scheduler日志中的错误信息。

controller

1. 压测 deployment controller处理能力

• 并发建立大量rc（1.3 之后是deployment，单副本），测试各个deployment被空感知并建立对应rs的耗时
• 观察rs controller建立对应pod的耗时
• 扩容、缩容（缩容到0副本）的耗时
• 不断加大新建deployment的数，测试在不一样deployment数量级下，控制器处理deployment的平均耗时、最大时间、最大QPS（吞吐量）和控制器负载等状况

   2. controller 重启恢复的时间（从重启开始到重启后系统恢复稳定）。须要考虑该时间用户是否可接受，重启后请求或者资源使用是否有异常。

   3. 关注controller日志中的错误信息。

kubelet

1. node心跳对系统性能的影响。
2. kubelet重启恢复的时间（从重启开始到重启后系统恢复稳定）。须要考虑该时间用户是否可接受，重启后请求或者资源使用是否有异常。
3. 关注kubelet日志中的错误信息。

etcd

1. 关注etcd 的写入性能

• 写最大并发数
• 写入性能瓶颈，这个主要是按期持久化snapshot操做的性能

   2. etcd 的存储设备对性能的影响。例如，写etcd的io。

   3. watcher hub 数对kubernetes系统性能的影响。

 

做者：张文娟，网易测试工程师

 

了解 网易云 ：
网易云官网：https://www.163yun.com/
新用户大礼包：https://www.163yun.com/gift
网易云社区：https://sq.163yun.com/