雲計算之路-阿里雲上-容器難容：容器服務故障以及自建 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 集羣，掛載到同一個負載均衡下，只有全部集羣所有宕機纔會形成網站訪問故障。