>原創文章,歡迎轉載。轉載請註明:轉載自IT人故事會,謝謝!
>原文鏈接地址:『高級篇』docker之DockerSwarm的瞭解(27)這次一起了解下docker Swarm,什麼是dockerSwarm。
什麼是docker Swarm
-
產品背景
使用docker的流程,ssh到一臺服務器,運行docker命令來運行本機的docker服務,隨着docker發展,越來越多的服務想要運行在docker容器中,如果在這樣挨個的登錄在每個ssh主機上管理容器,就非常的吃力了,而且我們的應用也需要高可用,也需要避免單點的故障,docker現有的能力已經很難滿足這樣的需求了,在這樣的背景下,docker社區就產生類的dockerSwarm項目。
-
概念
什麼是swarm,swarm這個名詞比較貼切,swarm這個單詞的意思就是動物的集羣行爲,比如我們常見的蜂羣,魚羣,大雁南飛都可以成爲swarm,swarm項目就是把多個docker 實例聚集在一起形成一個大的docker實例,對外提供集羣服務,同時這個集羣提供所有的api,用戶可以相使用docker實例一樣使用docker的集羣。
- 昨日今日
docker swarm在1.12之前是一個獨立的項目,需要單獨下載,在1.12之後該項目就合併到了docker中,成爲docker的子項目,目前docker唯一的一個原生支持docker集羣的管理工具。
docker swarm的架構圖
下面這個圖,就可以看到docker swarm管理docker的一個架構圖。以前使用docker命令行是針對docker主機的,然後到這臺機器上單獨的控制這臺機器上的主機,有了swarm之後,客戶端命令是針對docker集羣的。它的命令幾乎等同於docker的原生命令,它把命令發送給swarm,swarm選擇發送一個節點去真正的執行,swarm是通過docker自帶的遠程的API,來實現對docker的控制。
下面這個圖,這張圖跟上面一張圖描述的是一個事情,只不過它暴露了更多的的細節,上面的大框和下面的小框都代表了一臺服務器,物理機或者虛擬機,我們從上面說,上面是swarm的一個manager節點,管理這個worker節點,可以看到管理了多少個cpu,多少個內存,每個上面運行的服務,每個服務的狀況,比如他們的標籤,他們的健康狀態,Manager管理者每個節點的生命週期,比如加入一個節點,下線一個節點,manager還管理者每個服務的生命週期,服務的部署,更新,停止,刪除,Node節點比較單純他就運行了docker daemon,因爲在1.12之後swarm已經融入了docker本身,開發一個遠程的api給manager節點調度,運行具體的服務和容器,下面咱們一起看看服務的部署流程是怎樣的,在這樣的架構上是如何體現的。
環境的搭建
想想之前學習的mesos,需要先安裝docker,Marathon,zookeeper,加入我們現在有5臺liunx服務器,每個上面都裝有docker,選擇一臺作爲manager,上面執行下圖的第一條命令, 執行完之後會打印出來一個token作爲dockerSwarm的憑證,然後在每個worker節點下執行第二條命令,表示要加入集羣,只需要token和對應manager節點的ip和端口號,集羣環境就搭建完畢了
如何部署
客戶端的發起docker命令,兩種方式
- 直接ssh到manager節點,執行docker命令。
- 通過遠程訪問的方式,通過Remote API調用manager上的docker命令,我們這張圖畫的就是第二種方式。
docker Client 在manager節點的外邊,假如執行了docker service create,先會經過docker Deamon接受這條命令,傳給Scheduler模塊,Scheduler模塊主要實現調度的功能,負責選擇出來最優的節點,裏面包含了2個子模塊,Fiter 和Strategy,Fiter很明顯是過濾節點,用來找出滿足條件的節點(資源足夠多,節點正常的),Strategy是過濾出來後選擇出最優的節點(對比選擇資源剩餘最多的節點,或者找到資源剩餘最少的節點),當然Fiter 和Strategy都是用戶可以單獨定製的,中間的Cluster是抽象的worker節點集羣,包含了Swarm節點裏面每個節點的信息,右邊的Discovery是信息維護的模塊,比如Label Health。Cluster最終調用容器的api,完成容器啓動的劉而成。
調度模塊
用戶在創建服務的時候,選擇最優的節點,選擇最優節點的管理分爲2個階段。
過濾和策略
filter
-
Constraints
約束過濾器,根據當前的操作系統的類型,內核版本,存儲的類型進行指標上的約束,也可以自定義約束。當前系統啓動的時候可以通過label指定當前機器所具有的特性然後通過Constraints把他們過濾出來。
-
Affinity
親和性過濾器,支持容器的親和性和鏡像的親和性,比如一個應用,DB容器和web容器放在一起,就可以通過這個來實現,
-
Dependency
依賴過濾器,link等等吧Dependency會將這些容器放在同一個節點上,有依賴管理的會將創建的容器和依賴的容器放在同一個節點上。
-
Health filter
健康過濾器,根據節點的健康狀態進行過濾,把有問題的節點去掉。
- Ports filter
端口過濾器,根據端口的使用情況進行過濾,比如一個8080端口在某個主機上被佔用,某些主機未被佔用,會選用未被佔用的那些主機。
Strategy
-
Binpack
在同等情況下,會使用資源最多的節點,通過這個策略可以讓容器聚集起來。
-
Spread
在同等情況下,會使用資源最少的節點,通過這個策略可以讓容器均勻的分佈在每個節點上。
- Random
隨機選擇一個節點。
服務發現
稍微有點複雜,根據場景來說吧
- Ingress
基於物理網絡之上的虛擬網絡,Swarm的上層應用不在依賴於物理網絡,並且能夠讓下面的物理網絡保持不變,老鐵就理解到這裏就可以了,網絡本身涉及到的東西太多了,應該也聽過網絡工程師,既然有這個職位肯定這個不是那麼容易學的,在這裏就不會深入的進行詳解了。
PS:假定運行了一個nginx服務2個實例,nginx1 和nginx2,容器內的端口是80,主機內的端口是8080, 這2個容器分別運行在node2和node3上,看到了吧node1雖然沒有運行實例但是依然有8080端口在監聽,一個集羣在所有的worker節點上都是可以訪問到的,隨便選一個節點輸入它的ip和8080端口就可以訪問到,或者搭建一個負載均衡External LB,負責輪詢的方式訪問每個上邊的8080端口,爲什麼在每個節點上都可以訪問我們的服務呢?每個服務啓動後所有的節點都會更新自己的VIP LB,把新的服務端口號和服務的信息建立一個關係,VIP LB是基於虛擬IP的負載均衡,VIP LB可以通過虛擬IP解析到真實IP,然後訪問到服務。
- Ingress+ link
就類型docker-compose,可以通過docker-compose.yml文件創建出來一組容器,他們之前通過link的方式進行訪問,其實這種就類型docker-compose的link網絡。
PS:也就是在Ingress之上多了一個link的場景,可以通過link的方式訪問,也不需要主機的網絡,link怎麼實現的呢,如果讓一個容器link到另一個容器很容易畢竟他們在一臺主機上,一個服務link到另一個服務其實沒有那麼簡單了,可能包含一個容器,也可能包含很多個容器,可能運行在一臺機器上,也可能分佈在多臺機器上,我們如何實現可以通過名字來訪問彼此呢,這用到了容器的dns,這裏的nginx服務依賴於tomcat服務,nginx有2個實例,tomcat有一個實例,所有的nginx的容器都會對tomcat的解析,把它解析到tomcat的VIP,VIP負責做負載均衡,原理就是這樣的原理,link的方式外部是訪問不到的。link只適合swarm集羣內部的場景。
- 自定義網絡
使用自定義的網絡,首先要創建網絡,所有的網絡都可以通過名字來連接彼此,而不需要link操作了。只要連接這個網絡的彼此,都可以通過名字。底層來說它和link是類型的。通過dns來解析應用的名字。然後通過VIP LB的形式來進行負載均衡。
#創建自定義網絡
docker network create --driver=overlay --attachable mynet
#創建服務
docker service create -p 80:80 --network=mynet --name nginx nginx
Ingress 支持外部訪問,Ingress+ link和自定義網絡只能容器間進行訪問。
服務編排
- 服務部署&服務發現(上邊說到了)
- 服務更新 -- docker service update
- 服務擴縮容 -- docker service scale
Swarm
-
對外以Docker API 接口呈現
好處直接可以平滑的切換到docker swarm上。基本不需要改變現有的系統
-
容易上手,學習成本低
之前docker的經驗可以完成繼承過來。
-
輕量級,節省資源
專注docker集羣的管理。插件的機制swarm的模塊都抽象出來對應的API,可以根據自己的特點進行定製實現。
- 對docker命令參數支持完善
跟docker同步發佈,docker的新的特性在dockerSwarm上都可以得到體現。
PS:docker Swarm基本都瞭解的差不多了。下次開始docker swarm的環境搭建。