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 系还是很香的。

[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 试试看，有话直说再对比压测才有意义。