容器編排是一項(xiàng)快速發(fā)展的技術(shù)。目前有3個(gè)行業(yè)巨頭；Kubernetes、Docker Swarm 和 Apache Mesos。它們屬于DevOps 基礎(chǔ)設(shè)施管理工具的類(lèi)別，稱為“容器編排引擎”。Docker Swarm 贏得了廣大客戶的青睞，成為容器化的首選。Kubernetes 和 Mesos 是主要競(jìng)爭(zhēng)對(duì)手。在這方面，他們可以提供更多的東西。它們提供了不同的可用性梯度，并具有許多不斷發(fā)展的功能。
盡管 Docker Swarm 很受歡迎，但它也有一些缺點(diǎn)和有限的功能：
- Docker Swarm 依賴于平臺(tái)。
- Docker Swarm 不提供高效的存儲(chǔ)選項(xiàng)。
- Docker Swarm 的容錯(cuò)能力有限。
- Docker Swarm 監(jiān)控不足。
這些缺點(diǎn)引發(fā)企業(yè)質(zhì)疑：“如何選擇合適的容器管理和編排工具？”?許多公司現(xiàn)在都在選擇 Docker Swarm 的替代品。這就是 Kubernetes 和 Mesos 的用武之地。要系統(tǒng)地檢查這種選擇，有必要查看這兩種選擇所具有的核心競(jìng)爭(zhēng)力。因此，人們可以得出一個(gè)獨(dú)立知情的結(jié)論。
Docker Swarm、Kubernetes 和 Mesos 的特點(diǎn)
| 特征 | 碼頭工人群 | Kubernetes | 梅索斯/馬拉松 |
| 初始發(fā)布日期 | 2013 年 3 月，2019 年 7 月穩(wěn)定發(fā)布 | 2015 年 7 月，2019 年 9 月 v1.16 | 2016 年 7 月，穩(wěn)定版 2019 年 8 月 |
| 部署 | 基于 YAML | 基于 YAML | 獨(dú)特的格式 |
| 穩(wěn)定 | 相對(duì)較新且不斷發(fā)展 | 相當(dāng)成熟穩(wěn)定，持續(xù)更新 | 成熟 |
| 設(shè)計(jì)理念 | 基于 Docker | 基于 Pod 的資源分組 | 基于 Linux 的 Cgroups 和控制組 |
| 支持的圖像 | Docker 映像格式 | 有限地支持 Docker 和 rkt | 主要支持 Docker |
| 學(xué)習(xí)曲線 | 簡(jiǎn)單的 | 陡 | 陡 |
什么是 Kubernetes？
Kubernetes 于 2014 年 6 月首次發(fā)布，也稱為 k8s。它是谷歌為云原生計(jì)算提供的容器編排平臺(tái)。就功能而言，Kubernetes 是最原生集成的可用選項(xiàng)之一。它背后也有一個(gè)龐大的社區(qū)。Google 將 Kubernetes 用于其 Container as a Service 產(chǎn)品，更名為 Google Container Engine。對(duì) Kubernetes 提供擴(kuò)展支持的其他平臺(tái)包括 Microsoft Azure 和 Red Hat OpenShift。它還支持 Docker 并使用基于 YAML 的部署模型。
Kubernetes的架構(gòu)構(gòu)建在模塊化 API 核心?之上?，允許供應(yīng)商圍繞其專有技術(shù)集成系統(tǒng)。它在為應(yīng)用程序開(kāi)發(fā)人員提供強(qiáng)大的 Docker 容器編排和開(kāi)源項(xiàng)目工具方面做得很好。
什么是 Apache Mesos？
Apache Mesos 的根源可以追溯到 2009 年，當(dāng)時(shí)他獲得了博士學(xué)位。學(xué)生們首先在加州大學(xué)伯克利分校開(kāi)發(fā)了它。與 Kubernetes 和 Docker Swarm 相比，在管理數(shù)據(jù)中心和云資源方面，它采用了更多的分布式方法。
在處理容器管理時(shí)，它采用模塊化方法。它允許用戶在他們可以運(yùn)行的應(yīng)用程序的類(lèi)型和可擴(kuò)展性方面具有靈活性。Mesos 允許其他容器管理框架在其上運(yùn)行。這包括 Kubernetes、Apache Aurora、Mesosphere Marathon 和 Chronos。
創(chuàng)建 Mesos 是為了解決許多不同的挑戰(zhàn)。一個(gè)是，將數(shù)據(jù)中心資源抽象到一個(gè)池中。另一個(gè)是配置不同的工作負(fù)載并自動(dòng)化第二天的操作。最后，為正在運(yùn)行的任務(wù)和新應(yīng)用程序提供常青的可擴(kuò)展性。它具有單獨(dú)管理各種工作負(fù)載的獨(dú)特能力，包括 Java 等應(yīng)用程序組、無(wú)狀態(tài)微服務(wù)等。
容器管理：解釋
在我們決定如何選擇容器管理工具之前，必須進(jìn)一步解釋容器管理的概念。
容器管理是添加、組織和替換大量軟件容器的過(guò)程。它利用軟件自動(dòng)創(chuàng)建、部署和擴(kuò)展容器。容器管理需要一個(gè)平臺(tái)來(lái)組織軟件容器，稱為操作系統(tǒng)級(jí)虛擬化。該平臺(tái)無(wú)需使用復(fù)雜的相互依賴的系統(tǒng)架構(gòu)即可優(yōu)化效率并簡(jiǎn)化容器交付。
隨著越來(lái)越多的企業(yè)使用 DevOps 進(jìn)行更快的開(kāi)發(fā)及其應(yīng)用程序，容器變得非常流行。容器管理產(chǎn)生了對(duì)容器編排的需求，這是一種更專業(yè)的工具。它自動(dòng)化了基于容器的應(yīng)用程序的部署、管理、網(wǎng)絡(luò)擴(kuò)展和可用性。
容器編排：解釋
容器編排是指管理或調(diào)度用于多個(gè)集群中基于微服務(wù)的應(yīng)用程序的單個(gè)容器的自動(dòng)過(guò)程。它適用于 Kubernetes 和 Mesos。它還安排將容器部署到集群中，確定容器的最佳主機(jī)。
需要容器編排框架的一些原因包括：
- 配置和調(diào)度容器
- 容器可用性
- 容器供應(yīng)和部署
- 容器配置
- 擴(kuò)展容器應(yīng)用以實(shí)現(xiàn)負(fù)載均衡
- 容器的健康監(jiān)測(cè)
- 保護(hù)容器之間的交互
如何選擇容器管理和編排工具？
在決定如何有效地實(shí)施容器管理和編排時(shí)，需要考慮許多變量。最終的選擇將取決于用戶的具體要求。下面簡(jiǎn)要解釋其中的一些。
- CNI Networking：一個(gè)好的工具應(yīng)該允許服務(wù)之間的簡(jiǎn)單網(wǎng)絡(luò)連接。這是為了避免開(kāi)發(fā)人員不得不花時(shí)間在特殊用途的代碼上來(lái)查找依賴項(xiàng)。
- 簡(jiǎn)單性：使用的工具應(yīng)該盡可能簡(jiǎn)單地實(shí)現(xiàn)。
- 主動(dòng)開(kāi)發(fā)：選擇的工具應(yīng)該有一個(gè)為用戶提供定期更新的開(kāi)發(fā)團(tuán)隊(duì)。這是由于容器編排不斷發(fā)展的本質(zhì)。
- 云供應(yīng)商：選擇的工具不應(yīng)與任何單一的云供應(yīng)商綁定。
注意：容器編排只是 Mesos 模塊化架構(gòu)可以運(yùn)行的工作負(fù)載的一個(gè)示例。這種專門(mén)的編排框架稱為?Marathon。它最初是為了在 Linux cgroup 容器中編排應(yīng)用程序存檔而開(kāi)發(fā)的，后來(lái)在 2014 年擴(kuò)展了對(duì) Docker 容器的支持。
Kubernetes 和 Mesos 有什么區(qū)別？
Kubernetes 和 Mesos 對(duì)同一個(gè)問(wèn)題有不同的方法。Kubernetes 充當(dāng)容器編排器，而 Apache Mesos 就像云操作系統(tǒng)一樣工作。因此，兩者之間存在一些根本差異，下表突出顯示了這些差異。
| 差異點(diǎn) | Kubernetes | 阿帕奇梅索斯 |
| 應(yīng)用定義 | Kubernetes 是副本集、復(fù)制控制器、Pod 以及某些服務(wù)和部署的組合。這里，“Pod”是指一組位于同一位置的容器，被認(rèn)為是部署的原子單元。 | Mesos 的應(yīng)用程序組被建模為一個(gè) n 叉樹(shù)，組為分支，應(yīng)用程序?yàn)槿~子。它用于將多個(gè)應(yīng)用程序劃分為可管理的集合，其中組件按依賴順序部署。 |
| 可用性 | Pod 分布在 Worker 節(jié)點(diǎn)之間。 | 應(yīng)用程序分布在從節(jié)點(diǎn)之間。 |
| 負(fù)載均衡 | Pod 通過(guò)充當(dāng)負(fù)載均衡器的服務(wù)公開(kāi)。 | 可以通過(guò)代理負(fù)載均衡器訪問(wèn)應(yīng)用程序，即 Mesos-DNS。 |
| 貯存 | 有兩個(gè)階段 API。第一個(gè)為單個(gè)存儲(chǔ)后端提供抽象，例如 NFS、AWS 和 EBS 等。第二個(gè)為存儲(chǔ)資源請(qǐng)求提供抽象。這是通過(guò)不同的存儲(chǔ)后端來(lái)實(shí)現(xiàn)的。 | Marathon 容器能夠使用持久卷，它們位于創(chuàng)建它們的節(jié)點(diǎn)的本地。因此，容器總是需要在所述節(jié)點(diǎn)上運(yùn)行。實(shí)驗(yàn)性植絨器集成負(fù)責(zé)支持非單個(gè)節(jié)點(diǎn)本地的持久卷。 |
| 網(wǎng)絡(luò)模型 | Kubernetes 的網(wǎng)絡(luò)模型允許任何 pod 與任何服務(wù)或其他 pod 進(jìn)行通信。它需要兩個(gè)獨(dú)立的網(wǎng)絡(luò)來(lái)運(yùn)行，兩個(gè)網(wǎng)絡(luò)都不需要來(lái)自集群外部的連接。這是通過(guò)在集群節(jié)點(diǎn)上部署覆蓋網(wǎng)絡(luò)來(lái)實(shí)現(xiàn)的。 | Marathon 的 Docker 集成允許將容器端口映射到軟管端口，這是一種有限的資源。在這里，容器不會(huì)自動(dòng)獲取 IP，這只能通過(guò)與 Calico 集成來(lái)實(shí)現(xiàn)。需要注意的是，多個(gè)容器不能共享同一個(gè)網(wǎng)絡(luò)命名空間。 |
| 使用目的 | 它是集群領(lǐng)域新手的理想選擇，提供了一種快速、簡(jiǎn)單、輕松的方式來(lái)開(kāi)始他們的面向集群的開(kāi)發(fā)之旅。它提供了高度的多功能性和可移植性，并得到了微軟和 IBM 等少數(shù)知名供應(yīng)商的支持。 | 它是大型系統(tǒng)的理想選擇，因?yàn)樗荚趯?shí)現(xiàn)最大冗余。對(duì)于?Hadoop?或 Kafka 等現(xiàn)有工作負(fù)載，Mesos 提供了一個(gè)框架，允許用戶將這些工作負(fù)載相互交錯(cuò)。它是一個(gè)更穩(wěn)定的平臺(tái)，但使用起來(lái)相對(duì)復(fù)雜。 |
| 供應(yīng)商和開(kāi)發(fā)商 | Kubernetes 被多家公司和開(kāi)發(fā)人員使用，并得到其他一些平臺(tái)的支持，例如 Red Hat??OpenShift?和 Microsoft Azure。 | Mesos 得到 Twitter、Apple 和 Yelp 等大型組織的支持。它的學(xué)習(xí)曲線陡峭且相當(dāng)復(fù)雜，因?yàn)樗暮诵闹攸c(diǎn)是大數(shù)據(jù)和分析。 |
結(jié)論
Kubernetes 和 Mesos 采用不同的策略來(lái)解決相同的問(wèn)題。在基于幾個(gè)特性比較它們時(shí)，我們發(fā)現(xiàn)與 Docker Swarm 相比，這兩種解決方案在特性和其他優(yōu)勢(shì)方面是相當(dāng)?shù)摹Ｎ覀兛梢缘贸龅慕Y(jié)論是，它們都是容器管理和編排的可行選擇。每個(gè)工具都可以有效地管理 docker 容器。它們都提供對(duì)容器編排的訪問(wèn)，以實(shí)現(xiàn)應(yīng)用程序的可移植性和可擴(kuò)展性。
在通過(guò)其 DC/OS 處理遺留系統(tǒng)和大規(guī)模集群環(huán)境時(shí)，Mesos 直觀的架構(gòu)設(shè)計(jì)提供了很好的選擇。它還擅長(zhǎng)處理更具體的技術(shù)，例如使用 Hadoop 進(jìn)行分布式處理。想要構(gòu)建專門(mén)用于 docker 容器編排的系統(tǒng)的開(kāi)發(fā)團(tuán)隊(duì)更喜歡 Kubernetes。我們的直接比較應(yīng)該讓用戶清楚地了解 Kubernetes 與 Mesos 及其核心競(jìng)爭(zhēng)力。目的是為讀者提供相關(guān)數(shù)據(jù)和事實(shí)，以告知他們的決定。
美聯(lián)科技 Fre
美聯(lián)科技 Daisy
美聯(lián)科技 Fen
美聯(lián)科技
美聯(lián)科技 Sunny
美聯(lián)科技Zoe
夢(mèng)飛科技 Lily
美聯(lián)科技 Anny