Docker學習總結（26）——Docker 管理工具的選擇：Kubernetes 還是 Swarm？
阿新 • • 發佈：2019-01-22
Docker 容器技術已經成為推動雲技術發展最重要的技術之一。如果你還沒有使用容器技術，那麼你很可能很快就會使用到它，不管以什麼樣的方式。
使用這種技術有兩個步驟。首先，你需要理解容器的概念。然後你需要有一個編排工具來處理容器的排程和管理。最終選擇誰取決於技術偏好和需求。
Docker是一種高階技術，能給使用者帶來很多計算方面的優勢。這篇入門介紹是該複雜的計算機程序的一個概要。將使用簡單直接的方式呈現它的基礎知識。
Docker是一個容器的軟體平臺。容器將一個計算任務 - 或者一系列任務 - 所有需要的東西打包然後在隔離的環境中執行它們。簡單來說，容器能為一個軟體包提供執行的平臺，而不需要一個完整的作業系統的支援。
這個簡單的描述讓容器聽起來就像一個被吹噓的虛擬機器。但是這並不正確。一個VM可以部署很多的服務，並在一個計算機上執行不同的計算程序。然後這個寬泛的解釋基本上一樣適用於容器，它們的不同點在於部署方式。
例如，這兩種方式的一個本質區別是用來執行它們的裸機（bare metal）。VM需要一個宿主計算機，並且必須要能共享它的資源。VM 執行在 hypervisor 上，其充當管理工具的功能。結果，不是所有的計算機都能支援虛擬複製。
這個支援取決與計算機的處理器。這個限制是巨大的。要在一個計算機上執行很多的VM會話或者伺服器受到宿主機器資源富裕量的限制。
虛擬機器需要依賴於一個安裝好的作業系統才能執行。而容器，只需要作業系統的某些部分就能執行。這意味著容器的執行效率更高、資源佔用更少，使得它們相較於VM更實用，發揮更好的計算作用。
另外一個重要的差別是VM可以在隔離的環境下執行應用，而容器沒有獨立運作的能力並因此遭致問題。因為容器沒有作業系統或者 hypervisor，它們需要有自己的管理系統。
目前有兩個流行的開源技術在這個容器控制領域進行競爭。Docker開發了Swarm，現在將它整合進了 Docker Toolbox。另外一個更加成熟的容器管理器是 Google 的Kubernetes。它們都解決了缺乏獨立執行能力的問題，通過提供一個能跨多主機、多資料中心、多雲環境執行的系統。
選擇權在你手裡。不管你選了哪一個，Docker都能執行的很好。決定那個工具最好，首先是要理解它們的不同點。
Kubernetes
Kubernetes是一個開源的可以用來自動部署、伸縮和管理容器化應用的系統。Kubernetes叢集包含一些基本組成部分。這裡是簡要的概括一下：
Kubernetes成組地部署和排程容器，這個組叫Pod，常見的Pod包含一個到五個容器，它們協作來提供一個 Service。
Kubernetes預設使用扁平的網路模式。通過讓在一個相同 Pod 中的容器共享一個 IP 並使用 localhost 上的埠，允許所有的 Pod 彼此通訊。
Kubernetes 使用 Label 來搜尋和更新多個物件，就好像對一個集合進行操作一樣。
Kubernetes 會搭設一個 DSN 伺服器來供叢集監控新的服務，然後可以通過名字來訪問它們。
Kubernetes 使用 Replication Controller 來例項化的 Pod。作為一個提升容錯性的機制，這些控制器對一個服務的中執行的容器進行管理合監控。
Swarm
Docker的開發者現在將Docker Machine、Compose 和 Swarm 整合進了 Docker Toolbox 中。你可以對這三駕馬車進行配置來讓它們負責容器的配置、管理或者叢集化容器。
Docker Swarm，現在作為一個 beta 版本，是一個 Docker 的叢集化工具。它通過使用一個或者多個 Docker 主機來組成一個 Swarm 叢集。 Swarm 的設計是將容器打包到主機上，所以它能為更大的容器預留其他的主機資源。較之於隨機地將容器排程到叢集中的一個主機上，這種叢集的組成方式能取得更加經濟的伸縮效能。
下面是 Swarm 和 Kubernetes 關鍵的不同點：
Swarm 有能將一組 Docker 引擎轉變為一個虛擬的 Docker 引擎的原生能力。
一個 swarm 只包含兩個元件：agent 和 manager。
一個叢集有一個主機來執行一個 Swarm agent，另外一個主機來執行 Swarm manager。
這對於運作來說是必要的，因為 manager 負責容器在主機上的編排和排程。
Swarm 使用一個發現機制來處理主機的發現和向叢集的新增。
Swarm 提供了標準的 Docker API。這使得它提供了開箱即用的能力，能讓所有既有的 Docker 管理工具 - 包括第三方的產品- 能自動地、透明地在多個主機上進行伸縮。
細微的不同點
兩種方式 - Kubernetes 和 Swarm 都能處理同一種類型的工作負載，以雲原生應用的方式。然而，一個很大的不同點是如何處理伸縮。
在Kubernetes中，每一個應用層被定義成一個 Pod。一次部署或者複製控制器可以手工地或自動地處理伸縮。在Swarm中，對於單個容器的伸縮定義在 Compose 檔案中。
其他的不同點在於管理器系統如何處理高可用、負載均衡、應用滾動更新和回滾、日誌和監控、儲存、網路、服務發現以及效能合伸縮性上。
結論
Kubernetes 和 Swarm 都能大規模構建虛擬的容器。它們提供了用來取得同樣目標的兩個方式。它們有不同的運作方法，提供了可能更加適合你特定需求的功能。
不要僅僅因為 Docker Swarm 是Docker Toolkit 自帶的就是用它作為解決方案。首先，讓你的 IT 團隊的成員上手熟悉兩種工具。然後讓 IT 團隊根據自己公司的情況來建言，哪一種方式配置和部署更加容易。
用最簡單的比喻來說，選擇Kubernetes 或者 Swarm 就像在將 Linux 桌面發行版的範圍縮小到兩個後選出一個最喜歡的。哪個更滿足你的需要如何才是決定因素。
使用這種技術有兩個步驟。首先，你需要理解容器的概念。然後你需要有一個編排工具來處理容器的排程和管理。最終選擇誰取決於技術偏好和需求。
Docker是一種高階技術，能給使用者帶來很多計算方面的優勢。這篇入門介紹是該複雜的計算機程序的一個概要。將使用簡單直接的方式呈現它的基礎知識。
Docker是一個容器的軟體平臺。容器將一個計算任務 - 或者一系列任務 - 所有需要的東西打包然後在隔離的環境中執行它們。簡單來說，容器能為一個軟體包提供執行的平臺，而不需要一個完整的作業系統的支援。
這個簡單的描述讓容器聽起來就像一個被吹噓的虛擬機器。但是這並不正確。一個VM可以部署很多的服務，並在一個計算機上執行不同的計算程序。然後這個寬泛的解釋基本上一樣適用於容器，它們的不同點在於部署方式。
例如，這兩種方式的一個本質區別是用來執行它們的裸機（bare metal）。VM需要一個宿主計算機，並且必須要能共享它的資源。VM 執行在 hypervisor 上，其充當管理工具的功能。結果，不是所有的計算機都能支援虛擬複製。
這個支援取決與計算機的處理器。這個限制是巨大的。要在一個計算機上執行很多的VM會話或者伺服器受到宿主機器資源富裕量的限制。
虛擬機器需要依賴於一個安裝好的作業系統才能執行。而容器，只需要作業系統的某些部分就能執行。這意味著容器的執行效率更高、資源佔用更少，使得它們相較於VM更實用，發揮更好的計算作用。
另外一個重要的差別是VM可以在隔離的環境下執行應用，而容器沒有獨立運作的能力並因此遭致問題。因為容器沒有作業系統或者 hypervisor，它們需要有自己的管理系統。
目前有兩個流行的開源技術在這個容器控制領域進行競爭。Docker開發了Swarm，現在將它整合進了 Docker Toolbox。另外一個更加成熟的容器管理器是 Google 的Kubernetes。它們都解決了缺乏獨立執行能力的問題，通過提供一個能跨多主機、多資料中心、多雲環境執行的系統。
選擇權在你手裡。不管你選了哪一個，Docker都能執行的很好。決定那個工具最好，首先是要理解它們的不同點。
Kubernetes
Kubernetes是一個開源的可以用來自動部署、伸縮和管理容器化應用的系統。Kubernetes叢集包含一些基本組成部分。這裡是簡要的概括一下：
Kubernetes成組地部署和排程容器，這個組叫Pod，常見的Pod包含一個到五個容器，它們協作來提供一個 Service。
Kubernetes預設使用扁平的網路模式。通過讓在一個相同 Pod 中的容器共享一個 IP 並使用 localhost 上的埠，允許所有的 Pod 彼此通訊。
Kubernetes 使用 Label 來搜尋和更新多個物件，就好像對一個集合進行操作一樣。
Kubernetes 會搭設一個 DSN 伺服器來供叢集監控新的服務，然後可以通過名字來訪問它們。
Kubernetes 使用 Replication Controller 來例項化的 Pod。作為一個提升容錯性的機制，這些控制器對一個服務的中執行的容器進行管理合監控。
Swarm
Docker的開發者現在將Docker Machine、Compose 和 Swarm 整合進了 Docker Toolbox 中。你可以對這三駕馬車進行配置來讓它們負責容器的配置、管理或者叢集化容器。
Docker Swarm，現在作為一個 beta 版本，是一個 Docker 的叢集化工具。它通過使用一個或者多個 Docker 主機來組成一個 Swarm 叢集。 Swarm 的設計是將容器打包到主機上，所以它能為更大的容器預留其他的主機資源。較之於隨機地將容器排程到叢集中的一個主機上，這種叢集的組成方式能取得更加經濟的伸縮效能。
下面是 Swarm 和 Kubernetes 關鍵的不同點：
Swarm 有能將一組 Docker 引擎轉變為一個虛擬的 Docker 引擎的原生能力。
一個 swarm 只包含兩個元件：agent 和 manager。
一個叢集有一個主機來執行一個 Swarm agent，另外一個主機來執行 Swarm manager。
這對於運作來說是必要的，因為 manager 負責容器在主機上的編排和排程。
Swarm 使用一個發現機制來處理主機的發現和向叢集的新增。
Swarm 提供了標準的 Docker API。這使得它提供了開箱即用的能力，能讓所有既有的 Docker 管理工具 - 包括第三方的產品- 能自動地、透明地在多個主機上進行伸縮。
細微的不同點
兩種方式 - Kubernetes 和 Swarm 都能處理同一種類型的工作負載，以雲原生應用的方式。然而，一個很大的不同點是如何處理伸縮。
在Kubernetes中，每一個應用層被定義成一個 Pod。一次部署或者複製控制器可以手工地或自動地處理伸縮。在Swarm中，對於單個容器的伸縮定義在 Compose 檔案中。
其他的不同點在於管理器系統如何處理高可用、負載均衡、應用滾動更新和回滾、日誌和監控、儲存、網路、服務發現以及效能合伸縮性上。
結論
Kubernetes 和 Swarm 都能大規模構建虛擬的容器。它們提供了用來取得同樣目標的兩個方式。它們有不同的運作方法，提供了可能更加適合你特定需求的功能。
不要僅僅因為 Docker Swarm 是Docker Toolkit 自帶的就是用它作為解決方案。首先，讓你的 IT 團隊的成員上手熟悉兩種工具。然後讓 IT 團隊根據自己公司的情況來建言，哪一種方式配置和部署更加容易。
用最簡單的比喻來說，選擇Kubernetes 或者 Swarm 就像在將 Linux 桌面發行版的範圍縮小到兩個後選出一個最喜歡的。哪個更滿足你的需要如何才是決定因素。