博主介紹：Java領(lǐng)域優(yōu)質(zhì)創(chuàng)作者,博客之星城市賽道TOP20、專注于前端流行技術(shù)框架、Java后端技術(shù)領(lǐng)域、項(xiàng)目實(shí)戰(zhàn)運(yùn)維以及GIS地理信息領(lǐng)域。

🍅文末獲取源碼下載地址🍅

👇🏻 精彩專欄推薦訂閱👇🏻 歡迎點(diǎn)贊收藏評(píng)論拍磚........

【Docker Swarm總結(jié)】《容器技術(shù) Docker+K8S專欄》?

【uniapp+uinicloud多用戶社區(qū)博客實(shí)戰(zhàn)項(xiàng)目】《完整開發(fā)文檔-從零到完整項(xiàng)目》?

【Springcloud Alibaba微服務(wù)分布式架構(gòu) | Spring Cloud】《系列教程-更新完畢》?

【SpringSecurity-從入門到精通】《學(xué)習(xí)完整筆記-附（完整demo源碼）》?

【從零開始Vue項(xiàng)目中使用MapboxGL開發(fā)三維地圖教程】《系列教程-不定時(shí)更新》?

【Vue.js學(xué)習(xí)詳細(xì)課程系列】《共32節(jié)專欄收錄內(nèi)容》?

感興趣的可以先收藏起來相關(guān)問題都可以給我留言咨詢，希望幫助更多的人。

---

???????

目錄

8、service 操作

8.1 task 伸縮

8.2 task 容錯(cuò)

8.3 服務(wù)刪除

8.4 滾動(dòng)更新

8.5 更新回滾

9、service 全局部署模式

9.1 環(huán)境變更

9.2 創(chuàng)建 service

9.3 task 伸縮

10、overlay 網(wǎng)絡(luò)

10.1 測(cè)試環(huán)境 1搭建

10.2 overlay 網(wǎng)絡(luò)概述

10.3 docker_gwbridg 網(wǎng)絡(luò)基礎(chǔ)信息

10.4 ingress 網(wǎng)絡(luò)基礎(chǔ)信息

10.5 宿主機(jī)的 NAT 過程

10.6 ingress_sbox 的負(fù)載均衡

10.7 VXLAN

11 Raft 算法

11.1 基礎(chǔ)

11.2 角色、任期及角色轉(zhuǎn)變

11.3 leader 選舉

11.4 數(shù)據(jù)同步

11.5 腦裂

11.6 Leader 宕機(jī)處理

11.7 Raft 算法動(dòng)畫演示

---

8、service 操作

8.1 task 伸縮

根據(jù)訪問量的變化，需要在不停止服務(wù)的前提下對(duì)服務(wù)的 task 進(jìn)行擴(kuò)容/縮容，即對(duì)服
務(wù)進(jìn)行伸縮變化。有兩種實(shí)現(xiàn)方式：
（1） docker service update 方式
通過 docker service update --replicas 命令可以實(shí)現(xiàn)對(duì)指定服務(wù)的 task 數(shù)量進(jìn)行變更。

docker service ls

docker service update --replicas 4 tomcates

此時(shí)可以看到新增了一個(gè) task 節(jié)點(diǎn)。

docker service ps tomcates

（2） docker service scale 方式
通過 docker service scale 命令可以為指定的服務(wù)變更 task 數(shù)量。

docker service scale tomcates=7

此時(shí)可以看到新增了 3 個(gè) task 節(jié)點(diǎn)。由于共有 5 臺(tái)主機(jī)，現(xiàn)有 7 個(gè) task，所以就出現(xiàn)了
一個(gè)主機(jī)上有多個(gè) task 的情況。docker01上有兩個(gè)tom服務(wù)分別為tom1和tom5.

當(dāng)然，也可以使 task 數(shù)量減小。例如，下面的命令使 task 又變回了 3 個(gè)。

docker service scale tomcates=3

這三個(gè) task 分別在 docker01、docker04 與 docker05 主機(jī)。

（3） 暫停節(jié)點(diǎn)的 task 分配

docker node update  --help

生產(chǎn)環(huán)境下，可能由于某主機(jī)性能不高，在進(jìn)行 task 擴(kuò)容時(shí)，不想再為該主機(jī)再分配更多的 task，此時(shí)可通過 pause 暫停該主機(jī)節(jié)點(diǎn)的可用性來達(dá)到此目的。
例如，當(dāng)前 docker01、docker04 與 docker05三個(gè)主機(jī)上的tomcates 服務(wù)的 task 情況如下。

現(xiàn)準(zhǔn)備將 tomcates 服務(wù)的 task 擴(kuò)容為 10，但保持 docker02 節(jié)點(diǎn)中的 task 數(shù)量仍為 1 不變，
此時(shí)就可通過 docker node update --availability pause 命令修改 docker02 節(jié)點(diǎn)的可用性。

docker node update --availability pause docker02

將 tomcates 服務(wù)的 task 擴(kuò)容為 10。

docker service scale tomcates=10

查看各節(jié)點(diǎn)分配的 task 情況會(huì)發(fā)現(xiàn) docker02的 task 數(shù)量并未增加，其它節(jié)點(diǎn)主機(jī)有變化了。

（4） 清空 task
? ? 默認(rèn)情況下，manager 節(jié)點(diǎn)同時(shí)也具備 worker 節(jié)點(diǎn)的功能，可以由分發(fā)器為其分配 task。
但 manager 節(jié)點(diǎn)使用 raft 算法來達(dá)成 manager 間數(shù)據(jù)的一致性，對(duì)資源較敏感。因此，阻
止 manager 節(jié)點(diǎn)接收 task 是比較好的選擇。或者，由于某節(jié)點(diǎn)出現(xiàn)了性能問題，需要停止服務(wù)進(jìn)行維修，此時(shí)最好是將該節(jié)點(diǎn)上的task 清空，以不影響 service 的整體性能。
通過 docker node update –availability drain 命令可以清空指定節(jié)點(diǎn)中的所有 task。
例如，目前各個(gè)節(jié)點(diǎn)的對(duì)于 tomcates服務(wù)的 task 分配情況如下：

