目前在容器編排領域，Kubernetes、Mesos以及Swarm呈現“三分天下”的格局，各自都有著不同的應用場景。短期內，很難看到“一統天下”的局面，本文，來自阿里云高級專家陳萌輝將帶你了解阿里內部在推行容器化過程中的一些著力點，同時，他將深刻剖析Swarm的進化史以及在阿里云的大規模應用，最后，他給出三個案例，供大家參考。

阿里從前年開始就已經在集團內部大規模地推行容器化和運用Swarm來做應用的發布、集群管理等事情。特別值得注意的是去年，阿里云跟Docker達成了一項深度合作的協議，從中我們不難窺探阿里的容器戰略。本文將從三個方面闡述“Swarm的進化和大規模應用”，第一， Swarm架構；第二，Swarm Mode的編排；第三是Swarm在阿里的應用。

Swarm架構

圖1 Swarm架構

我們先看一下Swarm是什么？Swarm，是Docker官方推出的，它的特點就是跟Docker本身有很好的集成，另外，它也是一個非常簡單易用的工具，所以目前吸引了很多開發者在用。

Swarm是Docker公司繼Docker Engine之后推出的很重要的集群管理系統和容器編排與調度系統。架構底層是集群的機器資源，可以是一些物理機也可以是一些虛擬機，上面經過Swarm這一層把容器調度和部署到這些機器上去，它對外提供跟Docker類似的API。

具體來看，Swarm的框架分成三塊，第一塊是Engine，第二是Manager，第三是KV store。它有幾個特點，第一依賴外部存儲來完成節點發現并保證一致性；第二，Manager只跟Daemon通信，不跟Agent通信；第三，Manager可以有多副本,這是為高可用設計的，采用一主多熱備模式，所有manager都同時連接所有Daemon，備轉發請求至主，另外，它依賴外部KV選主。

API

Swarm提供的API，主要是有這么幾類：

• 集群類：info events

• 容器類：get/list、create、start/stop等

• 鏡像類：get/list、push、pull、tag等

• 數據卷類：get/list、create、delete

• 網絡類：get/list、create、delete等

調度

資源維度層面有三個： CPU 、Memory、 端口，CPU / Memory支持超賣；調度策略有兩種：spread / binpack，另外，它不支持優先級、搶占。

它比較有特點的一些功能有兩個，一個是叫節點約束，約束可以有兩種類型，比如說你可以約束我這個節點是哪一個，你可以給節點去一個名字或者打一個標簽什么的，另外一個可以通過打標簽去選擇一種機器，你在部署的時候，可以指定這些容器部署到哪些機器上去。

節點約束：

• 節點名：constraint:node==XXX

• 標簽：constraint:key==value

親和性也有兩種，一種是image，一種是service，比如我有一個應用鏡像很大，我不希望它在集群各個地方去部署，我希望他部署下來已經下載鏡像的地方，這樣的話可以減少一些啟動的時間和下載的過程，你可以說我這個服務不是跟某個鏡像做親和，也可以跟某個服務做親和。

親和性：

• 鏡像：affinity:image==foo

• 服務：affinity:service==foo

總結一下Swarm這個產品，Swarm整體來說有幾個特點，第一個是部署簡捷，只有三個模塊，外部的依賴只有KV Store和Docker Daemon這兩個，所有組件都容器化。第二高效友好的用戶交互，高度兼容Docker Engine API，可直接使用Docker Client。第三是靈活的約束與親和性描述，可以在一定程度上彌補調度策略的不足。

同時，我們也看到它有一些不足的地方，首先一個不足的地方就是它是容器級別的API，所有的API都是針對單個容器的，抽象層次較低。其次，響應式設計，不方便執行常駐后臺的操作，它在內存中不保存任何的狀態，所有的狀態都是從Docker上統計過來的。有一個好處，它一旦掛掉了，能夠很方便地恢復狀態，但也有一些壞處，比如你要跑一個離線的任務，就不太好做。除此之外，它依賴定期同步跟Docker Engine保持一致狀態。

Swarm Mode

針對Swarm這個產品的一些不足，從1.12版本開始，Docker就提供了Swarm Mode的功能，這個功能是將Swarm的集群管理、容器調度功能集成進Docker Engine，并且提供Service級別抽象和自帶的負載均衡，它從容器級別的調度器進化到了服務級別的調度器。

架構

圖2 Swarm Mode架構

它的架構比Swarm更簡單一些，首先就是它沒有任何的外部依賴，只要你裝 Docker Engine，它就可以構成一個容器集群，DockerDaemon本身會兼Engine、Manager、Agent三職。Managers之間通過RAFT協議組成分布式強一致性KV Store，Manager與Worker的Daemon不通信。

