容器雲技術選擇之kubernetes和swarm對比

swarm和k8s本質都是容器編排服務。它們都能把底層的宿主機抽象化，而後將應用從以構建好的鏡像開始，最終以docker的方式部署到宿主機上。

 

應該選擇哪一種方案做爲咱們的容器雲服務呢？

我以爲k8s（kubernetes簡稱）跟swarm的比較比如MySQL和SQL Server的比較，前者輕量級、實施快、以實現核心功能爲重，比較適合小規模部署，後者則是企業級、功能全、支撐場景多，適合作企業級docker雲方案。

以下我對二者作出的一些對比：

 

1. 設計理念有區別

swarm偏重的是容器的部署，而k8s更高一層：應用的部署。k8s對容器的全部操做都滲透着爲應用而服務的理念，好比pod是爲了讓聯繫緊密但又不適合部署在一塊兒的應用分別部署在不一樣docker裏面，但docker之間共享volume和network namespace方式，以便實現緊密地「交流」，在好比service是爲了隱藏pod（容器的集合，下文會介紹到）的網絡細節，讓pod提供固定的訪問入口，從而方便地讓其餘應用訪問等。

另外，k8s特別擅長大規模docker的管理。爲了解決複雜場景下應用的部署，k8s的組件要比swarm多得多，即使彷佛功能相似的組件，k8s不少時候都在場景支持上要優化swarm，以調度爲例，swarm只有三種調度策略：宿主機負載、宿主機運行容器的多寡、隨機指定宿主機，但K8s除此以外，策略更加豐富，它的策略數量是swarm的2倍以上。好比它還有端口衝突策略（在大規模部署docker時，端口衝突是必需要考慮的場景）、容器掛載的卷衝突策略、指定特定宿主機策略等。

 

2. k8s安裝複雜當適應更多場景

swarm與docker自然集成，安裝和使用很簡單，特別是docker 1.12及以上版本，swarm已經集成到了docker的engine中，所以docker安裝後swarm的 部署已經完成了一半，並且swarm的操做都是經過docker api來實現，掌握了docker的操做命令後上手swarm很簡單，基本上一個星期均可以玩的比較6了。

k8s基於docker，但圍繞着應用的部署開發了不少組件，這些組件不少並不依賴於docker的api，在部署時須要單獨規劃和實施，並且由於組件中不少策略適應不一樣的部署場景，因此在部署前不只僅要明白場景需求，並且還要對組件的設計邏輯瞭如指掌。因此安裝和熟悉過程相比swarm而言要曲折不少。

 

3. docker vs pod

在swarm中，被建立、調度和管理的最小單元就是docker。

在k8s中，最小單元則是pod（豌豆莢），pod由一個或者多個爲實現某個特定功能而放在一塊兒的容器組成。在pod內的docker共享volume和網絡namespace，彼此之間能夠經過localhost通訊或者標準進程間通訊。

用pod有什麼好處呢？

咱們試想這樣一個場景：咱們有一個web應用的容器，如今咱們爲了收集web日誌須要安裝一個日誌插件，若是把插件安裝在web應用容器的裏面，則會面臨以下一些問題：

• 若是插件有更新，儘管web應用沒有變化，但由於二者共享一個鏡像，則必須把整個鏡像構建一遍；
• 若是插件存在內存泄露的問題，整個容器就會有被拖垮的風險

若是把插件安裝在不一樣的容器，一樣也不合適，由於你要想辦法解決插件所在容器讀取web容器的日誌的問題。

有了pod之後，這些問題均可以迎刃而解。在pod裏面爲日誌插件和web應用各自建立一個容器，二者共享volume，web應用容器只需將日誌保存到volume，變能夠很方便的讓日誌插件讀取。同時，兩個容器擁有各自的鏡像，彼此更新互不影響。

 

4. 容器內的負載均衡

swarm自帶的負載均衡機制應用不廣，大部分仍是採用nginx+consul。nginx自己也是單獨的 容器，而consul保存了各個docker中應用的網絡信息（IP和端口），nginx鏡像在compose時，在dockerfile中指定consul的地址，取出consul中保存的應用的網絡信息，做爲參數配置到nginx的config file中，從而實現負載均衡。

這種模式的缺點就是：nginx的容器中的配置文件沒法跟着應用docker的網絡信息發生變化而更改，也就是說，若是新增長了docker，新增長的docker IP和應用端口則須要手動添加到nginx的config file中，或者從新構建nginx的容器。

kubernetes的負載均衡要完善不少，內部集成了負載均衡。並且，對於dockerIP變動的問題也有很好的處理機制：k8s經過service實現負載均衡，service是pod（pod包含了容器，容器中包含了應用）的訪問入口，它指向一組有相同label的多個pod。每一個service建立的時候會在k8s內置的dns服務器中寫入一條記錄：service的名稱和service的IP。當須要訪問pod中的應用時，只需訪問service的名稱便可，pod的IP對訪問者來講是透明的，所以無論怎麼變都不會影響負載均衡。

 

5. 誰最適合灰度發佈

二者都支持灰度發佈。

但swarm的灰度發佈是一次梭哈。當執行swarm update操做時，全部舊的docker逐一所有替換成新的版本。若是在替換過程當中我發現新版本存在問題時，我只能強行終止update，而後執行回滾。在這個過程當中對線上的應用會有影響。

而k8s有replication controller的機制，能夠人爲控制灰度發佈的過程。在發佈的過程當中，我可讓k8s經過replication controller起一小部分新版本的pod並減小對應數量老版本的pod，新的pod可響應用戶的請求，若是新的pod比較順利，則慢慢增長新版本的數量而減小老版本數量，直至新版本所有替換老版本，若是新的pod出現了問題，此時讓新pod當即下線，從而不對線上業務形成影響。

k8s的發佈過程能夠人爲干預，所以在重大發布時，這種方式其實更優。

 

6. 彈性伸縮

彈性伸縮是指根據宿主機硬件資源承載的狀況而作出的一種容器部署架構動態變化的過程。

好比某臺宿主機的CPU使用率使用偏高，k8s能夠根據Pod的使用率自動調整一個部署裏面Pod的個數，保障服務可用性，但swarm則不具有這種能力。

 

7. 生態

swarm是docke官方推出的集羣方案，k8s是脫胎於google的一款基於容器的應用部署和管理打造一套強大而且易用的管理平臺。相比swarm而言，k8s更懂容器的管理。

從github上也能夠到看到k8s項目的star和fork 都很高，並且網上找的資料也很是豐富。也正是基於k8s的生態影響力，致使docker不得不在新發布的docker EE（Enterprise Edition）將k8s整合進來。

 

結論：

綜上所述，K8S做爲一款企業級的容器雲方案，更值得咱們進行研究。套用業界流行的話：swarm懂容器，但K8S更懂管理。