docker service ps tomcates

現(xiàn)對(duì) docker02 與 docker05 兩個(gè)節(jié)點(diǎn)進(jìn)行 task 清空操作。

docker node update --availability drain docker02docker node update --availability drain docker05

此時(shí)可以看到，tomcates服務(wù)的 task 總量并沒有減少，只是 docker02 與 docker05 兩個(gè)節(jié)點(diǎn)上
是沒有 task 的，而全部都分配到了 docker01、docker03 與 docker04 三個(gè)節(jié)點(diǎn)上了。這個(gè)結(jié)果就是由編排器與分發(fā)器共同維護(hù)的。

8.2 task 容錯(cuò)

當(dāng)某個(gè) task 所在的主機(jī)或容器出現(xiàn)了問題時(shí)，manager 的編排器會(huì)自動(dòng)再創(chuàng)建出新的
task，然后分發(fā)器會(huì)再選擇出一臺(tái) available node 可用節(jié)點(diǎn)，并將該節(jié)點(diǎn)分配給新的 task。

（1） 停掉容器
現(xiàn)在通過停掉 docker03、docker02或 docker05 中某個(gè)主機(jī)容器的方式來模擬故障情況。例
如停掉 docker03 的容器。

（2） 查看 task 節(jié)點(diǎn)
此時(shí)再查看服務(wù)的 task 節(jié)點(diǎn)信息可以看到?task分配到其他 主機(jī)。

8.3 服務(wù)刪除

通過 docker service rm [service name|service ID]可以刪除指定的一個(gè)或多個(gè) service。

 docker service rm tomcates

刪除后，該 service 消失，當(dāng)然，該 service 的所有 task 也全部刪除，task 相關(guān)的節(jié)點(diǎn)容器全部消失。

8.4 滾動(dòng)更新

當(dāng)一個(gè) service 的 task 較多時(shí)，為了不影響對(duì)外提供的服務(wù)，在對(duì) service 進(jìn)行更新時(shí)可
采用滾動(dòng)更新方式。
（1） 需求
這里要實(shí)現(xiàn)的更新時(shí)，將原本鏡像為 tomcat:8.5.49 的 service 的鏡像滾動(dòng)更新為tomcat:8.5.39。
（2） 創(chuàng)建 service
創(chuàng)建一個(gè)包含 10 個(gè)副本 task 的服務(wù)，該服務(wù)使用的鏡像為 tomcat:8.5.49。

docker service create \
--name toms \
--replicas 10 \
--update-parallelism 2 \
--update-delay 3s \
--update-max-failure-ratio 0.2 \
--update-failure-action rollback \
--rollback-parallelism 2 \
--rollback-delay 3s \
--rollback-max-failure-ratio 0.2 \
--rollback-failure-action continue \
-p 9000:8080 \
tomcat:8.5.39

這 10 個(gè) task 被非常平均的分配到了 5 個(gè) swarm 節(jié)點(diǎn)上了。

docker service ps toms

（3） 更新 service
現(xiàn)要將 service 使用的鏡像由 tomcat:8.5.39 更新為 tomcat:8.5.49。

docker service update --image tomcat:8.5.49 toms

會(huì)發(fā)現(xiàn)這個(gè)更新的過程就是前面在創(chuàng)建服務(wù)時(shí)指定的那樣，每次更新 2 個(gè) task，更新間隔為 3 秒。更新完畢后再查看當(dāng)前的 task 情況發(fā)現(xiàn)，已經(jīng)將所有任務(wù)的鏡像更新為了 8.5.49 版本。

8.5 更新回滾

在更新過程中如果更新失敗，則會(huì)按照設(shè)置的回滾策略進(jìn)行回滾，回滾到更新前的狀態(tài)。
但用戶也可通過命令方式手工回滾。
下面的命令會(huì)按照前面設(shè)置的每次回滾 2 個(gè) task，每次回滾間隔 3 秒進(jìn)行回滾。下面的
是回滾過程中的某個(gè)回滾瞬間。

docker service update --rollback toms

以下是回滾完畢后的結(jié)果。

回滾完畢后再查看當(dāng)前的 task 情況發(fā)現(xiàn)，已經(jīng)將所有任務(wù)的鏡像恢復(fù)為了 8.5.39 版本。
但需要注意，task name 保持未變，但 task ID 與原來的 task ID 也是不同的，并不是恢復(fù)到了
更新之前的 task ID。即編排器新創(chuàng)建了 task，并由分發(fā)器重新為其分配了 node。

docker service ps toms

9、service 全局部署模式

根據(jù) task 數(shù)量與節(jié)點(diǎn)數(shù)量的關(guān)系，常見的 service 部署模式有兩種：replicated 模式與
global 模式。前面創(chuàng)建的 service 是 replicated 模式的，下面來創(chuàng)建 global 模式的 service。

9.1 環(huán)境變更

為了后面的演示效果，讓 swarm 集群的節(jié)點(diǎn)變?yōu)?4 個(gè)。這里先使 docker5 退群。

docker swarm leave

此時(shí) docker5 的節(jié)點(diǎn)狀態(tài)變?yōu)榱?Down。

docker node ls

將此節(jié)點(diǎn)再從 swarm 集群中刪除。

 docker node rm docker05

現(xiàn)在 docker5 節(jié)點(diǎn)才徹底被刪除。

9.2 創(chuàng)建 service

在 docker service create 命令中通過--mode 選項(xiàng)可以指定要使用的 service 部署模式，默
認(rèn)為 replicated 模式。

docker service create --name toms2 --mode global -p 9001:8080 tomcat:8.5.39

該模式會(huì)在每個(gè)節(jié)點(diǎn)上分配一個(gè) task。

docker service lsdocker service ps toms2

9.3 task 伸縮

