共計 8721 個字符，預(yù)計需要花費 22 分鐘才能閱讀完成。

本篇內(nèi)容介紹了“如何使用 Kubernetes 網(wǎng)絡(luò)”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓丸趣 TV 小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

許多 Kubernetes 部署指南中包含了在 K8S 部署中部署 Kubernetes 網(wǎng)絡(luò) CNI 的說明。但是如果你的 K8S 集群已經(jīng)運行，并且尚未部署任何網(wǎng)絡(luò)，那么部署網(wǎng)絡(luò)就像在 K8S 上運行其提供的配置文件一樣簡單（對于大多數(shù)網(wǎng)絡(luò)和基本用例而言）。例如，要部署 flannel：

這樣，從網(wǎng)絡(luò)的角度來看，K8S 已經(jīng)可以使用。為了測試一切是否正常，我們創(chuàng)建了兩個 Pod。

這將創(chuàng)建兩個 pod，它們正在使用我們的驅(qū)動器。查看其中一個容器，我們發(fā)現(xiàn)網(wǎng)絡(luò)的 IP 地址范圍為 10.42.0.0/24。

在另一個 Pod 進行的快速 ping 測試表明，網(wǎng)絡(luò)運行正常。

與 Docker 網(wǎng)絡(luò)相比，Kubernetes 網(wǎng)絡(luò)如何工作？

Kubernetes 通過 Docker 之上的 CNI 管理網(wǎng)絡(luò)，并將設(shè)備附加到 Docker。盡管有 Docker Swarm 的 Docker 也具有自己的聯(lián)網(wǎng)功能（例如 overlay、macvlan、bridging 等），但 CNI 也提供了類似類型的功能。

還有一點十分重要，K8S 并不使用 docker0（這是 Docker 的默認(rèn)網(wǎng)橋），而是創(chuàng)建自己的網(wǎng)橋，名為 cbr0，該網(wǎng)橋需要與 docker0 區(qū)分開來。

為什么我們需要 Overlay 網(wǎng)絡(luò)？

諸如 vxlan 或 ipsec 之類的 overlay 網(wǎng)絡(luò)可以將數(shù)據(jù)包封裝到另一個數(shù)據(jù)包中。這使得實體在另一臺計算機的范圍之外依舊可以尋址。Overlay 網(wǎng)絡(luò)的替代方案包括如 macvtap(lan) 之類的 L3 解決方案，甚至包括 ivtap(lan) 之類的 L2 解決方案，但是這些方案具有一定的局限性。

L2 或 L3 上的任何解決方案都可以讓 pod 在網(wǎng)絡(luò)上尋址。這意味著 pod 不僅在 Docker 網(wǎng)絡(luò)內(nèi)部訪問，還能直接從 Docker 網(wǎng)絡(luò)外部訪問。這些是公共 IP 地址或私有 IP 地址。

然而，在 L2 上進行通信比較麻煩，并且你的經(jīng)驗會因為網(wǎng)絡(luò)設(shè)備而異。某些交換機需要一些時間來注冊你的 Mac 地址，然后才能將其實際連接到網(wǎng)絡(luò)的其余部分。你還可能會遇到一些麻煩，因為系統(tǒng)中其他主機的 neighbor(ARP) table 仍在過時的緩存上運行，并且始終需要使用 dhcp 運行而不是 host-local，這樣可以避免主機之間的 ip 沖突。Mac 地址和 neighbor table 問題是諸如 ipvlan 之類的解決方案存在的原因。這些解決方案不會注冊新的 mac 地址，而是在現(xiàn)有地址上路由流量（盡管它們也有自己的問題）。

因此，我的建議是，對于大多數(shù)用戶而言，將 overlay 網(wǎng)絡(luò)作為默認(rèn)解決方案應(yīng)該足夠了。但是，一旦工作負(fù)載變得更加高級并提出了更具體的要求，你將需要考慮其他的解決方案，如 BGP 和直接路由。

Kubernetes 網(wǎng)絡(luò)如何工作？

