国产午夜视频专区,性8sex8春暖花开亚洲地址,亚洲一区二区三区大桥未久

K8S 網(wǎng)絡(luò)設(shè)計(jì)與實(shí)現(xiàn)是在學(xué)習(xí) K8S 網(wǎng)絡(luò)過(guò)程中總結(jié)的內(nèi)容。本文按照 K8S 網(wǎng)絡(luò)設(shè)計(jì)原則、Pod 內(nèi)部網(wǎng)絡(luò)、Pod 之間網(wǎng)絡(luò)等幾個(gè)步驟講解 K8S 復(fù)雜的網(wǎng)絡(luò)架構(gòu)。

圖片出自：《你女兒也能看懂的插畫(huà)版 Kubernetes 指南》

K8S 網(wǎng)絡(luò)設(shè)計(jì)原則

K8S 網(wǎng)絡(luò)設(shè)計(jì)原則如下：

每個(gè) Pod 都擁有一個(gè)獨(dú)立 IP 地址，Pod 內(nèi)所有容器共享該 IP 地址。
集群內(nèi)所有 Pod 都在一個(gè)直接連通的扁平網(wǎng)絡(luò)中，可通過(guò) IP 直接訪問(wèn)。
即：所有容器之間無(wú)需 NAT 就可以直接互相訪問(wèn)；所有 Node 和所有容器之間無(wú)需 NAT 就可以直接互相訪問(wèn)；容器自己看到的 IP 跟其他容器看到的一樣。

K8S 網(wǎng)絡(luò)規(guī)范

CNI 是由 CoreOS 提出的一個(gè)容器網(wǎng)絡(luò)規(guī)范。已采納規(guī)范的包括 Apache Mesos，Cloud Foundry，Kubernetes，Kurma 和 RKT。

另外 Contiv Networking，Project Calico 和 Weave 這些項(xiàng)目也為 CNI 提供插件。

CNI 規(guī)定了一個(gè)容器 Runtime 和網(wǎng)絡(luò)插件之間的簡(jiǎn)單的契約。這個(gè)契約通過(guò) JSON 的語(yǔ)法定義了 CNI 插件所需要提供的輸入和輸出。

CNI 插件提供兩個(gè)功能：

一個(gè)用來(lái)將網(wǎng)絡(luò)接口加入到指定網(wǎng)絡(luò)。
另一個(gè)用來(lái)將其移除。

這兩個(gè)接口分別在容器被創(chuàng)建和銷毀的時(shí)候被調(diào)用。容器 Runtime 首先需要獲得一個(gè)網(wǎng)絡(luò)命名空間以及一個(gè)容器 ID，然后連同一些 CNI 配置參數(shù)傳給網(wǎng)絡(luò)驅(qū)動(dòng)。

接著網(wǎng)絡(luò)驅(qū)動(dòng)會(huì)將該容器連接到網(wǎng)絡(luò)并將分配的 IP 地址以 JSON 的格式返回給容器 Runtime。

K8S 網(wǎng)絡(luò)插件要求

K8S 對(duì)網(wǎng)絡(luò)插件的要求總的來(lái)講主要有兩個(gè)最基本的，分別是：

要能夠?yàn)槊恳粋€(gè) Node 上的 Pod 分配互相不沖突的 IP 地址。
要所有 Pod 之間能夠互相訪問(wèn)。

K8S 網(wǎng)絡(luò)實(shí)現(xiàn)方案

K8S網(wǎng)絡(luò)實(shí)現(xiàn)方案有如下幾種：

隧道方案

隧道方案在 IaaS 層的網(wǎng)絡(luò)中應(yīng)用也比較多，將 Pod 分布在一個(gè)大二層的網(wǎng)絡(luò)規(guī)模下。網(wǎng)絡(luò)拓?fù)浜?jiǎn)單，但隨著節(jié)點(diǎn)規(guī)模的增長(zhǎng)復(fù)雜度會(huì)提升。

代表方案：

Weave：UDP 廣播，本機(jī)建立新的 BR，通過(guò) PCAP 互通。
Open vSwitch：基于 VxLan 和 GRE 協(xié)議，但是性能方面損失比較嚴(yán)重。
Flannel：UDP 廣播，VxLan。
Racher：IPsec。

路由方案

路由方案一般是從 3 層或者 2 層實(shí)現(xiàn)隔離和跨主機(jī)容器互通的，出了問(wèn)題也很容易排查。

代表方案：

Calico：基于 BGP 協(xié)議的路由方案，支持很細(xì)致的 ACL 控制，對(duì)混合云親和度比較高。
macvlan：從邏輯和 Kernel 層來(lái)看隔離性和性能優(yōu)的方案，基于二層隔離，所以需要二層路由器支持，大多數(shù)云服務(wù)商不支持，所以混合云上比較難以實(shí)現(xiàn)。

K8S Pod 的網(wǎng)絡(luò)創(chuàng)建流程

K8S Pod 的網(wǎng)絡(luò)創(chuàng)建流程如下：

每個(gè) Pod 除了創(chuàng)建時(shí)指定的容器外，都有一個(gè) Kubelet 啟動(dòng)時(shí)指定的基礎(chǔ)容器。
Kubelet 創(chuàng)建基礎(chǔ)容器，生成 Network Namespace。
Kubelet 調(diào)用網(wǎng)絡(luò) CNIdriver，根據(jù)配置調(diào)用具體的 CNI 插件。
CNI 插件給基礎(chǔ)容器配置網(wǎng)絡(luò)。
Pod 中其他的容器共享基礎(chǔ)容器的網(wǎng)絡(luò)。

Pod 中的網(wǎng)絡(luò)

Pod 是 K8S 的最小工作單元。每個(gè) Pod 包含一個(gè)或多個(gè)容器。K8S 管理的也是 Pod 而不是直接管理容器。Pod 中的容器會(huì)作為一個(gè)整體被 Master 調(diào)度到一個(gè) Node 上運(yùn)行。

Pod 的設(shè)計(jì)理念是支持多個(gè)容器在一個(gè) Pod 中共享網(wǎng)絡(luò)地址和文件系統(tǒng)，可以通過(guò)進(jìn)程間通信和文件共享這種簡(jiǎn)單高效的方式組合完成服務(wù)。

一個(gè) Pod 中可以包含多個(gè)容器，而一個(gè) Pod 只有一個(gè) IP 地址。那么多個(gè)容器之間互相訪問(wèn)和訪問(wèn)外網(wǎng)是如何使用這一個(gè) IP 地址呢？