對(duì)于 global 模式來說，若要實(shí)現(xiàn)對(duì) service 的 task 數(shù)量的變更，必須通過改變?cè)?servicve所依附的 swarm 集群的節(jié)點(diǎn)數(shù)量來改變。節(jié)點(diǎn)增加，則 task 會(huì)自動(dòng)增加；節(jié)點(diǎn)減少，則 task會(huì)自動(dòng)減少。
下面要在這個(gè) 4 節(jié)點(diǎn)的 swarm 集群中增加一個(gè)節(jié)點(diǎn)，以使 toms 服務(wù)的 task 也增一。
首先在 manager 節(jié)點(diǎn)獲取新增一個(gè)節(jié)點(diǎn)的 token。

docker swarm join-token worker

在 docker5 上運(yùn)行加入命令，完成 swarm 的入群。
?

docker swarm join --token SWMTKN-1-4xrmirqfkb41hzrqjtqtehzjom484oi77dq8u1cqgrx9dqqw21-0y0n33l0vjxfxj4lai4r5hi80 192.168.162.201:2377

此時(shí)查看 toms2 服務(wù)的 task 詳情，發(fā)現(xiàn)已經(jīng)自動(dòng)增加了一個(gè) task。

docker service ps toms2

10、overlay 網(wǎng)絡(luò)

10.1 測(cè)試環(huán)境 1搭建

（1） 暫停分配 task

現(xiàn)讓 docker2 主機(jī)暫停分配 task
?

docker node update --availability pause docker02

（2） 創(chuàng)建 service
現(xiàn)啟動(dòng)一個(gè) service，包含 10 個(gè) task。

docker service create --name toms --replicas 10 -p 9000:8080 tomcat:8.5.39

當(dāng)前 swarm 集群共有 5 個(gè)節(jié)點(diǎn)，10 個(gè) task 被分配到了 4 個(gè)可用節(jié)點(diǎn)上，其中除了被暫
停的 docker2 節(jié)點(diǎn)上是沒有分配 task 外，其余節(jié)點(diǎn)都分配了多個(gè) task。

docker service ps toms

此時(shí)，訪問docker02主機(jī)http://192.168.162.202:9000/

居然能訪問？？？？問題解決請(qǐng)繼續(xù)看下一節(jié)overlay網(wǎng)絡(luò)。

10.2 overlay 網(wǎng)絡(luò)概述

（1） overlay 網(wǎng)絡(luò)簡介
overlay 網(wǎng)絡(luò)，也稱為重疊網(wǎng)絡(luò)或覆蓋網(wǎng)絡(luò)，是一種構(gòu)建于 underlay 網(wǎng)絡(luò)之上的邏輯虛擬網(wǎng)絡(luò)。即在物理網(wǎng)絡(luò)的基礎(chǔ)上，通過節(jié)點(diǎn)間的單播隧道機(jī)制將主機(jī)兩兩相連形成的一種虛擬的、獨(dú)立的網(wǎng)絡(luò)。
Docker Swarm 集群中的 overlay 網(wǎng)絡(luò)主要是通過 iptables、ipvs、vxlan 等技術(shù)實(shí)現(xiàn)的、基于其本身通信需求的網(wǎng)絡(luò)模型。
（2） overlay 網(wǎng)絡(luò)模型
這里要說的 overlay 網(wǎng)絡(luò)模型，確切地說，是 Docker Swarm 集群的 overlay 網(wǎng)絡(luò)模型。

Docker Swarm 集群的 overlay 網(wǎng)絡(luò)模型在創(chuàng)建時(shí)，會(huì)創(chuàng)建出兩個(gè)網(wǎng)絡(luò)：docker_gwbidge
網(wǎng)絡(luò)與 ingress 網(wǎng)絡(luò)。這就是典型的 overlay 網(wǎng)絡(luò)——在宿主機(jī)的物理網(wǎng)絡(luò)之上又創(chuàng)建出新的
網(wǎng)絡(luò)。同時(shí)還創(chuàng)建出了 docker_gwbidge 網(wǎng)關(guān)與 br0 網(wǎng)關(guān)，及 ingress-sbox 容器。
當(dāng)請(qǐng)求到達(dá)后會(huì)首先經(jīng)由 docker_gwbidge 網(wǎng)關(guān)跳轉(zhuǎn)到 ingress-sbox 容器，在其中具有當(dāng)
前整個(gè)service的所有容器IP，在其中通過輪詢負(fù)載均衡方式選擇一個(gè)容器IP作為目標(biāo)地址，
然后再跳轉(zhuǎn)到 br0 網(wǎng)關(guān)。在 br0 網(wǎng)關(guān)中會(huì)根據(jù)目標(biāo)地址所在主機(jī)進(jìn)行判斷。若目標(biāo)地址為本
地容器 IP，則直接將請(qǐng)求轉(zhuǎn)發(fā)給該容器處理即可。若目標(biāo)地址非本地容器 IP，則會(huì)將請(qǐng)求經(jīng)
由 vxlan 接口，通過 vxlan 隧道技術(shù)將請(qǐng)求轉(zhuǎn)發(fā)給目標(biāo)地址容器。

10.3 docker_gwbridg 網(wǎng)絡(luò)基礎(chǔ)信息

在詳細(xì)分析 overlay 網(wǎng)絡(luò)模型的通信原理之前，首先來了解一下 docker swarm 的 overlay
網(wǎng)絡(luò)的基礎(chǔ)信息。
（1） 查看 docker_gwbridge 網(wǎng)絡(luò)詳情
docker swarm 集群的 overlay 網(wǎng)絡(luò)模型在創(chuàng)建時(shí)，會(huì)自動(dòng)創(chuàng)建兩個(gè)網(wǎng)絡(luò)：docker_gwbridge
網(wǎng)絡(luò)與 ingress 網(wǎng)絡(luò)。

查看 docker_gwbridge 網(wǎng)絡(luò)詳情可以看到，docker_gwbridge 網(wǎng)絡(luò)包含的子網(wǎng)為
172.18.0.0/16，其網(wǎng)關(guān)為 172.18.0.1。那么，這個(gè)網(wǎng)關(guān)是誰呢？

