Kubernetes vs Docker – 有何不同?

硬體虛擬化通過使用 hypervisor 將物理硬體與虛擬機器(VMs)共享,提供了一系列優勢,如可擴展性、安全性、隔離等。目前,虛擬機器不是唯一的虛擬化形式,容器也變得非常流行。雖然 VMs 分享底層機器的物理硬體,但容器分享底層操作系統的內核。容器不是輕量級虛擬機器,而是標準化的可執行套件,用於提供應用程序,包括使用基於微服務的軟體架構開發的應用程序,並包括運行應用程序所需的所有組件。

Docker 引擎是運行容器的最流行平台。Kubernetes 是一個詞彙,在容器化和雲計算領域聽到的頻率越來越高。但哪個更好 – Docker 還是 Kubernetes?這是一個熱門的辯論話題,但以這種方式提問並不正確。例如,您不能問:“什麼更好 – 熱還是藍?”

什麼是 Docker?

Docker 是一個開源獨立應用程序,用作運行容器化應用程序的引擎。它安裝在您的操作系統(OS)上,最好是在 Linux 上,但也可以安裝在 Windows 和 macOS 上,然後運行在物理或虛擬機器上。

運行在容器中的應用程序與系統的其餘部分和其他容器隔離,但給人一種運行在自己的操作系統實例中的錯覺。多個Docker容器可以同時在單個操作系統上運行;您可以使用Docker 管理這些容器,而 Docker 可以在不使用 Kubernetes 的情況下運行。如果您有多個主機用於運行容器,手動管理可能很困難,通常最好選擇一個集中式管理工具或管控解決方案。

Docker Compose是一個基本的容器编排工具,用於運行多容器 Docker 應用程序。您可以配置一個 YAML (yml) Docker Compose 配置文件來定義多容器應用程序,而不是為每個容器單獨手動配置 Dockerfile。配置完單個 YAML 文件後,您可以使用 Linux 控制台中的單個命令運行所有需要的容器。 使用 Docker Compose 是编排 Docker 容器的一種方式,不過,還有一種功能強大的替代品可用,這就是 Kubernetes。

什麼是 Kubernetes?

Kubernetes 是一個開源的容器编排解決方案,用於管理具備高度自動化的容器化軟件和服務。

Kubernetes 是一個谷歌項目,旨在自動化運行在容器中的應用程序的部署、擴展和可用性。您可以將運行容器的主機數目增加到 11 個或更多

在集群中使用的主机被称为节点。 Kubernetes 的架构类型是主从 – 集群由主节点和工作节点组成。 Kubernetes 建议的节点最小数量为四个。虽然您可以使用一台机器构建集群,但为了运行所有示例和测试,您至少需要四个节点。处理生产流量的 Kubernetes 集群应至少具有三个工作节点。使用两个主节点可以保护集群免受一个主节点的故障影响。如果需要,您可以使用超过两个主节点。

  • 主节点用于管理集群的状态,其中包括接受客户端请求、调度容器操作、运行控制循环等。存储集群所有数据的etcd数据库的副本需要在每个主节点上运行。主节点运行一组三个进程:kube-apiserverkube-controller-managerkube-scheduler
  • 工作节点用于通过运行容器执行应用程序工作负载。两个 Kubernetes 进程在非主节点上运行:kubelet(用于与主节点通信)和 kube-proxy(用于在每个节点上反映 Kubernetes 网络服务)。
  • 複製控制器是一個組件,用於確保在任何給定的時刻,其數量被指定的 Pod 副本始終運行。因此,您可以確保在需要時總是可用 Pod。如果使用 Kubernetes,則將使用不同的 CLI 和 API 來彼此通信服務。此外,還使用特定術語來命名 RESTful API 的對象和資源,這些對象和資源是使用 Kubernetes 構建的群集的組件。
  • Pod是 Kubernetes 中的基本調度單元。這是一組資源,其中多個容器可以工作。屬於一個 Pod 的容器可以在同一台主機上運行,並使用相同的資源和相同的本地網路。 Pod 中的容器是隔離的,但可以很容易地彼此通信。因此,Pod 通常用於 Kubernetes,但如果您使用獨立的 Docker 應用程序,則僅可用容器池。
  • 服務是一組一起工作的容器,例如,提供多層應用程序的功能。 Kubernetes 通過使用抽象來支持 Pod 的動態命名和負載平衡。這種方法通過名稱確保了服務之間的透明連接,並允許您跟踪它們的當前狀態。
  • 標籤是綁定到 Pod 和其他對象或服務的鍵/值對,除了易於分組和分配任務外。
  • 命名空間是一種方法,允許將聯合的 Kubernetes 叢集在多個虛擬叢集之間進行邏輯劃分。每個虛擬叢集可以存在於受配額限制的虛擬環境中,而不會對其他虛擬叢集產生影響。