答案是：多個(gè)容器共享同一個(gè)底層的網(wǎng)絡(luò)命名空間 Net（網(wǎng)絡(luò)設(shè)備、網(wǎng)絡(luò)棧、端口等）。

下面以一個(gè)小例子說(shuō)明，創(chuàng)建一個(gè) Pod 包含兩個(gè)容器，yaml 文件如下：

apiVersion: Apps/v1beta1
kind: Deployment
metadata:
 name: Pod-two-container
spec:
 replicas: 1
 template:
 metadata:
 labels:
 app: Nginx
 spec:
 containers:
 - name: busybox
 image: busybox
 command:
 - "/bin/sh"
 - "-c"
 - "while true;do echo hello;sleep 1;done"
 - name: nginx
 image: nginx

創(chuàng)建 1 個(gè) Pod 中包含 2 個(gè) Container，實(shí)際會(huì)創(chuàng)建 3 個(gè) Container。多出的一個(gè)是“Pause”容器。

該 Container 是 Pod 的基礎(chǔ)容器，為其他容器提供網(wǎng)絡(luò)功能。

查看 Pause 容器的基礎(chǔ)信息：

使用命令 Docker inspect 容器 _ID 查看 Nginx 詳細(xì)信息，其網(wǎng)絡(luò)命令空間使用了 Pause 容器的命名空間，同樣還有進(jìn)程間通信的命名空間。

再查看 Busybox，可以發(fā)現(xiàn)其網(wǎng)絡(luò)命令空間使用了 Pause 容器的命名空間，進(jìn)程通信的命名空間也是 Pause 容器的命名空間。

實(shí)現(xiàn)方式：Nginx 和 Busybox 之所以能夠和 Pause 的命名空間連通是因?yàn)?Docker 有一個(gè)特性：能夠在創(chuàng)建時(shí)使用指定 Docker 的網(wǎng)絡(luò)命名空間。

在 Docker 的官網(wǎng)上有一段描述：

https://docs.docker.com/engine/reference/run/

所以如果要手動(dòng)完成一個(gè)上面的 Pod，可以先創(chuàng)建 Pause，再創(chuàng)建 Nginx 和 Busybox，同時(shí)將網(wǎng)絡(luò)指定為 Pause 的網(wǎng)絡(luò)命名空間即可。

docker run --name pause mirrorgooglecontainers/pause-amd64:3.1
docker run --name=nginx --network=container:pause nginx 
docker run --name=busybox --network=container:pause busybox

上述步驟由 K8S 幫助我們完成，所以 Pod 命名空間應(yīng)該是這樣的：

講完了 Pod 內(nèi)部的網(wǎng)絡(luò)實(shí)現(xiàn)，我們主要來(lái)看 Pod 如何獲取 IP 地址，以及 Pod 與 Pod 之間的通信是怎么樣的過(guò)程？

Flannel 網(wǎng)絡(luò)

Flannel 簡(jiǎn)介

Flannel 是 CoreOS 團(tuán)隊(duì)針對(duì) Kubernetes 設(shè)計(jì)的一個(gè)網(wǎng)絡(luò)規(guī)劃服務(wù)，簡(jiǎn)單來(lái)說(shuō)，它的功能是讓集群中的不同節(jié)點(diǎn)主機(jī)創(chuàng)建的 Docker 容器都具有全集群唯一的虛擬 IP 地址。

在默認(rèn)的 Docker 配置中，每個(gè)節(jié)點(diǎn)上的 Docker 服務(wù)會(huì)分別負(fù)責(zé)所在節(jié)點(diǎn)容器的 IP 分配。這樣導(dǎo)致的一個(gè)問(wèn)題是，不同節(jié)點(diǎn)上容器可能獲得相同的 IP 地址。

Flannel 的設(shè)計(jì)目的就是為集群中的所有節(jié)點(diǎn)重新規(guī)劃 IP 地址的使用規(guī)則，從而使得不同節(jié)點(diǎn)上的容器能夠獲得“同屬一個(gè)內(nèi)網(wǎng)”且“不重復(fù)的”IP 地址，并讓屬于不同節(jié)點(diǎn)上的容器能夠直接通過(guò)內(nèi)網(wǎng) IP 通信。

Flannel 實(shí)質(zhì)上是一種“覆蓋網(wǎng)絡(luò)（overlay network）”，也就是將 TCP 數(shù)據(jù)包裝在另一種網(wǎng)絡(luò)包里面進(jìn)行路由轉(zhuǎn)發(fā)和通信。

目前已經(jīng)支持 UDP、Vxlan、Host-gw、Aws-vpc、Gce 和 Alloc 路由等數(shù)據(jù)轉(zhuǎn)發(fā)方式，默認(rèn)的節(jié)點(diǎn)間數(shù)據(jù)通信方式是 UDP 轉(zhuǎn)發(fā)。

適用場(chǎng)景：不需要隔離 Pod，集群規(guī)模小。

設(shè)計(jì)思想：為每一個(gè) Node 節(jié)點(diǎn)分配 IP 網(wǎng)段，使 Node 之間 IP 不重復(fù)，Pod 之間直接使用 IP 訪問(wèn)。

設(shè)計(jì)優(yōu)勢(shì)：網(wǎng)絡(luò)模型簡(jiǎn)單，安裝配置相對(duì)容易，成熟度高，適合大多數(shù)用例的環(huán)境。

Flannel 對(duì)網(wǎng)絡(luò)要求提出的解決辦法

互相不沖突的 IP：

Flannel 利用 Kubernetes API 或者 etcd 用于存儲(chǔ)整個(gè)集群的網(wǎng)絡(luò)配置，根據(jù)配置記錄集群使用的網(wǎng)段。
Flannel 在每個(gè)主機(jī)中運(yùn)行 Flanneld 作為 Agent，它會(huì)為所在主機(jī)從集群的網(wǎng)絡(luò)地址空間中，獲取一個(gè)小的網(wǎng)段 Subnet，本主機(jī)內(nèi)所有容器的 IP 地址都將從中分配。

如測(cè)試環(huán)境中 IP 分配：

①M(fèi)aster 節(jié)點(diǎn)

②Node1

③Node2

在 Flannel Network 中，每個(gè) Pod 都會(huì)被分配唯一的 IP 地址，且每個(gè) K8S Node 的 Subnet 各不重疊，沒(méi)有交集。

Pod 之間互相訪問(wèn)：

