哈嘍大家好，我是咸魚
咸魚在《一文帶你了解容器技術的前世今生》有介紹過容器技術的由來以及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
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/553370.html
標籤：Linux
上一篇：linux yum安裝
下一篇：返回列表