原創文章,歡迎轉載。轉載請註明:轉載自IT人故事會,謝謝!
原文連結地址:『中級篇』叢集服務間通訊之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的體驗
- 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到具體任務的路由,並把請求平均的分配給所有的健康任務。