Flanneld 將本主機(jī)獲取的 Subnet 以及用于主機(jī)間通信的 Public IP 通過(guò) etcd 存儲(chǔ)起來(lái)，需要時(shí)發(fā)送給相應(yīng)模塊。
Flannel 利用各種 Backend 機(jī)制，例如 UDP，Vxlan 等等，跨主機(jī)轉(zhuǎn)發(fā)容器間的網(wǎng)絡(luò)流量，完成容器間的跨主機(jī)通信。

Flannel 架構(gòu)原理

Flannel 架構(gòu)圖：

各個(gè)組件的解釋如下：

Cni0：網(wǎng)橋設(shè)備，每創(chuàng)建一個(gè) Pod 都會(huì)創(chuàng)建一對(duì) Veth Pair。其中一端是 Pod 中的 eth0，另一端是 cni0 網(wǎng)橋中的端口（網(wǎng)卡）。

Pod 中從網(wǎng)卡 eth0 發(fā)出的流量都會(huì)發(fā)送到 cni0 網(wǎng)橋設(shè)備的端口（網(wǎng)卡）上。

注：cni0 設(shè)備獲得的 IP 地址是該節(jié)點(diǎn)分配到的網(wǎng)段的第一個(gè)地址。

Flannel.1：Overlay 網(wǎng)絡(luò)的設(shè)備，用來(lái)進(jìn)行 Vxlan 報(bào)文的處理（封包和解包）。不同 Node 之間的 Pod 數(shù)據(jù)流量都從 Overlay 設(shè)備以隧道的形式發(fā)送到對(duì)端。

Flanneld：Flannel 在每個(gè)主機(jī)中運(yùn)行 Flanneld 作為 Agent，它會(huì)為所在主機(jī)從集群的網(wǎng)絡(luò)地址空間中，獲取一個(gè)小的網(wǎng)段 Subnet，本主機(jī)內(nèi)所有容器的 IP 地址都將從中分配。

同時(shí) Flanneld 監(jiān)聽(tīng) K8S 集群數(shù)據(jù)庫(kù)，為 Flannel.1 設(shè)備提供封裝數(shù)據(jù)時(shí)必要的 Mac，IP 等網(wǎng)絡(luò)數(shù)據(jù)信息。

不同 Node 上的 Pod 的通信流程：

Pod 中產(chǎn)生數(shù)據(jù)，根據(jù) Pod 的路由信息，將數(shù)據(jù)發(fā)送到 cni0。
cni0 根據(jù)節(jié)點(diǎn)的路由表，將數(shù)據(jù)發(fā)送到隧道設(shè)備 Flannel.1。
Flannel.1 查看數(shù)據(jù)包的目的 IP，從 Flanneld 獲得對(duì)端隧道設(shè)備的必要信息，封裝數(shù)據(jù)包。
Flannel.1 將數(shù)據(jù)包發(fā)送到對(duì)端設(shè)備。節(jié)點(diǎn)的網(wǎng)卡接收到數(shù)據(jù)包，發(fā)現(xiàn)數(shù)據(jù)包為 Overlay 數(shù)據(jù)包，解開(kāi)外層封裝，并發(fā)送內(nèi)層封裝到 Flannel.1 設(shè)備。
Flannel.1 設(shè)備查看數(shù)據(jù)包，根據(jù)路由表匹配，將數(shù)據(jù)發(fā)送給 cni0 設(shè)備。
cni0 匹配路由表，發(fā)送數(shù)據(jù)給網(wǎng)橋上對(duì)應(yīng)的端口。

通信流程

①Pod1 中的容器到 cni0

Pod1 與 Pod3 能夠互相 Ping 通：

Ping 包的 Dst IP 為 192.20.1.43，根據(jù)路由匹配到最后一條路由表項(xiàng)，去往 192.20.0.0/12 的包都轉(zhuǎn)發(fā)給 192.20.0.1。

192.20.0.1 為 cni0 的 IP 地址。

②cni0 到 Flannel1.1

當(dāng) Icmp 包達(dá)到 cni0 之后，cni0 發(fā)現(xiàn) Dst 為 192.20.1.43，CNI 根據(jù)主機(jī)路由表來(lái)查找匹配項(xiàng)。

根據(jù)最小匹配原則，匹配到圖上的一條路由表項(xiàng)。去往 192.20.1.0/24 網(wǎng)段的包，發(fā)送 192.20.1.0 網(wǎng)關(guān)，網(wǎng)關(guān)設(shè)備是 Flannel.1。

③Flannel.1

內(nèi)層封裝：Flannel.1 為 Vxlan 隧道端點(diǎn)，當(dāng)數(shù)據(jù)包來(lái)到 Flannel.1 時(shí)，需要將數(shù)據(jù)包封裝起來(lái)。此時(shí)：

源 IP src ip 為 192.20.0.51。
目的 IP dst ip 為 192.20.1.43。

數(shù)據(jù)包繼續(xù)封裝需要知道目的 IP 192.20.1.43，IP 地址對(duì)應(yīng)的 Mac 地址。此時(shí)，F(xiàn)lannel.1 不會(huì)發(fā)送 ARP 請(qǐng)求去獲得目的 IP 的 Mac 地址，而是將請(qǐng)求發(fā)送到用戶空間的 Flanned 程序。

Flanned 程序收到內(nèi)核的請(qǐng)求事件之后，從 etcd 查找能夠匹配該地址的子網(wǎng)的 Flannel.1 設(shè)備的 Mac 地址，即發(fā)往的 Pod 所在 Host 中 Flannel.1 設(shè)備的 Mac 地址。

Flannel 在為 Node 節(jié)點(diǎn)分配 IP 網(wǎng)段時(shí)記錄了所有的網(wǎng)段和 Mac 等信息。該過(guò)程交互流程如下圖所示：

Flanned 將查詢到的信息放入 Master 節(jié)點(diǎn)的 ARP Cache 表中：

到這里，Vxlan 的內(nèi)層數(shù)據(jù)包就完成了封裝。格式是這樣的：

簡(jiǎn)單總結(jié)這個(gè)流程：

數(shù)據(jù)包到達(dá) Flannel.1，通過(guò)查找路由表，知道數(shù)據(jù)包要通過(guò) Flannel.1 發(fā)往 192.20.1.0。
通過(guò) ARP Cache 表，知道了目的 IP 192.20.1.0 的 Mac 地址。

