V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
liuxu
V2EX  ›  Kubernetes

k8s 系真的是 qps 杀手

  •  1
     
  •   liuxu · 66 天前 · 7925 次点击
    这是一个创建于 66 天前的主题,其中的信息可能已经有所发展或是发生改变。
    测试了下 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 系还是很香的。
    第 1 条附言  ·  65 天前
    帖子的中心思想是

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

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

    大项目要 k8s 就直接上云,或者自己搞要有能力换组件分析组件性能
    68 条回复    2021-11-12 12:49:55 +08:00
    victor
        1
    victor  
       66 天前
    生产环境我也遇到了类似的问题,结论一样,但不知道原因是啥。目前只能通过加机器的方式来增加 QPS,性价比极低。
    插个眼,看看是否有大手子解答。
    WispZhan
        2
    WispZhan  
       66 天前   ❤️ 2
    您就是传说中的标题党?

    ---

    建议直接测 k8s 。控制变量,麻烦态度严谨一点。
    Cooky
        3
    Cooky  
       66 天前
    容器影响进程 /线程上下文切换效率?
    liuxu
        4
    liuxu  
    OP
       66 天前
    @victor 目前看是 ingress 和 apiserver 这一批占用了大量 cpu
    JRyan
        5
    JRyan  
       66 天前 via iPhone
    把资源限制调高看看 容器是有一点性能损耗 但不至于低这么多
    liuxu
        6
    liuxu  
    OP
       66 天前
    @WispZhan 我并发和 rps1k10k 逐步加量测了十几组数据,给出来的这 3 张图,别张口就来伙计
    liuxu
        7
    liuxu  
    OP
       66 天前
    @JRyan htop 看 node 是 cpu 爆了
    liuxu
        8
    liuxu  
    OP
       66 天前
    @JRyan 容器损耗并不高,单独 docker 和物理机直接 nginx 差别不大,主要是 k8s 系自身占用大量资源,用的话最好有大量 node,起码 5 台以上 4C8G 最好
    JRyan
        9
    JRyan  
       66 天前 via iPhone
    可能是本身集群占用的资源
    johnsonqrr
        10
    johnsonqrr  
       66 天前   ❤️ 3
    测试:K3s
    结论:K8s
    UC 命令你马上来报道
    liuxu
        11
    liuxu  
    OP
       66 天前
    @johnsonqrr k8s 系,k3s 和 microk8s 都属于,k8s 需要的硬件基础更高
    JRyan
        12
    JRyan  
       66 天前 via iPhone
    你这可以在云上跑个集群测试就知道实际性能差异了
    opengps
        13
    opengps  
       66 天前
    io 问题并非 k8s 独有,而是虚拟化的环节损失的,搭建的虚拟机同样也是性能损失大户
    liuxu
        14
    liuxu  
    OP
       66 天前
    @Cooky 对,开了 k3s 系统直接 200 多 thread,如果 runtime 改成 dockerd,300 多 thread,cpu 爆时,主要是 nginx 、ingress(traefik ) cpu 和 k3s 自身进程 cpu 占用高
    WispZhan
        15
    WispZhan  
       66 天前 via Android
    @liuxu 自己 uc 风的标题,说我张开就来?

    另外 1 没人是你伙计
    liuxu
        16
    liuxu  
    OP
       66 天前
    @JRyan k8s 系能上云的话会更好,主要是 ingress 用云的 LB,避免和业务 pod 在同一 node,下文切换导致性能衰减
    wdlth
        17
    wdlth  
       66 天前
    没看到安装 k8s 具体的配置和测试的方法,是否启用 IPVS,是否经过 ingress,是否优化 ingress 等等。
    coolrc
        18
    coolrc  
       66 天前 via Android
    态度严谨?那是不是还要查重呢
    liuxu
        19
    liuxu  
    OP
       66 天前
    @wdlth k3s 的官方命令默认安装,没有 IPVS,ingress 也是默认的 traefik v1 。主要是上次发了一个很详细的测试贴被人喷太多不想看,所以这次直接给图了。

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

    全部测这十一假期都测不完,万一某些没说清楚还要被楼上喷态度不严谨,或者喷你 UC 标题党
    mengdodo
        20
    mengdodo  
       66 天前
    这个问题我看到了不止你一篇帖子,都是这个结论,小企业小应用不适用
    Nitroethane
        21
    Nitroethane  
       66 天前 via iPhone
    我记得之前看过一篇文章,说 kube-proxy 使用 iptables 模式时会有随机丢包的情况出现。建议用 ipvs 模式再测测
    Actrace
        22
    Actrace  
       66 天前
    哈哈,k8s 的很多情况都是典型的为了解决一个问题而带来更多的问题。

    运维领域其实非常专业,目前还没有出现能解决一切问题的万金油。
    momocraft
        23
    momocraft  
       66 天前
    k3s 已经是号称轻量了 那完整的 k8s 会不会更严重
    joesonw
        24
    joesonw  
       66 天前 via iPhone   ❤️ 1
    k8s 网络没选对对性能影响很大。每个节点的 kubelet,网络 ds,日志等很多基础组件都是有消耗的。2c4g 作为生产确实太小,一般都是 8c/16c 起步。一个简单的 nginx static server 肯定比直接跑要差,还是要看业务场景。
    wellsc
        25
    wellsc  
       66 天前 via iPhone
    问好
    wellsc
        26
    wellsc  
       66 天前 via iPhone
    ihciah
        27
    ihciah  
       66 天前
    cri 没控制变量,也没有 cpu 占用率的数据,同时你的 docker 网络模式,cni 用的啥也没讲。
    就一个延迟数据,谁知道是哪块导致的呢。你这个数据没办法科学严谨地推导出你的结论。
    ToBeHacker
        28
    ToBeHacker  
       66 天前
    性能肯定是有影响的,k8s 这样的架构本身就是为了牺牲一定的性能来换取伸缩性与可维护性。
    1 、最好拿 k8s 来测试,实际生产环境用 k3s 还是相对少一些的
    2 、network 层对性能影响很大,实际上可能并不是 k8s 的锅,而是网络层的损耗导致的性能问题
    ch2
        29
    ch2  
       65 天前   ❤️ 3
    这种牺牲是必要的,各个组件不可能不占计算资源就把调度做好
    就算你起个 nginx 接 upstream,nginx 自己也能占满你一台机器的 cpu
    fkdog
        30
    fkdog  
       65 天前
    "裸 docker run 并发 10k,rps 30k 。k3s 直接降到并发 1k,rps 1k"
    如果是这种降法,那我感觉可能是哪方面配置出了问题。牺牲换取伸缩弹性很好理解,但是能牺牲 10 倍 30 倍这种性能的,我理解不了。
    Reficul
        31
    Reficul  
       65 天前 via Android
    ingress 没用云的 lb 的话,过了一层 nodeport ( iptables ),cni 的 pod 网络,clusterip ( iptables ),再 cni 的 pod 网络。 单纯 docker run 的话可能都是 host 网络,差别很大
    cassyfar
        32
    cassyfar  
       65 天前
    你要确保那个 node 只跑你自己服务的 pod 再做压测对比。k8s 需要的硬件资源肯定是比 docker 多的啊。
    swulling
        33
    swulling  
       65 天前 via iPhone   ❤️ 1
    你可以直接用 daemonset 加 hostnetwork=true 来测。
    swulling
        34
    swulling  
       65 天前 via iPhone   ❤️ 1
    如果是通过 k3s 默认的 ingress,那么整个流量过程是 ingress-ipvs-nginx,加上你的服务器才 2c4g,性能差是理所当然的。

    至于 k3s 自身组件,流量又不过他们,那些是控制面,也只是占点资源而已。
    kiripeng
        35
    kiripeng  
       65 天前
    多过一层网络了
    dusu
        36
    dusu  
       65 天前 via iPhone
    说个恐怖故事:裸跑 docker 都还有 10-20%的 qps 损失
    ospider
        37
    ospider  
       65 天前   ❤️ 1
    你这目标机器太小了,资源都用来跑 k3s 了,那可不是性能低么?你弄个 16C64G 的机器测测,看看还是相同结论么?
    ericbize
        38
    ericbize  
       65 天前 via iPhone
    容器内部优化试一下
    plko345
        39
    plko345  
       65 天前 via Android
    画图用什么工具?有时间我也测一波,用 k8s
    liuxu
        40
    liuxu  
    OP
       65 天前 via Android
    @plko345 http://hdrhistogram.org/

    wrk2 github 文档中有说明,压测参数带-L,输出到 txt 上传,可以一次上传多和 txt,每个都是一条线
    yidinghe
        41
    yidinghe  
       65 天前 via Android   ❤️ 1
    @WispZhan 懂你就多说两句,这么多人看着呢,要么别张嘴,张嘴就要讲出有说服力的话,不然自己名声没了
    choury
        42
    choury  
       65 天前
    用容器方案可优化的地方多了,用默认配置跑当然性能不行,cpu 绑核,中断绑定,网络模式这些,甚至日志打的多了都会影响性能
    guyskk0x0
        43
    guyskk0x0  
       65 天前 via Android
    一般业务代码 2c4g 机器只能跑到几十上百 QPS,响应时间 50ms 左右。index.html 太小了,响应时间太短。
    liuxu
        44
    liuxu  
    OP
       65 天前 via Android
    @guyskk0x0 我掐指一算你要么是个 java 写中台的,要么是个 php 但是用的 laravel /dog
    HelloAmadeus
        45
    HelloAmadeus  
       65 天前 via iPhone
    2c4g 基本上 CPU 和内存都被 k8s 占了吧,配置太低了
    guyskk0x0
        46
    guyskk0x0  
       65 天前
    @liuxu #42 问题不在语言框架,只要用了数据库,或是请求了外部接口,响应时间和 QPS 都是这个水平。仅讨论问题,没必要瞎猜,而且你都猜错了。
    tinkerer
        47
    tinkerer  
       65 天前
    @liuxu 你这一路点评下来,到底是为了找到问题根源还是想证明自己正确?
    jiangzhizhou
        48
    jiangzhizhou  
       65 天前
    上云很贵嘛? EKS ?
    好奇为什么要自己运维,友善讨论。
    liuxu
        49
    liuxu  
    OP
       65 天前 via Android
    @guyskk0x0 就认真讨论问题话,2h4g 的 qps 简单业务用上异步框架可以过 1-2k,没有的话建议跑下 profile 分析下,以及数据库性能
    liuxu
        50
    liuxu  
    OP
       65 天前 via Android
    @tinkerer 要分析 k3s 发帖回帖是找不到答案的,找答案要自己分析系统 profile,主要是我自己的几个网站用的 k3s 后 qps 极速下降,我还以为是 cf 的问题,这测了下才知道是 k3s 导致
    liuxu
        51
    liuxu  
    OP
       65 天前 via Android
    @jiangzhizhou 很贵,按楼上大佬的意思搞几台 16c64g,简单的 4c8g 每个月小几千,个人项目和小公司很难负担吧
    uucloud
        52
    uucloud  
       65 天前
    裸 docker 跑有限制 cgroup 吗,同 cpu limit 下跑的差 10 倍? 感觉有点离谱...大概率是实验设计的有问题
    jiangzhizhou
        53
    jiangzhizhou  
       65 天前
    @liuxu 嗯,能够理解。小公司咬咬牙上云长远来看肯定省心,只要一次事故,钱肯定回来了。个人项目这个就不好说了,丰简由人。
    PS:小公司在基础设施上省钱肯定要转嫁到客户头上去的。
    Skmgo
        54
    Skmgo  
       65 天前
    这个问题我曾经提问过, 大家都说没问题.
    idblife
        55
    idblife  
       65 天前 via iPhone
    @liuxu
    如果没那么多预算,说明项目不大,用 k8s 的考虑是啥呢?
    liuxu
        56
    liuxu  
    OP
       65 天前
    @idblife 我自己的是有一堆小项目每年换服务器商能快速迁移,其次接入 github actions 自动化部署也方便很多,而且有时候突然流量来了能快速伸缩
    yc8332
        57
    yc8332  
       64 天前
    有损耗是一定的。但是 10 倍我是不信,估计是你的机器资源问题。。这个和并发设置一样,并不是设置越高性能就会越高,资源不足的时候切换就越慢
    offswitch
        58
    offswitch  
       64 天前
    nginx 用 return 200 再压测一下,对比一下。
    dcoder
        59
    dcoder  
       64 天前
    docker, k8s 就是又慢又复杂啊...

    但是, 大家都是"面向简历编程", 不妨碍浪费公司资源用这套破烂
    carrotrollroll
        60
    carrotrollroll  
       64 天前
    1. 标题说 k8s,实测用 k3s 有点标题党,k3s 本身就是为资源紧张的设备设计的,没有刻意优化高并发下的性能
    2. k8s 是通过 nodeport 暴露的吗,有没有看过瓶颈在哪?
    感觉只剩不足 10%的性能有些夸张,我在生产环境大量使用 k8s 上也没遇到过(默认的 k8s 配置有 20%左右的 rps 损失)
    carrotrollroll
        61
    carrotrollroll  
       64 天前
    @liuxu 啥,压测是经过了 traefik ingress ?那瓶颈当然在这里了,小机器下 traefik 性能损失比较严重。。。。。。还以为你用 nodeport 暴露的呢

    你测 docker 只走了 iptables 网络,测 k3s 却经过了一个性能不怎么高的 traefik ingress (比 nginx 效率低),不公平啊
    salmon5
        62
    salmon5  
       64 天前
    我觉得既然压测了,就别用的有点拧巴;直接 kubeadm 部署,32C/128 、64C128G 的机器搞几台;
    liuxu
        63
    liuxu  
    OP
       64 天前
    @carrotrollroll

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

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

    @salmon5

    2c4h 是我自己的站常用的配置,我觉得的小成本就是几台 2c4g,为了测试我自己的项目用的,可能每个人眼中的小成本不太一样,而且我测试常用 vultr 或者 digitalocean 这种,最高配置 8c16g
    ZSeptember
        64
    ZSeptember  
       64 天前
    你测试的这种 workload 中,网络传输是最大的瓶颈,多了一层转发,肯定会下降很多,在真实的业务场景中,影响会小很多。
    然后,机器确实可能影响到测试结果,如果性能损耗这么大,肯定没那么多公司用。
    calmzhu
        65
    calmzhu  
       63 天前
    - k8s 用 docker runtime 确实有性能不如 containerd,k8s 已经弃用了 docker 。
    - 单机配置不足不建议 k8s 。k8s 本身资源占用相对固定,配置越高,这部分资源锁定越可以忽略。

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

    结论的话,网络组件用的啥,服务暴露方式是什么。比如图里面 3 节点跟 4 节点后段曲线趋同,就很像节点外的单点性能瓶颈导致的
    kennylam777
        66
    kennylam777  
       63 天前
    直接上 hostPort,直連 nginx 再回來說 k8s 的不是,都經過了 Ingress 還有意思嗎?
    liuxu
        67
    liuxu  
    OP
       63 天前
    @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
        68
    mogging  
       25 天前 via Android
    同意刚才看到的大佬回复: k8s 网络没选对对性能影响很大,flannel 本身就不是一个 production ready 的方案,另外 dns 解析也非常影响 QPS ,上 nodelocaldns 试试看,有话直说再对比压测才有意义。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2620 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 14:22 · PVG 22:22 · LAX 06:22 · JFK 09:22
    ♥ Do have faith in what you're doing.