在 Kubernetes 中首先要了解的是，pod 實際上并不等同于容器，而是容器的集合。在同一集合的容器中共享一個網(wǎng)絡(luò)堆棧。Kubernetes 通過在暫停容器上設(shè)置網(wǎng)絡(luò)來進行管理，你可以在你所創(chuàng)建的每個 pod 中找到這些暫停容器。所有其他 pod 都連接到暫停容器的網(wǎng)絡(luò)，該容器本身除了提供網(wǎng)絡(luò)外不執(zhí)行任何操作。因此，也可以使一個容器通過 localhost 與不同容器中的服務(wù)進行通信，此時該容器具有相同 pod 的相同定義。

除了本地通信之外，pod 之間的通信看起來與 Docker 網(wǎng)絡(luò)中的 container-to-container 通信幾乎相同。

Kubernetes 流量路由

我將以兩種場景為例，詳細(xì)地說明如何在 Pod 之間路由流量。

1、在同一主機上路由流量：

在兩種情況下，流量不會離開主機。一是當(dāng)調(diào)用的服務(wù)在同一節(jié)點上運行，一是單個 pod 中的同一個容器集合。

如果從第一個 pod 中的容器 1 調(diào)用 localhost:80 并在容器 2 中運行服務(wù)，則流量將通過網(wǎng)絡(luò)設(shè)備并將數(shù)據(jù)包轉(zhuǎn)發(fā)到其他目的地。在這種情況下，路由流量的路線很短。

如果我們想要與其他 pod 進行通信，時間會更長一些。首先，流量將傳遞到 cbr0，接下來 cbr0 將會注意到我們在同一個子網(wǎng)通信，因此它會將流量轉(zhuǎn)發(fā)到目標(biāo) Pod，過程如下圖所示：

2、跨主機路由流量：

當(dāng)我們離開節(jié)點時，這將變得更加復(fù)雜。現(xiàn)在，cbr0 會將流量傳遞到下一個節(jié)點，該節(jié)點的配置由 CNI 管理。這些基本上只是以目標(biāo)主機為網(wǎng)關(guān)的子網(wǎng)路由。然后，目標(biāo)主機可以繼續(xù)使用自己的 cbr0 并將流量轉(zhuǎn)發(fā)到目標(biāo)容器，如下所示：

究竟什么是 CNI？

CNI 是 Container Networking Interface（容器網(wǎng)絡(luò)接口）的縮寫，基本上是一個具有定義明確的外部接口，Kubernetes 可以調(diào)用它來提供網(wǎng)絡(luò)功能。

你可以在以下鏈接中找到維護的參考插件，其中包括容器網(wǎng)絡(luò)官方 repo 中的大多數(shù)重要插件：

https://github.com/containernetworking/plugins

CNI 3.1 版不是很復(fù)雜。它包含三個必需的功能，ADD、DEL 和 VERSION，這些功能可以盡其所能管理網(wǎng)絡(luò)。有關(guān)每個函數(shù)應(yīng)返回和傳遞的內(nèi)容的更詳細(xì)說明，您可以在此處閱讀規(guī)范：

https://github.com/containernetworking/cni/blob/master/SPEC.md

CNI 之間的區(qū)別

以下我們將介紹一些最受歡迎的 CNI：

Flannel

Flannel 是一個簡單的網(wǎng)絡(luò)，并且是 overlay 網(wǎng)絡(luò)最簡單的設(shè)置選項。它的功能包括原生網(wǎng)絡(luò)，但在多個網(wǎng)絡(luò)中使用時會受到限制。對于大多數(shù)用戶來說，F(xiàn)lannel 是 Canal 下面的默認(rèn)網(wǎng)絡(luò)，部署起來非常簡單，甚至還有本地網(wǎng)絡(luò)功能，如主機網(wǎng)關(guān)。但是 Flannel 有一些限制，包括缺乏對網(wǎng)絡(luò)安全策略的支持以及沒有多網(wǎng)絡(luò)的功能。

Calico