Kubernetes 可與 Docker 一起使用,但 Docker 不是唯一可用於 Kubernetes 的容器平台。Kubernetes 也可以與 Windows 容器、Linux 容器、rkt 等一起使用。K8s 是 Kubernetes 的名稱,有時可以在技術文檔中找到。

Kubernetes vs Docker: 網路比較

讓我們來檢視每個解決方案的網路選項。

Docker提供了三種容器之間的網路通信模式。

Bridge。此模式默認情況下使用,創建虛擬的第 3 層橋接。對於此網路,主機上的網路名稱是 docker0。Docker 自動創建第 3 層網路橋接並為外部網路接口配置對外掩碼規則,使用網路地址轉換(NAT)原則,允許容器彼此通信並連接到外部網路。如果您希望從其他主機和外部網路連接到容器,則可以為主機機器的網路接口配置端口轉發。因此,通過連接到主機機器的適當端口,您將被轉發到 Docker 容器的必要端口。如果需要,您可以為 Docker 容器創建多個網路接口。

主機。在此模式下,主機網路驅動程序確保容器不與 Docker 主機隔離。容器共享主機網路堆棧,且容器的主機名稱與主機操作系統的主機名稱相同。如果在其中運行 TCP 端口 8080 的容器,則容器應用程序可在主機機器的 IP 地址的 TCP 端口 8080 上使用。主機網路驅動程序僅適用於 Linux 機器。

。對於給定容器的網路界面,未配置任何 IP 地址,除了對於回環界面的 127.0.0.1 地址。如果設置了 網路模式,則無法訪問外部網路。

用於 Docker 容器的多主機網路。如果容器在不同主機上運行,則在配置了覆蓋網路後,它們可以彼此通信。必須配置有效的鍵值存儲服務(ConsulEtcdZooKeeper)來創建這樣的網路。

Kubernetes 。如果使用獨立的 Docker 容器,則每個容器都可以被視為通過適當的網路界面進行通信的基本單元。如果您正在使用 Kubernetes,Pod 是容器集群的基本單元。每個 Pod 都有自己的 IP 地址,並且至少由一個容器組成。一個 Pod 可以由多個用於相關任務的容器組成。同一 Pod 的容器不能同時打開相同的端口。這種限制是因為一個由多個容器組成的 Pod 仍然具有單一的 IP 地址。

此外,Kubernetes 為每個 Pod 建立一個特殊的暫停容器。這個特殊容器旨在為其他容器提供網路介面(用於內部和外部通信),通常處於暫停(睡眠模式)。這些暫停容器會在 Kubernetes 發送“SIGTERM”信號時喚醒。

Flannel通常被用作 Kubernetes 中連接容器的網路基礎結構,採用網路覆蓋的原則。覆蓋網路允許您通過集群中不同實體主機(被稱為節點)的邏輯網路進行容器之間的通信。開源的 etcd 鍵/值存儲庫用於保存由主機分配給容器的實際 IP 地址與覆蓋網路中的 IP 地址之間的映射。

通過使用 NSX 容器插件,Kubernetes 網路可以與 VMware NSX-T 集成。該集成允許您使用多租戶網路拓撲,在 Kubernetes 中不會“開箱即用”。

Kubernetes 網路模型提供以下功能:

  • 所有容器可以在集群內部與任何其他容器通信,無需 NAT。
  • 所有集群節點可以在集群內部與所有容器通信,無需 NAT。反之,所有容器可以與所有集群節點通信。
  • 容器看到自己的 IP 地址,並且 Kubernetes 的其他組件也看到這些 IP 地址。

