这是一个创建于 1155 天前的主题，其中的信息可能已经有所发展或是发生改变。
测试了下 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 系还是很香的。
压测机：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 系还是很香的。
第 1 条附言 · 2021-10-03 14:06:00 +08:00
帖子的中心思想是
小项目要是有 qps 要求，还要节省成本就别上 k8s 系列，k3s 这种轻量级都很吃配置
没有 qps 要求就随便上，传统项目想迁移到 k8s 的要提前掂量掂量收益和损失
大项目要 k8s 就直接上云，或者自己搞要有能力换组件分析组件性能
小项目要是有 qps 要求，还要节省成本就别上 k8s 系列，k3s 这种轻量级都很吃配置
没有 qps 要求就随便上，传统项目想迁移到 k8s 的要提前掂量掂量收益和损失
大项目要 k8s 就直接上云，或者自己搞要有能力换组件分析组件性能
 |
1
victor 2021-10-02 18:05:19 +08:00
生产环境我也遇到了类似的问题，结论一样，但不知道原因是啥。目前只能通过加机器的方式来增加 QPS，性价比极低。
插个眼，看看是否有大手子解答。 |
 |
2
WispZhan 2021-10-02 18:16:10 +08:00  2
您就是传说中的标题党？
--- 建议直接测 k8s 。控制变量，麻烦态度严谨一点。 |
 |
3
Cooky 2021-10-02 18:27:48 +08:00
容器影响进程 /线程上下文切换效率？
|
 |
5
JRyan 2021-10-02 18:39:56 +08:00 via iPhone
把资源限制调高看看 容器是有一点性能损耗 但不至于低这么多
|
 |
8
liuxu OP @JRyan 容器损耗并不高，单独 docker 和物理机直接 nginx 差别不大，主要是 k8s 系自身占用大量资源，用的话最好有大量 node，起码 5 台以上 4C8G 最好
|
|
9
JRyan 2021-10-02 18:46:13 +08:00 via iPhone
可能是本身集群占用的资源
|
 |
10
johnsonqrr 2021-10-02 18:47:41 +08:00 4
测试：K3s
结论：K8s UC 命令你马上来报道 |
|
11
liuxu OP @johnsonqrr k8s 系，k3s 和 microk8s 都属于，k8s 需要的硬件基础更高
|
|
12
JRyan 2021-10-02 18:53:46 +08:00 via iPhone
你这可以在云上跑个集群测试就知道实际性能差异了
|
 |
