兩個最具影響力的云計算開源項目之間的異同。

Kubernetes vs. Docker 是一個在云計算行業被多次提及的話題。無論你來自非技術背景，需要快速介紹，還是需要做商業決策，我都希望以下幾點能一勞永逸地澄清這件事。

我們需要超越圍繞 Kubernetes 和 Docker 的炒作。這些詞的意思很重要，在它們之上運行您的業務之前要掌握。

Kubernetes 和 Docker 之間的共生關系

問題“Kubernetes vs. Docker?” 本身是相當荒謬的，就像將蘋果比作橘子一樣。一個不是另一個的替代品。恰恰相反，Kubernetes 可以在沒有 Docker 的情況下運行，而 Docker 可以在沒有 Kubernetes 的情況下運行。但是 Kubernetes 可以(并且確實)從 Docker 中受益匪淺，反之亦然。

Docker 是一個獨立的應用程序，可以安裝在任何計算機上以運行容器化應用程序。容器化是一種在操作系統上運行應用程序的方法，以便應用程序與系統的其余部分隔離。盡管可能有其他容器在同一系統上運行，但您為應用程序創建了一種錯覺，認為它正在獲得自己的操作系統實例。Docker 使我們能夠在單個操作系統上運行、創建和管理容器。

Kubernetes 將其增加到 11。如果您在一堆主機(不同的操作系統)上安裝了 Docker，則可以利用 Kubernetes。這些節點或 Docker 主機可以是裸機服務器或虛擬機。然后，Kubernetes 可以讓您從單個命令行或儀表板跨所有這些節點自動執行容器配置、網絡、負載平衡、安全性和擴展。由單個 Kubernetes 實例管理的節點集合稱為 Kubernetes 集群。

現在，為什么首先需要有多個節點?其背后的兩個主要動機是：

1. 使基礎設施更加健壯——即使某些節點離線，您的應用程序也將在線，即高可用性。

2. 使您的應用程序更具可擴展性——如果工作負載增加，只需生成更多容器和/或向 Kubernetes 集群添加更多節點。

Kubernetes 和 Docker 之間的差異

原則上，Kubernetes可以使用任何容器化技術。Kubernetes 可以集成的兩個最流行的選項是 rkt 和 Docker。然而，Docker贏得了最大的細分市場，這導致在完善 Docker 和Kubernetes 之間的集成方面付出了很多努力，比任何其他容器化技術都多。

同樣，Docker背后的公司 Docker Inc. 也提供了自己的容器編排引擎，名為 Docker Swarm。但即使是他們也意識到 Kubernetes 已經上升到甚至 Docker for Desktop(MacOS 和 Windows)都帶有自己的 Kubernetes 發行版。

如果有人對在基于 Docker 的產品中采用 Kubernetes 感到緊張，那么最后一點將消除所有疑慮。這兩個項目都全心全意地相互擁抱，并從這種共生關系中受益匪淺。

Kubernetes 和 Docker 之間的相似之處

這些項目不僅僅是技術，它們是一個人的社區，盡管存在差異，但由業內一些最聰明的人組成。當志同道合的人合作時，他們會交換聰明的想法并相互學習最佳實踐。

這些是Kubernetes 和 Docker 共享的一些想法：

1. 他們對基于微服務的架構的熱愛(稍后會詳細介紹)。

2. 他們對開源社區的熱愛。兩者都是主要的開源項目。

3. 它們主要是用 Go 編寫的，因此可以將它們作為小型輕量級二進制文件發送。

4. 他們使用人類可讀的 YAML 文件來指定應用程序堆棧及其部署。

從理論上講，您可以在不了解另一個的情況下了解其中一個。但請記住，在實踐中，如果您從 Docker 在單機上運行的簡單案例開始，然后逐漸了解 Kubernetes 如何發揮作用，您將受益更多。

什么是 Docker?

有兩種看待 Docker 的方式。第一種方法涉及將 Docker 容器視為真正的輕量級虛擬機。第二種方法是將 Docker 視為軟件打包和交付平臺。后一種方法被證明對人類開發人員更有幫助，并導致該技術得到廣泛采用

Docker 容器概述：