Calico 與 Flannel 采用不同的方法，從技術(shù)的角度來說，它不是 overlay 網(wǎng)絡(luò)，而是在所有相關(guān)系統(tǒng)之間配置路由的系統(tǒng)。為此，Calico 利用邊界網(wǎng)關(guān)協(xié)議（BGP），它在名為 peering 的過程中用于 Internet。其中每方 peering 交換流量并參與 BGP 網(wǎng)絡(luò)。BGP 協(xié)議本身會在其 ASN 下傳播路由，不同之處在于它們是私有的，不需要再 RIPE 中注冊它們。

但是，在某些情況下，Calico 可與 overlay 網(wǎng)絡(luò)配合使用，如 IPINIP。當(dāng)節(jié)點位于不同網(wǎng)絡(luò)上時使用，以便啟動兩個主機之間的流量交換。

Canal

Canal 基于 Flannel，但有一些 Calico 自己的組件，例如 felix（主機代理），它可以利用網(wǎng)絡(luò)安全策略。這些通常在 Flannel 中不存在。因此，它基本上通過添加安全策略來擴展 Flannel。

Multus

Multus 是一個 CNI，但實際上它本身并不是網(wǎng)絡(luò)接口。只是它編排了多個接口，并且沒有配置實際的網(wǎng)絡(luò)，因而 Pod 無法單獨與 Multus 通信。實際上，Multus 是多設(shè)備和多子網(wǎng)網(wǎng)絡(luò)的推動者。下圖顯示了它是如何工作的，Multus 本身基本上調(diào)用了真正的 CNI 而不是 kubelet，并將結(jié)果傳遞回 kubelet。

Kube-Router

同樣值得一提的是 kube-router，與 Calico 一樣，它可以與 BGP 和路由而不是 overlay 網(wǎng)絡(luò)一起使用。就像 Calico 一樣，它在必要的時候可以使用 IPINIP。它還能利用 ipvs 進行負(fù)載均衡。

設(shè)置多網(wǎng)絡(luò) K8S 集群

如果您需要使用多個網(wǎng)絡(luò)，則可能需要 Multus。

設(shè)置 Multus

我們需要做的第一件事是設(shè)置 Multus。我們使用的幾乎是 Multus 倉庫示例中的配置，但進行了一些重要的調(diào)整。請參閱下面的示例。

首先是調(diào)整 configmap。因為我們計劃使用 Flannel 創(chuàng)建默認(rèn)網(wǎng)絡(luò)，所以我們在 Multus 配置的 delegates 數(shù)組中定義配置。這里用紅色標(biāo)記的一些重要設(shè)置是“masterplugin”：true，用于定義 Flannel 網(wǎng)絡(luò)本身的網(wǎng)橋。你將在接下來的步驟中了解為什么我們需要這樣做。除此之外，還需要添加配置映射的安裝定義，其他則不需要調(diào)整，因為由于某些原因，此示例未完成。

關(guān)于此 configmap 的另一件重要事情是，這一 configmap 中定義的所有內(nèi)容都是默認(rèn)網(wǎng)絡(luò)，這些默認(rèn)網(wǎng)絡(luò)會自動安裝到容器，而無需進一步說明。另外，如果要編輯此文件，請注意，你要么需要終止并重新運行守護進程的容器，要么重新啟動節(jié)點才能使更改生效。

示例 yaml 文件：

設(shè)置主要的 Flannel Overlay 網(wǎng)絡(luò)

對于主要的 Flannel 網(wǎng)絡(luò)，設(shè)置非常簡單。我們可以從 Multus 倉庫中獲取示例，然后進行部署。此處所做的調(diào)整是 CNI 安裝、容差的調(diào)整以及對 Flannel 的 CNI 設(shè)置所做的一些調(diào)整。例如，添加“forceAddress”：true 并刪除“hairpinMode”：true。

這已在使用 RKE 設(shè)置的集群上進行了測試，但是只要您從主機正確安裝 CNI（在本例中為 / opt / cni / bin），它就可以在其他集群上工作。

Multus 本身并沒有太大的改變。他們只注釋了 initcontainer 配置，你可以刪除它。之所以如此，是因為 Multus 將建立其 delegates，并充當(dāng)主要的“CNI”。

這是修改后的 Flannel daemonset：

部署了這些樣本之后，我們已經(jīng)完成了很多工作，現(xiàn)在應(yīng)該為 pod 分配一個 IP 地址。讓我們測試一下：