同時(shí)還看到，該網(wǎng)絡(luò)中包含了 6 個(gè)容器。其中 5 個(gè)為 service 的 task 容器，另一個(gè)的容
器 ID 為 ingress-sbox。

（2） ingress-sbox 容器

通過 docker ps –a 命令查看當(dāng)前主機(jī)中的所有容器，發(fā)現(xiàn)并沒有 ingress-sbox 容器。為
什么？因?yàn)?docker ps 命令的本質(zhì)是 docker process status，查看的是當(dāng)前主機(jī)中真實(shí)存在的
容器進(jìn)程的狀態(tài)。而 ingress-sbox 容器是由 overlay 網(wǎng)絡(luò)虛擬出的，并不是真實(shí)存在的進(jìn)程，
所以通過 docker ps 命令是查看不到的。
從 docker_gwbridge 的網(wǎng)絡(luò)詳情中可以看到，其中 2 個(gè)為 service 的 task 容器，其 ID 由
64 位 16 進(jìn)制數(shù)構(gòu)成，而 ingress-sbox 容器的 ID 就是 ingress-sbox，與其它 2 個(gè)容器的 ID 構(gòu)
成方式完全不同。

（3） docker_gwbridge 網(wǎng)關(guān)
docker_gwbridge 的網(wǎng)絡(luò)詳情中的網(wǎng)關(guān) 172.18.0.1 是誰呢？

在宿主機(jī)中通過 ip a 命令查看宿主機(jī)的網(wǎng)絡(luò)接口，可以看到 docker_gwbridge 接口的 IP
為 172.18.0.1。即 docker_gwbridge 網(wǎng)絡(luò)中具有一個(gè)與網(wǎng)絡(luò)名稱同名的網(wǎng)關(guān)。同時(shí)還看到，下
面的 3 個(gè)接口全部都是連接在 docker_gwbridge 上的。

（4） 查看 task 容器的接口
查看 docker_gwbridge 網(wǎng)絡(luò)的 task 容器的接口情況，可以看到這些容器中正好有接口與
docker_gwbridge 網(wǎng)關(guān)中的相應(yīng)接口構(gòu)成 veth paire。

（5） 查看 ingress-sbox 容器的接口
如何查看docker_gwbridge網(wǎng)絡(luò)的ingress-sbox容器的接口情況呢？每個(gè)容器都具有一個(gè)
獨(dú)立的網(wǎng)絡(luò)命名空間，而每個(gè) docker 主機(jī)中的網(wǎng)絡(luò)命名空間，都是以文件的形式保存在目
錄/var/run/docker/netns 中。

其中 ingress_sbox 就是容器 ingress-sbox 的網(wǎng)絡(luò)命名空間。通過 nsenter 命令可進(jìn)入該命
名空間并查看其接口情況?？梢钥吹皆撁臻g中正好也存在接口與 docker_gwbridge 網(wǎng)關(guān)
中的相應(yīng)接口構(gòu)成 veth paire。

10.4 ingress 網(wǎng)絡(luò)基礎(chǔ)信息

（1） 查看 ingress 網(wǎng)絡(luò)詳情
overlay 網(wǎng)絡(luò)除了創(chuàng)建了 docker_gwbridge 網(wǎng)絡(luò)外，還創(chuàng)建了一個(gè) ingress 網(wǎng)絡(luò)。

查看 ingress 網(wǎng)絡(luò)詳情可以看到，ingress 網(wǎng)絡(luò)包含的子網(wǎng)為 10.0.0.0/24，其網(wǎng)關(guān)為 10.0.0.1。
那么，這個(gè)網(wǎng)關(guān)是誰呢？

同時(shí)還看到，該網(wǎng)絡(luò)中也包含了 3 個(gè)容器，這 3 個(gè)容器與 docker_gwbridge 網(wǎng)絡(luò)中的 3
個(gè)容器是相同的容器，雖然 Name 不同，IP 不同，但容器 ID 相同。說明這 3 個(gè)容器都同時(shí)
連接在 2 個(gè)網(wǎng)絡(luò)中。

（2） br0 網(wǎng)關(guān)
10.0.0.1 網(wǎng)關(guān)是誰呢？
每個(gè)容器都具有一個(gè)獨(dú)立的網(wǎng)絡(luò)空間，而每個(gè) docker 主機(jī)中的網(wǎng)絡(luò)命名空間，都是以
文件的形式保存在/var/run/docker/netns 目錄中。查看當(dāng)前主機(jī)的網(wǎng)絡(luò)空間：

查看/var/run/docker/netns 目錄中的命名空間發(fā)現(xiàn)，其包含的 4 個(gè)命名空間中，有 2 個(gè)
命名空間是 2 個(gè) task 容器的，它們的名稱由 12 位長度的 16 進(jìn)制數(shù)構(gòu)成；ingress_sbox 是
ingress-sbox 容器的命名空間。那么，1-pfq75ijiz4 命名空間是誰呢？進(jìn)入該命名空間，查看
其接口信息。

可以看到 2 號(hào)接口 br0 的 IP 為 10.0.0.1，即 ingress 網(wǎng)絡(luò)的網(wǎng)關(guān)為 1-pfq75ijiz4 命名空間
中的 br0。同時(shí)還看到，br0 上還連接著 4 個(gè)接口，說明 br0 就是一個(gè)網(wǎng)關(guān)。那么，都是誰
連接在這 4 個(gè)接口上呢？
（3） 查看 task 容器的接口
查看 ingress 網(wǎng)絡(luò)的 task 容器的接口情況，可以看到這些容器中正好有接口與 br0 網(wǎng)關(guān)
中的相應(yīng)接口構(gòu)成 veth paire。

（4） 查看 ingress-sbox 容器的接口
查看 ingress-sbox 容器的命名空間 ingress_sbox 的接口情況，可以看到該命名空間中正
好也存在接口與 br0 網(wǎng)關(guān)中的相應(yīng)接口構(gòu)成 veth paire。

10.5 宿主機(jī)的 NAT 過程

