在本地和公共云上使用相同的編排允許高度的靈活性和易操作性。您可以跨裸機和公共云使用相同的 API 。 Kubernetes 是一個開源的容器編排系統，用于自動化容器化應用程序的部署、擴展和管理。它最初是由谷歌設計的，現在由云本地計算基金會維護。

Kubernetes 正在迅速成為在混合云中部署和管理容器的新標準。作為一個網絡工程師，你為什么要關心開發人員對 Kubernetes 做了什么？它不只是另一個消耗網絡資源的應用程序嗎？ Kubernetes 提供了一個靈活可靠的平臺，使開發人員能夠專注于開發和擴展他們的應用程序。

在本文中，我將討論 Kubernetes 的基本構建塊和一些網絡挑戰。

Kubernetes 積木

Kubernetes 是一個工具，它使您能夠管理云基礎設施以及管理虛擬機或網絡的復雜性。

節點

節點是 Kubernetes 中計算元素的最小單位。它是集群中單個機器的表示。在大多數生產系統中，節點通常是物理服務器或托管在本地或云上的虛擬機。

圖 1 。在 Kubernetes 中，多個節點構成了主機工作者和主組件的基礎結構

集群

Kubernetes 集群是一組用于運行容器化應用程序的節點機。當您在集群上部署應用程序時，集群將智能地處理將工作分發到各個節點的工作。如果添加或刪除了任何節點，集群會根據需要轉移工作負載。對于應用程序或開發人員來說，哪個節點實際運行代碼并不重要。

圖 2 。集群由工作節點組成，工作節點表示一個計算主機，可以在該主機上部署、運行和管理容器化應用程序

持久卷

由于不能保證在集群上運行的應用程序在特定節點上運行，因此無法將數據保存到文件系統中的任意位置。如果應用程序試圖保存數據以供以后使用，但隨后又重新定位到新節點上，則數據將不再位于應用程序所期望的位置。因此，與每個節點相關聯的傳統本地存儲被視為一個臨時緩存來保存應用程序，但本地保存的任何數據都不能持久。

為了永久存儲數據， Kubernetes 使用持久卷。雖然所有節點的 CPU 和 RAM 資源都由集群有效地匯集和管理，但持久性文件存儲不是必需的。相反，本地或云存儲可以作為持久卷附加到集群。

容器和微型服務

運行在 Kubernetes 上的應用程序被打包為 Linux 容器。容器是一個被廣泛接受的標準，因此已經有許多預構建的映像可以部署在 Kubernetes 上。

圖 3 。容器將所有代碼和依賴項打包在一起，允許軟件堆棧在其所在的任何環境中運行

容器化允許創建自包含的 Linux 執行環境。任何應用程序及其所有依賴項都可以捆綁到單個文件中。容器允許形成強大的連續集成（ CI ）和連續部署（ CD ）管道，因為每個容器可以容納應用程序的特定部分。容器是微服務的基礎設施。

微服務是一種軟件開發技術，一種將應用程序構造為松散耦合服務集合的體系結構風格。將應用程序分解為不同的較小服務的好處是它改進了模塊化。這使得應用程序更易于理解、開發、測試和部署。

Pods

Kubernetes 不直接運行容器。相反，它將一個或多個容器包裝成一個更高層次的結構，稱為 Pod 。同一 Pod 中的任何容器共享同一節點和本地網絡。容器可以輕松地與同一個 Pod 中的其他容器進行通信，就像它們在同一臺機器上一樣，同時保持與其他容器的一定程度的隔離。

圖 4 。吊艙是集群中最小的可部署單元，包含一組容器

豆莢是庫伯內特斯的復制單位。如果您的應用程序變得太重，單個 Pod 實例無法承載負載，那么可以配置 Kubernetes ，以便根據需要將 Pod 的新副本部署到集群。即使不是在重載下，在生產系統中隨時運行一個 Pod 的多個副本也是標準的，以允許負載平衡和抗故障。

部署

雖然 pod 是 Kubernetes 的基本計算單元，但它們通常不會直接在集群上啟動。相反， pod 通常由另一個抽象層來管理： deployment 。部署的目的是聲明一次應該運行多少個 Pod 副本。當部署被添加到集群中時，它會自動增加請求的 pod 數量，然后監視它們。如果吊艙死亡，部署會自動重新創建它。

對于部署，您不必手動處理 pod 。您只需聲明所需的系統狀態，系統就會自動為您進行管理。

圖 5 。部署用于管理復制集、 pod 定義和更新以及其他概念

服務和服務網格

Kubernetes 服務是一種抽象，它定義了一組邏輯 pod 和訪問它們的策略。服務支持依賴吊艙之間的松散耦合。

圖 6 。服務支持依賴吊艙之間的耦合。

術語 服務網 用于描述組成此類應用程序的微服務網絡以及它們之間的交互。隨著服務網格的規模和復雜性的增長，它可能變得更難理解和管理。它的需求可以包括發現、負載平衡、故障恢復、度量和監視。服務 mesh 通常還有更復雜的操作需求，如 A / B 測試、 canary 發布、速率限制、訪問控制和端到端身份驗證。

控制服務網格最流行的插件之一是 Istio ，這是一個開源的獨立服務，它提供了成功運行分布式微服務體系結構所需的基礎。 Istio 提供了對整個服務網格的行為洞察力和操作控制，提供了一個完整的解決方案來滿足微服務應用程序的各種需求。使用 Istio ，應用程序的所有實例都有自己的 sidecar 容器。此側車充當所有傳出和傳入網絡流量的服務代理。

