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

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

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

Kubernetes 積木

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

節(jié)點(diǎn)

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

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

集群

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

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

持久卷

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

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

容器和微型服務(wù)

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

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

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

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

Pods

Kubernetes 不直接運(yùn)行容器。相反，它將一個(gè)或多個(gè)容器包裝成一個(gè)更高層次的結(jié)構(gòu)，稱為 Pod 。同一 Pod 中的任何容器共享同一節(jié)點(diǎn)和本地網(wǎng)絡(luò)。容器可以輕松地與同一個(gè) Pod 中的其他容器進(jìn)行通信，就像它們?cè)谕慌_(tái)機(jī)器上一樣，同時(shí)保持與其他容器的一定程度的隔離。

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

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

部署

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

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

圖 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 測(cè)試、 canary 發(fā)布、速率限制、訪問控制和端到端身份驗(yàn)證。

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

網(wǎng)絡(luò)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

NVIDIA Spectrum EVPN VXLAN 微分器

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

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

印花布作為設(shè)計(jì)選項(xiàng)

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

圖 11 。典型的印花布部署

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

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

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

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

容器會(huì)根據(jù)需要在群集中的任何服務(wù)器上自動(dòng)啟動(dòng)和銷毀。因?yàn)槿萜魑挥谥鳈C(jī)內(nèi)部，所以網(wǎng)絡(luò)工程師可能看不到它們。你永遠(yuǎn)不知道它們?cè)谀睦?，也不知道它們何時(shí)被創(chuàng)造和毀滅。

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

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

關(guān)于作者

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

審核編輯：郭婷