傳統上，云服務提供商使用虛擬機將正在運行的應用程序相互隔離。管理程序或主機操作系統為許多客戶操作系統提供虛擬 CPU、內存和其他資源。每個來賓操作系統都像在實際物理硬件上運行一樣工作，理想情況下，它不知道在同一物理服務器上運行的其他來賓操作系統。VMware 是最早普及這一概念的公司之一。

但是，這種虛擬化存在幾個問題。首先，資源的供應需要時間。每個虛擬磁盤映像都很大很笨重，準備使用 VM 可能需要長達一分鐘的時間! 其次，也是一個更重要的問題，是系統資源的低效利用。操作系統內核是控制狂，想要管理他們認為可用的一切。

因此，當客戶操作系統認為它有 2GB 內存可用時，它會控制該內存，即使在該操作系統上運行的應用程序只使用其中的一半。 另一方面，當我們運行容器化應用程序時，我們虛擬化操作系統(您的標準庫、包等)本身，而不是硬件。

現在，您不再為 VM 提供虛擬硬件，而是為應用程序提供虛擬操作系統。如果需要，您可以運行多個應用程序并對其資源利用率施加限制，并且每個應用程序都將在運行時忽略與其一起運行的數百個其他容器。

Docker——作為開發者的工具：

開發人員面臨的問題之一是運行應用程序的生產服務器與開發應用程序的他們自己的開發機器(通常是筆記本電腦和工作站)之間的差異。假設您在桌面上運行 Windows 10，但您想為 Ubuntu 18.04 編寫應用程序。也許您正在使用 Python v3.6 來編寫您的應用程序，而 Ubuntu 服務器仍在運行 3.4。

有太多的變量需要考慮，所以我們使用 Docker 來抽象出這種復雜性。Docker 可以安裝在任何操作系統上，甚至 Windows 和 Mac OS X 都得到很好的支持。因此，您可以將代碼打包到 Docker 映像中，使用 Docker 在本地運行和測試它，以確保從該 Docker 映像創建的容器在生產中的行為方式相同。

注意：所有依賴項，如編程語言版本、標準庫等，都包含在該映像中。

這種將Docker 鏡像視為軟件包的方式導致了以下流行語錄：

包管理器Apt 仍然在底層使用 tar，但用戶永遠不必擔心它。同樣，在使用 Docker 時，我們永遠不必擔心包管理器，盡管它仍然存在。即使在 Node.js 技術之上進行開發時，開發人員也更喜歡在 Node 的官方 Docker 鏡像之上構建他們的 Docker 鏡像。

所以，這是對 Docker 是什么以及為什么即使他們沒有參與 DevOps 也可能想了解它的一個簡要概述。現在讓我們繼續 Kubernetes。

什么是 Kubernetes?

Kubernetes 采用了如上所述的容器化技術，并將其變成了 11 個。它允許我們跨多個計算節點(這些可以是虛擬機或裸機服務器)運行容器。一旦 Kubernetes 控制了一組節點，容器就可以在任何給定時間根據我們的需要啟動或拆除。

如果您訪問他們的官方網站，Kubernetes 會非常清楚地說明其目的：

到目前為止，我們僅將Kubernetes的簡要概述表示為自動化一堆容器創建。應用程序需要有存儲空間，并且需要管理一些 DNS 記錄。您需要確保參與的計算節點彼此安全連接等等。擁有一組不同的節點而不是單個主機會帶來一系列完全不同的問題。

Kubernetes 架構的簡要概述將幫助我們闡明它如何設法實現所有這些以及更多。

Kubernetes 架構 — 簡要概述：

關于 Kubernetes 集群，您需要了解兩個基本概念。第一個是節點。這是 Kubernetes 管理的 VM 和/或裸機服務器的通用術語。第二個術語是 pod，它是 Kubernetes 中的基本部署單元。Pod 是需要共存的相關 Docker 容器的集合。例如，您的 Web 服務器可能需要與 Redis 緩存服務器一起部署，以便您可以將它們兩者封裝到一個 Pod 中。Kubernetes 并排部署它們。如果這對您來說更簡單，您可以完全想象一個由單個容器組成的 pod，那就沒問題了。

回到節點，有兩種類型的節點。一個是主節點，其中安裝了 Kubernetes 的核心，它控制著應用程序實際運行的各個工作節點之間的 pod 調度。主節點的工作是確保維持集群的期望狀態。

下面是對 Kubernetes 圖表的簡要總結，如上所示。