Ingress 是 Kubernetes 的 API 物件,用於從集群外部管理對服務的訪問(主要是 HTTP 和 HTTPS)。您可以配置 Ingress 來執行對容器化服務的外部訪問,用於負載平衡、SSL 終止和基於名稱的虛擬主機。必須在主節點上部署 Ingress 控制器,以使 Ingress 規則正常工作。

使用案例

將 Docker 作為獨立軟件使用對於應用程序的開發是很好的,因為開發人員可以在隔離的環境中運行其應用程序。此外,測試人員也可以使用 Docker 在沙盒環境中運行應用程序。如果您希望在生產環境中運行大量容器,您可能會遇到一些問題。例如,一些容器可能會很容易被過載或失敗。您可以手動重新啟動適當的機器上的容器,但手動管理可能會花費您大量的寶貴時間和精力。

Kubernetes 允許您通過提供高可用性、負載平衡、容器編排工具等關鍵功能來解決這些問題。因此,Kubernetes 最適合於具有大量 Docker 容器的高負載生產環境。部署 Kubernetes 比安裝獨立的 Docker 應用程序更困難,這就是為什麼 Kubernetes 不總是用於開發和測試的原因。

Kubernetes vs Docker Swarm

Docker Swarm 是 Docker 的本地集群工具,可以将一组 Docker 主机转换为单个虚拟主机。Docker Swarm 完全集成到 Docker 引擎中,允许您使用标准 API 和网络流程;旨在部署、管理和扩展 Docker 容器。

Swarm 是一组称为节点的 Docker 主机集群。在比较使用 Docker Swarm 时的集群部署与 Kubernetes 和 Docker Swarm 之前,让我们考虑一下集群的以下主要组件:

管理节点 用于执行控制编排、集群管理和任务分配。

工作节点 用于运行由管理节点分配任务的容器。每个节点可以配置为管理节点、工作节点或两者兼而有之,以执行管理节点和工作节点功能。请注意,工作节点运行 Swarm 服务。

服务。Docker Swarm 的服务定义了每个容器化服务所需的最佳状态。服务控制诸如副本数量、可用于其的网络资源、必须从外部网络开放的端口等参数。服务配置(如网络配置)可以在不需要手动重新启动容器的情况下修改并应用到容器上。

任务。任务是一个容器正在运行的槽位。任务是 Swarm 服务的组成部分。

因此,Docker Swarm 和 Kubernetes 是用於相似目的的兩個不同平台。現在是時候在適當的一組類別中進行比較了。

集群部署

Docker Swarm。通過使用標準的 Docker CLI(命令行界面),標準的 Docker API 允許您使用 Swarm 部署集群,這使得部署更加容易,特別是在第一次使用時。與 Kubernetes 相比,Swarm 的部署易用性也是由單個 Docker 主控制器決定如何分配服務而實現的。在 Docker Swarm 中不使用 Pod。

Kubernetes需要您使用不同於標準 Docker 命令的指定命令。在 Kubernetes 中使用指定的 API,這意味著即使您熟悉 Docker 管理命令,您也可能需要學習使用額外的工具來部署 Kubernetes。在 Kubernetes 集群中必須手動定義節點 – 您應該選擇主控節點,定義控制器、調度器等。

可擴展性

Docker Swarm。由於 Docker 提供的簡單 API,可以更快地在大型和小型集群中部署容器和服務更新。命令行界面(CLI)相當簡單且易於理解。因此,與 Kubernetes 相比,Swarm 可以被認為是一個更具可擴展性的解決方案。

Kubernetes 提供相對統一的 API,以及一些功能,這些功能通常會導致部署過程較慢。必須配置三種類型的組件:Pod、Deploy 和 Service。當涉及自動擴展時,Kubernetes 是首選,因為它能夠分析伺服器負載,並且根據給定要求自動擴展和縮小。Kubernetes 是大型分散式網絡和複雜系統的最佳選擇。

高可用性

兩種解決方案選項都具有類似的服務複製和冗餘機制,在這兩種情況下,系統都是自我調節的,不需要在失敗節點重新變成集群後進行手動重新配置。

Docker Swarm。管理節點處理工作節點和整個集群的資源。Swarm 集群節點參與服務的複製。

Kubernetes。Kubernetes 的負載平衡服務檢測到不健康的節點,並將其從集群中消除。所有 Pod 都分佈在節點之間,從而在運行容器化應用程序的節點失敗時提供高可用性。

