k8s 系真的是 qps 杀手

[liuxu]

测试了下 k3s，发现 qps 10 倍下跌。

压测机：ubuntu20.04 ，wrk2，6C16G 。
靶机：ubuntu20.04 ，2C4G 。
靶机和压测机均为同一内网，使用 vultr 多台机器搭建。

准备：
ubuntu20.04 下编译最新的 stable 版本 nginx-1.20.1，编译后的文件制作成 docker 镜像上传到 docker hub，然后又制作了一个 helm 包，用于直接安装到 k3s 测试。
其中 index.html 均为字符串"helloworld"，nginx 配置 worker_connections 为 102400，worker_processes 为 auto 。
所有系统 nofile 为 102400 。

压测目标：
所有请求保证在 1s 以内，1k 或 10k 加减，如测试 1k 、2k，2k 超过 1s 则丢弃 2k 的数据，只留下 1k 的。10k 、20k，20k 超过 1 秒则丢弃 20k 的数据。


压测步骤：
1. 裸机启动 docker run，压测，然后卸载 docker，安装 k3s，默认 runtime 为 containerd 。
结果：裸 docker run 并发 10k，rps 30k 。k3s 直接降到并发 1k，rps 1k 。



2.分别安装 k3s(runtime 为 containerd)和 k3s(runtime 为 docker)压测。
结果：同为并发 1k，rps 1k，docker 延迟明显高于 containerd 。



3. k3s 使用 containerd，并分别安装 2 、3 、4 个 node 压测，其中 master 会被 taint 掉 agent，也就是真正运行 nginx 的为 1 、2 、3 个 node，其中每个 node 分配 1 个 nginx pod （当然 master 没有 pod ）。
结果：随着 node 数增加，rps 也可以慢慢增加。但总的来说，即使此时有 4 个 2C4G 的 node，也只能并发 1k，rps 7k，远不如裸机跑 docker run 。




结论：使用 k8s 系可以拥有自动扩展，高可用等能力，而且可以直接对接多种 CI 平台。但是对于小成本又想要高 qps 的项目，不要使用 k8s 系，建议使用传统环境部署。当然很多人的项目永远都不会有 1k qps，所以这种业务情况上 k8s 系还是很香的。

帖子的中心思想是

小项目要是有 qps 要求，还要节省成本就别上 k8s 系列，k3s 这种轻量级都很吃配置

没有 qps 要求就随便上，传统项目想迁移到 k8s 的要提前掂量掂量收益和损失

大项目要 k8s 就直接上云，或者自己搞要有能力换组件分析组件性能

[victor]

生产环境我也遇到了类似的问题，结论一样，但不知道原因是啥。目前只能通过加机器的方式来增加 QPS，性价比极低。
插个眼，看看是否有大手子解答。

[WispZhan]

您就是传说中的标题党？

---

建议直接测 k8s 。控制变量，麻烦态度严谨一点。

[Cooky]

容器影响进程 /线程上下文切换效率？

[liuxu]

@victor 目前看是 ingress 和 apiserver 这一批占用了大量 cpu

[JRyan]

把资源限制调高看看 容器是有一点性能损耗 但不至于低这么多

[liuxu]

@WispZhan 我并发和 rps1k10k 逐步加量测了十几组数据，给出来的这 3 张图，别张口就来伙计

[liuxu]

@JRyan htop 看 node 是 cpu 爆了

[liuxu]

@JRyan 容器损耗并不高，单独 docker 和物理机直接 nginx 差别不大，主要是 k8s 系自身占用大量资源，用的话最好有大量 node，起码 5 台以上 4C8G 最好

[JRyan]

可能是本身集群占用的资源

[johnsonqrr]

测试：K3s
结论：K8s
UC 命令你马上来报道

[liuxu]

@johnsonqrr k8s 系，k3s 和 microk8s 都属于，k8s 需要的硬件基础更高

[JRyan]

你这可以在云上跑个集群测试就知道实际性能差异了

[opengps]

io 问题并非 k8s 独有，而是虚拟化的环节损失的，搭建的虚拟机同样也是性能损失大户

