云计算之路-阿里云上-容器难容：容器服务故障以及自建 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 节点时，出现下面的错误

The swarm does not have a leader. It's possible that too few managers are online. Make sure more than half of the managers are online.

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

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

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

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