外層封裝：此時(shí)內(nèi)層封裝已經(jīng)準(zhǔn)備好，需要找到 Vxlan 的外層封裝。Kernel 需要查看 Node 上的 FDB（forwarding database）以獲得內(nèi)層封包中目的 Vtep 設(shè)備所在的 Node 地址。

因?yàn)橐呀?jīng)從 ARP Table 中查到目的設(shè)備 Mac 地址為 52:77:71:e6:4f:58，同時(shí)在 FDB 中存在該 Mac 地址對(duì)應(yīng)的 Node 節(jié)點(diǎn)的 IP 地址。

如果 FDB 中沒(méi)有這個(gè)信息，那么 Kernel 會(huì)向用戶空間的 Flanned 程序發(fā)起“L2 MISS”事件。Flanneld 收到該事件后，會(huì)查詢 etcd，獲取該 Vtep 設(shè)備對(duì)應(yīng)的 Node 的“Public IP”，并將信息注冊(cè)到 FDB 中。

當(dāng)內(nèi)核獲得了發(fā)往機(jī)器的 IP 地址后，ARP 得到 Mac 地址，之后就能完成 Vxlan 的外層封裝。

④對(duì)端 Flannel.1

Node 節(jié)點(diǎn)的 eth0 網(wǎng)卡接收到 Vxlan 設(shè)備包，Kernal 將識(shí)別出這是一個(gè) Vxlan 包，將包拆開(kāi)之后轉(zhuǎn)給節(jié)點(diǎn)上的 Flannel.1 設(shè)備。

這樣數(shù)據(jù)包就從發(fā)送節(jié)點(diǎn)到達(dá)目的節(jié)點(diǎn)，F(xiàn)lannel.1 設(shè)備將接收到一個(gè)如下的數(shù)據(jù)包：

目的地址為 192.20.1.43，F(xiàn)lannel.1 查找自己的路由表，根據(jù)路由表完成轉(zhuǎn)發(fā)。

根據(jù)匹配原則，F(xiàn)lannel.1 將去往 192.20.1.0/24 的流量轉(zhuǎn)發(fā)到 cni0 上去。

⑤cnio 到 Pod

cni0 是一個(gè)網(wǎng)橋設(shè)備。當(dāng) cni0 拿到數(shù)據(jù)包之后，通過(guò) Veth Pair，將數(shù)據(jù)包發(fā)送給 Pod。查看 Node 節(jié)點(diǎn)中的網(wǎng)橋。

在 Node 節(jié)點(diǎn)上通過(guò) ARP 解析可以開(kāi)出，192.20.1.43 的 Mac 地址為 66:57:8e:3d:00:85：

該地址為 Pod 的網(wǎng)卡 eth0 的地址。

同時(shí)通過(guò) Veth Pair 的配對(duì)關(guān)系可以看出，Pod 中的 eth0 是 Veth Pair 的一端，另一端在 Node 節(jié)點(diǎn)行上，對(duì)應(yīng)的網(wǎng)卡是 vethd356ffc1@if3：

所以，在 cni0 網(wǎng)橋上掛載的 Pod 的 Veth Pair 為 vethd356ffc1，即：

eth0@if50 和 vethd356ffc1@if3 組成的一對(duì) Veth Pair。其效果相當(dāng)于將 Pod 中的 eth0 直接插在到 cni0 上。

簡(jiǎn)單總結(jié) cni0 轉(zhuǎn)發(fā)流量的原理：

首先通過(guò) ARP 查找出 IP 地址對(duì)應(yīng)的 Mac 地址。
將流量轉(zhuǎn)發(fā)給 Mac 地址所在 eth0 網(wǎng)的對(duì)應(yīng)的 Veth Pair 端口。
Veth Pair 端口接收到流量，直接將流量注入到 Pod 的 eth0 網(wǎng)卡上。

總結(jié) Flannel 的特點(diǎn)：

使集群中的不同 Node 主機(jī)創(chuàng)建的 Docker 容器都具有全集群唯一的虛擬 IP 地址。
建立一個(gè)覆蓋網(wǎng)絡(luò)（overlay network），通過(guò)這個(gè)覆蓋網(wǎng)絡(luò)，將數(shù)據(jù)包原封不動(dòng)的傳遞到目標(biāo)容器。
創(chuàng)建一個(gè)新的虛擬網(wǎng)卡 Flannel0 接收 Docker 網(wǎng)橋的數(shù)據(jù)，通過(guò)維護(hù)路由表，對(duì)接收到的數(shù)據(jù)進(jìn)行封包和轉(zhuǎn)發(fā)。
etcd 保證了所有 Node 上 Flanned 所看到的配置是一致的。同時(shí)每個(gè) Node 上的 Flanned 監(jiān)聽(tīng) etcd 上的數(shù)據(jù)變化，實(shí)時(shí)感知集群中 Node 的變化。

不同后端的封裝

Flannel 可以指定不同的轉(zhuǎn)發(fā)后端網(wǎng)絡(luò)，常用的有 Hostgw，UDP，Vxlan 等，上述使用的就是 Vxlan 網(wǎng)絡(luò)。

①Hostgw：是簡(jiǎn)單的 Backend，它的原理非常簡(jiǎn)單，直接添加路由，將目的主機(jī)當(dāng)做網(wǎng)關(guān)，直接路由原始封包。

例如，我們從 etcd 中監(jiān)聽(tīng)到一個(gè) EventAdded 事件 Subnet 為 10.1.15.0/24 被分配給主機(jī) Public IP 192.168.0.100。

Hostgw 要做的工作就是在本主機(jī)上添加一條目的地址為 10.1.15.0/24，網(wǎng)關(guān)地址為 192.168.0.100，輸出設(shè)備為上文中選擇的集群間交互的網(wǎng)卡即可。

優(yōu)點(diǎn)：簡(jiǎn)單，直接，效率高。

缺點(diǎn)：要求所有的 Pod 都在一個(gè)子網(wǎng)中，如果跨網(wǎng)段就無(wú)法通信。

②UDP：如何應(yīng)對(duì) Pod 不在一個(gè)子網(wǎng)里的場(chǎng)景呢？將 Pod 的網(wǎng)絡(luò)包作為一個(gè)應(yīng)用層的數(shù)據(jù)包，使用 UDP 封裝之后在集群里傳輸，即 Overlay。

上圖來(lái)自 Flannel 官方，其中右邊 Packer 的封裝格式就是使用 UDP 完成 Overlay 的格式。

