Kubernetes 1.16 与 1.14性能对比

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器镜像服务 ACR,镜像仓库100个 不限时长
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: 作者针对ACK 1.16 版本与 1.14 版本进行性能测试后,对测试结果进行了总结和分析。1.16 在多个方面都有不同程度的性能提升。

测试环境

  • 阿里云 ACK 1.16.6 3master 3worker(4c 8g) 独占版, kubemark 模拟 100 个 node;
  • 阿里云 ACK 1.14.8 3master 3worker(4c 8g) 独占版, kubemark 模拟 100 个 node。

测试指标

PodstartuplatencySaturate(饱和测试)

在 1 个 namespace 下创建 replicas 为 3000 的 deployment,记录每个 pod 所需时间,按照时间大小排序后得到(50 90 99 百分点结果)。

Podstartuplatencylatency(存量测试)

在已创建 3000 个 pod 的场景下,连续创建 500 个 replicas 为 1 的 deployment,测试 pod 的创建时间。

吞吐量

在创建 pod 的过程中,测试每秒创建的 pod 个数。

api 响应时间

在整个测试过程(创建 pod,删除 pod)中,api-server 收到请求到响应的时间汇总,按 verb、resouce、scope、percentage 区分。

实验结果

PodstartuplatencySaturate(ms)

1.16

PodStartupLatency create_to_schedule schedule_to_run run_to_watch schedule_to_watch pod_startup
50 0 1000 1044.237 1749.131 1749.184
90 0 1000 1640.885 2401.273 2401.273
99 0 1000 2126.116 2958.44 2958.44

1.14

PodStartupLatency create_to_schedule schedule_to_run run_to_watch schedule_to_watch pod_startup
50 0 1000 1083.588 1836.33 1838.244
90 0 1000 1790.928 2610.571 2611.449
99 0 2000 2852.53 4303.789 4303.789
对比:

空载下运行3000个pod,50%pod启动时间1.16相比1.14快5%左右。 90%的pod启动时间,1.16启动时间提升3%-10%,99%的pod启动时间上1.16提升最大,速度提升25%-50%。在最坏情况下,1.16的效果明显好于1.14.

Podstartuplatency(ms)

1.16

PodStartupLatency create_to_schedule schedule_to_run run_to_watch schedule_to_watch pod_startup
50 0 1000 1004.569 1727.642 1727.662
90 0 1000 1692.732 2414.719 2429.138
99 0 1000 2124.746 2892.659 2897.378

1.14

PodStartupLatency create_to_schedule schedule_to_run run_to_watch schedule_to_watch pod_startup
50 0 1000 1046.108 1772.073 1774.335
90 0 1000 1772.192 2613.083 2613.083
99 0 1000 2260.846 2959.74 2959.74

对比

在存量测试下,50% pod 启动时间上, 1.16 效率提升 3%;90% 和 99% pod 的启动时间上,1.16 效率提升 5%。总体来说 1.16 效果略微好于 1.14。

吞吐量(个数)

版本 average 50 90 99
1.14 19.354 20 20 23.6
1.16 19.354 20 20 24.2

对比

  • 在创建 pod 过程中,50%、90% 和平均情况下,1.14 和 1.16 创建 pod 吞吐量相同;
  • 99 分位点情况,1.16 提升 3%。在最坏情况下,1.16 的效果优于 1.14。

api 响应延时(ms)

1.14

Resource Scope Verb Perc50 Perc90 Perc99
pods namespace DELETE 25.279 45.502 54.906
pods namespace GET 25.17 45.307 49.837
pods namespace LIST 25 45 49.5

(Pod)

Resource Scope Verb Perc50 Perc90 Perc99
nodes cluster PATCH 25.41 45.74 78.87
nodes cluster LIST 25 45 49.5
nodes cluster GET 25 45 49.5

(Nodes)

1.16

Resource Scope Verb Perc50 Perc90 Perc99
pods namespace DELETE 25.432 45.779 76.445
pods namespaces GET 25.018 45.033 49.536
pods namespaces LIST 25 45 49.5

(Pod)

Resource Scope Verb Perc50 Perc90 Perc99
nodes cluster PATCH 25 45 49.5
nodes cluster LIST 25 45 49.5
nodes cluster GET 25 45 49.5

(Nodes)

对比

统计整个创建 Pod 和删除 Pod 过程中 api 响应时间,将其根据时间大小排序后对 pod 和 node 操作选取时间最长的三项进行对比。