如你所見，我們已經(jīng)成功部署了 Pod，并在 eth0 接口（默認(rèn)接口）上為其分配了 IP 10.42.2.43。所有其他接口都將顯示為 netX，即 net1。

設(shè)置輔助網(wǎng)絡(luò)

輔助網(wǎng)絡(luò)還需要進行一些調(diào)整，這些調(diào)整的前提是假設(shè)你要部署 vxlan。為了實際服務(wù)于輔助 overlay，我們需要更改 VXLAN 標(biāo)識符“VIN”，默認(rèn)情況下將其設(shè)置為 1，并且我們的第一個 overlay 網(wǎng)絡(luò)現(xiàn)在已經(jīng)使用了它。因此，我們可以通過在 etcd 服務(wù)器上配置網(wǎng)絡(luò)來更改此設(shè)置。我們使用自己的集群 etcd，此處標(biāo)記為綠色（并且假設(shè) job 在運行 etcd 客戶端的主機上運行），然后從本地主機（在我們的情況下，將其存儲在本地主機）中裝入密鑰（此處標(biāo)記為紅色），存儲在 / etc / kubernetes / ssl 文件夾中。

完整的 YAML 文件示例：

接下來，我們可以實際部署輔助網(wǎng)絡(luò)。此設(shè)置幾乎與主要網(wǎng)絡(luò)設(shè)置相同，但有一些關(guān)鍵區(qū)別。最明顯的是，我們更改了子網(wǎng)，但是我們還需要更改其他一些內(nèi)容。

首先，我們需要設(shè)置一個不同的 dataDir，即 / var / lib / cni / flannel2，以及一個不同的 subnetFile，即 /run/flannel/flannel2.env。這十分必要，因為它們已經(jīng)被我們的主要網(wǎng)絡(luò)占用。接下來，我們需要調(diào)整網(wǎng)橋，因為主要的 Flannel overlay 網(wǎng)絡(luò)已經(jīng)使用了 kbr0。

其余還需更改的配置包括將其更改為實際針對我們之前配置的 etcd 服務(wù)器。在主網(wǎng)絡(luò)中，這是通過–kube-subnet-mgr flag 直接連接到 K8S API 來完成的。但是我們不能這樣做，因為我們還需要修改要讀取的前綴。你可以在下面看到橙色標(biāo)記的內(nèi)容，而集群 etcd 連接的設(shè)置則顯示為紅色。最后一個設(shè)置是再次指定子網(wǎng)文件，在示例中以綠色標(biāo)記。最后一點是，我們添加了一個網(wǎng)絡(luò)定義。其余部分與我們的主要網(wǎng)絡(luò)配置相同。

有關(guān)上述步驟，請參見示例配置文件：

完成此操作后，我們便準(zhǔn)備好了輔助網(wǎng)絡(luò)。

分配額外的網(wǎng)絡(luò)

既然我們已經(jīng)準(zhǔn)備好輔助網(wǎng)絡(luò)，那么我們現(xiàn)在需要分配他。為此，我們需要先定義一個 NetworkAttachmentDefinition，之后我們可以使用它將網(wǎng)絡(luò)分配給容器。基本上，這是在初始化 Multus 之前，我們設(shè)置的 configmap 的動態(tài)替代方案。這樣，我們可以按需安裝所需的網(wǎng)絡(luò)。在此定義中，我們需要指定網(wǎng)絡(luò)類型（本例中是 Flannel）以及必要的配置。這包括前面提到的 subnetFile、dataDir 和網(wǎng)橋名稱。

我們需要確定的最后一件事是網(wǎng)絡(luò)的名稱，我們將其命名為 flannel2。

現(xiàn)在，我們終于可以使用輔助網(wǎng)絡(luò)生成第一個 pod。

現(xiàn)在應(yīng)該使用輔助網(wǎng)絡(luò)創(chuàng)建新的 Pod，并且我們將那些附加網(wǎng)絡(luò)視為額外添加的網(wǎng)絡(luò)接口。

成功啦，輔助網(wǎng)絡(luò)分配 10.5.22.4 作為其 IP 地址。

