选型

业务类型 允许短时间（数秒内）部分业务中断，不允许超过1分钟以上的故障。 现有服务 多为无状态服务，一部分为半无状态，另外有redis和pgsql 。
服务器 目前共有 12台 目前10台在线 2台冗余热备。主要是阿里云和腾讯云，另有两台异地pve。
首先说，服务器有一些本身是云厂商的活动价格购入的，配置2H2G那种。k8s肯定是不适合，太重。k3s只能说是空服务的是内存占用可以（本身512M左右内存），开启服务后和k8s并没有明显有时。
除去性能的占用，k8s/k3s集群公网通讯开支较大。容器数量只有几十个，机器不到10台，所以无论如何Kubernetes都不适合目前的场景。
其次考虑到 mesos,无奈了解太少，加上过于非主流了，所以没有去尝试。
然后目光就投到了 docker swarm。

docker swarm 优势

• 硬件资源占用很低，cpu和内存占用可以忽略不计
• 节点之间公网通讯带宽占用在10-几十K，可以忽略不计。
• 原docker/podman容器迁移成本时间成本极低，毕竟docker自家的，docker compose yml略微修改就可以。
• partainer 够轻量，够直观，也足够docker swarm的图形化管理（毕竟有时候还是需要直观的查看的服务的分布情况）

docker swarm 的缺点

只针对目前项目的情况的一些看法

• 日后迁移云k8s需要二次折腾，目前主流云厂商都放弃了docker swarm
• 可能B格不够 有人为阻力

服务的处理

半无状态服务（弱持久化储存依赖的）

无状态服务没啥可说的，但是有一些半无状态的服务，需要存取数据。在从手动管理docker升到swarm的时候需要简单处理一下。

• 尽可能 使用constraint参数 把服务分布指定的某台或某组机器上。
• 使用云储存，在云主机上使用内网读写对应的数据。

有状态服务redis/mysql

项目里面存在3个redis集群 一个pgsql主从。

• 原则上 尽可能的使用云厂商的，不自建。非要自建的情况参考下文
• 使用constraint参数 把服务分布指定的某台或某组机器上。
• 读写不频繁的文件，例如redis的 rdb/aof 直接到云储存上。
• 读写频繁但是可用性要求不高的文件，直接落地到机器的硬盘上，然后定时同步到云储存。
• 读写频繁并且可用性要求高的文件，直接落地云储存或者直接用云厂商的服务。比如pgsql

实践

• 配置项目 尽可能使用环境变量，直接到swarm的服务里面。
• 配置项目 只能使用配置文件的，配置文件到云储存。使用 docker rclone插件，直接绑定到docker卷。
• 嵌入式kv，写频繁但是允许短时间丢失的，落地硬盘，并定时同步到的云储存。
• redis持久化文件 使用 docker rclone插件，直接绑定到docker卷。