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 |
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
3.
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节点规模性能测试,其最大峰值时数据如下
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指标,华云云原生集群能够稳定支持和管理大规模节点。
联系客服