我们公司的应用都是部署在客户的环境中的,评估过,在几百家财力不一,环境不一、技术人员以及水平不一的客户环境,整个 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 开始慢慢走向这条路吗?目前还没想通,各位有什么看法吗?
1
dayeye2006199 2023-04-05 00:21:49 +08:00 via Android
这么折腾还不如上 k3s ,或者考虑 nomad
|
2
echo1937 2023-04-05 00:28:00 +08:00
如果对方接受 all in one ,我也是用 docker-compose ,
如果对方需求分布式,拿 3-5 台机器初始化一套 k8s 也不是太麻烦; docker-swarm 和 mesos 已经是历史的眼泪了。 |
3
hrong 2023-04-05 00:36:03 +08:00
客户指定 AWS ECS 保平安。。。。。。
|
4
14 2023-04-05 00:39:14 +08:00
我们自己是 k8s ,给客户部署也是以 docker-compose 为主,通过 ansible 实现自动化和重用
|
5
abc612008 2023-04-05 00:51:11 +08:00
> 当然我知道 K3S/K3D 或许轻量,学习成本跟使用成本摆在那里。
所以除了“我不会,不想学”以外还有啥不用 k3s/k3d 的原因吗 |
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 这条路子,当时走通上面那条就没再折腾这条了 |
7
seers 2023-04-05 08:51:43 +08:00 via Android
我司领导不懈努力下让客户整上了阿里私有云,这下连 k8s 都不要自己搞了
|
8
winglight2016 2023-04-05 08:55:16 +08:00
@seers 正解,啥时代了,还不上云?
|
9
JackyTsang OP @dayeye2006199
@abc612008 是的,我感觉我是 old school 的典型了,虽然我知道有些客户再 “穷” 或再 “吝啬” 也可以提供最低两台配置尚可的机器,上个 K3S 问题也不大,不过,现成的 compose up 一下就能搞定的事情,就始终没有跨出这一步,这确实是我的问题。 |
10
JackyTsang OP |
11
JackyTsang OP |
12
abc612008 2023-04-05 09:27:52 +08:00
@JackyTsang k3d 完全可以只跑在一台机子上,和 compose 效果一样
|
13
seers 2023-04-05 09:31:29 +08:00 via Android
@JackyTsang 自建后期运维成本可高了,很多人只看到眼前
|
14
jellyspot 2023-04-05 10:39:07 +08:00
其实很多问题还是客户自己技术能力缺失。
我遇到很多客户,把容器当虚拟机用,一个镜像 20g |
15
tomczhen 2023-04-05 12:26:35 +08:00 via Android 1
验证阶段提供最简单的方式即可,性能如果够用,那么不算什么问题,docker swarm 也未尝不可。
对于缺少技术力的用户可以考虑交付包含硬件环境,这样可以对环境更可控,也可以提高毛利,毕竟就算用用户自己的硬件维护成本也跑不掉。提供一个 onebox 解决方案开箱即用,可以解决很多问题。也不一定非要完全从零做,基于一些开源系统适配成套件 /应用就是个不错的选择,比如 truenas 之类的。 |
16
SmiteChow 2023-04-05 17:42:46 +08:00
看法是你有数不清的资源和流量,非 k8s 管理不过来,例外情况 docker compose 足够了
|
17
litchinn 2023-04-06 08:50:50 +08:00 1
想要用一套方案解决所有场景,这个想法就有问题
客户这么多,完全可以根据不同场景的用户给出不同的方案,上私有云,上 k8s ,上 minikube ,只用 docker compose 。 你看现在的某些开源软件都会给出原生部署,docker 部署,k8s 部署,helm 部署,k8s operator 等各个场景的部署方案 |
18
dennissky 2023-04-06 09:14:31 +08:00
所以最佳答案是 k3s 吗
|
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 |