同時，它也是有高可用設計的，Manager數量需要大于等于3才可以實現高可用，它也是一主多熱備，另外也可以動態添加/刪除Manager，如果有的機器宕機或者掛掉了，你不需要把這個機器再恢復起來，很多系統對Manager控制器的機器是有依賴的。如果一旦掛掉了你只能把它修好之后再上來，但是這個是不需要的，你可以任意在里面編程。這樣他會通過RAFT協議把原來集群狀態信息統一到Manager上去，這樣有實現了高可用。

Swarm Mode API

在剛才Swarm的API之上，多提供了兩類的API:

集群管理類:

• init、join、leave

• token

服務類:

• get/list

• create、delete、update

• inspect、ps

同時，Swarm的API有兩個特點，它分兩類，一類是像Swarm、Service、Network類，只有Manager能處理的。還有一類容器、鏡像、數據卷類，所有節點都能處理。另外它的API還是高度兼容舊的API，你可以拿低版本的去訪問Swarm mode的集群。

Service

我們來看一下Swarm Service的概念，它提供了三級的概念：

• Service：相同功能的一組容器

• Task：任務調度單元，由Manager生成，同步至Worker

• Container：Task落地

另外，還提供Rolling Update功能。

在Swarm mode里面Service分為兩類，一類是有Replicated Service，一類是Global Service。

Replicated Service：

• 用戶指定副本數

• Reconciled：自動確保副本數

• constraint

node.id node.hostname：

• node.role

• node.labels engine.labels

Global Service：

• 每個節點有且僅有一個容器

• 添加加點時自動擴展

• 可附加constraint

網絡模型方面，支持overlay網絡，同一網絡內，服務名、容器名可解析；一個服務一個網絡；服務發現支持不同服務可加入同一個網絡。

Routing Mesh

下面我們看一下Swarm自帶的負載均衡，它取的名字叫做Routing Mesh，Service自帶的負載均衡是基于LVS，主要有兩種模式，

VIP模式：每個服務一個VIP，通過LVS實現；服務名解析至VIP；

DNS模式：服務名解析至容器IP，RoundRobin方式。另外，服務發生變化時，自動調整后端。

總結一下Swarm Mode的產品，第一個它是無任何依賴，可以安裝Engine+一個命令，無中心架構。第二個它可以部署高可用服務，你可以在集群這邊進行訪問的，比如說你的容器只布在了三臺機器，這個集群所有的機器都可以訪問到這個服務，這樣的話就很容易做成高可用的。再一個Secure by default,自帶證書頒發、更新功能，Manager與Worker之間通過SSL連接。

當然它也有一些不足的地方，第一個只有Service級抽象，Stack級抽象仍無API，另外，部署有狀態服務比較復雜。第二，Service API有很多容器特性不支持，如host network、host pid、privileged等。還有一個缺點，它無法自舉，是需要手工init的。

Swarm在阿里內部的應用

上面介紹了Docker Swarm的產品相關的東西。下面我就來介紹一下Swarm在阿里內部的應用，這個也是大家更關心的一個地方，有幾個方面。第一是阿里內部的容器化，可能大家都知道，阿里內部有一支非常強大的運維團隊，除非查問題的時候，一般開發人員是不接觸現代的機器的，所有的應用部署、升級這些都是運維人員來做的。強大的運維團隊也導致了一些問題，它的應用的部署和升級往往是很個性化的，可能這個運維人員他在支持這個應用的時候，通過寫一些腳本或者用一些工具，實現業務的部署的自動化，而另外的運維人員運用另外的工具和另外的腳本，導致了很多應用的升級部署不是一個標準化的方式。這樣的話，比如說這個人員他轉崗了，新來的人首先要去熟悉那個部署的工具，這個運維任務比較大，所以應該是從去年、前年阿里內部開始推容器化，由Swarm來統一管理我們的集群，應用的話就是容器化之后，由Swarm去統一做部署，這樣的話就會形成一個跟業務無關的統一的部署平臺。運維人員不再去關心應用如何地去部署，他只要關心把這個應用部署上去就可以了，所有的應用都是一樣的方式，即使有新的人接替他學起來也非常地方便。

圖3 阿里云容器服務整體架構

另外是阿里云的專有云輸出，因為專有云這個東西一旦部署到用戶的機房之后，你升級就變得非常麻煩，有了容器之后，它的鏡像的管理和升級就非常方便了。還有一個優點，它可以實現管控部署的資源優化，因為原來可能所有的管控都是獨占機器的，這樣的話比如說你布很多服務就會占很多機器，有了容器之后管控就可以共享機器了，減少了管控所占的資源，提高了用戶能使用的資源的數量。

第二是阿里云的容器服務，這是我們在阿里云公有云上推出的一款產品，作用是幫用戶管理集群和部署應用，當然還提供更多高級別的服務。

