容器編排器們的自我介紹

哈嘍大家好，我是鹹魚

鹹魚在《一文帶你瞭解容器技術的前世今生》有介紹過容器技術的由來以及Docker項目的發展

我們知道，Docker 及其他容器技術能夠極大地簡化應用程式的部署，做到了”開箱即用“

俗話說：”凡是具有兩面性“。容器技術給我們帶來便利的同時，一些問題也隨之出現了

隨著企業規模或者說業務規模的不斷擴大，應用程式越來越多、而每個應用程式往往又由多個容器組成

例如想要實現一個簡單的資料庫 web 界面也可能需要為資料庫伺服器和應用程式運行單獨的容器

於是容器的管理便成為了一個棘手的難題。工程師們為瞭解決這個問題，開發了一系列的容器編排器（container orchestrator），其中最有名的當屬 kubernetes

容器編排器可以將一組容器作為一個基本單元去進行管理（例如 K8s 里的 pod），而且容器編排器可以在集群之間自動分配容器工作負載

那麼今天，鹹魚將以自我介紹的形式來帶大家瞭解三個容器編排器——Docker Compose、Swarm、Kubernetes

Docker Compose

大家好，我叫 Docker Compose 。我的爸爸是一個名叫 Docker 的公司

我的前身是一個叫 Fig 的項目，Fig 項目可是大有來頭——因為它第一次提出了容器編排的概念

你只需要執行一條命令 fig up 就能夠依次創建一系列容器，並且容器之間的關係及依賴性，都會自動幫你解決

當時它在 Github 上的熱度可是比肩 Docker 的，後來我的爸爸秉承”打不過就加入“的理念，把 Fig 項目收購了

收購之後將名字改成了 Compose，於是我誕生了

我是根據一個 yaml 格式的配置文件來工作的，通常命名為 Docker-compose.yml ：

• 首先我會去讀取這個文件，然後通過 Docker API 創建這個文件聲明的資源
• 我還會為這些資源打上標簽，方便我創建之後將它們分組管理

實際上我並不能夠稱得上是一個容器編排器，因為我實際上是通過 Docker 命令行介面（Docker command-line interface ）去操作一組組容器的

舉個例子，比如說在配置文件里有這三種類型的資源：

• service：包含了要啟動的容器的聲明。裡面的每一個條目都相當於一個 Docker run 命令
• networks：包含了可以訪問到容器的網路。裡面的每個條目都相當於一個 Docker network create 命令
• volumes：包含了可以訪問到容器內部的容器捲（容器捲即能夠掛載到容器內部的持久存儲）。裡面的每一個條目都相當於一個 Docker vloume create 命令

儘管如此，我依舊能夠較好地管理容器之間的依賴關係，我還能夠為容器創建一個共用網路和捲，使它們可以相互通信和共用數據

但是我不能夠實現容器的高可用性，如果容器出現故障，需要手動進行恢復

Swarm

哈嘍大家好，我叫 Swarm

Docker Compose 雖然為大家提供了一種方便的方式去管理容器，但他在一開始的時候只能在單台主機上工作

也就是說他創建的所有容器都在同一臺機器上面運行，拋開性能不談，如果所有應用都在一臺伺服器上，要是這台伺服器宕了，後果可是不堪設想的

為瞭解決這個問題，早在 2014 年我的哥哥 Classic Swarm （https://github.com/Docker-archive/classicswarm ）

就已經開始提供跨主機運行容器的解決方案了，但不久之後我的爸爸就不管他了，在社區上不再維護

時間來到 2016 年，我誕生了

與我的哥哥 Classic Swarm 相比，我是直接被內置到了 Docker 當中

不但如此，我能夠提供更強大的功能和更好的性能，支持服務發現、負載均衡、滾動更新等特性

創建集群的時候，我只需要在初始節點上執行 Docker swarm init 命令，然後在每個要添加進集群的其他節點上面執行 Docker swarm join 命令就可以了

怎麼樣，是不是非常方便

小伙伴們可能對我怎麼管理集群比較關心，首先我會將集群中的節點分成兩類：

• 管理節點（Manager nodes）

管理節點提供了一個 API ，可以通過這個 API 來啟動容器

而且管理節點之間使用基於 Raft 共識演算法的協議相互通信，便於同步集群的狀態，實現了高可用性和數據一致性

• 工作節點（Worker nodes）

工作節點，顧名思義就是就負責幹活的節點啦。它們負責執行實際的容器工作

而且我的爸爸跟我說管理節點最多只能設置七個，但工作節點數量不限制

別看我這麼能幹，其實我也有一些缺點，畢竟器無完器嘛

缺點一：集群裡面不能夠實現跨節點共用存儲

雖然我支持集群裡面跨節點網路通信（使用橋接方法），但是我不能夠支持跨節點的共用存儲。我必須依賴第三方的捲插件才能實現

缺點二：stack file 和 compose file 難以區分

自從我被集成到 Docker Engine 後，我發現我能夠通過 compose 文件來部署服務了（部署 services、volumes等資源）