在 Kubernetes Master 上，我們有：

1. kube-controller-manager：負責考慮集群的當前狀態(例如，X 個正在運行的 Pod)并做出決定以實現所需的狀態(例如，有 Y 個活動的 Pod)。它在 kube-apiserver 上偵聽有關集群狀態的信息

2. kube-apiserver：這個 API 服務器公開了Kubernetes 的齒輪和杠桿。它由 WebUI 儀表板和命令行實用程序(如 kubeclt)使用。這些實用程序反過來被人類操作員用來與 Kubernetes 集群交互。

3. kube-scheduler：這決定了如何根據資源的可用性、運營商設置的策略等在集群中調度事件和作業。它也偵聽kube-apiserver 以獲取有關集群狀態的信息。

4. etcd：這是 Kubernetes 主節點的“存儲堆棧”。它使用鍵值對，用于保存策略、定義、秘密、系統狀態等

我們可以有多個主節點，這樣即使一個主節點發生故障，Kubernetes 也能存活下來。

在工作節點上，我們有：

1. kubelet：這將有關節點健康狀況的信息中繼回主節點，并執行主節點給它的指令

2. kube-proxy：此網絡代理允許您的應用程序的各種微服務在集群內相互通信，并且如果您愿意，還可以將您的應用程序公開給世界其他地方。原則上，每個 Pod 都可以通過此代理與其他每個 Pod 通信。

3. Docker：這是拼圖的最后一塊。每個節點都有一個 Docker 引擎來管理容器。

當然，還有更多 Kubernetes，我鼓勵您探索所有這些。

Docker 和 Kubernetes 的全行業采用

到目前為止，我們討論的許多概念在紙面上聽起來不錯，但它們是否經濟?它們真的會幫助您的業務增長、減少停機時間并節省人力和計算能力方面的資源嗎?

生產環境中的 Docker：

在采用 Docker 時，答案很簡單。特別是如果你為你的軟件采用基于微服務的架構，你絕對應該為每個微服務使用 Docker 容器。

這項技術相當成熟，幾乎沒有人可以反對它。請記住，僅僅容器化您的代碼不會讓您的代碼變得更好。如果您真的想使用容器化平臺，請嘗試避免單體設計并使用微服務。

生產中的 Kubernetes：

不能因為在生產中對 Kubernetes 的咆哮而受到指責，在我個人看來，其背后的原因有兩個方面。

首先，大多數組織在對分布式系統的基本概念沒有任何了解的情況下盲目跳槽。他們嘗試建立自己的Kubernetes 集群并使用它來托管簡單的網站或小型可擴展應用程序。

其次，Kubernetes 正在快速發展，其他組織正在為其添加自己的特殊調味料，例如服務網格、網絡插件等。其中大部分是開源的，因此對運營商很有吸引力。但是，在生產中運行它們并不是我推薦的。跟上它們需要不斷維護集群并花費更多的人力時間。

但是，組織可以使用云托管的 Kubernetes 平臺來運行其應用程序。AWS、Azure、Joyent 或 GCE 等公司提供的數據中心的全球可用性實際上可以幫助您充分利用 Kubernetes的分布式特性。而且，當然，您不必擔心維護集群。

這是中小型組織經常忽略的東西。如果您想在節點故障中幸存下來并獲得高可擴展性，您不應該在單個 1-U 機架甚至單個數據中心上運行 Kubernetes。

那么，Kubernetes 在生產中嗎?是的，但對于大多數人來說，我會推薦云托管解決方案。

容器和云計算的新時代

Docker 并不是作為操作系統級別的虛擬化軟件進行宣傳的，而是作為一種軟件打包和交付機制進行營銷的。Docker容器引起其競爭對手關注的唯一原因是這種軟件交付方法。

多虧了 Dockerfiles，自動化構建變得容易多了。由于 docker-compose，復雜的多容器部署現在已經標準化。通過提供完整的CI/CD 解決方案，包括構建和測試 Docker 鏡像以及管理公共或私有 Docker 注冊表，軟件工程師將容器發揮到了邏輯極限。

Kubernetes 將容器從被困在一臺計算機上解放出來，使云成為這項技術的一個更具吸引力的地方。慢慢地，但可以肯定的是，容器化將成為每個依賴于云的服務的規范，因此，盡早而不是以后采用這項技術非常重要。這樣做可以最大限度地減少遷移成本和相關風險。

