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

自认为仿 k8s 宣告失败,对于在客户的环境部署应用的一些思考

  •  
  •   JackyTsang · 2023-04-04 23:08:06 +08:00 · 2476 次点击
    这是一个创建于 578 天前的主题,其中的信息可能已经有所发展或是发生改变。

    我们公司的应用都是部署在客户的环境中的,评估过,在几百家财力不一,环境不一、技术人员以及水平不一的客户环境,整个 K8S 相当不现实,因为会很累,当然我知道 K3S/K3D 或许轻量,学习成本跟使用成本摆在那里。

    在这一两年的经验中,确立了以 docker-compose 为主体,加之其它的 12345678... 脚本完成应用、中间件、数据库的部署。

    随之而来的是一个维护问题,比方说,遇到被动迁移、改 IP 、换网段等这些 “破事”,环境变量各种改 IP ,Nacos 配置中心各种改 IP ,Nginx 、HAproxy 各种哔哩吧啦都要改,原来一直以来忽略了一个严重的问题,DNS 。

    我当然没有 Kube-DNS 、CoreDNS 还有服务发现这类的 “高科技”,docker-compose 也只是针对一台机器,其容器网络的 dns 也仅存于这个文件而已。

    这时候想到了 docker-swarm ,这个貌似被遗忘的产物,今天也算是挺有兴致地重做了某个应用的 docker-compose 文件,all-in-one ,把中间件数据库都放在一起了,初始化 docker-swarm 、创建 overlay 网络、中间件先 docker stack ,配置集群,启动,仿佛一切都很顺利,结果...

    我在 2018 年就看过一篇 2016 年的文章,就说到 docker-swarm 有着极为糟糕的性能,但是在 2023 年的今天,在最新版的 docker-ce 23.0.2 下,随意测了一下 overlay 下 redis 6.2.7 三主三从集群,

    root@redis01:/data# redis-benchmark -n 1000000 -t set,get -P 16 -q -h localhost -p 6379 --cluster
    Cluster has 3 master nodes:
    
    Master 0: 8ef74ab71432e2bd5affc9b804bae34eaa34a25a 172.200.1.122:6379
    Master 1: 37689bd72fe71800fef7b617587b58ee9cb4a7fb 172.200.1.126:6379
    Master 2: e2527a6bfa4327bb1adb6aa832a2443dc25ae654 172.200.1.128:6379
    
    SET: 361271.69 requests per second, p50=0.439 msec
    GET: 498504.47 requests per second, p50=0.311 msec
    

    再测了一下 host 下的,

    root@cnhis:/data# redis-benchmark -n 1000000 -t set,get -P 16 -q -h localhost -p 6379 --cluster
    Cluster has 3 master nodes:
    
    Master 0: 708760b7913c87ea2932248d3821dd5a4dc2afa1 192.168.100.244:6379
    Master 1: 770211c5a234fb97fe63e2fb40a939578ccbdd3a 192.168.100.240:6379
    Master 2: 304c250b7327e09a6bc4d190aa549ed0d0cfe78a 192.168.100.66:6379
    
    SET: 1331558.00 requests per second, p50=0.279 msec
    GET: 1996008.00 requests per second, p50=0.223 msec
    

    结果很明显了,我乐观了罢了。

    macvlan 据说性能好,但可惜没有 dns ,还要配置固定 IP ,繁琐不堪,所以...至此这个仿 k8s 的计划应该是宣告失败了,这或许是也 docker-swarm 失败的原因之一?

    看起来在客户环境内搭建一个 DNS 是必然的事情,或者呢?开始从 k3s/k3d 开始慢慢走向这条路吗?目前还没想通,各位有什么看法吗?

    19 条回复    2023-04-17 18:41:04 +08:00
    dayeye2006199
        1
    dayeye2006199  
       2023-04-05 00:21:49 +08:00 via Android
    这么折腾还不如上 k3s ,或者考虑 nomad
    echo1937
        2
    echo1937  
       2023-04-05 00:28:00 +08:00
    如果对方接受 all in one ,我也是用 docker-compose ,
    如果对方需求分布式,拿 3-5 台机器初始化一套 k8s 也不是太麻烦;
    docker-swarm 和 mesos 已经是历史的眼泪了。
    hrong
        3
    hrong  
       2023-04-05 00:36:03 +08:00
    客户指定 AWS ECS 保平安。。。。。。
    14
        4
    14  
       2023-04-05 00:39:14 +08:00
    我们自己是 k8s ,给客户部署也是以 docker-compose 为主,通过 ansible 实现自动化和重用
    abc612008
        5
    abc612008  
       2023-04-05 00:51:11 +08:00
    > 当然我知道 K3S/K3D 或许轻量,学习成本跟使用成本摆在那里。

    所以除了“我不会,不想学”以外还有啥不用 k3s/k3d 的原因吗
    sofukwird
        6
    sofukwird  
       2023-04-05 01:09:12 +08:00 via Android
    当年我也遇到了,最后走的宿主机 host port 模式避免性能问题
    https://docs.docker.com/compose/compose-file/compose-file-v3/#ports

    可以试试 docker network plugin 这条路子,当时走通上面那条就没再折腾这条了
    seers
        7
    seers  
       2023-04-05 08:51:43 +08:00 via Android
    我司领导不懈努力下让客户整上了阿里私有云,这下连 k8s 都不要自己搞了
    winglight2016
        8
    winglight2016  
       2023-04-05 08:55:16 +08:00
    @seers 正解,啥时代了,还不上云?
    JackyTsang
        9
    JackyTsang  
    OP
       2023-04-05 08:56:13 +08:00
    @dayeye2006199
    @abc612008

    是的,我感觉我是 old school 的典型了,虽然我知道有些客户再 “穷” 或再 “吝啬” 也可以提供最低两台配置尚可的机器,上个 K3S 问题也不大,不过,现成的 compose up 一下就能搞定的事情,就始终没有跨出这一步,这确实是我的问题。
    JackyTsang
        10
    JackyTsang  
    OP
       2023-04-05 09:02:38 +08:00
    @echo1937 我乐观以为这么多年过去了,Docker 本家也没有放弃,会好点吧?可惜了。

    @14 除了我们自身无业务以外,我们也是这么做的,就是在多机、负载均衡、高可用,以及后期维护等,经验还是欠缺了一点。

    @sofukwird 是的,我们当前就是这么做的,不过失去了 Bridge/Overlay 带来的跨机互联以及 DNS 的功能,如果要持续走 compose 的道路,就要考虑自建 DNS 了。
    JackyTsang
        11
    JackyTsang  
    OP
       2023-04-05 09:03:25 +08:00
    @seers
    @winglight2016

    很遗憾我们公司的客户,老古董老思维的占绝大多数。
    abc612008
        12
    abc612008  
       2023-04-05 09:27:52 +08:00
    @JackyTsang k3d 完全可以只跑在一台机子上,和 compose 效果一样
    seers
        13
    seers  
       2023-04-05 09:31:29 +08:00 via Android
    @JackyTsang 自建后期运维成本可高了,很多人只看到眼前
    jellyspot
        14
    jellyspot  
       2023-04-05 10:39:07 +08:00
    其实很多问题还是客户自己技术能力缺失。
    我遇到很多客户,把容器当虚拟机用,一个镜像 20g
    tomczhen
        15
    tomczhen  
       2023-04-05 12:26:35 +08:00 via Android   ❤️ 1
    验证阶段提供最简单的方式即可,性能如果够用,那么不算什么问题,docker swarm 也未尝不可。

    对于缺少技术力的用户可以考虑交付包含硬件环境,这样可以对环境更可控,也可以提高毛利,毕竟就算用用户自己的硬件维护成本也跑不掉。提供一个 onebox 解决方案开箱即用,可以解决很多问题。也不一定非要完全从零做,基于一些开源系统适配成套件 /应用就是个不错的选择,比如 truenas 之类的。
    SmiteChow
        16
    SmiteChow  
       2023-04-05 17:42:46 +08:00
    看法是你有数不清的资源和流量,非 k8s 管理不过来,例外情况 docker compose 足够了
    litchinn
        17
    litchinn  
       2023-04-06 08:50:50 +08:00   ❤️ 1
    想要用一套方案解决所有场景,这个想法就有问题
    客户这么多,完全可以根据不同场景的用户给出不同的方案,上私有云,上 k8s ,上 minikube ,只用 docker compose 。
    你看现在的某些开源软件都会给出原生部署,docker 部署,k8s 部署,helm 部署,k8s operator 等各个场景的部署方案
    dennissky
        18
    dennissky  
       2023-04-06 09:14:31 +08:00
    所以最佳答案是 k3s 吗
    sofukwird
        19
    sofukwird  
       2023-04-17 18:41:04 +08:00 via Android
    我最近又折腾下 docker swarm network ,得到最终解决方案是 ipvlan ,性能几乎无损,每个节点分配好网段就行

    https://github.com/mark-church/docs/blob/master/local-scope-swarm-networking.md#macvlan-networking
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2532 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 15:39 · PVG 23:39 · LAX 08:39 · JFK 11:39
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.