當(dāng)容器 10.1.15.2/24 要和容器 10.1.20.2/24 通信時(shí)：

因?yàn)樵摲獍哪康牡夭辉诒局鳈C(jī) Subnet 內(nèi)，因此封包會(huì)首先通過(guò)網(wǎng)橋轉(zhuǎn)發(fā)到主機(jī)中。
在主機(jī)上經(jīng)過(guò)路由匹配，進(jìn)入網(wǎng)卡 Flannel.1。(需要注意的是 Flannel.1 是一個(gè) Tun 設(shè)備，它是一種工作在三層的虛擬網(wǎng)絡(luò)設(shè)備，而 Flanneld 是一個(gè) Proxy，它會(huì)監(jiān)聽(tīng) Flannel.1 并轉(zhuǎn)發(fā)流量。)
當(dāng)封包進(jìn)入 Flannel.1 時(shí)，F(xiàn)lanneld 就可以從 Flanne.1 中將封包讀出，由于 Flanne.1 是三層設(shè)備，所以讀出的封包僅僅包含 IP 層的報(bào)頭及其負(fù)載。
最后 Flanneld 會(huì)將獲取的封包作為負(fù)載數(shù)據(jù)，通過(guò) UDP Socket 發(fā)往目的主機(jī)。
在目的主機(jī)的 Flanneld 會(huì)監(jiān)聽(tīng) Public IP 所在的設(shè)備，從中讀取 UDP 封包的負(fù)載，并將其放入 Flannel.1 設(shè)備內(nèi)。
容器網(wǎng)絡(luò)封包到達(dá)目的主機(jī)，之后就可以通過(guò)網(wǎng)橋轉(zhuǎn)發(fā)到目的容器了。

優(yōu)點(diǎn)：Pod 能夠跨網(wǎng)段訪問(wèn)。

缺點(diǎn)：隔離性不夠，UDP 不能隔離兩個(gè)網(wǎng)段。

③Vxlan：和上文提到的 udpbackend 的封包結(jié)構(gòu)是非常類似的，不同之處是多了一個(gè) vxlanheader，以及原始報(bào)文中多了個(gè)二層的報(bào)頭。

當(dāng)初始化集群里，Vxlan 網(wǎng)絡(luò)的初始化工作：主機(jī) B 加入 Flannel 網(wǎng)絡(luò)時(shí)，它會(huì)將自己的三個(gè)信息寫(xiě)入 etcd 中，分別是：Subnet10.1.16.0/24、Public IP 192.168.0.101、Vtep 設(shè)備 Flannel.1 的 Mac 地址 MAC B。

之后，主機(jī) A 會(huì)得到 EventAdded 事件，并從中獲取上文中 B 添加至 etcd 的各種信息。

這個(gè)時(shí)候，它會(huì)在本機(jī)上添加三條信息：

路由信息：所有通往目的地址 10.1.16.0/24 的封包都通過(guò) Vtep 設(shè)備 Flannel.1 設(shè)備發(fā)出，發(fā)往的網(wǎng)關(guān)地址為 10.1.16.0，即主機(jī) B 中的 Flannel.1 設(shè)備。
FDB 信息：MAC 地址為 MAC B 的封包，都將通過(guò) Vxlan 發(fā)往目的地址 192.168.0.101，即主機(jī) B。
ARP 信息：網(wǎng)關(guān)地址 10.1.16.0 的地址為 MAC B。

事實(shí)上，F(xiàn)lannel 只使用了 Vxlan 的部分功能，由于 VNI 被固定為 1，本質(zhì)上工作方式和 UDP Backend 是類似的，區(qū)別無(wú)非是將 UDP 的 Proxy 換成了內(nèi)核中的 Vxlan 處理模塊。

而原始負(fù)載由三層擴(kuò)展到了二層，但是這對(duì)三層網(wǎng)絡(luò)方案 Flannel 是沒(méi)有意義的，這么做也僅僅只是為了適配 Vxlan 的模型。

存在問(wèn)題

存在的問(wèn)題如下：

不支持 Pod 之間的網(wǎng)絡(luò)隔離。Flannel 設(shè)計(jì)思想是將所有的 Pod 都放在一個(gè)大的二層網(wǎng)絡(luò)中，所以 Pod 之間沒(méi)有隔離策略。
設(shè)備復(fù)雜，效率不高。Flannel 模型下有三種設(shè)備，數(shù)量經(jīng)過(guò)多種設(shè)備的封裝、解析，勢(shì)必會(huì)造成傳輸效率的下降。

Calico 網(wǎng)絡(luò)

Calico 簡(jiǎn)介

Calico 是一種開(kāi)源網(wǎng)絡(luò)和網(wǎng)絡(luò)安全解決方案，適用于容器，虛擬機(jī)和基于主機(jī)的本機(jī)工作負(fù)載。

Calico 支持廣泛的平臺(tái)，包括 Kubernetes，OpenShift，Docker EE，OpenStack 和裸機(jī)服務(wù)。

在虛擬化平臺(tái)中，比如 OpenStack、Docker 等都需要實(shí)現(xiàn) Workloads 之間互連，但同時(shí)也需要對(duì)容器做隔離控制，就像在 Internet 中的服務(wù)僅開(kāi)放 80 端口、公有云的多租戶一樣，提供隔離和管控機(jī)制。

而在多數(shù)的虛擬化平臺(tái)實(shí)現(xiàn)中，通常都使用二層隔離技術(shù)來(lái)實(shí)現(xiàn)容器的網(wǎng)絡(luò)，這些二層的技術(shù)有一些弊端，比如需要依賴 VLAN、Bridge 和隧道等技術(shù)。

其中 Bridge 帶來(lái)了復(fù)雜性，Vlan 隔離和 Tunnel 隧道則消耗更多的資源并對(duì)物理環(huán)境有要求，隨著網(wǎng)絡(luò)規(guī)模的增大，整體會(huì)變得越加復(fù)雜。

Calico 是一個(gè)純?nèi)龑拥姆桨福衙總€(gè) Node 節(jié)點(diǎn)認(rèn)為是一個(gè)路由器，然后把所有的容器認(rèn)為是連在這個(gè)路由器上的網(wǎng)絡(luò)終端，在路由器之間跑標(biāo)準(zhǔn)的路由協(xié)議——BGP 的協(xié)議，然后讓它們自己去學(xué)習(xí)這個(gè)網(wǎng)絡(luò)拓?fù)湓撊绾无D(zhuǎn)發(fā)。