分布式操作系統案例

既然我已經對公司在沒有完全理解的情況下采用 Kubernetes 大發雷霆，請允許我說明為什么你應該采用 Kubernetes。云計算已經發展成為這個競爭激烈的市場，谷歌、微軟、亞馬遜和許多其他玩家相互競爭。

這大大降低了在云中部署軟件的成本。Kubernetes 的最大優點是它在很大程度上是開源的，因此您可以了解正在發生的事情，而不會被細節所困擾。

這是 Azure 宣傳其Kubernetes 服務：

僅僅知道它在表面上是如何工作的，就可以讓您對在分布式系統中運行的軟件進行推理。但是您不必擔心實際管理底層集群!

亞馬遜、谷歌和 DigitalOcean 正在提供類似的解決方案。即使是小型企業和個人開發人員現在也可以在整個地球上擴展他們的應用程序。稍微了解它是如何實現的并沒有什么壞處，所以你至少應該對 Kubernetes 和 Docker 有一定的了解。

每次你想，“Kubernetes vs. Docker?” 反對者會回應說 Docker 很酷，但 Kubernetes 有點極端。但是整個計算機科學都是關于極端自動化的，Kubernetes將容器化模型帶到了它的邏輯極端!

更細微的差異——網絡

許多 Kubernetes 與Docker 的爭論都源于基礎知識，例如存儲堆棧和網絡的實現。Docker 和 Kubernetes 都喜歡以不同的方式做事。

容器需要的不僅僅是 CPU 和一些內存才能發揮作用。在 Kubernetes 和 Docker 主機等平臺上運行應用程序之間存在許多細微差別。這些差異太多了，無法在此簡明扼要地提及，但總是引起我注意的是事物的網絡方面。

Kubernetes 指定每個 pod 應該能夠在給定的命名空間中與集群中的每個其他 pod 自由通信。而 Docker 有一個創建虛擬網絡拓撲的概念，您必須指定您希望容器連接到哪些網絡。像這樣的區別確實會讓嘗試試水的人望而卻步，但是當您考慮 Kubernetes 與 Docker 的根本區別時，它們至關重要：

對于這種困境，確實別無選擇，您只需要在學習曲線上保持耐心即可。漸漸地，更大的畫面對你的眼睛來說會變得更清晰。

Docker 與 Kubernetes 的采用心態

使用 Docker，好處是相當明顯的。如果您在 Docker 容器上發布您的應用程序，那么它也可以在任何 Linux 發行版上運行。即使基于 Illumos 的操作系統(根本不是 Linux)也支持 Docker，并且可以運行 Docker 容器。

您的應用程序實際上可以分解為多個微服務，這樣每個微服務都可以打包為一個 Docker 容器。通過定義明確的 API，可以輕松地向現有功能添加新功能。例如，如果您需要分析，只需啟動一個可以與數據庫通信的 Hadoop 容器。

同樣，當談到 Kubernetes 時，用戶和云服務提供商實際上都可以通過采用它而大大受益。由于它基于容器化，與傳統虛擬機不同，云服務提供商可以有效地利用其資源獲得高密度的容器。這使他們能夠顯著降低價格。

另一方面，用戶可以在全球部署他們的應用程序，減少延遲并改善用戶體驗。

這種轉變的唯一例外是桌面應用程序開發人員。由于大多數桌面應用程序可能會使用云進行更新和/或備份，但它們主要設計為在單臺機器上運行。

結論

容器是驚人的!它們使我們能夠以全新的數字化方式思考服務和系統。Docker 和 Kubernetes 都將繼續存在。他們不斷地改變以在未來將自己轉變為更好的東西。讓您的公司參與到技術時代并實施您的基礎設施最需要的容器。

為以容器為中心的平臺設計更新的軟件不僅會使您的應用程序更具可擴展性，而且更能適應未來的發展。堅持使用舊的 VM 可能暫時有效，但幾年后，您最終將不得不承擔將所有內容遷移到容器中的沉重成本，或者完全放棄您的項目。希望現在如果有人提出“Kubernetes vs Docker”的話題，你不會被行話沖昏頭腦。

原文鏈接：https://dzone.com/articles/kubernetes-vs-docker