這篇文章主要介紹docker中swarm集群故障與異常的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！
具體如下：
在上次遭遇 docker swarm 集群故障后，我們將 docker 由 17.10.0-ce 升級為最新穩(wěn)定版 docker 17.12.0-ce 。
前天晚上22:00之后集群中的2個節(jié)點突然出現(xiàn)CPU波動，在CPU波動之后，在凌晨夜深人靜、訪問量極低的時候，整個集群出現(xiàn)了故障，訪問集群上的所有站點都出現(xiàn)了502，過了一段時間后自動恢復(fù)正常。
ECS實例：swarm1-node5，CPU百分比于00:52發(fā)生告警，值為96.14%，持續(xù)時間0分鐘
。。。
昨天早上發(fā)現(xiàn)訪問部分節(jié)點中的容器應(yīng)用響應(yīng)有些慢，于是我們通過阿里云控制臺強制重啟這些節(jié)點后恢復(fù)正常。
今天上午我們在集群上更新一個應(yīng)用時（部署新的鏡像），出現(xiàn)了奇怪的問題。應(yīng)用是在 swarm1-node1 這個 manager 節(jié)點上部署的，部署后容器運行在其他節(jié)點上，但奇怪的是只有在 swarm1-node1 這個節(jié)點上可以正常訪問容器中的站點，在其他節(jié)點上訪問都是 503 ，用 docker stack rm 命令刪除應(yīng)用并重新部署問題依舊。
當時 docker-flow-proxy（路由應(yīng)用） 的 2 個容器都是部署在 swarm1-node1 節(jié)點上的，從問題現(xiàn)象看，在 swarm1-node1 節(jié)點上 docker-flow-proxy 容器與外界的通信正常，docker-flow-proxy 容器與其他節(jié)點上的容器的 overlay 網(wǎng)絡(luò)（網(wǎng)絡(luò)A）通信正常；在其他節(jié)點上，外界的請求通過 overlay 網(wǎng)絡(luò)（網(wǎng)絡(luò)B）被正常轉(zhuǎn)發(fā)到 docker-flow-proxy 容器，卻不能被正常路由到其他節(jié)點上對應(yīng)的容器（也是通過 overlay 網(wǎng)絡(luò)A）。對這個奇怪現(xiàn)象實在想不通，但是問題擺在那，想不通也要解決。想不通背后的原因，那我們換個角度，其他節(jié)點都異常，就 swarm1-node1 正常，根據(jù)少數(shù)服從多數(shù)的粗暴原則，那就認為swarm1-node1 不正常吧。于是通過下面的命令將swarm1-node1 節(jié)點下線：
docker node update --availability drain swarm1-node1
swarm1-node1 下線后，其他節(jié)點都恢復(fù)了正常，果然是 swarm1-node1 不正常。
swarm1-node1 下線的背后是 docker-flow-proxy 容器換到其他節(jié)點上運行。
問題就這樣被猜測解決了。
以上是“docker中swarm集群故障與異常的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)成都網(wǎng)站設(shè)計公司行業(yè)資訊頻道！
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。
重慶分公司
重慶分公司