对比可以发现,对 pod 和 node 操作的 api 时间,1.14 和 1.16 基本一致:

  • 最坏情况下(99 分点)对 pod 的 delete 操作时间,1.14 相比 1.16 要快 30% 左右;
  • 对 node 的 PATCH 操作,1.16 相比 1.14 要快 40% 左右;
  • 对于其它 apicall(如 LIST 和 GET)二者并没有明显差距。

总结

总体来说,1.16 版本相对于 1.14 版本的主要提高在无状态 Pod(Pod 不用挂载 configmap、secret 等 volume)的创建速度上:

  • 1.16 和 1.14 的 pod 创建时间都满足 Kubernetes sig-scalability 定义的 SLA((99% 的已拉取好镜像的 pod 启动时间在 5s 内);
  • 但在最差情况下(99 分位点),1.14 版本的 Pod 创建速度接近 5s,表现差于同指标下 K8s 1.16 的 3s。

说明 1.16 版本更适用于对 pod 创建速度有要求(如弹性业务)的场景。

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
2月前
|
Prometheus Kubernetes 监控
Kubernetes 性能调优与成本控制
【8月更文第29天】随着 Kubernetes 在企业中的广泛应用,如何有效地管理和优化 Kubernetes 集群的性能和成本成为了一个重要的课题。本篇文章将介绍 Kubernetes 性能监控的基础知识,以及一些实用的成本优化技巧,包括资源配额的设置、Pod 密度的提高和集群规模的合理调整。
78 1
|
2月前
|
Kubernetes 算法 测试技术
Kubernetes的垂直和水平扩缩容的性能评估
Kubernetes的垂直和水平扩缩容的性能评估
41 6
|
API 容器 Kubernetes
当 K8s 集群达到万级规模,阿里巴巴如何解决系统各组件性能问题?
作者 | 阿里云容器平台高级技术专家 曾凡松(逐灵) 本文主要介绍阿里巴巴在大规模生产环境中落地 Kubernetes 的过程中,在集群规模上遇到的典型问题以及对应的解决方案,内容包含对 etcd、kube-apiserver、kube-controller 的若干性能及稳定性增强,这些关键的增强是阿里巴巴内部上万节点的 Kubernetes 集群能够平稳支撑 2019 年天猫 618 大促的关键所在。
|
2月前
|
Kubernetes 安全 Linux
在K8S中,calico和cilium这两种cni有什么区别?cailico的ipip模型和ciliume的vxlan模型,两种不通模型性能也不同,它们怎么处理数据的?
在K8S中,calico和cilium这两种cni有什么区别?cailico的ipip模型和ciliume的vxlan模型,两种不通模型性能也不同,它们怎么处理数据的?
|
4月前
|
Kubernetes 网络协议 Cloud Native
Kubernetes网络问题排查分享两则(1)——calico特定场景下的网络性能问题
在对Kubernetes项目[kosmos](https://github.com/kosmos-io/kosmos)与Calico网络性能进行对比测试时,发现kosmos在跨集群容器网络的性能显著优于Calico的集群内网络(约6Gbit/s对比2.9Gbit/s)。物理机网络测试达到9.38Gbit/s,显示Calico有68%的性能损耗。问题定位到网卡的checksum/offload参数,尝试用`ethtool`调整后虽短暂提升,但随后恢复原状。转载自:https://mp.weixin.qq.com/s/XsQZCSqZAXJK46zqc7IpLw
|
12月前
|
Kubernetes jenkins 持续交付
jenkins结合k8s构建流水线如何提升运行性能和构建效率
jenkins结合k8s构建流水线如何提升运行性能和构建效率
|
Kubernetes 调度 容器
kubernetes调度器性能调优
kubernetes调度器性能调优
BXA
|
缓存 Kubernetes 负载均衡
如何优化Kubernetes的性能和资源利用率优化
根据业务实际需求可以添加或删除节点。如果我们的业务中有一段时间流量比较大可以考虑增加节点来增加集群的承载能力,等过了这段时间之后就可以减少节点了以节省成本
BXA
12596 2
|
Kubernetes 安全 API
【kubernetes】API Server 保证性能的方式
【kubernetes】API Server 保证性能的方式
117 0
|
Kubernetes Java jenkins
K8S环境的Jenkin性能问题处理
通过helm部署的jenkins,在实际使用过程中时常出现响应变慢的问题,本文回顾了问题的分析和处理过程,希望能给您一些参考
337 1
K8S环境的Jenkin性能问题处理

相关产品

  • 容器服务Kubernetes版
  • 下一篇
    无影云桌面