（1） 查看宿主機(jī)路由
用戶提交的192.168.192.101:9000請(qǐng)求會(huì)首先被192.168.192.101主機(jī)的哪個(gè)接口接收并
處理呢？通過命令 ip route 可以查看當(dāng)前網(wǎng)絡(luò)命名空間中的靜態(tài)路由信息。

可以看出，所有對(duì) 192.168.182.0/24 網(wǎng)絡(luò)的請(qǐng)求，都需要經(jīng)過 ens33 接口，而該接口連
接的 IP 為 192.168.192.101。即 ens33 接口會(huì)處理該請(qǐng)求。當(dāng)然，查看該主機(jī)的接口情況也
可以看到，ens33 接口地址為 192.168.192.101。

那么 ens33 接口又會(huì)將請(qǐng)求轉(zhuǎn)發(fā)到哪里呢？這就需要查看宿主機(jī)的路由轉(zhuǎn)發(fā)表 nat 中的
路由規(guī)則了。
（2） 查看 ip 轉(zhuǎn)換規(guī)則
首先通過 iptables –nvL –t nat 命令來查看宿主機(jī)中網(wǎng)絡(luò)地址轉(zhuǎn)發(fā)表 nat 中的轉(zhuǎn)發(fā)規(guī)則。
nat 表的主要功能是根據(jù)規(guī)則進(jìn)行地址映射、端口映射，以完成地址轉(zhuǎn)換。

DOCKER-INGRESS 路由鏈路中的 DNAT 映射規(guī)則中指出，對(duì)于任何源 IP，只要其訪問端
口號(hào)為 9000，就會(huì)將其轉(zhuǎn)換為 172.18.0.2:9000 的請(qǐng)求，即將請(qǐng)求轉(zhuǎn)發(fā)到 172.18.0.2。那么請(qǐng)
求是如何到達(dá) 172.18.0.2 的呢？
（3） 查看宿主機(jī)路由
通過 ip route 命令查看當(dāng)前宿主機(jī)的靜態(tài)路由信息。

可以看出，所有對(duì) 172.18.0.0/16 網(wǎng)絡(luò)的請(qǐng)求，都需要經(jīng)過 docker_gwbridge 接口，而該
接口連接的 IP 為 172.18.0.1。即 docker_gwbridge 接口會(huì)處理該請(qǐng)求。由一個(gè)網(wǎng)絡(luò)去訪問另
一個(gè)網(wǎng)絡(luò)必須要經(jīng)過該目標(biāo)網(wǎng)絡(luò)的網(wǎng)關(guān)。經(jīng)前面的學(xué)習(xí)知道，docker_gwbridge 正好就是
172.18.0.0/16 網(wǎng)絡(luò)的網(wǎng)關(guān)。
也就是說，客戶端提交的 192.168.192.101:9000 的請(qǐng)求，經(jīng) docker_gwbridge 網(wǎng)關(guān)，被
路由到了 IP 為 172.18.0.2 的接口。那么誰的 IP 是 172.18.0.2 呢？經(jīng)過前面網(wǎng)絡(luò)基礎(chǔ)信息查
看可知，docker_gwbridge 網(wǎng)絡(luò)中包含 IP 為 172.18.0.2 的 ingress-sbox 容器。

10.6 ingress_sbox 的負(fù)載均衡

客戶端請(qǐng)求經(jīng)宿主機(jī)的 NAT 已經(jīng)成功通過 docker_gwbridge 網(wǎng)關(guān)轉(zhuǎn)發(fā)到了 172.18.0.2，
即轉(zhuǎn)發(fā)到了 ingress-sbox 容器，或者更確切地說，是轉(zhuǎn)發(fā)到了 ingress_sbox 命名空間。那么，
ingress_sbox 命名空間又會(huì)將請(qǐng)求轉(zhuǎn)發(fā)到哪里呢？這就需要查看 ingress_sbox 命名空間的
iptables 的 mangle 表與 IPVS 功能了。
（1） 查看 ingress_sbox 的 mangle 表
mangle 表的主要功能是根據(jù)規(guī)則修改數(shù)據(jù)包的一些標(biāo)志位，以便其他規(guī)則或程序可以
利用這種標(biāo)志對(duì)數(shù)據(jù)包進(jìn)行過濾或路由。

該路由鏈中為任意源地址端口為 9000 的請(qǐng)求打了一個(gè) MARK 標(biāo)記 0x101，該 MARK 標(biāo)
記將被 IPVS 用于負(fù)載均衡。
（2） 安裝 ipvsadm 命令
后面我們需要使用該命令查看 IPVS 實(shí)現(xiàn)的負(fù)載均衡規(guī)則，但由于 CentOS 系統(tǒng)中默認(rèn)沒
有安裝 ipvsadm 命令，所以需要先 yum 安裝。

（3） 查看 ingress_sbox 負(fù)載均衡規(guī)則

端口為 9000 的請(qǐng)求被打上了一個(gè)數(shù)值為 257 的 MARK 標(biāo)記，該標(biāo)記通過 LVS 的 IPVS 的
負(fù)載均衡，將該請(qǐng)求轉(zhuǎn)發(fā)到了下面的 10 個(gè) IP 接口，且這 10 個(gè)接口的權(quán)重 weight 是相同的，
都是 1。這 10 個(gè) IP 接口具有一個(gè)共同點(diǎn)，全部來自于 10.0.0.0/24 網(wǎng)絡(luò)。那么，如何能到達(dá)
10.0.0.0/24 網(wǎng)絡(luò)呢？
（4） 查看命名空間路由
通過前面的學(xué)習(xí)可知，若要由一個(gè)網(wǎng)絡(luò)轉(zhuǎn)發(fā)到另一個(gè)網(wǎng)絡(luò)，則必須要先到目標(biāo)網(wǎng)絡(luò)的網(wǎng)
關(guān)。由于目前尚在 172.18.0.0/16 網(wǎng)絡(luò)，預(yù)轉(zhuǎn)發(fā)到 10.0.0.0/24 網(wǎng)絡(luò)，所以必須要先到 10.0.0.0/24
網(wǎng)絡(luò)的網(wǎng)關(guān) 10.0.0.1，即 br0。通過查看 br0 所在命名空間 1-pfq75ijiz4 的靜態(tài)路由也可看出：

