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

Kubernetes 正在迅速成為在混合云中部署和管理容器的新標(biāo)準(zhǔn)。作為一個網(wǎng)絡(luò)工程師，你為什么要關(guān)心開發(fā)人員對 Kubernetes 做了什么？它不只是另一個消耗網(wǎng)絡(luò)資源的應(yīng)用程序嗎？ Kubernetes 提供了一個靈活可靠的平臺，使開發(fā)人員能夠?qū)Ｗ⒂陂_發(fā)和擴展他們的應(yīng)用程序。

在本文中，我將討論 Kubernetes 的基本構(gòu)建塊和一些網(wǎng)絡(luò)挑戰(zhàn)。

Kubernetes 積木

Kubernetes 是一個工具，它使您能夠管理云基礎(chǔ)設(shè)施以及管理虛擬機或網(wǎng)絡(luò)的復(fù)雜性。

節(jié)點

節(jié)點是 Kubernetes 中計算元素的最小單位。它是集群中單個機器的表示。在大多數(shù)生產(chǎn)系統(tǒng)中，節(jié)點通常是物理服務(wù)器或托管在本地或云上的虛擬機。

圖 1 。在 Kubernetes 中，多個節(jié)點構(gòu)成了主機工作者和主組件的基礎(chǔ)結(jié)構(gòu)

集群

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

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

持久卷

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

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

容器和微型服務(wù)

運行在 Kubernetes 上的應(yīng)用程序被打包為 Linux 容器。容器是一個被廣泛接受的標(biāo)準(zhǔn)，因此已經(jīng)有許多預(yù)構(gòu)建的映像可以部署在 Kubernetes 上。

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

容器化允許創(chuàng)建自包含的 Linux 執(zhí)行環(huán)境。任何應(yīng)用程序及其所有依賴項都可以捆綁到單個文件中。容器允許形成強大的連續(xù)集成（ CI ）和連續(xù)部署（ CD ）管道，因為每個容器可以容納應(yīng)用程序的特定部分。容器是微服務(wù)的基礎(chǔ)設(shè)施。

微服務(wù)是一種軟件開發(fā)技術(shù)，一種將應(yīng)用程序構(gòu)造為松散耦合服務(wù)集合的體系結(jié)構(gòu)風(fēng)格。將應(yīng)用程序分解為不同的較小服務(wù)的好處是它改進了模塊化。這使得應(yīng)用程序更易于理解、開發(fā)、測試和部署。

Pods

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

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

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

部署

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

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

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

服務(wù)和服務(wù)網(wǎng)格

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

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

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

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

網(wǎng)絡(luò)

Kubernetes 網(wǎng)絡(luò)的核心是一個重要的基本設(shè)計理念：每個 Pod 都有一個唯一的 IP 地址。

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

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

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

為了降低復(fù)雜性并使應(yīng)用程序移植無縫進行，在 Kubernetes 網(wǎng)絡(luò)模型中，一些規(guī)則作為基本要求被強制執(zhí)行：

容器可以在沒有網(wǎng)絡(luò)地址轉(zhuǎn)換（ NAT ）的情況下與所有其他容器通信。

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

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

圖 8 。 Kubernetes 網(wǎng)絡(luò)模型

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

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

圖 9 。當(dāng)使用覆蓋網(wǎng)絡(luò)時， Flannel 需要 Kubernetes 節(jié)點之間的 L2 連接， VXLAN 是首選。

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

圖 10 。 L2 連接提供給 BGP 路由結(jié)構(gòu)頂部的節(jié)點。

NVIDIA Spectrum ASIC 在 VXLAN 吞吐量、延遲和規(guī)模方面提供了巨大的價值。大多數(shù)交換機最多可支持 128 個遠(yuǎn)程 VTEP ，這意味著單個結(jié)構(gòu)中最多可支持 128 個機架。 NVIDIA Spectrum ASIC 支持多達(dá) 750 個遠(yuǎn)程 vtep ，在單個結(jié)構(gòu)中允許多達(dá) 750 個機架。

NVIDIA Spectrum EVPN VXLAN 微分器

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

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

印花布作為設(shè)計選項

在印花布網(wǎng)絡(luò)中，每個端點都是一條路由。硬件網(wǎng)絡(luò)平臺受到他們可以學(xué)習(xí)的路由數(shù)量的限制。這通常在 10000 或 100000 條路線的范圍內(nèi)。路由聚合可以有所幫助，但這通常取決于編排軟件（例如 OpenStack ）使用的調(diào)度器的功能。

圖 11 。典型的印花布部署

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

跨物理網(wǎng)絡(luò)和 Kubernetes 的路由棧持久性

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

Kubernetes 的網(wǎng)絡(luò)可見性挑戰(zhàn)

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

眾所周知，運營現(xiàn)代敏捷數(shù)據(jù)中心非常困難，因為網(wǎng)絡(luò)可見性有限，流量模式不斷變化。

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

關(guān)于作者

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

審核編輯：郭婷