『中級篇』叢集服務間通訊之RoutingMesh（47）

原創文章，歡迎轉載。轉載請註明：轉載自IT人故事會，謝謝！

原文連結地址： ofollow,noindex">『中級篇』叢集服務間通訊之RoutingMesh（47）

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

實驗的方式瞭解這個網路

• 必須建立overlay的network

sudo docker network create -d overlay demo
複製程式碼

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

docker service create --name whoami -p 8000:8000 --network demo jwilder/whoami
#檢視service 裡面的服務
docker service ls
#檢視whoami的資訊
docker service ps whoami
#因為service ps whoami 在manager上執行，直接在manager檢視ps下
docker ps 
複製程式碼

#訪問下本地manager的whoami
curl 127.0.0.1:8000
複製程式碼

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

docker service create --name client -d --network demo busybox sh -c "while true;do sleep 3600;done"
docker service ls
#執行在swam-worker1機器上
docker service ps client
複製程式碼

#在swam-work1上進行執行 172.28.128.4 
docker exec -it busybox的容器ID sh
ping whoami
複製程式碼

ping whoami ip地址是10.0.0.247

• 測試whoami的ip是否發生變化

在manager下進行scale 擴充套件為2個，檢視到一個在worker2上邊，並在worker2的ps上可以檢視到whoami的執行，嘗試繼續ping whoami，結果ip不發生變化。

#manager機器上進行擴充套件
docker service scale whoami=2
#worker2 上執行 檢視whoami 是否存在
docker ps
#worker1 上ping whoami發現ip沒有發生變化10.0.0.247
ping whoami
複製程式碼

為什麼呢 ip不發生變化，其實我們ping的地址是一個虛擬的ip，docker 叢集預設使用 Overlay 網路驅動，Overlay 驅動實現了跨主機叢集內部虛擬網路。它的作用：將執行的多個容器（不同主機），附加（attach to）到一個網路預設情況下，服務發現為群集中的每個服務分配虛擬IP地址（VIP）和 動態 DNS，使其可以通過服務名稱將其提供給同一網路上的容器。即在一個 Overlay 虛擬網路內，使用服務名稱訪問，將實現任務級別的負載均衡在群集中使用覆蓋網路，需要在群集節點之間開啟以下埠：

埠7946 TCP / UDP用於容器網路發現。

埠4789 UDP用於容器覆蓋網路。

機器進行遷移的時候有一套map<k,v>關係，虛擬ip 和實際的ip 有個對應的關係，

• 輪訓的負載機制

wget whoami:8000
more index.html
#因為目前就有2個whoami，
#所以可以看到第三次執行wget獲取的時候發現id重複了也變成了65beb6796165
複製程式碼

Routing Mesh的體驗

1. Internal --- Container 和Container 之間的訪問通過overlay網路（通過VIP虛擬IP）
2. 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到具體任務的路由，並把請求平均的分配給所有的健康任務。