但存在的問題是，請(qǐng)求目前尚在 ingress_sbox 命名空間中，怎樣才能從 ingress_sbox 命
名空間中出去，然后跳轉(zhuǎn)到 br0 呢？查看 ingress_sbox 命名空間中的靜態(tài) IP 路由：

可以看出，所有對(duì) 10.0.0.0/24 網(wǎng)絡(luò)的請(qǐng)求，都需要經(jīng)過 eth0 接口，而該接口連接的 IP
為 10.0.0.11。在 ingress_sbox 命名空間中 eth0 接口就是 7 號(hào)接口，其 veth pair 接口就是 br0
中的 8 號(hào)接口。所以，ingress_sbox 命名空間中請(qǐng)求經(jīng)由 7 號(hào)接口跳轉(zhuǎn)到了 br0 網(wǎng)關(guān)。

（5） br0 網(wǎng)關(guān)的處理
到達(dá) br0 后，再將請(qǐng)求從 br0 的哪個(gè)接口轉(zhuǎn)發(fā)出去，是由目標(biāo)地址決定的，而目標(biāo)地址
就是 IPVS 負(fù)載均衡選擇出的 IP。請(qǐng)求到達(dá) br0 后，首先會(huì)將目標(biāo)地址與本地的 task 容器地
址進(jìn)行比較，若恰好就是當(dāng)前宿主機(jī)中的 task 容器的 IP，那么直接將請(qǐng)求通過相應(yīng)的接口
將其轉(zhuǎn)發(fā)；若不是當(dāng)前宿主機(jī)中的 IP，則會(huì)將請(qǐng)求轉(zhuǎn)發(fā)到 vxlan0 接口。經(jīng)過 vxlan0 接口，
可經(jīng)由 VXLAN 技術(shù)將請(qǐng)求通過“網(wǎng)絡(luò)隧道”發(fā)送到目標(biāo)地址。

10.7 VXLAN

（1） VXLAN 簡介
VXLAN 是一種隧道技術(shù)，可以將不同協(xié)議的數(shù)據(jù)包重新封裝后發(fā)送。新的包頭提供了路由信息，從而使被封裝的數(shù)據(jù)包在隧道的兩個(gè)端點(diǎn)間通過公共互聯(lián)網(wǎng)絡(luò)進(jìn)行路由。被封裝的
數(shù)據(jù)包在公共互聯(lián)網(wǎng)絡(luò)上傳遞時(shí)所經(jīng)過的邏輯路徑稱為隧道。一旦到達(dá)網(wǎng)絡(luò)終點(diǎn)，數(shù)據(jù)將被
解包并轉(zhuǎn)發(fā)到最終目的地。
（2） 測(cè)試環(huán)境 2 搭建
為了能夠看清楚請(qǐng)求在不同主機(jī)的容器間所進(jìn)行了通信，及通信過程中所使用的 VXLAN
技術(shù)，這里將原來的服務(wù)先刪除，然后再創(chuàng)建一個(gè)新的服務(wù)。不過，該服務(wù)僅有一個(gè)副本。
首先刪除原來的 service。

然后在任意主機(jī)中創(chuàng)建一個(gè)新的 servivce，其僅包含一個(gè)副本。這里在 docker3 主機(jī)創(chuàng)
建了服務(wù)。可以看到，這唯一的副本被分配到了 docker5 主機(jī)。

（3） 安裝 tcpdump 命令
這里準(zhǔn)備使用 tcpdump 命令對(duì) VXLAN 數(shù)據(jù)進(jìn)行監(jiān)聽，但在 centOS7 系統(tǒng)中默認(rèn)是沒有
安裝 tcpdump 命令的，所以需要使用 yum 命令先在 docker5 主機(jī)安裝。

yum install -y tcpdump 

（4） docker5 先監(jiān)聽
無論對(duì)哪個(gè)主機(jī)的該服務(wù)進(jìn)行訪問，請(qǐng)求最終都會(huì)通過 docker5 主機(jī)的 ens33 接口進(jìn)入，
然后再找到該 task 容器。所以這里要先監(jiān)聽 docker5 的 ens33 接口。

（5） docker3 訪問
在瀏覽器可以對(duì)任意主機(jī)提交訪問請(qǐng)求。這里是向 docker3 主機(jī)發(fā)出的訪問請(qǐng)求。

（6） docker5 查看抓包數(shù)據(jù)
當(dāng)向 docker3 主機(jī)發(fā)送了訪問請(qǐng)求后，docker5 上就會(huì)看到抓取的 VXLAN 數(shù)據(jù)包。

11 Raft 算法

11.1 基礎(chǔ)

Raft 算法是一種通過對(duì)日志復(fù)制管理來達(dá)到集群節(jié)點(diǎn)一致性的算法。這個(gè)日志復(fù)制管理
發(fā)生在集群節(jié)點(diǎn)中的 Leader 與 Followers 之間。Raft 通過選舉出的 Leader 節(jié)點(diǎn)負(fù)責(zé)管理日志
復(fù)制過程，以實(shí)現(xiàn)各個(gè)節(jié)點(diǎn)間數(shù)據(jù)的一致性。

11.2 角色、任期及角色轉(zhuǎn)變

在 Raft 中，節(jié)點(diǎn)有三種角色：

• Leader：唯一負(fù)責(zé)處理客戶端寫請(qǐng)求的節(jié)點(diǎn)；也可以處理客戶端讀請(qǐng)求；同時(shí)負(fù)責(zé)日志復(fù)制工作
• Candidate：Leader 選舉的候選人，其可能會(huì)成為 Leader。是一個(gè)選舉中的過程角
• Follower：可以處理客戶端讀請(qǐng)求；負(fù)責(zé)同步來自于 Leader 的日志；當(dāng)接收到其它Cadidate 的投票請(qǐng)求后可以進(jìn)行投票；當(dāng)發(fā)現(xiàn) Leader 掛了，其會(huì)轉(zhuǎn)變?yōu)?Candidate 發(fā)起Leader 選舉