負載平衡

Docker Swarm。負載平衡是一個內置功能,可以通過使用內部 Swarm 網絡自動執行。將所有對集群的請求分發並重定向到集群節點;任何節點都可以連接到任何容器。Docker Swarm 使用 DNS 元素將傳入的請求分發給服務名稱。

Kubernetes。Pod 中定義的策略在 Kubernetes 中用於負載平衡。在這種情況下,容器 Pod 必須定義為服務。您必須手動配置負載平衡設置,而 Ingress 可以用於負載平衡。

創建和運行容器

Docker Swarm。當使用 Docker Swarm 時,由於 Docker Swarm 的標準化 API,可以利用 Docker CLI 提供的絕大多數命令。Docker Compose 定義了與卷和使用的網絡一起工作,除了定義必須將哪些容器分組在一起。可以使用 Docker Compose 為 Docker Swarm 設置精確數量的副本。

Kubernetes。Kubernetes 擁有自己的 API、客戶端,需要配置 YAML 文件。這是其中一個關鍵差異,因為在這種情況下,無法使用 Docker Compose 和 Docker CLI 部署容器。在 Kubernetes 中,定義服務的系統遵循與 Docker Compose 類似的工作原理,但更為復雜。在 Kubernetes 中,使用 Pods、Deployments 和 Services 執行 Docker Compose 的功能,其中每一層都用於其指定的目的。Pods 負責容器交互,而 deployments 負責集群中單個節點的高可用性和網絡(類似於 Docker Compose 用於獨立的 Docker 應用程序而無需 Swarm),而 Kubernetes 服務則負責配置集群內部的服務操作、容錯等。

網絡

Docker Swarm。叢集內容器間的通信有一個預設的內部網路,如果需要的話,可以添加更多網路。網路受到生成的TLS證書的保護。也支援手動證書生成以加密容器數據流量。

Kubernetes。Kubernetes的網路模型非常不同,通過使用插件來實現,其中一個是Flannel,最受歡迎的選項之一。Pods相互交互,這種交互可以通過策略進行限制。由etcd服務管理的內部網路。TLS加密也可用,但需要手動配置。Kubernetes的網路模型假設配置兩個CIDRs,即無類別域間路由,也被稱為超網掩碼。

監控

Docker Swarm。沒有內建的監控和日誌記錄工具,但可以手動設置第三方監控工具。可以使用ELK或Reimann來實現這一目的。

Kubernetes。Kubernetes提供了內建的日誌記錄和監控工具。Elasticsearch和Kibana(ELK)可用於監控整個叢集狀態,而Heapster、Grafana和Influx則支持監控容器服務。

圖形用戶界面(GUI)

Docker Swarm。GUI可以通過第三方工具啟用,例如Portainer.io,它提供了一個用戶友好的網頁界面。作為替代,您可以使用提供集群管理圖形界面的Docker企業版。

Kubernetes。Kubernetes 提供的 GUI 是一個可靠的儀表板,通過網頁界面可以輕鬆控制您的集群。對於對於使用 CLI 管理 Kubernetes 有較少經驗的用戶來說,GUI 可以是一個非常有價值的工具。

結論

Docker Swarm 是一個本地 Docker 解決方案,主要使用 Docker API 和 CLI。相比之下,Kubernetes 是 Google 的項目,用於部署運行容器的集群。

Docker Swarm 和 Kubernetes 都提供高可用性、負載平衡、覆蓋網絡和可擴展性功能。Docker Swarm 是這兩者中更容易部署的,因為它的大部分功能配置是自動化的,並且消耗較少的硬件資源。但是,功能受到 Docker API 的限制,並且缺少本地監控工具。

與此相反,Kubernetes 是一個具有高靈活性的模塊化解決方案,被大多數大型企業支持了多年。Kubernetes 提供了用於監控服務和整個集群的內置工具,儘管部署和配置較難,這使得該資源成為一個更具挑戰性的解決方案。Kubernetes 不兼容 Docker CLI 和 Docker Compose。在運行高負載的多容器應用程序的大型環境中,更喜歡使用 Kubernetes。

Source:
https://www.nakivo.com/blog/docker-vs-kubernetes/