不错，有点抽象的味道(非贬义)

是不是你的服务器开了 ip 白名单？

@kyonn Jokesy 说的 ds 指的应该是 DaemonSet 这种类型的负载。

docker swarm 也有和这个类似的机制： https://docs.docker.com/reference/compose-file/deploy/#mode
就是用 global 模式，和 k8s DaemonSet 的效果几乎一样，也会在集群里面每个节点都运行一个实例。

你的这个需求挺简单的，写好 docker compose yaml 之后(写好镜像、挂载目录)，然后补充上 depoy 的那部分就好了(指定一下模式，资源限制)，然后 deploy 一下就好了。

如果我来选的话，我会选 docker swarm 。

如果对 k8s 不熟悉的话，用 docker swarm 也是一个很不错的选择。

docker swarm 优势就是简单，有 docker compose 使用经验的话，上手很容易。装好 docker 后，执行加入集群的命令就好了。

docker swarm 也支持创建 daemon 类型的服务，还是很符合你描述的使用场景的。

哈哈，我之前做了一个，写着玩的没开源。

浏览器装上了插件之后，会同步当前的 tab 到服务端，用 websocket 个服务器同步状态。

服务器会下发命令，执行 js ，获取网页内容等等。

服务端下发任务的时候，可以随机分配任务到连接的客户端上，执行分布式任务。。

做出来了之后特别像后门软件，可以在没有察觉的情况下监控浏览器的上网情况。。。

突发性能实例优势就是便宜，价格比其他同规格的实例少很多。

主要区别就是它有 cpu 积分，如果负载高于基准值，超过的部分就会开始扣 cpu 积分，负载低于基准的时候 cpu 积分会慢慢加回来。

根据这个规则，如果你的业务高峰时间比较短，cpu 使用率超过基准值的时间只有几个小时，那么积分肯定是够用的，这点基本不用担心。

但是问题也很明显，如果其他虚拟机同时刻都在消耗大量的 cpu 资源，分配给每个虚拟机的资源肯定会更少。考虑到其他虚拟机也都是低负载情况，我感觉出现的概率应该不高，我自己实测也是这样。所以如果追求性能稳定释放的话，肯定是只能选别的规格了。

---
我看你描述的问题，我感觉大概率不是实例的问题，建议看看是不是内存不够了，卡住的那个时间点是不是 内存 和 磁盘 io 100% 了。

@realpg 70% 确实是保守了，说多了我怕被喷。。。

一般云上 debian 系的都是 netplan 配置，桌面的大多都是 NetworkManager 来配置(可能是因为 NetworkManager 有 gui 前端吧)

@5xX4U5sUwdELgdQ3 op 贴出来的文档是没错的，一般云上都是用的云镜像 cloud-init 初始化的系统，云镜像 debian 是用的 netplan 。

如果京东能做到像商城自营那样的服务，我觉得还是有前景的。

@967182 并不是释放的问题，据我的观察，最少 70%的开发对自己开发的系统，需要用多少资源、能用多少资源，是需要内存还是 CPU 还是磁盘 IO 读写，这些问题完全没啥概念。然后配置就直接拉满了。

就直接导致了上线之后各种资源使用率 0%的情况。

提高服务器资源利用率我觉得完全没问题。能理解并且支持。

@wryyyyyyyyyyyy 我现在正在用的这个键盘应该和你的是同款 84 键 35g ，今年是第 8 年了。

可是猴子也会用工具呀

从去年起从 iOS 换到了 Android ，基本赞同 op 的说法。

看看是不是运行中的容器占用了，比如说写了很多日志文件放在容器里面。