云计算之路-阿里云上-2017年最错误的选择： 生产环境使用 docker swarm
<p>2017年12月29日 10:18 ~ 11:00 左右，由于整个 docker swarm 集群宕机，造成我们迁移至 .net core 跑在 docker swram 上的所有站点无法正常访问，由此给您带来很大很大的麻烦，请您谅解。受这次故障影响的站点有 闪存，博问，班级，园子，短信息，招聘，小组，openapi ...</p><p>2017年，随着将一个一个项目从 .net framework 迁移至 .net core ，我们兴奋地在部署上迈出了重要的一步——终于可以进行 docker 部署了。对于 docker 集群的选型，我们最终选择了 docker swarm ，因为 docker swarm 的简单，因为 docker swarm 与 docker 结合的天衣无缝，因为 docker swarm 已经经历了多年的磨练与发展，因为阿里云对 docker 支持的与时俱进，我们想应该不会有什么大坑。</p>
<p>但是，我们错了，大错特错。一次一次的 docker swarm 集群的不稳定让我们痛苦不堪，不管是开发环境，还是生产环境，有时少数节点宕机，有时多数节点宕机造成整个集群宕机，有时节点看似正常而实际节点的overlay网络无法进行正常通信。。。当出现节点宕机时，多数情况下通过阿里云控制台1次或多次重启服务器可以恢复正常，但有时多数 manager 节点出现宕机，重启后集群无法恢复，只有重建整个集群，我们今天遇到的故障就属于这种情况。</p>
<p>从我们一次次遇到的生产集群宕机情况看，宕机发生的概率可能与集群中节点的持续运行时间有关，当我们将集群中的所有节点通过阿里云控制台重启后的一段时间内，不会出现宕机问题。这次故障是发生在集群持续运行25天之后。接下来，我们会每隔2周重启一下集群中的所有节点，看是否还会出现节点宕机的问题。</p>
<p>我们的 docker swarm 集群节点使用了 5 台阿里云 2 核 4 G的独享服务器（VPC网络），3 个 manager 节点，2 个 worker 节点，运行的容器在 50 个之内，docker 版本是 Docker version 17.10.0-ce, build f4ffd25 。</p>
<p>我们真的不知道这是 docker swarm 的问题，还是阿里云的问题，但是我们知道这是我们选择的问题，我们要为我们的选择负责，想尽一切办法避免再次出现整个集群宕机的问题。再次请大家谅解这次故障给您带来的麻烦。</p><br><br>
来源：https://www.cnblogs.com/cmt/p/8143854.html
頁:
[1]