云计算之路-阿里云上-容器难容：容器服务故障以及自建 docker swarm 集群故障

3月21日，由于使用阿里云服务器自建 docker swarm 集群的不稳定，我们将自建 docker swarm 集群上的所有应用切换阿里云容器服务 swarm 版（非swarm mode）。

3月22日，我们进行移除与重启节点的操作时引发了故障，详见 云计算之路-阿里云上-容器服务：移除节点引发博问站点短暂故障 。

3月24日，我们参考阿里云容器服务帮助文档-指定多节点调度通过给节点添加用户标签的方式成功移除了部分节点。我们是这么操作的，当时所有节点没有添加用户标签，给待移除节点之外的所有节点添加了“group:1”标签，在编排文件的 environment 配置中添加了“constraint:group==1”，对待移除节点上部署的所有应用进行“变更配置”操作（选中“重新调度”）。

3月31日（昨天），16:00 左右，我们再次进行移除节点的操作。由于上次操作时已给所有节点打上了“group:1”标签，这次操作时就需要删除待移除节点的“group:1”标签，然后进行“变更配置”+“重新调度”。但操作后发现不起作用，待移除节点上的所有应用容器纹丝不动。多次操作，一次次仔细检查操作步骤，未发现任何问题，而容器依然与待移除节点在一起，我们似乎听到容器对节点说“You jump, I jump”。被容器与节点在一起的决心所打动，再加上实在找不到其他解决方法，我们决定铤而走险——直接移除这个节点，但这不是盲目的选择，是基于一个前提——这个节点上对应的应用都有2个容器，并且部署在不同的节点上。结果幸运的是冒险成功，节点成功移除，容器与节点比翼双飞，这些应用剩下的部署在其他节点上的容器正常提供服务。

在移除节点后，我们向集群中添加了一个同样配置的新节点。

之后，我们准确对集群中的一个节点进行重启，为了避免重启节点引发故障，我们参考阿里云容器服务帮助文档-容器重新调度在编排文件的 environment 中添加了 “reschedule:on-node-failure”，17: 00 左右重启了节点服务器。

17:20 左右，悲剧开始上演了。。。

一边接到 CPU 报警

一边发现集群上的部分站点 503

一边发现有节点离线

怎么回事？重启节点时，那个被重启节点上的容器被迁移到了配置最低、容器最多的节点上，造成那个节点 CPU 100%，为什么不迁移到新加的节点上？

干脆把这个挂掉的节点移除吧，却发现移除按钮为灰色，不可点，只好重启节点。。。

又发现另外一个低配节点出现同样的问题，但可以移除，先将之移除。。。

在这期间越来越多的站点出现 503 。。。

将开始移除的高配节点加入进来。。。

后来节点逐步恢复了正常，然后一个一个“重新部署”应用，有些应用恢复了。但很多应用不管“重新部署”还是“变更配置”，依然503，虽然阿里云容器服务控制台显示应用正常，其实容器列表中一个容器没有，只能通过容器服务控制台一个一个删除并重新创建应用，重建后容器都起来了，多数应用恢复了正常。但发现有些跑在容器中的内部服务连不上，排查发现集群的服务发现出现了问题，解析出来的 IP 地址与实际运行的容器的 IP 地址不匹配，很可能是解析的是已经删除的容器的 IP 。

被迫无奈，只能赶紧创建 docker swarm 集群，将那些始终无法恢复的应用先迁移过来。

直到 19:30 左右才基本恢复正常。

后来，我们将阿里云容器服务中的所有应用全部迁移回自建 docker swarm 集群。但在 22:35 左右，docker swarm 集群的 2 个 worker 节点宕机造成故障，当时只有 1 manger 节点 2 个 worker 节点，重启 worker 节点后 22:45 左右恢复正常。

然后往集群中加节点，在加第 2 个 manager 节点时，出现下面的错误

郁闷至极，我们知道 2 个 manager 节点会出现这个问题，但我们是想从 1 个 manager 加到 3 个 manager 节点，必然要经过 2 个 manager ，就那一会就出现了集群群龙无首的问题。

在 23:15 左右再次出现故障，只能重建集群，刚建好集群不久，因为 1 个 manager 节点出现问题又出现故障，最后将这个 manager 节点退出并重新加入集群后，在 23:25 左右恢复正常。

非常抱歉，昨天下午到晚上的故障给您带来了很大的麻烦，请您谅解！

接下来，我们将要采取的应对措施是同时部署多个自建 docker swarm 集群，挂载到同一个负载均衡下，只有所有集群全部宕机才会造成网站访问故障。