11.3 leader 選舉

通過 Raft 算法首先要實(shí)現(xiàn)集群中 Leader 的選舉。
（1） 我要選舉

若 follower 在心跳超時(shí)范圍內(nèi)沒有接收到來自于 leader 的心跳，則認(rèn)為 leader 掛了。此
時(shí)其首先會(huì)使其本地 term 增一。然后 follower 會(huì)完成以下步驟：

• 此時(shí)若接收到了其它 candidate 的投票請(qǐng)求，則會(huì)將選票投給這個(gè) candidate
• 由 follower 轉(zhuǎn)變?yōu)?candidate
• 若之前尚未投票，則向自己投一票
• 向其它節(jié)點(diǎn)發(fā)出投票請(qǐng)求，然后等待響應(yīng)

（2） 我要投票
follower 在接收到投票請(qǐng)求后，其會(huì)根據(jù)以下情況來判斷是否投票：

• 發(fā)來投票請(qǐng)求的 candidate 的 term 不能小于我的 term
• 在我當(dāng)前 term 內(nèi)，我的選票還沒有投出去
• 若接收到多個(gè) candidate 的請(qǐng)求，我將采取 first-come-first-served 方式投票

（3） 等待響應(yīng)
當(dāng)一個(gè) Candidate 發(fā)出投票請(qǐng)求后會(huì)等待其它節(jié)點(diǎn)的響應(yīng)結(jié)果。這個(gè)響應(yīng)結(jié)果可能有三
種情況：

• 收到過半選票，成為新的 leader。然后會(huì)將消息廣播給所有其它節(jié)點(diǎn)，以告訴大家我是新的 Leader 了
• 接收到別的 candidate 發(fā)來的新 leader 通知，比較了新 leader 的 term 并不比自己的 term小，則自己轉(zhuǎn)變?yōu)?follower
• 經(jīng)過一段時(shí)間后，沒有收到過半選票，也沒有收到新 leader 通知，則重新發(fā)出選舉

（4） 選舉時(shí)機(jī)
在很多時(shí)候，當(dāng) Leader 真的掛了，Follower 幾乎同時(shí)會(huì)感知到，所以它們幾乎同時(shí)會(huì)變?yōu)?candidate 發(fā)起新的選舉。此時(shí)就可能會(huì)出現(xiàn)較多 candidate 票數(shù)相同的情況，即無法選舉出 Leader。

為了防止這種情況的發(fā)生，Raft 算法其采用了 randomized election timeouts 策略來解決這個(gè)問題。其會(huì)為這些 Follower 隨機(jī)分配一個(gè)選舉發(fā)起時(shí)間 election timeout，這個(gè) timeout在 150-300ms 范圍內(nèi)。只有到達(dá)了 election timeout 時(shí)間的 Follower 才能轉(zhuǎn)變?yōu)?candidate，否則等待。那么 election timeout 較小的 Follower 則會(huì)轉(zhuǎn)變?yōu)?candidate 然后先發(fā)起選舉，一般情況下其會(huì)優(yōu)先獲取到過半選票成為新的 leader。

11.4 數(shù)據(jù)同步

在 Leader 選舉出來的情況下，通過日志復(fù)制管理實(shí)現(xiàn)集群中各節(jié)點(diǎn)數(shù)據(jù)的同步。
（1） 狀態(tài)機(jī)
Raft 算法一致性的實(shí)現(xiàn)，是基于日志復(fù)制狀態(tài)機(jī)的。狀態(tài)機(jī)的最大特征是，不同 Server
中的狀態(tài)機(jī)若當(dāng)前狀態(tài)相同，然后接受了相同的輸入，則一定會(huì)得到相同的輸出。

（2） 處理流程

當(dāng) leader 接收到 client 的寫操作請(qǐng)求后，大體會(huì)經(jīng)歷以下流程：

• leader 在接收到 client 的寫操作請(qǐng)求后，leader 會(huì)將數(shù)據(jù)與 term 封裝為一個(gè) box，并隨

著下一次心跳發(fā)送給所有 followers，以征求大家對(duì)該 box 的意見。同時(shí)在本地將數(shù)據(jù)封
裝為日志

• ?follower 在接收到來自 leader 的 box 后首先會(huì)比較該 box 的 term 與本地記錄的曾接受過

的 box 的最大 term，只要不比自己的小就接受該 box，并向 leader 回復(fù)同意。同時(shí)會(huì)將
該 box 中的數(shù)據(jù)封裝為日志。

• 當(dāng) leader 接收到過半同意響應(yīng)后，會(huì)將日志 commit 到自己的狀態(tài)機(jī)，狀態(tài)機(jī)會(huì)輸出一

個(gè)結(jié)果，同時(shí)日志狀態(tài)變?yōu)榱?committed

• 同時(shí) leader 還會(huì)通知所有 follower 將日志 commit 到它們本地的狀態(tài)機(jī)，日志狀態(tài)變?yōu)?/li>

了 committed

• 在 commit 通知發(fā)出的同時(shí)，leader 也會(huì)向 client 發(fā)出成功處理的響應(yīng)。

（3） AP 支持

Log 由 term index、log index 及 command 構(gòu)成。為了保證可用性，各個(gè)節(jié)點(diǎn)中的日志可
以不完全相同，但 leader 會(huì)不斷給 follower 發(fā)送 box，以使各個(gè)節(jié)點(diǎn)的 log 最終達(dá)到相同。
即 raft 算法不是強(qiáng)一致性的，而是最終一致的。

11.5 腦裂

Raft 集群存在腦裂問題。在多機(jī)房部署中，由于網(wǎng)絡(luò)連接問題，很容易形成多個(gè)分區(qū)。
而多分區(qū)的形成，很容易產(chǎn)生腦裂，從而導(dǎo)致數(shù)據(jù)不一致。
由于三機(jī)房部署的容災(zāi)能力最強(qiáng)，所以生產(chǎn)環(huán)境下，三機(jī)房部署是最為常見的。下面以
三機(jī)房部署為例進(jìn)行分析，根據(jù)機(jī)房斷網(wǎng)情況，可以分為五種情況：

