在上次遭遇 docker swarm 集羣故障後,咱們將 docker 由 17.10.0-ce 升級爲最新穩定版 docker 17.12.0-ce 。html
前天晚上22:00以後集羣中的2個節點忽然出現CPU波動,在CPU波動以後,在凌晨夜深人靜、訪問量極低的時候,整個集羣出現了故障,訪問集羣上的全部站點都出現了502,過了一段時間後自動恢復正常。node
ECS實例:swarm1-node5,CPU百分比於00:52發生告警,值爲96.14%,持續時間0分鐘docker
。。。網絡
昨天早上發現訪問部分節點中的容器應用響應有些慢,因而咱們經過阿里雲控制檯強制重啓這些節點後恢復正常。阿里雲
今天上午咱們在集羣上更新一個應用時(部署新的鏡像),出現了奇怪的問題。應用是在 swarm1-node1 這個 manager 節點上部署的,部署後容器運行在其餘節點上,但奇怪的是隻有在 swarm1-node1 這個節點上能夠正常訪問容器中的站點,在其餘節點上訪問都是 503 ,用 docker stack rm 命令刪除應用並從新部署問題依舊。code
當時 docker-flow-proxy(路由應用) 的 2 個容器都是部署在 swarm1-node1 節點上的,從問題現象看,在 swarm1-node1 節點上 docker-flow-proxy 容器與外界的通訊正常,docker-flow-proxy 容器與其餘節點上的容器的 overlay 網絡(網絡A)通訊正常;在其餘節點上,外界的請求經過 overlay 網絡(網絡B)被正常轉發到 docker-flow-proxy 容器,卻不能被正常路由到其餘節點上對應的容器(也是經過 overlay 網絡A)。對這個奇怪現象實在想不通,可是問題擺在那,想不通也要解決。想不通背後的緣由,那咱們換個角度,其餘節點都異常,就 swarm1-node1 正常,根據少數服從多數的粗暴原則,那就認爲 swarm1-node1 不正常吧。因而經過下面的命令將 swarm1-node1 節點下線:htm
docker node update --availability drain swarm1-node1
swarm1-node1 下線後,其餘節點都恢復了正常,果真是 swarm1-node1 不正常。blog
swarm1-node1 下線的背後是 docker-flow-proxy 容器換到其餘節點上運行。路由
問題就這樣被猜想解決了。部署