13
opengps 2021-10-02 18:54:11 +08:00
io 问题并非 k8s 独有，而是虚拟化的环节损失的，搭建的虚拟机同样也是性能损失大户
|
|
14
liuxu OP @Cooky 对，开了 k3s 系统直接 200 多 thread，如果 runtime 改成 dockerd，300 多 thread，cpu 爆时，主要是 nginx 、ingress(traefik ） cpu 和 k3s 自身进程 cpu 占用高
|
|
16
liuxu OP @JRyan k8s 系能上云的话会更好，主要是 ingress 用云的 LB，避免和业务 pod 在同一 node，下文切换导致性能衰减
|
 |
17
wdlth 2021-10-02 19:06:38 +08:00
没看到安装 k8s 具体的配置和测试的方法，是否启用 IPVS，是否经过 ingress，是否优化 ingress 等等。
|
 |
18
coolrc 2021-10-02 19:08:09 +08:00 via Android
态度严谨？那是不是还要查重呢
|
|
19
liuxu OP @wdlth k3s 的官方命令默认安装，没有 IPVS，ingress 也是默认的 traefik v1 。主要是上次发了一个很详细的测试贴被人喷太多不想看，所以这次直接给图了。
实际上 k8s 优化起来，runtime 用 docker 或 containerd，网络用 fannel 或者 calico，ingress 是 traefik 1 或 2 或者 nginx，都对最终结果影响很大。 全部测这十一假期都测不完，万一某些没说清楚还要被楼上喷态度不严谨，或者喷你 UC 标题党 |
 |
20
mengdodo 2021-10-02 19:23:20 +08:00
这个问题我看到了不止你一篇帖子，都是这个结论，小企业小应用不适用
|
 |
21
Nitroethane 2021-10-02 21:03:07 +08:00 via iPhone
我记得之前看过一篇文章，说 kube-proxy 使用 iptables 模式时会有随机丢包的情况出现。建议用 ipvs 模式再测测
|
 |
22
Actrace 2021-10-02 21:06:41 +08:00
哈哈，k8s 的很多情况都是典型的为了解决一个问题而带来更多的问题。
运维领域其实非常专业，目前还没有出现能解决一切问题的万金油。 |
 |
23
momocraft 2021-10-02 21:12:04 +08:00
k3s 已经是号称轻量了 那完整的 k8s 会不会更严重
|
 |
24
joesonw 2021-10-02 21:14:44 +08:00 via iPhone 1
k8s 网络没选对对性能影响很大。每个节点的 kubelet，网络 ds，日志等很多基础组件都是有消耗的。2c4g 作为生产确实太小，一般都是 8c/16c 起步。一个简单的 nginx static server 肯定比直接跑要差，还是要看业务场景。
|
 |
25
wellsc 2021-10-02 21:24:56 +08:00 via iPhone
问好
|
|
26
wellsc 2021-10-02 21:25:06 +08:00 via iPhone
❓
|
 |
27
ihciah 2021-10-02 21:51:17 +08:00
cri 没控制变量，也没有 cpu 占用率的数据，同时你的 docker 网络模式，cni 用的啥也没讲。
就一个延迟数据，谁知道是哪块导致的呢。你这个数据没办法科学严谨地推导出你的结论。 |
 |
28
ToBeHacker 2021-10-02 22:09:30 +08:00
性能肯定是有影响的，k8s 这样的架构本身就是为了牺牲一定的性能来换取伸缩性与可维护性。
1 、最好拿 k8s 来测试，实际生产环境用 k3s 还是相对少一些的 2 、network 层对性能影响很大，实际上可能并不是 k8s 的锅，而是网络层的损耗导致的性能问题 |
 |
29
ch2 2021-10-02 22:40:49 +08:00 3
这种牺牲是必要的，各个组件不可能不占计算资源就把调度做好
就算你起个 nginx 接 upstream，nginx 自己也能占满你一台机器的 cpu |
 |
30
fkdog 2021-10-02 23:56:37 +08:00
"裸 docker run 并发 10k，rps 30k 。k3s 直接降到并发 1k，rps 1k"
如果是这种降法，那我感觉可能是哪方面配置出了问题。牺牲换取伸缩弹性很好理解，但是能牺牲 10 倍 30 倍这种性能的，我理解不了。 |
 |
31
Reficul 2021-10-03 01:27:42 +08:00 via Android
ingress 没用云的 lb 的话，过了一层 nodeport （ iptables ），cni 的 pod 网络，clusterip （ iptables ），再 cni 的 pod 网络。 单纯 docker run 的话可能都是 host 网络，差别很大
|
 |
32
cassyfar 2021-10-03 03:05:07 +08:00
你要确保那个 node 只跑你自己服务的 pod 再做压测对比。k8s 需要的硬件资源肯定是比 docker 多的啊。
|
 |
33
swulling 2021-10-03 04:12:06 +08:00 via iPhone 1
你可以直接用 daemonset 加 hostnetwork=true 来测。
|
|
34
swulling 2021-10-03 04:21:50 +08:00 via iPhone 1
如果是通过 k3s 默认的 ingress，那么整个流量过程是 ingress-ipvs-nginx，加上你的服务器才 2c4g，性能差是理所当然的。
至于 k3s 自身组件，流量又不过他们，那些是控制面，也只是占点资源而已。 |
 |
35
kiripeng 2021-10-03 04:25:19 +08:00
多过一层网络了
|
 |
36
dusu 2021-10-03 04:53:01 +08:00 via iPhone
说个恐怖故事：裸跑 docker 都还有 10-20%的 qps 损失
|
 |
37
ospider 2021-10-03 08:54:22 +08:00 1
你这目标机器太小了，资源都用来跑 k3s 了，那可不是性能低么？你弄个 16C64G 的机器测测，看看还是相同结论么？
|
 |
38
ericbize 2021-10-03 08:57:14 +08:00 via iPhone
容器内部优化试一下
|
 |
39
plko345 2021-10-03 09:12:15 +08:00 via Android
画图用什么工具？有时间我也测一波，用 k8s
|
|
40
liuxu OP |
 |
41
yidinghe 2021-10-03 10:38:32 +08:00 via Android 1
@WispZhan 懂你就多说两句，这么多人看着呢，要么别张嘴，张嘴就要讲出有说服力的话，不然自己名声没了
|
 |
42
choury 2021-10-03 10:45:25 +08:00
用容器方案可优化的地方多了，用默认配置跑当然性能不行，cpu 绑核，中断绑定，网络模式这些，甚至日志打的多了都会影响性能
|
 |
43
guyskk0x0 2021-10-03 10:49:16 +08:00 via Android
一般业务代码 2c4g 机器只能跑到几十上百 QPS，响应时间 50ms 左右。index.html 太小了，响应时间太短。
|
|
44
liuxu OP @guyskk0x0 我掐指一算你要么是个 java 写中台的，要么是个 php 但是用的 laravel /dog
|
 |
45
HelloAmadeus 2021-10-03 11:02:08 +08:00 via iPhone
2c4g 基本上 CPU 和内存都被 k8s 占了吧，配置太低了
|
|
46
guyskk0x0 2021-10-03 11:16:44 +08:00
@liuxu #42 问题不在语言框架，只要用了数据库，或是请求了外部接口，响应时间和 QPS 都是这个水平。仅讨论问题，没必要瞎猜，而且你都猜错了。
|
 |
48
jiangzhizhou 2021-10-03 13:03:13 +08:00
上云很贵嘛？ EKS ？
好奇为什么要自己运维，友善讨论。 |
|
49
liuxu OP @guyskk0x0 就认真讨论问题话，2h4g 的 qps 简单业务用上异步框架可以过 1-2k，没有的话建议跑下 profile 分析下，以及数据库性能
|
|
50
liuxu OP @tinkerer 要分析 k3s 发帖回帖是找不到答案的，找答案要自己分析系统 profile，主要是我自己的几个网站用的 k3s 后 qps 极速下降，我还以为是 cf 的问题，这测了下才知道是 k3s 导致
|
|
51
liuxu OP @jiangzhizhou 很贵，按楼上大佬的意思搞几台 16c64g，简单的 4c8g 每个月小几千，个人项目和小公司很难负担吧
|
 |
52
uucloud 2021-10-03 14:37:08 +08:00
裸 docker 跑有限制 cgroup 吗，同 cpu limit 下跑的差 10 倍？ 感觉有点离谱...大概率是实验设计的有问题
|
|
53
jiangzhizhou 2021-10-03 15:17:05 +08:00
@liuxu 嗯，能够理解。小公司咬咬牙上云长远来看肯定省心，只要一次事故，钱肯定回来了。个人项目这个就不好说了，丰简由人。
PS:小公司在基础设施上省钱肯定要转嫁到客户头上去的。 |
 |
54
Skmgo 2021-10-03 19:11:20 +08:00
这个问题我曾经提问过, 大家都说没问题.
|
|
56
liuxu OP @idblife 我自己的是有一堆小项目每年换服务器商能快速迁移，其次接入 github actions 自动化部署也方便很多，而且有时候突然流量来了能快速伸缩
|
 |
57
yc8332 2021-10-03 23:13:36 +08:00
有损耗是一定的。但是 10 倍我是不信，估计是你的机器资源问题。。这个和并发设置一样，并不是设置越高性能就会越高，资源不足的时候切换就越慢
|
 |
58
offswitch 2021-10-03 23:15:54 +08:00
nginx 用 return 200 再压测一下，对比一下。
|
 |
59
dcoder 2021-10-04 00:37:32 +08:00
docker, k8s 就是又慢又复杂啊...
但是, 大家都是"面向简历编程", 不妨碍浪费公司资源用这套破烂 |
 |
60
carrotrollroll 2021-10-04 10:20:24 +08:00
1. 标题说 k8s，实测用 k3s 有点标题党，k3s 本身就是为资源紧张的设备设计的，没有刻意优化高并发下的性能
2. k8s 是通过 nodeport 暴露的吗，有没有看过瓶颈在哪？ 感觉只剩不足 10%的性能有些夸张，我在生产环境大量使用 k8s 上也没遇到过（默认的 k8s 配置有 20%左右的 rps 损失） |
|
61
carrotrollroll 2021-10-04 10:22:22 +08:00
@liuxu 啥，压测是经过了 traefik ingress ？那瓶颈当然在这里了，小机器下 traefik 性能损失比较严重。。。。。。还以为你用 nodeport 暴露的呢
你测 docker 只走了 iptables 网络，测 k3s 却经过了一个性能不怎么高的 traefik ingress （比 nginx 效率低），不公平啊 |
 |
62
salmon5 2021-10-04 11:22:53 +08:00
我觉得既然压测了，就别用的有点拧巴；直接 kubeadm 部署，32C/128 、64C128G 的机器搞几台；
|
|
63
liuxu OP @carrotrollroll
k8s 系有 k8s，k3s，microk8s 等。标题是 rhel 的 yum 源慢，帖子说 centos 更新好慢有问题么 说的是小成本项目，铺个 100 台 64c128g，不管是裸机还是 docker 还是 k8s 系，最后 qps 都会相近，任何基础组件的损耗占比都可以被抹平，你还有 20%损失说明机器还不够多，再铺一倍机器损耗会到 10% @salmon5 2c4h 是我自己的站常用的配置，我觉得的小成本就是几台 2c4g，为了测试我自己的项目用的，可能每个人眼中的小成本不太一样，而且我测试常用 vultr 或者 digitalocean 这种，最高配置 8c16g |
 |
64
ZSeptember 2021-10-04 17:30:12 +08:00
你测试的这种 workload 中，网络传输是最大的瓶颈，多了一层转发，肯定会下降很多，在真实的业务场景中，影响会小很多。
然后，机器确实可能影响到测试结果，如果性能损耗这么大，肯定没那么多公司用。 |
 |
65
calmzhu 2021-10-05 01:05:25 +08:00
- k8s 用 docker runtime 确实有性能不如 containerd，k8s 已经弃用了 docker 。
- 单机配置不足不建议 k8s 。k8s 本身资源占用相对固定，配置越高，这部分资源锁定越可以忽略。 但是，也不至于拉垮到 1000kps 都困难，能看下整个性能约束点在哪，服务转发，网络处理还是后段之类的，找到约束点，而这个约束点确实是 k8s 本身设计不合理产生的那就比较有说服力。 结论的话，网络组件用的啥，服务暴露方式是什么。比如图里面 3 节点跟 4 节点后段曲线趋同，就很像节点外的单点性能瓶颈导致的 |
 |
66
kennylam777 2021-10-05 05:30:30 +08:00
直接上 hostPort，直連 nginx 再回來說 k8s 的不是，都經過了 Ingress 還有意思嗎?
|
|
67
liuxu OP 1
@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 记录来分担负载 |
 |
68
mogging 2021-11-12 12:49:55 +08:00 via Android
同意刚才看到的大佬回复: k8s 网络没选对对性能影响很大，flannel 本身就不是一个 production ready 的方案，另外 dns 解析也非常影响 QPS ，上 nodelocaldns 试试看，有话直说再对比压测才有意义。
|
Select Language