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

[JackyTsang]

我们公司的应用都是部署在客户的环境中的，评估过，在几百家财力不一，环境不一、技术人员以及水平不一的客户环境，整个 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 开始慢慢走向这条路吗？目前还没想通，各位有什么看法吗？

[dayeye2006199]

这么折腾还不如上 k3s ，或者考虑 nomad

[echo1937]

如果对方接受 all in one ，我也是用 docker-compose ，
如果对方需求分布式，拿 3-5 台机器初始化一套 k8s 也不是太麻烦；
docker-swarm 和 mesos 已经是历史的眼泪了。

[hrong]

客户指定 AWS ECS 保平安。。。。。。

[14]

我们自己是 k8s ，给客户部署也是以 docker-compose 为主，通过 ansible 实现自动化和重用

[abc612008]

> 当然我知道 K3S/K3D 或许轻量，学习成本跟使用成本摆在那里。

所以除了“我不会，不想学”以外还有啥不用 k3s/k3d 的原因吗

[sofukwird]

当年我也遇到了，最后走的宿主机 host port 模式避免性能问题
https://docs.docker.com/compose/compose-file/compose-file-v3/#ports

可以试试 docker network plugin 这条路子，当时走通上面那条就没再折腾这条了

[seers]

我司领导不懈努力下让客户整上了阿里私有云，这下连 k8s 都不要自己搞了

[winglight2016]

@seers 正解，啥时代了，还不上云？

[JackyTsang]

@dayeye2006199
@abc612008

是的，我感觉我是 old school 的典型了，虽然我知道有些客户再 “穷” 或再 “吝啬” 也可以提供最低两台配置尚可的机器，上个 K3S 问题也不大，不过，现成的 compose up 一下就能搞定的事情，就始终没有跨出这一步，这确实是我的问题。

[JackyTsang]

@echo1937 我乐观以为这么多年过去了，Docker 本家也没有放弃，会好点吧？可惜了。

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

@sofukwird 是的，我们当前就是这么做的，不过失去了 Bridge/Overlay 带来的跨机互联以及 DNS 的功能，如果要持续走 compose 的道路，就要考虑自建 DNS 了。

[JackyTsang]

@seers
@winglight2016

很遗憾我们公司的客户，老古董老思维的占绝大多数。

[abc612008]

@JackyTsang k3d 完全可以只跑在一台机子上，和 compose 效果一样

[seers]

@JackyTsang 自建后期运维成本可高了，很多人只看到眼前

[jellyspot]

其实很多问题还是客户自己技术能力缺失。
我遇到很多客户，把容器当虚拟机用，一个镜像 20g

[tomczhen]

验证阶段提供最简单的方式即可，性能如果够用，那么不算什么问题，docker swarm 也未尝不可。

对于缺少技术力的用户可以考虑交付包含硬件环境，这样可以对环境更可控，也可以提高毛利，毕竟就算用用户自己的硬件维护成本也跑不掉。提供一个 onebox 解决方案开箱即用，可以解决很多问题。也不一定非要完全从零做，基于一些开源系统适配成套件 /应用就是个不错的选择，比如 truenas 之类的。

[SmiteChow]

看法是你有数不清的资源和流量，非 k8s 管理不过来，例外情况 docker compose 足够了

[litchinn]

想要用一套方案解决所有场景，这个想法就有问题
客户这么多，完全可以根据不同场景的用户给出不同的方案，上私有云，上 k8s ，上 minikube ，只用 docker compose 。
你看现在的某些开源软件都会给出原生部署，docker 部署，k8s 部署，helm 部署，k8s operator 等各个场景的部署方案

[dennissky]

所以最佳答案是 k3s 吗

[sofukwird]

我最近又折腾下 docker swarm network ，得到最终解决方案是 ipvlan ，性能几乎无损，每个节点分配好网段就行

https://github.com/mark-church/docs/blob/master/local-scope-swarm-networking.md#macvlan-networking