[liuxu]

@Cooky 对，开了 k3s 系统直接 200 多 thread，如果 runtime 改成 dockerd，300 多 thread，cpu 爆时，主要是 nginx 、ingress(traefik ） cpu 和 k3s 自身进程 cpu 占用高

[WispZhan]

@liuxu 自己 uc 风的标题，说我张开就来？

另外 1 没人是你伙计

[liuxu]

@JRyan k8s 系能上云的话会更好，主要是 ingress 用云的 LB，避免和业务 pod 在同一 node，下文切换导致性能衰减

[wdlth]

没看到安装 k8s 具体的配置和测试的方法，是否启用 IPVS，是否经过 ingress，是否优化 ingress 等等。

[coolrc]

态度严谨？那是不是还要查重呢

[liuxu]

@wdlth k3s 的官方命令默认安装，没有 IPVS，ingress 也是默认的 traefik v1 。主要是上次发了一个很详细的测试贴被人喷太多不想看，所以这次直接给图了。

实际上 k8s 优化起来，runtime 用 docker 或 containerd，网络用 fannel 或者 calico，ingress 是 traefik 1 或 2 或者 nginx，都对最终结果影响很大。

全部测这十一假期都测不完，万一某些没说清楚还要被楼上喷态度不严谨，或者喷你 UC 标题党

[mengdodo]

这个问题我看到了不止你一篇帖子，都是这个结论，小企业小应用不适用

[Nitroethane]

我记得之前看过一篇文章，说 kube-proxy 使用 iptables 模式时会有随机丢包的情况出现。建议用 ipvs 模式再测测

[Actrace]

哈哈，k8s 的很多情况都是典型的为了解决一个问题而带来更多的问题。

运维领域其实非常专业，目前还没有出现能解决一切问题的万金油。

[momocraft]

k3s 已经是号称轻量了 那完整的 k8s 会不会更严重

[joesonw]

k8s 网络没选对对性能影响很大。每个节点的 kubelet，网络 ds，日志等很多基础组件都是有消耗的。2c4g 作为生产确实太小，一般都是 8c/16c 起步。一个简单的 nginx static server 肯定比直接跑要差，还是要看业务场景。

[wellsc]

问好

[wellsc]

❓

[ihciah]

cri 没控制变量，也没有 cpu 占用率的数据，同时你的 docker 网络模式，cni 用的啥也没讲。
就一个延迟数据，谁知道是哪块导致的呢。你这个数据没办法科学严谨地推导出你的结论。

[ToBeHacker]

性能肯定是有影响的，k8s 这样的架构本身就是为了牺牲一定的性能来换取伸缩性与可维护性。
1 、最好拿 k8s 来测试，实际生产环境用 k3s 还是相对少一些的
2 、network 层对性能影响很大，实际上可能并不是 k8s 的锅，而是网络层的损耗导致的性能问题

[ch2]

这种牺牲是必要的，各个组件不可能不占计算资源就把调度做好
就算你起个 nginx 接 upstream，nginx 自己也能占满你一台机器的 cpu

[fkdog]

"裸 docker run 并发 10k，rps 30k 。k3s 直接降到并发 1k，rps 1k"
如果是这种降法，那我感觉可能是哪方面配置出了问题。牺牲换取伸缩弹性很好理解，但是能牺牲 10 倍 30 倍这种性能的，我理解不了。

[Reficul]

ingress 没用云的 lb 的话，过了一层 nodeport （ iptables ），cni 的 pod 网络，clusterip （ iptables ），再 cni 的 pod 网络。 单纯 docker run 的话可能都是 host 网络，差别很大

[cassyfar]

你要确保那个 node 只跑你自己服务的 pod 再做压测对比。k8s 需要的硬件资源肯定是比 docker 多的啊。

[swulling]

你可以直接用 daemonset 加 hostnetwork=true 来测。

[swulling]

如果是通过 k3s 默认的 ingress，那么整个流量过程是 ingress-ipvs-nginx，加上你的服务器才 2c4g，性能差是理所当然的。

至于 k3s 自身组件，流量又不过他们，那些是控制面，也只是占点资源而已。

[kiripeng]

多过一层网络了

[dusu]

说个恐怖故事：裸跑 docker 都还有 10-20%的 qps 损失

[ospider]

你这目标机器太小了，资源都用来跑 k3s 了，那可不是性能低么？你弄个 16C64G 的机器测测，看看还是相同结论么？

[ericbize]

容器内部优化试一下

[plko345]

画图用什么工具？有时间我也测一波，用 k8s

[liuxu]

@plko345 http://hdrhistogram.org/

wrk2 github 文档中有说明，压测参数带-L，输出到 txt 上传，可以一次上传多和 txt，每个都是一条线

[yidinghe]

@WispZhan 懂你就多说两句，这么多人看着呢，要么别张嘴，张嘴就要讲出有说服力的话，不然自己名声没了

[choury]

用容器方案可优化的地方多了，用默认配置跑当然性能不行，cpu 绑核，中断绑定，网络模式这些，甚至日志打的多了都会影响性能

[guyskk0x0]

一般业务代码 2c4g 机器只能跑到几十上百 QPS，响应时间 50ms 左右。index.html 太小了，响应时间太短。

[liuxu]

@guyskk0x0 我掐指一算你要么是个 java 写中台的，要么是个 php 但是用的 laravel /dog

[HelloAmadeus]

2c4g 基本上 CPU 和内存都被 k8s 占了吧，配置太低了

[guyskk0x0]

@liuxu #42 问题不在语言框架，只要用了数据库，或是请求了外部接口，响应时间和 QPS 都是这个水平。仅讨论问题，没必要瞎猜，而且你都猜错了。

[tinkerer]

@liuxu 你这一路点评下来，到底是为了找到问题根源还是想证明自己正确？

[jiangzhizhou]

上云很贵嘛？ EKS ？
好奇为什么要自己运维，友善讨论。

[liuxu]

@guyskk0x0 就认真讨论问题话，2h4g 的 qps 简单业务用上异步框架可以过 1-2k，没有的话建议跑下 profile 分析下，以及数据库性能

[liuxu]

@tinkerer 要分析 k3s 发帖回帖是找不到答案的，找答案要自己分析系统 profile，主要是我自己的几个网站用的 k3s 后 qps 极速下降，我还以为是 cf 的问题，这测了下才知道是 k3s 导致

[liuxu]

@jiangzhizhou 很贵，按楼上大佬的意思搞几台 16c64g，简单的 4c8g 每个月小几千，个人项目和小公司很难负担吧

[uucloud]

裸 docker 跑有限制 cgroup 吗，同 cpu limit 下跑的差 10 倍？ 感觉有点离谱...大概率是实验设计的有问题

[jiangzhizhou]

@liuxu 嗯，能够理解。小公司咬咬牙上云长远来看肯定省心，只要一次事故，钱肯定回来了。个人项目这个就不好说了，丰简由人。
PS:小公司在基础设施上省钱肯定要转嫁到客户头上去的。

[Skmgo]

这个问题我曾经提问过, 大家都说没问题.

[idblife]

@liuxu
如果没那么多预算，说明项目不大，用 k8s 的考虑是啥呢？

[liuxu]

@idblife 我自己的是有一堆小项目每年换服务器商能快速迁移，其次接入 github actions 自动化部署也方便很多，而且有时候突然流量来了能快速伸缩

[yc8332]

有损耗是一定的。但是 10 倍我是不信，估计是你的机器资源问题。。这个和并发设置一样，并不是设置越高性能就会越高，资源不足的时候切换就越慢

[offswitch]

nginx 用 return 200 再压测一下，对比一下。

[dcoder]

docker, k8s 就是又慢又复杂啊...

但是, 大家都是"面向简历编程", 不妨碍浪费公司资源用这套破烂

[carrotrollroll]

1. 标题说 k8s，实测用 k3s 有点标题党，k3s 本身就是为资源紧张的设备设计的，没有刻意优化高并发下的性能
2. k8s 是通过 nodeport 暴露的吗，有没有看过瓶颈在哪？
感觉只剩不足 10%的性能有些夸张，我在生产环境大量使用 k8s 上也没遇到过（默认的 k8s 配置有 20%左右的 rps 损失）

[carrotrollroll]

@liuxu 啥，压测是经过了 traefik ingress ？那瓶颈当然在这里了，小机器下 traefik 性能损失比较严重。。。。。。还以为你用 nodeport 暴露的呢

你测 docker 只走了 iptables 网络，测 k3s 却经过了一个性能不怎么高的 traefik ingress （比 nginx 效率低），不公平啊

[salmon5]

我觉得既然压测了，就别用的有点拧巴；直接 kubeadm 部署，32C/128 、64C128G 的机器搞几台；

[liuxu]

@carrotrollroll

k8s 系有 k8s，k3s，microk8s 等。标题是 rhel 的 yum 源慢，帖子说 centos 更新好慢有问题么

说的是小成本项目，铺个 100 台 64c128g，不管是裸机还是 docker 还是 k8s 系，最后 qps 都会相近，任何基础组件的损耗占比都可以被抹平，你还有 20%损失说明机器还不够多，再铺一倍机器损耗会到 10%

@salmon5

2c4h 是我自己的站常用的配置，我觉得的小成本就是几台 2c4g，为了测试我自己的项目用的，可能每个人眼中的小成本不太一样，而且我测试常用 vultr 或者 digitalocean 这种，最高配置 8c16g

[ZSeptember]

你测试的这种 workload 中，网络传输是最大的瓶颈，多了一层转发，肯定会下降很多，在真实的业务场景中，影响会小很多。
然后，机器确实可能影响到测试结果，如果性能损耗这么大，肯定没那么多公司用。

[calmzhu]

- k8s 用 docker runtime 确实有性能不如 containerd，k8s 已经弃用了 docker 。
- 单机配置不足不建议 k8s 。k8s 本身资源占用相对固定，配置越高，这部分资源锁定越可以忽略。

但是，也不至于拉垮到 1000kps 都困难，能看下整个性能约束点在哪，服务转发，网络处理还是后段之类的，找到约束点，而这个约束点确实是 k8s 本身设计不合理产生的那就比较有说服力。

结论的话，网络组件用的啥，服务暴露方式是什么。比如图里面 3 节点跟 4 节点后段曲线趋同，就很像节点外的单点性能瓶颈导致的

[kennylam777]

直接上 hostPort，直連 nginx 再回來說 k8s 的不是，都經過了 Ingress 還有意思嗎?

[liuxu]

@calmzhu 遇到了个大佬，终于有人分析压测图了

htop 观测（ linode ubuntu 20.04 ）:
裸机：Tasks：24，5 thread
裸机+dockerd: Tasks: 30, 25 thread
裸机+k3s+containerd: Task: 46, 117 thread
裸机+k3s+dockerd: Task: 52, 193 thread

问题：
1. 单 node 是因为 traefik 和 nginx pod 争抢 cpu 导致的瓶颈，2c4g 太低，25 thread vs 117 thread
2. 多 node 实际上我搭建压测环境偷懒了，实验设计会因为 1 的瓶颈导致整体没有达到最理想状态，新加入的 node cpu 利用率只有 50%左右，而 4node 一开始的延迟比 3node 还要高，就是入口 node 过载更严重导致，3node 用的 6k，4node 用的 7k

不过问题 1 才是我需要的答案，问题 2 对我无足轻重，只是想看看现有方案添加多 node 会怎样，所以问题 2 没有太严谨的压测

目前得到的结果是：
1. 后期会加强 ingress 入口机器的配置，并不是只加 agent 机器数量
2. 或者前置一个负载均衡均匀分配请求到所有 node
3. 或者用 CF 的 DNS 多 A 记录来分担负载

[mogging]

同意刚才看到的大佬回复: k8s 网络没选对对性能影响很大，flannel 本身就不是一个 production ready 的方案，另外 dns 解析也非常影响 QPS ，上 nodelocaldns 试试看，有话直说再对比压测才有意义。