Calico 為每個(gè)主機(jī)分配了一段子網(wǎng)作為容器可分配的 IP 范圍，這樣就可以根據(jù)子網(wǎng)的 CIDR 為每個(gè)主機(jī)生成比較固定的路由規(guī)則，Pod 發(fā)送另一個(gè)主機(jī)的流量能夠根據(jù)路由規(guī)則匹配而被轉(zhuǎn)發(fā)。

適用場(chǎng)景：集群規(guī)模較大，環(huán)境中的 Pod 之間需要隔離。

設(shè)計(jì)思想：Calico 不使用隧道或 NAT 來(lái)實(shí)現(xiàn)轉(zhuǎn)發(fā)，而是巧妙的把所有二三層流量轉(zhuǎn)換成三層流量，并通過(guò) Host 上路由配置完成跨 Host 轉(zhuǎn)發(fā)。

設(shè)計(jì)優(yōu)勢(shì)如下：

①更優(yōu)的資源利用：二層網(wǎng)絡(luò)通訊需要依賴廣播消息機(jī)制，廣播消息的開(kāi)銷與 Host 的數(shù)量呈指數(shù)級(jí)增長(zhǎng)，Calico 使用的三層路由方法，則完全抑制了二層廣播，減少了資源開(kāi)銷。

另外，二層網(wǎng)絡(luò)使用 VLAN 隔離技術(shù)，天生有 4096 個(gè)規(guī)格限制，即便可以使用 Vxlan 解決，但 Vxlan 又帶來(lái)了隧道開(kāi)銷的新問(wèn)題。而 Calico 不使用 Vlan 或 Vxlan 技術(shù)，使資源利用率更高。

②可擴(kuò)展性：Calico 使用與 Internet 類似的方案，Internet 的網(wǎng)絡(luò)比任何數(shù)據(jù)中心都大，Calico 同樣天然具有可擴(kuò)展性。

③簡(jiǎn)單而更容易 Debug：因?yàn)闆](méi)有隧道，意味著 Workloads 之間路徑更短更簡(jiǎn)單，配置更少，在 Host 上更容易進(jìn)行 Debug 調(diào)試。

④更少的依賴：Calico 僅依賴三層路由可達(dá)。

⑤可適配性：Calico 較少的依賴性使它能適配所有 VM、Container、白盒或者混合環(huán)境場(chǎng)景。

Calico 架構(gòu)原理

架構(gòu)圖如下：

Calico 網(wǎng)絡(luò)模型主要工作組件：

Felix：運(yùn)行在每一臺(tái) Host 的 Agent 進(jìn)程，主要負(fù)責(zé)網(wǎng)絡(luò)接口管理和監(jiān)聽(tīng)、路由、ARP 管理、ACL 管理和同步、狀態(tài)上報(bào)等。
etcd：分布式鍵值存儲(chǔ)，主要負(fù)責(zé)網(wǎng)絡(luò)元數(shù)據(jù)一致性，確保 Calico 網(wǎng)絡(luò)狀態(tài)的準(zhǔn)確性，可以與 Kubernetes 共用。
BGP Client（BIRD）：Calico 為每一臺(tái) Host 部署一個(gè) BGP Client，使用 BIRD 實(shí)現(xiàn)，BIRD 是一個(gè)單獨(dú)的持續(xù)發(fā)展的項(xiàng)目，實(shí)現(xiàn)了眾多動(dòng)態(tài)路由協(xié)議比如 BGP、OSPF、RIP 等。
在 Calico 的角色是監(jiān)聽(tīng) Host 上由 Felix 注入的路由信息，然后通過(guò) BGP 協(xié)議廣播告訴剩余 Host 節(jié)點(diǎn)，從而實(shí)現(xiàn)網(wǎng)絡(luò)互通。
BGP Route Reflector(BIRD)：在大型網(wǎng)絡(luò)規(guī)模中，如果僅僅使用 BGP Client 形成 Mesh 全網(wǎng)互聯(lián)的方案就會(huì)導(dǎo)致規(guī)模限制，因?yàn)樗泄?jié)點(diǎn)之間倆倆互聯(lián)，需要 N^2 個(gè)連接。
為了解決這個(gè)規(guī)模問(wèn)題，可以采用 BGP 的 RouterReflector 的方法，使所有 BGPClient 僅與特定 RR 節(jié)點(diǎn)互聯(lián)并做路由同步，從而大大減少連接數(shù)。

Felix：會(huì)監(jiān)聽(tīng) ectd 中心的存儲(chǔ)，從它獲取事件，比如說(shuō)用戶在這臺(tái)機(jī)器上加了一個(gè) IP，或者是創(chuàng)建了一個(gè)容器等。

用戶創(chuàng)建 Pod 后，F(xiàn)elix 負(fù)責(zé)將其網(wǎng)卡、IP、MAC 都設(shè)置好，然后在內(nèi)核的路由表里面寫(xiě)一條，注明這個(gè) IP 應(yīng)該到這張網(wǎng)卡。

同樣如果用戶制定了隔離策略，F(xiàn)elix 同樣會(huì)將該策略創(chuàng)建到 ACL 中，以實(shí)現(xiàn)隔離。

BIRD：是一個(gè)標(biāo)準(zhǔn)的路由程序，它會(huì)從內(nèi)核里面獲取哪一些 IP 的路由發(fā)生了變化，然后通過(guò)標(biāo)準(zhǔn) BGP 的路由協(xié)議擴(kuò)散到整個(gè)其他的宿主機(jī)上，讓其他 Node 節(jié)點(diǎn)都知道這個(gè) IP 在這里，生成路由條目就比較方便。

由于 Calico 是一種純?nèi)龑拥膶?shí)現(xiàn)，因此可以避免與二層方案相關(guān)的數(shù)據(jù)包封裝的操作，中間沒(méi)有任何的 NAT，沒(méi)有任何的 Overlay。

所以它的轉(zhuǎn)發(fā)效率可能是所有方案中最高的，因?yàn)樗陌苯幼咴?TCP/IP 的協(xié)議棧，它的隔離也因?yàn)檫@個(gè)棧而變得好做。

因?yàn)?TCP/IP 的協(xié)議棧提供了一整套的防火墻的規(guī)則，所以它可以通過(guò) IPTABLES 的規(guī)則達(dá)到比較復(fù)雜的隔離邏輯。

Calico 網(wǎng)絡(luò) Node 之間兩種網(wǎng)絡(luò)