Troubleshooting

如果該示例沒有正常工作，你需要查看 kubelet 的日志。

一個常見的問題的是缺少 CNI。我第一次測試的時候，遺漏了 CNI 網(wǎng)橋，因為 RKE 沒有部署它。但是這個問題十分容易解決。

外部連接和負(fù)載均衡

現(xiàn)在我們已經(jīng)建立并運行網(wǎng)絡(luò)，接下來我們要做的是使我們的應(yīng)用程序可以訪問并將其配置為高可用和可擴展。高可用性和可伸縮性不僅可以通過負(fù)載均衡來實現(xiàn)，它還我們需要具備的關(guān)鍵組件。

Kubernetes 有四個概念，可以使應(yīng)用程序在外部可用。

使用負(fù)載均衡器

Ingress

Ingress 基本上就是具有 Layer7 功能的負(fù)載均衡器，特別是 HTTP(s)。最常用的 ingress controller 是 NGINX ingress。但這主要取決于你的需求以及你的使用場景。例如，你還可以選擇 traefik 或 HA Proxy。

配置一個 ingress 十分簡單。在以下例子中，你將了解一個鏈接服務(wù)的例子。藍(lán)色標(biāo)注的是指向服務(wù)的基本配置。綠色標(biāo)注的是鏈接 SSL 證書所需的配置（需要在此之前安裝這一證書）。最后，你會看到調(diào)整了 NGINX ingress 的一些詳細(xì)設(shè)置。

Layer 4 負(fù)載均衡器

在 Kubernetes 中，使用 type: LoadBalancer 定義 Layer 4 負(fù)載均衡器，這是一個依賴于負(fù)載均衡解決方案的服務(wù)提供程序。對于本地計算機，大概率會使用 HA 代理或一個路由解決方案。云提供商會使用自己的解決方案以及專用硬件，也可以使用 HA 代理或路由解決方案。

最大的區(qū)別是第 4 層負(fù)載平衡器不了解高級應(yīng)用程序協(xié)議（layer 7），并且僅能夠轉(zhuǎn)發(fā)流量。此級別上的大多數(shù)負(fù)載均衡器還支持 SSL 終止。這通常需要通過注釋進行配置，并且尚未標(biāo)準(zhǔn)化。

使用 {host,node} 端口

{host，node} Port 基本上等同于 docker -p port:port，尤其是 hostPort。與 hostPort 不同，nodePort 在所有節(jié)點上可用，而不是僅在運行 pod 的節(jié)點上可用。對于 nodePort，Kubernetes 首先創(chuàng)建一個 clusterIP，然后通過該端口負(fù)載均衡流量。nodePort 本身只是將端口上的流量轉(zhuǎn)發(fā)到 clusterIP 的 iptable 規(guī)則。

除了快速測試外，很少使用 nodePort，只有在你希望每個節(jié)點公開端口（即用于監(jiān)視）時才會在生產(chǎn)中使用 nodePort。大多數(shù)時候，你需要使用 Layer 4 負(fù)載均衡器。hostPort 僅用于測試，或者少數(shù)時候，將 pod 粘貼到特定節(jié)點并在指向該節(jié)點的特定 IP 地址下發(fā)布。

例如，在容器規(guī)范中定義了 hostPort，如下所示：

什么是 ClusterIP？

clusterIP 是 Kubernetes 集群及其中所有服務(wù)的內(nèi)部可訪問 IP。該 IP 本身將負(fù)載均衡流量到與其 selector 規(guī)則匹配的所有 Pod。在很多情況下，例如在指定類型：LoadBalancer 服務(wù)或設(shè)置 nodePort 時，也會自動生成 clusterIP。其背后的原因是所有負(fù)載均衡都是通過 clusterIP 進行的。

clusterIP 作為一個概念是為了解決多個可尋址主機以及這些主機的有效更新的問題。具有不變的單個 IP 比始終通過服務(wù)發(fā)現(xiàn)針對服務(wù)的所有性質(zhì)重新獲取數(shù)據(jù)要容易得多。盡管有時在某些情況下更適合使用服務(wù)發(fā)現(xiàn)，但如果你想要 explicit control，那么還是建議使用 clusterIP，如在某些微服務(wù)環(huán)境中。

