集群服務間通信之RoutingMesh

上次講了通過service create 部署了wordpress，我們的這個wordpress有2個service組成一個wordpress，一個mysql。這2個service運行在不同的機器上邊，並且他們之前是可以進行通信的，可以通過servicename的方式通信。先創建mysql，wordpress查找mysql就是通過servicename這種方式。懂網路的老鐵應該就知道了，這裡面肯定有DNS的功勞在裡面。

實驗的方式了解這個網路

必須創建overlay的network

創建一個service，這個service 使用whoami，這個image，這個image的作用，就是訪問後，返回當前訪問的主機名稱

創建一個service，這個service 使用busybox，之前創建過是一個比較簡單的image，這個是為了當客戶端service之間的訪問。

ping whoami ip地址是10.0.0.247

測試whoami的ip是否發生變化

在manager下進行scale 擴展為2個，查看到一個在worker2上邊，並在worker2的ps上可以查看到whoami的運行，嘗試繼續ping whoami，結果ip不發生變化。

為什麼呢 ip不發生變化，其實我們ping的地址是一個虛擬的ip，docker 集群默認使用 Overlay 網路驅動，Overlay 驅動實現了跨主機集群內部虛擬網路。它的作用：將運行的多個容器（不同主機），附加（attach to）到一個網路默認情況下，服務發現為群集中的每個服務分配虛擬IP地址（VIP）和 動態 DNS，使其可以通過服務名稱將其提供給同一網路上的容器。即在一個 Overlay 虛擬網路內，使用服務名稱訪問，將實現任務級別的負載均衡在群集中使用覆蓋網路，需要在群集節點之間打開以下埠： 埠7946 TCP / UDP用於容器網路發現。埠4789 UDP用於容器覆蓋網路。機器進行遷移的時候有一套map關係，虛擬ip 和實際的ip 有個對應的關係，

輪訓的負載機制

Routing Mesh的體驗

Internal --- Container 和Container 之間的訪問通過overlay網路（通過VIP虛擬IP）

Ingress---- 如果服務有綁定介面，則此服務可以通過任意swarm節點的響應介面訪問

Load Balancing

現在有3台機器1個client，2個web，他們3個連通在同一個swam下，當client訪問web的時候其實，其實是訪問10.0.9.4，然後通過負載的方式映射到10.0.9.5或者10.0.9.6上面。

PS：內部負載均衡

當在docker swarm集群模式下創建一個服務時，會自動在服務所屬的網路上給服務額外的分配一個虛擬IP，當解析服務名字時就會返回這個虛擬IP。對虛擬IP的請求會通過overlay網路自動的負載到這個服務所有的健康任務上。這個方式也避免了客戶端的負載均衡，因為只有單獨的一個虛擬IP會返回到客戶端，docker會處理虛擬IP到具體任務的路由，並把請求平均的分配給所有的健康任務。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！