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

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