常見的故障

如果您使用公有云環(huán)境并手動設(shè)置主機，則您的集群可能缺少防火墻規(guī)則。例如，在 AWS 中，您將需要調(diào)整安全組，以允許集群間通信以及 ingress 和 egress。如果不這樣做，將導(dǎo)致集群無法運行。確保始終打開主節(jié)點和 worker 節(jié)點之間的必要端口。直接在主機上打開的端口（即 hostPort 或 nodePort）也是如此。

網(wǎng)絡(luò)安全

既然我們已經(jīng)設(shè)置了所有 Kubernetes 網(wǎng)絡(luò)，我們還需要確保它們具備一定的安全性。保證安全性的最低原則是為應(yīng)用程序提供其運行所需的最少訪問量。這可以在一定程度上確保即使在發(fā)生安全漏洞的情況下，攻擊者也將難以深入挖掘你的網(wǎng)絡(luò)。雖然它不能完全確保你的安全，但無疑會使攻擊者進行攻擊時變得更加困難和耗時。這很重要，因為它會使你有更多的時間做出反應(yīng)并防止進一步的破壞。這里有一個典型的例子，不同應(yīng)用程序的不同 exploits/ 漏洞的組合，這使得攻擊者只有從多個維度（例如，網(wǎng)絡(luò)、容器、主機）到達(dá)任何攻擊面的情況下，才能進行攻擊。

這里的選擇要么是利用網(wǎng)絡(luò)策略，要么是尋求第三方安全解決方案以實現(xiàn)容器網(wǎng)絡(luò)安全。有了網(wǎng)絡(luò)策略，我們有堅實的基礎(chǔ)來確保流量僅在流量應(yīng)流的地方進行，但這僅適用于少數(shù)幾個 CNI。例如，它們可與 Calico 和 Kube-router 一起使用。Flannel 不支持它，但是幸運的是，你可以移至 Canal，這使得 Flannel 可以使用 Calico 的網(wǎng)絡(luò)策略功能。對于大多數(shù)其他 CNI，則沒有支持，目前尚未有支持的計劃。

但這不是唯一的問題。問題在于，網(wǎng)絡(luò)策略規(guī)則只是針對特定端口的防火墻規(guī)則，它十分簡單。這意味著你無法應(yīng)用任何高級設(shè)置。例如，如果你發(fā)現(xiàn)某個容器可疑，就不能按需阻止它。進一步來說，網(wǎng)絡(luò)規(guī)則無法理解流量，因此你不知道流量的流向，并且僅限于在第 3 層和第 4 層上創(chuàng)建規(guī)則。最后，它還無法檢測到基于網(wǎng)絡(luò)的威脅或攻擊，例如 DDoS，DNS，SQL 注入以及即使在受信任的 IP 地址和端口上也可能發(fā)生的其他破壞性網(wǎng)絡(luò)攻擊。

因此，我們需要專用的容器網(wǎng)絡(luò)安全解決方案，它可為關(guān)鍵應(yīng)用程序（例如財務(wù)或合規(guī)性驅(qū)動的應(yīng)用程序）提供所需的安全性。我個人喜歡 NeuVector。它具有我曾在 Arvato / Bertelsmann 進行部署的容器防火墻解決方案，并提供了我們所需的 Layer7 可見性和保護。

應(yīng)該注意的是，任何網(wǎng)絡(luò)安全解決方案都必須是云原生的，并且可以自動擴展和調(diào)整。部署新應(yīng)用程序或擴展 Pod 時，你無需檢查 iptable 規(guī)則或更新任何內(nèi)容。也許對于幾個節(jié)點上的簡單應(yīng)用程序堆棧，你可以手動進行管理，但是對于任何企業(yè)而言，部署安全不能減慢 CI / CD 流水線的速度。