IPIP：是把一個(gè) IP 數(shù)據(jù)包放在在一個(gè) IP 包里，即把 IP 層封裝到 IP 層的一個(gè) Tunnel。

它的作用基本上就相當(dāng)于一個(gè)基于 IP 的網(wǎng)橋！一般來(lái)說(shuō)，普通的網(wǎng)橋是基于 Mac 的，根本不需 IP。

而 IPIP 則是通過(guò)兩端的路由做一個(gè) Tunnel，把兩個(gè)本來(lái)不通的網(wǎng)絡(luò)通過(guò)點(diǎn)對(duì)點(diǎn)連接起來(lái)。

BGP：邊界網(wǎng)關(guān)協(xié)議（Border Gateway Protocol, BGP）是互聯(lián)網(wǎng)上一個(gè)核心的去中心化自治路由協(xié)議。

它通過(guò)維護(hù) IP 路由表或‘前綴’表來(lái)實(shí)現(xiàn)自治系統(tǒng)（AS）之間的可達(dá)性，屬于矢量路由協(xié)議。

BGP 不使用傳統(tǒng)的內(nèi)部網(wǎng)關(guān)協(xié)議（IGP）的指標(biāo)，而使用基于路徑、網(wǎng)絡(luò)策略或規(guī)則集來(lái)決定路由。

IPIP 工作模式

①測(cè)試環(huán)境

一個(gè) Msater 節(jié)點(diǎn)，IP 172.171.5.95，一個(gè) Node 節(jié)點(diǎn) IP 172.171.5.96：

創(chuàng)建一個(gè) Daemonset 的應(yīng)用，Pod1 落在 Master 節(jié)點(diǎn)上 IP 地址為 192.168.236.3，Pod2 落在 Node 節(jié)點(diǎn)上 IP 地址為 192.168.190.203：

Pod1 Ping Pod2：

②Ping 包旅程

Pod1 上的路由信息：

根據(jù)路由信息，Ping 192.168.190.203，會(huì)匹配到第一條。第一條路由的意思是：去往任何網(wǎng)段的數(shù)據(jù)包都發(fā)往網(wǎng)管 169.254.1.1，然后從 eth0 網(wǎng)卡發(fā)送出去。

路由表中 Flags 標(biāo)志的含義：

U：UP 表示當(dāng)前為啟動(dòng)狀態(tài)。
H：Host 表示該路由為一個(gè)主機(jī)，多為達(dá)到數(shù)據(jù)包的路由。
G：Gateway 表示該路由是一個(gè)網(wǎng)關(guān)，如果沒(méi)有說(shuō)明目的地是直連的。
D：Dynamicaly 表示該路由是重定向報(bào)文修改。
M：表示該路由已被重定向報(bào)文修改。

Master 節(jié)點(diǎn)上的路由信息：

當(dāng) Ping 包來(lái)到 Master 節(jié)點(diǎn)上，會(huì)匹配到路由 tunl0。該路由的意思是：去往 192.169.190.192/26 的網(wǎng)段的數(shù)據(jù)包都發(fā)往網(wǎng)關(guān) 172.171.5.96。

因?yàn)?Pod1 在 5.95，Pod2 在 5.96。所以數(shù)據(jù)包就通過(guò)該路由發(fā)往到 Node 節(jié)點(diǎn)上。

Node 節(jié)點(diǎn)上路由信息：

當(dāng) Node 節(jié)點(diǎn)網(wǎng)卡收到數(shù)據(jù)包之后，發(fā)現(xiàn)發(fā)往的目的 IP 為 192.168.190.203，于是匹配到紅線的路由（綠線是 Node 結(jié)點(diǎn)對(duì)應(yīng)的發(fā)往 Master 的路由）。

該路由的意思是：192.168.190.203 是本機(jī)直連設(shè)備，去往設(shè)備的數(shù)據(jù)包發(fā)往 caliadce112d250。這個(gè)設(shè)備就是 Pod2 的 Veth Pair 的一端。

在創(chuàng)建 Pod2 時(shí) Calico 會(huì)給 Pod2 創(chuàng)建一個(gè) Veth Pair 設(shè)備。一端是 Pod2 的網(wǎng)卡，另一端就是我們看到的 caliadce112d250。

可以通過(guò)如下方式驗(yàn)證：在 Pod2 中安裝 ethtool 工具，然后使用 ethtool-S eth0，查看 Veth Pair 另一端的設(shè)備號(hào)。

Pod2 網(wǎng)卡另一端的設(shè)備編號(hào)是 18，在 Node 上查看編號(hào)為 18 的網(wǎng)絡(luò)設(shè)備，可以發(fā)現(xiàn)該網(wǎng)絡(luò)設(shè)備就是 caliadce112d250。

所以，Node 上的路由，發(fā)送 caliadce112d250 的數(shù)據(jù)其實(shí)就是發(fā)送到 Pod2 的網(wǎng)卡中。Ping 包的旅行到這里就到了目的地。

查看一下 Pod2 中的路由信息，發(fā)現(xiàn)該路由信息和 Pod1 中是一樣的。

顧名思義，IPIP 網(wǎng)絡(luò)就是將 IP 網(wǎng)絡(luò)封裝在 IP 網(wǎng)絡(luò)里。IPIP 網(wǎng)絡(luò)的特點(diǎn)是所有 Pod 的數(shù)據(jù)流量都從隧道 tunl0 發(fā)送，并且在 tunl0 這增加了一層傳輸層的封包。

在 Master 網(wǎng)卡上抓包分析該過(guò)程：

打開(kāi) ICMP 285，Pod1 Ping Pod2 的數(shù)據(jù)包，能夠看到該數(shù)據(jù)包一共 5 層，其中 IP 所在的網(wǎng)絡(luò)層有兩個(gè)，分別是 Pod 之間的網(wǎng)絡(luò)和主機(jī)之間的網(wǎng)絡(luò)封裝。

根據(jù)數(shù)據(jù)包的封裝順序，應(yīng)該是在 Pod1 Ping Pod2 的 ICMP 包外面多封裝了一層主機(jī)之間的數(shù)據(jù)包。

之所以要這樣做是因?yàn)?tunl0 是一個(gè)隧道端點(diǎn)設(shè)備，在數(shù)據(jù)到達(dá)時(shí)要加上一層封裝，便于跨網(wǎng)段訪問(wèn)。

兩層 IP 封裝的具體內(nèi)容：

IPIP 的連接方式：

BGP 工作模式

