如何进行大规模Kubernetes集群测试

前言

Kubernetes作为当下应用最广泛的容器集群管理系统，为容器化的应用提供资源调度、部署运行、滚动升级、扩容缩容等功能。容器集群管理给业务带来了便利，但是随着业务的不断增长，应用数量可能会发生爆发式的增长，这都对 Kubernenetes 集群的快速扩缩容和大规模大压力下的集群管理等能力提出了更高的要求。

测试工具介绍

kubemark 是 K8s 官方给出的性能测试工具，能够不受任何资源限制，模拟出一个大规模 K8s 集群。kubemark可以将在external 集群运行的hollowpod，注册成为测试集群的hollow node，实现增加node规模的作用。该hollow node具备被测试集群调度和运行pod的能力。

kubemark cluster为测试集群
k8s cluster为运行hollowpod的扩展集群

clusterloader2是一个自带yaml的kubernetes负载测试工具，位于perf-tests工具集项目之中，是官方的k8s可扩展性和性能测试框架。目前可用的指标为

· APIAvailabilityMeasurement

· APIResponsivenessPrometheusSimple

· APIResponsivenessPrometheus

· CPUProfile

· EtcdMetrics

· MemoryProfile

· MetricsForE2E

· PodStartupLatency

· ResourceUsageSummary

· SchedulingMetrics

· SchedulingThroughput

· Timer

· WaitForControlledPodsRunning

· WaitForRunningPods

· Sleep

测试目标

大规模K8s集群重要的特性是可扩展性和性能稳定性。我们可以使用SLI（Service Level indicators）和 SLO(Service Level Objectives)来定义集群测试的标准和目标。

Kubernetes社区定义多种SLIs/SLOs以便衡量集群的服务质量，在本文的测试中主要关注以下几点：

Status	SLI	SLO
Official	Latency of mutating API calls for single objects for every (resource, verb) pair, measured as 99th percentile over last 5 minutes	In default Kubernetes installation, for every (resource, verb) pair, excluding virtual and aggregated resources and Custom Resource Definitions, 99th percentile per cluster-day1 <= 1s
Official	Latency of non-streaming read-only API calls for every (resource, scope) pair, measured as 99th percentile over last 5 minutes	In default Kubernetes installation, for every (resource, scope) pair, excluding virtual and aggregated resources and Custom Resource Definitions, 99th percentile per cluster-day1 (a) <= 1s if `scope=resource` (b) <= 30s otherwise (if `scope=namespace` or `scope=cluster`)
Official	Startup latency of schedulable stateless pods, excluding time to pull images and run init containers, measured from pod creation timestamp to when all its containers are reported as started and observed via watch, measured as 99th percentile over last 5 minutes	In default Kubernetes installation, 99th percentile per cluster-day1 <= 5s

测试方案

kubernetes管理面采用3 master进行部署，etcd采用ssd进行存取数据。clusterloader2将发起density负载测试。prometheus将对集群指标进行采集，通过grafana进行更好的数据展示。

受限于External Cluster的资源限制，本次我们将进行100节点、200节点、500节点的测试，观察集群性能是否达标。

测试环境信息

1、Kubernetes版本与规格

采用华云云原生软件上的Kubernetes v1.18 版本，集群采用 3 master 节点和模拟 node节点。

2、Master节点配置

· CPU： 32C

· MEMORY: 125G

· ETCD DISK : Type:SSD,Size:120GB

3、External cluster配置： 8C16G * 3

4、参数调优

kubelet参数默认情况下，最大pod数量为110。太小会导致模拟时每个节点的pod数量有限。

1. $ vi /etc/kubernetes/kubelet-config.yaml

2. maxPods: 110---> 300

4. $ systemctl restart kubelet

kube-apiserver 参数

1. --max-requests-inflight=2000 # 非变更类型请求的最大个数。默认400.

2. --max-mutating-requests-inflight=1000 # 限制进行中变更类型请求的最大个数，零表示无限制。默认200

kube-controller-manager 参数

1. --kube-api-qps=100 # 与 API 服务器通信时每秒请求数（QPS）限制。默认20

2. --kube-api-burst=100 # 与 Kubernetes API 服务器通信时突发峰值请求个数上限。默认30

kube-scheduler 参数

1. --kube-api-qps=200 # 默认值：50

2. --kube-api-burst=400 # 与 kubernetes API 通信时使用的突发请求个数限值。默认100

测试结果

分别进行100节点、200节点和500节点规模性能测试，其最大峰值时数据如下

1 Mutating API call latency(threshold=1s)

2 Read-only API call latency(scope=cluster, threshold=30s)

3 PodStartupLatency

100节点

metric	p50(ms)	p90(ms)	p99(ms)	SLO(ms)
pod_start_up	1455	1949	2245	5000
create_to_schedule	588	978	1003	N/A
schedule_to_run	0	191	230	N/A
run_to_watch	1190	1514	1897	N/A
schedule_to_watch	881	1291	1316	N/A

200节点

metric	p50(ms)	p90(ms)	p99(ms)	SLO(ms)
pod_start_up	1300	1840	1997	5000
create_to_schedule	485	871	902	N/A
schedule_to_run	0	142	314	N/A
run_to_watch	922	1654	1856	N/A
schedule_to_watch	709	1190	1379	N/A

500节点

metric	p50(ms)	p90(ms)	p99(ms)	SLO(ms)
pod_start_up	1362	1726	2361	5000
create_to_schedule	590	979	1011	N/A
schedule_to_run	0	189	202	N/A
run_to_watch	1049	1480	1669	N/A
schedule_to_watch	748	1210	1381	N/A

总结

本文介绍了大规模 Kubernetes集群的测试方法，并设计测试方案和测试目标对模拟的大规模 K8s 集群进行了多轮的测试。

在华云云原生集群上，Kubernetes 控制面的API调用延迟和Pod启动延迟均维持在较低值，符合Kubernetes社区的SLIs/SLOs指标，华云云原生集群能够稳定支持和管理大规模节点。

本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请点击举报。