除了安全性和可見性之外，我還發(fā)現(xiàn)擁有連接和數(shù)據(jù)包級容器網(wǎng)絡(luò)工具有助于在測試和 staging 期間調(diào)試應(yīng)用程序。借助 Kubernetes 網(wǎng)絡(luò)，除非您能看到流量，否則您將永遠(yuǎn)無法真正確定所有數(shù)據(jù)包的去向以及將哪些 Pod 路由到其中。

選擇網(wǎng)絡(luò) CNI 的一些建議

現(xiàn)在已經(jīng)介紹了 Kubernetes 網(wǎng)絡(luò)和 CNI，始終會出現(xiàn)一個大問題：應(yīng)該選擇哪種 CNI 解決方案？我將嘗試提供一些有關(guān)如何做出此決定的建議。

首先，定義問題

每個項目的第一件事是盡可能詳細(xì)地定義你需要首先解決的問題。你也許想知道要部署哪種應(yīng)用程序以及它們將產(chǎn)生什么樣的負(fù)載。你可能會問自己的一些問題：

我的應(yīng)用程序：

網(wǎng)絡(luò)是否繁忙？

是否對延遲敏感？

是單體架構(gòu)嗎？

還是微服務(wù)架構(gòu)服務(wù)？

需要在多個網(wǎng)絡(luò)上嗎？

我可以承受宕機時間嗎，甚至是最小的宕機時間？

這是一個十分重要的問題，因為你需要事先確定好。如果你現(xiàn)在選擇一種解決方案，以后再進行切換，則需要重新設(shè)置網(wǎng)絡(luò)并重新部署所有容器。除非你已經(jīng)擁有 Multus 之類的東西并且可以使用多個網(wǎng)絡(luò)，否則這將意味著您的服務(wù)會停機。在大多數(shù)情況下，如果你有計劃的維護時段，那么事情會沒那么嚴(yán)重，但是隨著應(yīng)用程序的不斷迭代，零停機時間變得更加重要！

我的應(yīng)用程序在多個網(wǎng)絡(luò)上

這一情況在本地安裝中十分常見，實際上，如果你只想將通過專用網(wǎng)絡(luò)和公用網(wǎng)絡(luò)的流量分開，那么這需要你設(shè)置多個網(wǎng)絡(luò)或者有智能的路由。

我是否需要 CNI 中的某些特定功能？

影響你做決定的另一件事是，你需要一些特定的功能，在某些 CNI 中可用，而其他 CNI 中不可用。例如，你想使用 Weave 或希望通過 ipvs 進行更為成熟的負(fù)載均衡。

需要什么網(wǎng)絡(luò)性能？

如果你的應(yīng)用程序?qū)ρ舆t敏感或網(wǎng)絡(luò)繁忙，那么你需要避免使用任何 overlay 網(wǎng)絡(luò)。Overlay 在性能上并不劃算，規(guī)模上也是如此。這這種情況下，提高網(wǎng)絡(luò)性能的唯一方法是避免 overlay 并改用路由之類的網(wǎng)絡(luò)實用程序。尋找網(wǎng)絡(luò)性能時，你有幾種選擇，例如：

Ipvlan：它有良好的性能，但需要注意，你不能在同一主機上同時使用 macv{tap,lan}。

Calico：這個 CNI 不是對用戶最友好的，但于 vxlan 相比，它可以為你提供更好的性能，并且可以進行擴展而無需擔(dān)心。

Kube-Router：它通過使用 BGP 和路由，以及支持 LVS/IPVS，來提供更好的性能（這與 Calico 類似）。但 Calico 比它更為成熟。

云提供商解決方案：一些云提供商提供了自己的網(wǎng)絡(luò)解決方案，這些方案的好壞需要根據(jù)具體情況來確定，這里無法一概而論。值得一提的是，Rancher 的一個開源項目 Submariner。它支持多個 Kubernetes 集群之間的跨集群網(wǎng)絡(luò)連接，并且創(chuàng)建了必要的隧道和路徑，能為部署在需要相互通信的多個 Kubernetes 集群中的微服務(wù)提供網(wǎng)絡(luò)連接。

“如何使用 Kubernetes 網(wǎng)絡(luò)”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注丸趣 TV 網(wǎng)站，丸趣 TV 小編將為大家輸出更多高質(zhì)量的實用文章！