現(xiàn)在我這邊使用 docker swarm 遇到了一個(gè)非常棘手的問題，
我們使用 docker swarm 搭建集群跑的 java 容器。
在做滾動更新的時(shí)候。總是有請求進(jìn)來，結(jié)果 nginx 那邊報(bào)了一堆 502。因?yàn)槲覀兠颗_機(jī)器上面都跑了一個(gè) nginx 然后在通過 nginx 的 upstream 來轉(zhuǎn)發(fā)給本地機(jī)器的容器進(jìn)程的。
upstream web {
server localhost:18081;
keepalive 300;
理論上 docker swarm 集群在做滾動更新的時(shí)候。會先把集群內(nèi)部的負(fù)載均衡里面摘掉既然廢棄的容器進(jìn)程，切斷流量。然后停止這個(gè)容器，進(jìn)而拉起一個(gè)容器。接著通過健康檢測判斷這個(gè)容器是否啟動完畢。啟動完畢之后，就會把這個(gè)容器進(jìn)程加入到負(fù)載均衡里面的。這么下來就完成了滾動更新，畢竟集群會先在負(fù)載均衡摘掉流量的，所以不可能還有有流量打入這個(gè)即將廢棄的容器進(jìn)程了?？墒乾F(xiàn)在我們每次發(fā)布更新總會伴著 1000 多條 502 的記錄。
通過 docker file 生成鏡像的，而健康檢測也是寫到了 docker file 里面的。
健康檢測設(shè)置如下：
HEALTHCHECK --interval=20s --timeout=10s --retries=10 CMD wget --quiet --tries=1 --spider http://localhost:$service_port/healthCheck || exit 1
我們嘗試過優(yōu)雅關(guān)閉，設(shè)置過了 --stop-signal 為 30s 甚至 60s 發(fā)現(xiàn)還是一樣，發(fā)布過程中會出現(xiàn) 502，現(xiàn)在兩個(gè)方向。不確定這些 502 是由于流量打到了舊容器而導(dǎo)致的，還是流量打到新容器而導(dǎo)致的，新容器這個(gè)是懷疑我們的健康檢測設(shè)置不合理，也就是容器進(jìn)程還沒有能夠?qū)ν馓峁┓?wù)，健康檢測卻通過了，認(rèn)為這個(gè)新容器進(jìn)程是啟動完畢了，加入了負(fù)載均衡有部分流量打到了新容器進(jìn)程去。
k8s 悄悄處理了這個(gè)問題，比如他們配置了 preStop 等這種策略。能夠完美解決這個(gè)問題，但是 docker swarm 目前，不敢相信會有這種問題。畢竟按照 docker swarm 的滾動發(fā)布流程，是不可能有這種問題的。它是先摘除流量的?，F(xiàn)在非常的頭疼，不知道從何下手了。而一時(shí)之間我們也不能斷然的上 k8s 集群。畢竟體量也很少，暫時(shí)不考慮。各位在使用 docker swarm 的時(shí)候是否遇見過這樣的問題。
請教，萬分感謝，提前祝大家新年快樂~~
補(bǔ)充一下：我們的nginx 部署的網(wǎng)絡(luò)是host模式，而應(yīng)用是專門創(chuàng)建了一個(gè)overlay網(wǎng)絡(luò)在里面跑的
NETWORK ID NAME DRIVER SCOPE
wqpezy5g2pjl bobo-network overlay swarm （這是我們后端應(yīng)用跑的網(wǎng)絡(luò)命名空間）
b4f0b8c4ef4d bridge bridge local
59347c5dfa7a docker_gwbridge bridge local
4079bbadea8b host host local
2cw5xft9mtyj ingress overlay swarm
cadc70451b26 none null local
efmpcxfd7yv1 portainer-agent_portainer_agent overlay swarm
dockerdocker-swarmkubernetes集群運(yùn)維
1 月 12 日遇到了一模一樣的問題。
每次滾動更新的時(shí)候，都會出現(xiàn)幾十上百條不等的502，基本上發(fā)生在停止的那一秒鐘。也沒啥好的解決辦法，然后我選擇了忽略它 :（
這個(gè)過程可能是在發(fā)送停止信號和完全停止之間。之前測試過，在這個(gè)停止的過程中，docker swarm仍然會把請求轉(zhuǎn)發(fā)到這個(gè)容器里，實(shí)際上程序已經(jīng)不能處理請求了，所以猜測可能是這個(gè)過程導(dǎo)致了502，但是后面沒怎么驗(yàn)證。
也有點(diǎn)好奇這個(gè)情況應(yīng)該怎么處理，我覺得這應(yīng)該是個(gè)普遍的現(xiàn)象。用了一段時(shí)間docker swarm集群了，目前發(fā)現(xiàn)問題還不只是這一點(diǎn)，比如：
在高并發(fā)的情況下，會出現(xiàn)轉(zhuǎn)發(fā)請求超時(shí)的問題，這個(gè)目前通過改配置可以解決。master節(jié)點(diǎn)的dockerd偶爾會出現(xiàn)內(nèi)存泄漏的問題，發(fā)現(xiàn)有時(shí)候dockerd的內(nèi)存會漲到4-5G，這個(gè)還只能通過重啟解決。目前也是計(jì)劃換到k8s上，現(xiàn)在糾結(jié)的也是規(guī)模不大，上k8s感覺有點(diǎn)不太合適。
2 月 3 日 四川我也遇到了這個(gè)問題，不過還有更重要的問題要解決，所以這個(gè)問題被擱置了。我倒是沒考慮過使用host模式，主要是覺得這種模式隱患很大。路由的話，我部分固定組件用的nginx，頻繁更新用的traefik 我感覺會好一些，不過還是有問題，不過我沒有詳細(xì)的debug，另外我也找到了一些組件比如nginx-proxy ，可能這種模式更加適合容器模式，不過我沒有測試過。
免費(fèi)試用：點(diǎn)我提交開通試用
資產(chǎn)管理系統(tǒng)免費(fèi)試用
相關(guān)內(nèi)容
相關(guān)標(biāo)簽
400-0589-976