網絡

Kubernetes 網絡的核心是一個重要的基本設計理念：每個 Pod 都有一個唯一的 IP 地址。

圖 7 。 Pod IP 地址由內部的所有容器共享，并且可以從所有其他 Pod 路由。

Pod 的 IP 地址由內部的所有容器共享，并且可以從其他 Pod 路由。這種 IP-per-Pod 模型的一個巨大好處是沒有與底層主機的 IP 地址或端口沖突。不必擔心應用程序使用什么端口。

有了這一點， Kubernetes 唯一的要求就是 Pod IP 地址是可路由的，并且可以從所有其他 Pod 訪問，而不管它們的節點是什么。

為了降低復雜性并使應用程序移植無縫進行，在 Kubernetes 網絡模型中，一些規則作為基本要求被強制執行：

容器可以在沒有網絡地址轉換（ NAT ）的情況下與所有其他容器通信。

節點可以在沒有 NAT 的情況下與所有容器通信，反之亦然。

容器將自己視為的 IP 地址與其他容器看到的 IP 地址相同。

圖 8 。 Kubernetes 網絡模型

Kubernetes 有許多網絡實現。法蘭絨和印花布可能是最流行的用作容器網絡接口（ CNI ）的網絡插件。 CNI 可以看作是容器運行時和網絡實現之間最簡單的接口，其目標是為容器創建一個通用的基于插件的網絡解決方案。

Flannel 可以使用多個封裝后端運行，建議使用 VXLAN 。在 VXLAN 中使用 Flannel 時， Kubernetes 節點之間需要 L2 連接。由于這一要求，結構 MIG 的大小將受到限制，如果部署了純 L2 網絡，則連接的機架數將限制為脊椎交換機上的端口數。

圖 9 。當使用覆蓋網絡時， Flannel 需要 Kubernetes 節點之間的 L2 連接， VXLAN 是首選。

為了克服這個問題，可以在葉級部署一個具有 VXLAN 和 EVPN 的 L3 結構。 L2 連接提供給 BGP 路由結構上的節點，該結構可以輕松擴展。來自節點的 VXLAN 數據包被封裝到葉交換機之間運行的 VXLAN 隧道中。

圖 10 。 L2 連接提供給 BGP 路由結構頂部的節點。

NVIDIA Spectrum ASIC 在 VXLAN 吞吐量、延遲和規模方面提供了巨大的價值。大多數交換機最多可支持 128 個遠程 VTEP ，這意味著單個結構中最多可支持 128 個機架。 NVIDIA Spectrum ASIC 支持多達 750 個遠程 vtep ，在單個結構中允許多達 750 個機架。

NVIDIA Spectrum EVPN VXLAN 微分器

觀看以下視頻，了解為什么 NVIDIA Spectrum 以太網交換機是構建可擴展、高效和高性能 EVPN VXLAN 結構的最佳平臺。

視頻了解 EVPN VXLAN 微分器 NVIDIA Spe CTR um 交換機提供的功能

印花布作為設計選項

在印花布網絡中，每個端點都是一條路由。硬件網絡平臺受到他們可以學習的路由數量的限制。這通常在 10000 或 100000 條路線的范圍內。路由聚合可以有所幫助，但這通常取決于編排軟件（例如 OpenStack ）使用的調度器的功能。

圖 11 。典型的印花布部署

為 Kubernetes 部署選擇交換機時，請確保它的路由表大小不會限制 Kubernetes 的計算規模。 NVIDIA Spectrum ASIC 提供了完全靈活的表大小， Spectrum 1 支持多達 176000 個 IP 路由條目， Spectrum 2 支持多達 512000 個 IP 路由條目，支持全球最大企業運行的最大 Kubernetes 集群。

跨物理網絡和 Kubernetes 的路由棧持久性

在交換層上使用 Cumulus Linux 操作系統時，我們建議使用 FRR 作為節點上的路由棧，利用 BGP 未編號 。如果你正在尋找一個純開源的解決方案，考慮一下 NVIDIA Linux 交換機 ，它支持 FRR 和 BEAR 作為路由棧。

Kubernetes 的網絡可見性挑戰

容器會根據需要在群集中的任何服務器上自動啟動和銷毀。因為容器位于主機內部，所以網絡工程師可能看不到它們。你永遠不知道它們在哪里，也不知道它們何時被創造和毀滅。

眾所周知，運營現代敏捷數據中心非常困難，因為網絡可見性有限，流量模式不斷變化。

通過在運行 Cumulus 操作系統的 NVIDIA Spectrum 交換機上使用 Cumulus NetQ ，您可以廣泛了解 Kubernetes 部署，并在這些快速變化的動態環境中運行。

關于作者

Erez Scop 是 NVIDIA 的產品管理總監，負責管理存儲、數據平面開發套件 （DPDK） 和軟件加速產品線。Erez 是管理開源項目的 dpdk.org 管理委員會的成員。在加入Mellanox和NVIDIA之前，Erez 是 AudioCodes 有限公司的產品經理，在那里他領導了他們在電信、VoIP 和統一通信領域的主要產品線超過五年。Erez 在產品管理方面有超過 8 年的經驗，并擔任了超過 10 年的研發管理職位。Erez 擁有電氣和電子工程 B.Sc 和 MBA 學位。

審核編輯：郭婷