Kubernetes 與 Docker – 兩者有何不同？
硬體虛擬化透過使用虛擬機器管理程式(hypervisors),讓虛擬機器(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 容器的一種方式,但目前有一種比 Docker Compose 更強大的替代方案,名為 Kubernetes。
什麼是 Kubernetes？
Kubernetes 是一套開源的容器編排解決方案,用於以高度自動化的方式管理容器化軟體與服務。
Kubernetes 是 Google 的專案,旨在自動化執行於容器中的應用程式的部署、縮放與可用性。您可以將執行容器的主機數量增加至 11 台或更多。此外,您還可透過 Kubernetes 建立 Docker 容器叢集,以確保高可用性與負載平衡。
叢集中使用的主機稱為節點。Kubernetes 採用主從架構,叢集由主節點和工作節點組成。Kubernetes 建議的節點最低數量為四台。雖然您可以僅使用一台機器建立叢集,但若要執行所有範例和測試,至少需要四台節點。 處理生產環境流量的 Kubernetes 叢集應至少具備三個工作節點。使用兩個主節點可保護叢集免於單一主節點故障的影響。如有需要,您也可以使用超過兩個主節點。
Master nodes用於管理叢集的狀態,包括接收客戶端請求、為容器排程作業、執行控制迴圈等。一份 etcd 資料庫 該服務需在每個主節點上運行,以儲存叢集的所有資料。主節點會執行以下三項程序: kube-apiserver, kube-controller-manager 以及 kube-scheduler.Working nodes用於透過執行容器來處理應用程式工作負載。以下兩個 Kubernetes 進程在非主節點上運行: kubelet (用於與主節點通訊)以及 kube-proxy (用於在每個節點上映射 Kubernetes 網路服務)。Replication Controller這是一個用於確保在任何特定時刻,指定數量的 Pod 複本始終處於運行狀態的元件。因此,您可以確保在需要時,Pod 始終可用。
若使用 Kubernetes,服務之間會透過不同的命令列介面 (CLI) 和 API 進行通訊。此外,在命名 RESTful API 的物件和資源時,也會使用特定的術語,這些物件和資源是使用 Kubernetes 建置的叢集所包含的組件。Pod是 Kubernetes 中的基本調度單位。這是一組資源,其中多個容器能夠協同運作。屬於同一個 Pod 的容器可以運行在同一台主機上,並共用相同的資源和本地網路。Pod 中的容器彼此隔離,但可以非常輕鬆地相互通訊。因此,Pod 通常用於 Kubernetes 環境中;但若您使用獨立的 Docker 應用程式,則僅能使用容器池。Service是一組協同運作的容器,例如可提供多層次應用程式的功能性。Kubernetes 透過抽象化機制,支援 Pod 的動態命名與負載平衡。此方法確保服務間能透過名稱建立透明的連線,並讓您能夠追蹤其當前狀態。Labels這些是與 Pod 及其他物件或服務綁定的鍵值對,除了能讓您輕鬆將它們分組並指派任務外,Namespaces這是一種可將單一 Kubernetes 叢集邏輯上劃分為多個虛擬叢集的方法。每個虛擬叢集皆可在受配額限制的虛擬環境中運作,且不會影響其他虛擬叢集。
Kubernetes 可以與 Docker 搭配使用,不過 Docker 並非 Kubernetes 唯一能配合使用的容器平台。Kubernetes 也能與 Windows 容器、Linux 容器、rkt 等技術協同運作。K8s 是 Kubernetes 的簡稱,在技術文件中偶爾會看到這個名稱。
Kubernetes 與 Docker:網路架構比較
讓我們來檢視各解決方案的網路連線選項。
Docker 提供三種網路模式,供容器之間進行網路通訊。
Bridge. 此模式為預設模式,會建立一個虛擬第三層橋接器。您主機上的網路名稱是 docker0 針對此網路。Docker 會自動建立一個第三層網路橋接,並針對外部網路介面設定網址轉換規則,採用網路位址轉換(NAT)原理,讓容器能夠相互通訊並連線至外部網路。 若您希望從其他主機或外部網路連線至容器,可為主機的網路介面設定端口轉發。如此一來,當您連線至主機的指定端口時,系統會將您轉發至 Docker 容器的對應端口。如有需要,您可為 Docker 容器建立多個網路介面。
Host在此模式下,主機網路驅動程式會確保容器不會與 Docker 主機隔離。容器會共用主機的網路堆疊,且容器的主機名稱與主機作業系統的主機名稱相同。若您執行一個正在監聽 TCP 埠 8080 的容器,則該容器應用程式可透過主機 IP 位址的 TCP 埠 8080 存取。 主機網路驅動程式僅適用於 Linux 系統。
None. 除了迴路介面的 127.0.0.1 位址外,該容器的網路介面未配置任何 IP 位址。若 無 已設定網路模式。
Multi-host networking for Docker containers. 若容器運行於不同主機上,在您設定覆蓋網路後,它們便能相互通訊。一個有效的鍵值儲存服務(領事, 等等,或 ZooKeeper) 必須進行設定,才能建立此類網路。
Kubernetes. 若使用獨立的 Docker 容器,每個容器皆可視為透過適當的網路介面進行通訊的基本單位。若使用 Kubernetes,Pod 則是容器叢集的基本單位。每個 Pod 都有專屬的 IP 位址,且至少包含一個容器。一個 Pod 可以包含多個用於執行相關任務的容器。 同一 Pod 內的容器無法同時開啟相同的端口。之所以採用此類限制,是因為由多個容器組成的 Pod 仍僅擁有單一 IP 位址。
此外,Kubernetes 會建立一個特殊的 暫停容器 每個 Pod 皆會擁有一個此類特殊容器。此特殊容器的設計目的是為其他容器提供網路介面(用於內部與外部通訊),且通常處於暫停狀態(即睡眠模式)。當 Kubernetes 傳送"SIGTERM"訊號時,這些暫停容器便會甦醒。
Flannel 通常作為 Kubernetes 中連接容器的網路架構,採用網路覆蓋(overlay networking)的原理。透過網路覆蓋,您可以讓容器透過邏輯網路與叢集中的不同實體主機(稱為節點)進行通訊。開源的 etcd 鍵值儲存庫用於儲存容器運行主機所分配的實際 IP 位址,與覆蓋網路中 IP 位址之間的對應關係。
透過 NSX Container Plugin,可將 Kubernetes 網路功能與 VMware NSX-T 整合。此整合讓您能夠使用多租戶網路拓撲,而此特點在 Kubernetes 中並未預設提供。
Kubernetes 網路模型提供以下特點:
- 所有容器皆可在不需 NAT 的情況下,與叢集內的其他容器進行通訊。
- 所有叢集節點都能在不使用 NAT 的情況下,與叢集內的所有容器進行通訊。反之,所有容器也能與所有叢集節點進行通訊。
- 容器可以看到自己的 IP 位址,而這些 IP 位址也會被 Kubernetes 的其他元件所偵測到。
Ingress 是 Kubernetes 中的 API 物件,用於管理從外部存取叢集內服務(主要為 HTTP 和 HTTPS)。您可以配置 Ingress 來執行對容器化服務的外部存取,以實現負載平衡、SSL 終止及基於名稱的虛擬主機功能。必須在主節點上部署 Ingress 控制器, Ingress 規則才能生效。
使用情境
將 Docker 作為獨立軟體使用,對於應用程式開發相當有利,因為開發人員可以在隔離的環境中執行其應用程式。 此外,測試人員也能利用 Docker 在沙盒環境中執行應用程式。若您希望在生產環境中使用 Docker 運行大量容器,過程中可能會遇到一些複雜情況。例如,某些容器容易過載或發生故障。雖然您可以手動在相應的機器上重新啟動容器,但手動管理會耗費您大量寶貴的時間和精力。
Kubernetes 透過提供高可用性、負載平衡、容器編排工具等關鍵特點,協助您解決這些問題。因此,Kubernetes 最適合用於擁有大量 Docker 容器且負載極高的生產環境。部署 Kubernetes 的難度高於安裝獨立的 Docker 應用程式,這也是為何 Kubernetes 未必總是適用於開發與測試階段。
Kubernetes 對比 Docker Swarm
Docker Swarm Docker Swarm 是一款原生的 Docker 叢集工具,能夠將一組 Docker 主機轉變為單一虛擬主機。Docker Swarm 與 Docker Engine 完全整合,讓您能夠使用標準 API 和網路處理程序;其設計目的是用於部署、管理及縮放 Docker 容器。
Swarm 是由稱為"節點"的 Docker 主機所組成的叢集。 在比較 Kubernetes 與 Docker Swarm 的叢集部署之前,讓我們先來了解使用 Docker Swarm 時叢集的主要組成部分:
Manager nodes 用於執行控制編排、叢集管理及任務分配。
Worker nodes 用於執行由管理節點指派任務的容器。每個節點均可配置為管理節點、工作節點,或同時具備兩者功能,以同時執行管理節點與工作節點的職能。請注意,工作節點會執行 Swarm 服務。
Services. Docker Swarm 中的服務會為每個容器化服務定義所需的最佳狀態。服務會控制諸如複本數量、可供其使用的網路資源,以及必須對外部網路開放的埠號等參數。服務設定(例如網路設定)可隨時修改並套用至容器,無需手動重新啟動包含該容器的服務。
Tasks. 任務是指正在執行單一容器的時槽。任務是 Swarm 服務的組成部分。
因此,Docker Swarm 和 Kubernetes 是兩個用途相近但性質不同的平台。現在是時候針對適當的類別對其進行比較了。
叢集部署
Docker Swarm. 標準 Docker API 允許您透過標準 Docker CLI(命令列介面)部署 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 採用標準化的 API,因此在使用 Docker Swarm 時,Docker CLI 所提供的絕大多數指令皆可沿用。Docker Compose 除了定義哪些容器必須分組外,還負責管理卷 (volumes) 及所使用的網路。透過 Docker Compose,可以為 Docker Swarm 設定精確的複本數量。
Kubernetes. Kubernetes 擁有專屬的 API 和客戶端,且需透過 YAML 檔案進行配置。這正是兩者間的關鍵差異之一,因為在此使用情境下,無法使用 Docker Compose 或 Docker CLI 來部署容器。 在 Kubernetes 中,定義服務的系統運作原理與 Docker Compose 相似,但更為複雜。Docker Compose 的功能性在 Kubernetes 中由 Pod、Deployment 和 Service 來實現,其中每一層級皆用於其特定目的。 Pod 負責容器的互動,而 Deployment 則負責叢集內單一節點的高可用性與網路連線(類似於未使用 Swarm 的獨立 Docker 應用程式所使用的 Docker Compose),至於 Kubernetes 服務,則負責叢集內服務運作的配置、容錯機制等。
人脈建立
Docker Swarm. 叢集內有一個預設的內部網路供容器間通訊使用,必要時可在此基礎上新增更多網路。網路透過生成的 TLS 憑證進行保護。系統支援手動生成憑證,以對容器資料流量進行加密。
KubernetesKubernetes 的網路模型截然不同,其透過外掛程式來實現,其中最受歡迎的選項是 Flannel。Pod 之間會相互互動,而這種互動可透過政策加以限制。 系統內建由 etcd 服務管理的內部網路。雖然支援 TLS 加密,但需手動進行設定。Kubernetes 的網路模型預設需配置兩個 CIDR(無類別域間路由),此機制亦稱為超網段(supernetting)。
監測
Docker Swarm. 雖然沒有內建的監控與記錄工具,但您可以手動設定第三方監控工具。ELK 或 Reimann 皆可作為此用途。
Kubernetes. Kubernetes 提供了內建的日誌記錄與監控工具。可使用 Elasticsearch 和 Kibana(ELK)來監控整個叢集的狀態,而 Heapster、Grafana 和 Influx 則支援監控容器服務。
圖形使用者介面 (GUI)
Docker Swarm. 您可以透過第三方工具(例如 Portainer.io)啟用圖形使用者介面,該工具提供了一個易於使用的網頁介面。此外,您也可以使用 Docker Enterprise 版本,該版本提供了用於叢集管理的圖形介面。
Kubernetes. Kubernetes 提供的圖形化使用者介面 (GUI) 是一個可靠的儀表板,可透過網頁介面存取,讓您輕鬆管理叢集。對於僅具備少量 Kubernetes 命令列介面 (CLI) 管理經驗的使用者而言,此 GUI 將是一項極具價值的工具。
結論
Docker Swarm 是一項原生 Docker 解決方案,主要透過 Docker API 和 CLI 進行操作。相較之下,Kubernetes 是 Google 的專案,用於部署執行容器的叢集。
Docker Swarm 和 Kubernetes 皆提供高可用性、負載平衡、覆蓋網路以及可擴展性等特點。 在兩者之中,Docker Swarm 的部署較為簡易,因為其大部分特點配置皆已自動化,且消耗的硬體資源較少。然而,其功能性受限於 Docker API,且缺乏原生監控工具。
另一方面,Kubernetes 則是一個具備高度靈活性的模組化解決方案,多年來已獲得多數大型企業的支援。 Kubernetes 雖具備監控服務及整個叢集的內建工具,但部署與設定較為困難,因此對資源需求較高。Kubernetes 不相容於 Docker CLI 和 Docker Compose。在運行高負載多容器應用程式的大型環境中,建議優先採用 Kubernetes。
