容器編排器們的自我介紹
哈嘍大家好，我是鹹魚
鹹魚在《一文帶你瞭解容器技術的前世今生》有介紹過容器技術的由來以及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
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/