（1） 情況一--不確定
這種情況下，B 機(jī)房中的主機(jī)是感知不到 Leader 的存在的，所以 B 機(jī)房中的主機(jī)會(huì)發(fā)
起新一輪的 Leader 選舉。由于 B 機(jī)房與 C 機(jī)房是相連的，雖然 C 機(jī)房中的 Follower 能夠感
知到 A 機(jī)房中的 Leader，但由于其接收到了更大 term 的投票請(qǐng)求，所以 C 機(jī)房的 Follower
也就放棄了 A 機(jī)房中的 Leader，參與了新 Leader 的選舉。

若新 Leader 出現(xiàn)在 B 機(jī)房，A 機(jī)房是感知不到新 Leader 的誕生的，其不會(huì)自動(dòng)下課，
所以會(huì)形成腦裂。但由于 A 機(jī)房 Leader 處理的寫操作請(qǐng)求無法獲取到過半響應(yīng)，所以無法
完成寫操作。但 B 機(jī)房 Leader 的寫操作處理是可以獲取到過半響應(yīng)的，所以可以完成寫操
作。故，A 機(jī)房與 B、C 機(jī)房中出現(xiàn)腦裂，且形成了數(shù)據(jù)的不一致。
若新 Leader 出現(xiàn)在 C 機(jī)房，A 機(jī)房中的 Leader 則會(huì)自動(dòng)下課，所以不會(huì)形成腦裂。
（2） 情況二--形成腦裂

這種情況與情況一基本是一樣的。不同的是，一定會(huì)形成腦裂，無論新 Leader 在 B 還
是 C 機(jī)房。
（3） 情況三--無腦裂

A、C 可以正常對(duì)外提供服務(wù)，但 B 無法選舉出新的 Leader。由于 B 中的主機(jī)全部變?yōu)?br /> 了選舉狀態(tài)，所以無法提供任何服務(wù)，沒有形成腦裂。
（4） 情況四--無腦裂

A、B、C 均可以對(duì)外提供服務(wù)，不受影響。

（5） 情況五--無腦裂

A 機(jī)房無法處理寫操作請(qǐng)求，但可以對(duì)外提供讀服務(wù)。
B、C 機(jī)房由于失去了 Leader，均會(huì)發(fā)起選舉，但由于均無法獲取過半支持，所以均無
法選舉出新的 Leader。

11.6 Leader 宕機(jī)處理

（1） 請(qǐng)求到達(dá)前 Leader 掛了
client 發(fā)送寫操作請(qǐng)求到達(dá) Leader 之前 Leader 就掛了，因?yàn)檎?qǐng)求還沒有到達(dá)集群，所以
這個(gè)請(qǐng)求對(duì)于集群來說就沒有存在過，對(duì)集群數(shù)據(jù)的一致性沒有任何影響。Leader 掛了之
后，會(huì)選舉產(chǎn)生新的 Leader。

由于 Stale Leader 并未向 client 發(fā)送成功處理響應(yīng)，所以 client 會(huì)重新發(fā)送該寫操作請(qǐng)求。
（2） 未開始同步數(shù)據(jù)前 Leader 掛了
client 發(fā)送寫操作請(qǐng)求給 Leader，請(qǐng)求到達(dá) Leader 后，Leader 還沒有開始向 Followers
發(fā)出數(shù)據(jù) Leader 就掛了。這時(shí)集群會(huì)選舉產(chǎn)生新的 Leader。Stale Leader 重啟后會(huì)作為
Follower 重新加入集群，并同步新 Leader 中的數(shù)據(jù)以保證數(shù)據(jù)一致性。之前接收到 client 的
數(shù)據(jù)被丟棄。
由于 Stale Leader 并未向 client 發(fā)送成功處理響應(yīng)，所以 client 會(huì)重新發(fā)送該寫操作請(qǐng)求。
（3） 同步完部分后 Leader 掛了

client 發(fā)送寫操作請(qǐng)求給 Leader，Leader 接收完數(shù)據(jù)后向所有 Follower 發(fā)送數(shù)據(jù)。在部
分 Follower 接收到數(shù)據(jù)后 Leader 掛了。由于 Leader 掛了，就會(huì)發(fā)起新的 Leader 選舉。

• 若 Leader 產(chǎn)生于已完成數(shù)據(jù)接收的 Follower，其會(huì)繼續(xù)將前面接收到的寫操作請(qǐng)求轉(zhuǎn)換為日志，并寫入到本地狀態(tài)機(jī)，并向所有 Flollower 發(fā)出詢問。在獲取過半同意響應(yīng)后會(huì)向所有 Followers 發(fā)送 commit 指令，同時(shí)向 client 進(jìn)行響應(yīng)。
• 若 Leader 產(chǎn)生于尚未完成數(shù)據(jù)接收的 Follower，那么原來已完成接收的 Follower 則會(huì)放
  棄曾接收到的數(shù)據(jù)。由于 client 沒有接收到響應(yīng)，所以 client 會(huì)重新發(fā)送該寫操作請(qǐng)求。

（4） commit 通知發(fā)出后 Leader 掛了
client 發(fā)送寫操作請(qǐng)求給 Leader，Leader 也成功向所有 Followers 發(fā)出的 commit 指令，
并向 client 發(fā)出響應(yīng)后，Leader 掛了。
由于 Stale Leader 已經(jīng)向 client 發(fā)送成功接收響應(yīng)，且 commit 通知已經(jīng)發(fā)出，說明這個(gè)
寫操作請(qǐng)求已經(jīng)被 server 成功處理。

11.7 Raft 算法動(dòng)畫演示

在網(wǎng)絡(luò)上有一個(gè)關(guān)于 Raft 算法的動(dòng)畫，其非常清晰全面地演示了 Raft 算法的工作原理。
該動(dòng)畫的地址為：http://thesecretlivesofdata.com/raft/???????