①修改配置

在安裝 Calico 網(wǎng)絡(luò)時(shí)，默認(rèn)安裝是 IPIP 網(wǎng)絡(luò)。calico.yaml 文件中，將 CALICO_IPV4POOL_IPIP 的值修改成"off"，就能夠替換成 BGP 網(wǎng)絡(luò)。

②對(duì)比

BGP 網(wǎng)絡(luò)相比較 IPIP 網(wǎng)絡(luò)，最大的不同之處就是沒(méi)有了隧道設(shè)備 tunl0，且不通過(guò)隧道設(shè)備發(fā)送流量。

前面介紹過(guò) IPIP 網(wǎng)絡(luò) Pod 之間的流量發(fā)送 tunl0，然后 tunl0 發(fā)送對(duì)端設(shè)備。BGP 網(wǎng)絡(luò)中，Pod 之間的流量直接從網(wǎng)卡發(fā)送目的地，減少了 tunl0 這個(gè)環(huán)境。

Master 節(jié)點(diǎn)上路由信息。從路由信息來(lái)看，沒(méi)有 tunl0 設(shè)備。

同樣創(chuàng)建一個(gè) Daemonset，Pod1 在 Master 節(jié)點(diǎn)上，Pod2 在 Node 節(jié)點(diǎn)上。

③Ping 包旅程

Pod1 Ping Pod2：

根據(jù) Pod1 中的路由信息，Ping 包通過(guò) eth0 網(wǎng)卡發(fā)送到 Master 節(jié)點(diǎn)上。

Master 節(jié)點(diǎn)上路由信息。根據(jù)匹配到的 192.168.190.192 路由，該路由的意思是：去往網(wǎng)段 192.168.190.192/26 的數(shù)據(jù)包，發(fā)送網(wǎng)段 172.171.5.96。

而 5.96 就是 Node 節(jié)點(diǎn)。所以，該數(shù)據(jù)包直接發(fā)送了 5.96 機(jī)器：

Node 節(jié)點(diǎn)上的路由信息。根據(jù)匹配到的 192.168.190.192 的路由，數(shù)據(jù)將發(fā)送給 cali6fcd7d1702e 設(shè)備，該設(shè)備和上面分析的是一樣，為 Pod2 的 Veth Pair 的一端。數(shù)據(jù)就直接發(fā)送給 Pod2 的網(wǎng)卡。

當(dāng) Pod2 對(duì) Ping 包做出回應(yīng)之后，數(shù)據(jù)到達(dá) Node 節(jié)點(diǎn)上，匹配到 192.168.236.0 的路由。

該路由說(shuō)的是：去往網(wǎng)段 192.168.236.0/26 的數(shù)據(jù)，發(fā)送給網(wǎng)關(guān) 172.171.5.95。數(shù)據(jù)包就直接通過(guò)網(wǎng)卡 ens160，發(fā)送到 Master 節(jié)點(diǎn)上。

通過(guò)在 Master 節(jié)點(diǎn)上抓包，查看經(jīng)過(guò)的流量，篩選出 ICMP，找到 Pod1 Ping Pod2 的數(shù)據(jù)包。

可以看到 BGP 網(wǎng)絡(luò)下，沒(méi)有使用 IPIP 模式，數(shù)據(jù)包是正常的封裝。

值得注意的是 Mac 地址的封裝。192.168.236.0 是 Pod1 的 IP，192.168.190.198 是 Pod2 的 IP。

而源 Mac 地址是 Master 節(jié)點(diǎn)網(wǎng)卡的 Mac，目的 Mac 是 Node 節(jié)點(diǎn)的網(wǎng)卡的 Mac。

這說(shuō)明，在 Master 節(jié)點(diǎn)的路由接收到數(shù)據(jù)，重新構(gòu)建數(shù)據(jù)包時(shí)，使用 ARP 請(qǐng)求，將 Node 節(jié)點(diǎn)的 Mac 拿到，然后封裝到數(shù)據(jù)鏈路層。

BGP 的連接方式如下圖：

網(wǎng)絡(luò)對(duì)比

IPIP 網(wǎng)絡(luò)：

流量：tunlo 設(shè)備封裝數(shù)據(jù)，形成隧道，承載流量。
適用網(wǎng)絡(luò)類型：適用于互相訪問(wèn)的 Pod 不在同一個(gè)網(wǎng)段中，跨網(wǎng)段訪問(wèn)的場(chǎng)景。外層封裝的 IP 能夠解決跨網(wǎng)段的路由問(wèn)題。
效率：流量需要 tunl0 設(shè)備封裝，效率略低。

BGP 網(wǎng)絡(luò)：

流量：使用路由信息導(dǎo)向流量。
適用網(wǎng)絡(luò)類型：適用于互相訪問(wèn)的 Pod 在同一個(gè)網(wǎng)段，跨網(wǎng)段需要上行交換機(jī)或路由器支持。適用于大型網(wǎng)絡(luò)。
效率：原生 HostGW，效率高。

存在問(wèn)題

①租戶隔離問(wèn)題

Calico 的三層方案是直接在 Host 上進(jìn)行路由尋址，那么對(duì)于多租戶如果使用同一個(gè) CIDR 網(wǎng)絡(luò)就面臨著地址沖突的問(wèn)題。

②路由規(guī)模問(wèn)題

通過(guò)路由規(guī)則可以看出，路由規(guī)模和 Pod 分布有關(guān)，如果 Pod 離散分布在 Host 集群中，勢(shì)必會(huì)產(chǎn)生較多的路由項(xiàng)。

③IPtables 規(guī)則規(guī)模問(wèn)題

1 臺(tái) Host 上可能虛擬化十幾或幾十個(gè)容器實(shí)例，過(guò)多的 IPtables 規(guī)則造成復(fù)雜性和不可調(diào)試性，同時(shí)也存在性能損耗。

④跨子網(wǎng)時(shí)的網(wǎng)關(guān)路由問(wèn)題

當(dāng)對(duì)端網(wǎng)絡(luò)不為二層可達(dá)時(shí)，需要通過(guò)三層路由時(shí)，需要網(wǎng)關(guān)支持自定義路由配置，即 Pod 的目的地址為本網(wǎng)段的網(wǎng)關(guān)地址，再由網(wǎng)關(guān)進(jìn)行跨三層轉(zhuǎn)發(fā)。

K8S 網(wǎng)絡(luò)方案對(duì)比

以下對(duì)比為摘錄內(nèi)容：