第三是阿里云高性能計算 HPC也會用到容器，在高計算領域，它的安裝很復雜、很麻煩，經常比如說你拿到一個帶顯卡的機器，你在上面部署基礎的應用，可能得花掉你一周的時間，如果你的應用是容器化的，這個事情就可以放到容器里面去，你只要關心自己的應用就可以了，可以大大地提高應用部署的效率。

下面重點介紹一下阿里云容器服務的一些特性，我們先看一下整體的架構，整體來說，阿里云容器服務是一個集群托管的模式，機器是用戶的，但是管控是我們提供的。現在相當于我們幫用戶管理他的機器，我們通過某一些界面化、某一些API的信息讓用戶去管理集群以及管理他的應用。

用戶的機器下面會裝Engine、下面會跑容器，我們這邊的管控提供一個控制臺，提供集群的創建和擴容這樣的功能，然后提供服務、注冊和發現的功能，提供應用生命周期管理和使用調度的功能。同時我們還會把很多阿里云上的服務都集成進來，比如說我們集成了SLB、ECS等功能，達到的目標讓用戶只關心我的應用，而不需要關心底下的機器。

我們可以看一下我們提供的功能，從四個角度講。

第一個是集群的管理，這是最基本的功能，我們可以幫用戶一鍵創建出一個容器集群，同時支持公有云、專有云、混合云以及敏捷版，公有云包括GPU的機器，專有云是部署在用戶機房的，混合云就是你可以一部分集群管控在我們的機房，但是真正的用戶機器在你自己的機房。你可以實現應用跨云的統一部署。另外還支持bare metal敏捷版。

第二是鏡像服務，這是對容器化很重要的服務，我們支持公有和私有的倉庫，你可以有自己的私有倉庫，同時支持DockerHub的加速，我們提供這個加速的功能可以讓你像訪問國內的機器一樣，另外可以連接第三方代碼庫，這樣，其實你可以當成CICD系統的最重要的環節，你可以從代碼到最終生成鏡像，甚至到最后部署把它全自動打通。

第三是應用生命周期的管理，支持Swarm和Swarm Mode兩種模式。

同時支持Rolling Update、藍綠發布、離線與定時任務。

最后是微服務的支持，微服務它不是為容器而生，但是有了容器之后它的實現會變得更簡單一些，為了微服務的支持，我們提供了一些很重要的基礎的功能。包括服務發現、負載均衡、彈性伸縮、集成監控與日志、集成共享存儲。

這是在阿里云上部署一個nginx應用的一個例子，這是用的3.0的模板，用Engine來部署，它可以通過8080端口來訪問到。

圖4 負載均衡案例

version: ”3.0” ?#支持v1 v2 v3 compose模板services:nginx:image: nginx:latestdeploy:mode: replicatedreplicas: 3ports:- 8080:80labels:aliyun.lb.port_8080`: tcp://slbtest:8080 #負載均衡 aliyun.log_store_dbstdout: stdout ? ? ? ? #日志收集aliyun.log_store_varlog: /var/log/*.logvolumes:- 'website:/usr/share/nginx/html' volumes:website:driver: ossfs ?#共享存儲數據卷，支持oss、nasdriver_opts:bucket: acs-sample

自動擴容的事例，簡單來說，你只要聲明一下，當CPU超過70%了就擴展出兩個容器來，我們的做法是通過監控平臺把數據收集上去，之后，如果當它超過了70%的時候會調用集群管理的API，給它擴出容器來，同時會把負載均衡的后端再掛到新的容器上，這樣就實現了自動擴容。

圖5 自動擴容案例

聲明式自動擴容

aliyun.auto_scaling.max_cpu: 70?
aliyun.auto_scaling.step: 2

監控插件

• 輸入: nagios, apache, docker, UDP, ….

• 輸出: Influxdb, prometheus, kafka

藍綠發布的事例，如圖6，藍色的應用要進行升級，怎么做呢？首先部署一個新的應用，這兩個是同時在線的，它會通過SLB給它分流量，比如80%和20%，之后做驗證，驗證之后，發布完成，系統就會把原來老的刪掉。

圖6 藍綠發布案例

機器學習案例，假如你的集群是穩步的，有GPU機器和非GPU機器，你可以在你的Service里面注明需要兩個GPU，系統會把你調度到有GPU的集群，同時把你的應用綁到GPU卡上去。

圖7 機器學習案例

version: '2' services:inception:image: acs_sample/inception:demovolumes:- inception_model/inception_model ? ?labels:- aliyun.gpu=2 ? ?ports:- "9000:9000"volumes:inception_model: driver: nas

作者簡介：陳萌輝，阿里云高級專家。

---

總結

以上是生活随笔為你收集整理的Swarm的进化和大规模应用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。