而你們也知道的，compose 文件一開始是給 Docker Compose 用的

我們來看下對比，可以看到用法是很相似的

Docker-compose -f Docker-compose up

Docker stack deploy -c Docker-compose.yml somestackname

但實際上我是通過 stack file 來進行集群部署的，stack file 也是 YML 格式的文件，它跟 compose file 極其相似

這樣就會導致一些初學者在學習的時候不知道該用 stack file 還是 compose file ，可以看下下麵這個 issue

https://stackoverflow.com/questions/43099408/whats-the-difference-between-a-stack-file-and-a-compose-file

PS：一般來講，Stack file 和Compose file 的語法和功能非常相似，都可以用來定義和部署多個服務或容器

但是，Stack file 更加適合用來管理生產環境中的服務，而Compose file 更加適合用來管理開發和測試環境中的容器

此外，Stack file 還支持一些 Compose file 不支持的功能，如服務發現、負載均衡、滾動更新等

我的器生並非一帆風順，我曾經可是 Docker Cloud 的支柱，但是 Docker Cloud 在 2018 年的時候就被關閉了

不但如此，隨著對手 Kubernetes 的發展，我的地位不斷地受到威脅。直到 2019 年，我的爸爸宣佈停止對我的開發和維護，將重心轉向 Kubernetes

可謂是：”躋攀分寸不可上，失勢一落千丈強“

Kubernetes

哈嘍大家好，我叫 Kubernetes。為了方便，你們可以叫我 K8s

想必大家都聽說過我，作為迄今為止最受歡迎的容器編排器，我能夠在多達數千個節點的集群上管理和分配資源

請允許我驕傲一下，我在容器編排器中地位相當於谷歌在搜素引擎中的地位，可以說是我主導了容器編排

但我能有今天，一方面歸功於我的爸爸是谷歌，另一方面我得到了雲原生計算基金會(Cloud Native Computing Foundation，CNCF)的支持

在 2014~2015 年間，整個容器社區可謂熱鬧非凡。但是熱鬧非凡的景象背後則是許多人的擔憂和不滿

那時候 Docker 項目已經成為 Docker 公司一個商業產品，當時我的爸爸找到了 Docker 公司，希望能夠跟 Docker 合作，但是強硬的 Docker 覺得這會消弱自己的地位，拒絕掉了這個請求

而且 Docker 公司在 Docker 開源項目的發展上，始終保持著絕對的權威和發言權，併在多個場合用實際行動挑戰到了其他玩家（比如，CoreOS、RedHat，甚至我爸爸和微軟）的切身利益

於是這些開源基礎設施領域巨頭們聯合我爸爸發起了一個名為CNCF（Cloud Native Computing Foundation）的基金會

這個基金會的目的就是希望以 Kubernetes 項目為基礎，建立一個由開源基礎設施領域廠商主導的、按照獨立基金會方式運營的平臺級社區，來對抗以 Docker 公司為核心的容器商業生態

於是在那個時候，我誕生了。我的前身是 Borg （一個谷歌內部工具）

如果你看過 Kubernetes 項目早期的 GitHub Issue 和 Feature 的話，就會發現它們大多來自於 Borg 和 Omega 系統的內部特性，這些特性落到 Kubernetes 項目上，就是 Pod、Sidecar 等功能和設計模式

我剛出生那會，因為操作太過複雜被很多人抱怨

如果你們想要配置集群，除了我本身，你們還需要選擇和配置一些第三方組件。這就跟 Linux 內核需要跟 GNU 相結合才能構成一個完整的操作系統一樣，我只是一個編排器，我需要跟其他軟體結合才能構成一個完整的集群

還記得上面說過的 CNCF 基金會不，RedHat 也在裡面，它把它的那一套玩法搬到了我的身上

跟 Linux 發行版本一樣，我跟安裝程式和其他精心挑選的第三方組件捆綁在一起，搖身一變就成了 K8s 發行版

有了 K8s 發行版，你們對我的抱怨就少了很多

不但如此，我的爸爸開始在 K8s 社區上大力推行”民主化“變革，即從 API 到容器運行時的每一層，Kubernetes 項目都為開發者暴露出了可以擴展的插件機制，鼓勵用戶通過代碼的方式介入 Kubernetes 項目的每一個階段

這個民主化變革帶來的效果是巨大的，很快在整個容器社區中催生出了大量的、基於 Kubernetes API 和擴展介面的二次創新工作

隨著我不斷崛起不斷擴大，Docker 公司也不得不面對自己即將失敗的現實，從 2017 年開始，Docker 公司先是將 Docker 項目的容器運行時部分 Containerd 捐贈給 CNCF 社區

接著 10 月份的時候，Docker 公司出人意料地宣佈，將我內置到它們的主打產品 Docker 企業版中，這標志著這場轟轟烈烈的”編排器之爭“至此落下帷幕

如果當初 Docker 公司選擇了跟我爸爸合作，那麼如今的容器生態又會是一番怎樣的景象呢？

本文參考鏈接：https://lwn.net/Articles/905164/#t