Kubernetes容器网络及网络模型
1、Docker 網(wǎng)絡(luò)模型
在討論Kubernetes網(wǎng)絡(luò)之前，讓我們先來看一下Docker網(wǎng)絡(luò)。Docker采用插件化的網(wǎng)絡(luò)模式，默認提供bridge、host、none、overlay、maclan和Network plugins這幾種網(wǎng)絡(luò)模式，運行容器時可以通過–network參數(shù)設(shè)置具體使用那一種模式。
- bridge：這是Docker默認的網(wǎng)絡(luò)驅(qū)動，此模式會為每一個容器分配Network Namespace和設(shè)置IP等，并將容器連接到一個虛擬網(wǎng)橋上。如果未指定網(wǎng)絡(luò)驅(qū)動，這默認使用此驅(qū)動。
- host：此網(wǎng)絡(luò)驅(qū)動直接使用宿主機的網(wǎng)絡(luò)。
- none：此驅(qū)動不構(gòu)造網(wǎng)絡(luò)環(huán)境。采用了none 網(wǎng)絡(luò)驅(qū)動，那么就只能使用loopback網(wǎng)絡(luò)設(shè)備，容器只能使用127.0.0.1的本機網(wǎng)絡(luò)。
- overlay：此網(wǎng)絡(luò)驅(qū)動可以使多個Docker daemons連接在一起，并能夠使用swarm服務(wù)之間進行通訊。也可以使用overlay網(wǎng)絡(luò)進行swarm服務(wù)和容器之間、容器之間進行通訊，
- macvlan：此網(wǎng)絡(luò)允許為容器指定一個MAC地址，允許容器作為網(wǎng)絡(luò)中的物理設(shè)備，這樣Docker daemon就可以通過MAC地址進行訪問的路由。對于希望直接連接網(wǎng)絡(luò)網(wǎng)絡(luò)的遺留應(yīng)用，這種網(wǎng)絡(luò)驅(qū)動有時可能是最好的選擇。
- Network plugins：可以安裝和使用第三方的網(wǎng)絡(luò)插件。可以在Docker Store或第三方供應(yīng)商處獲取這些插件。
在默認情況，Docker使用bridge網(wǎng)絡(luò)模式，bridge網(wǎng)絡(luò)驅(qū)動的示意圖如下，此文以bridge模式對Docker的網(wǎng)絡(luò)進行說明。
[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-LTAOHZ8u-1637238702941)(/home/westone/桌面/20190909-01.jpeg)]
1.1 bridge網(wǎng)絡(luò)的構(gòu)建過程
1）安裝Docker時，創(chuàng)建一個名為docke0的虛擬網(wǎng)橋，虛擬網(wǎng)橋使用“10.0.0.0 -10.255.255.255 “、”172.16.0.0-172.31.255.255″和“192.168.0.0——192.168.255.255”這三個私有網(wǎng)絡(luò)的地址范圍。
通過 ifconfig 命令可以查看docker0網(wǎng)橋的信息：
通過 docker network inspect bridge 可以查看網(wǎng)橋的子網(wǎng)網(wǎng)絡(luò)范圍和網(wǎng)關(guān)：
2）運行容器時，在宿主機上創(chuàng)建虛擬網(wǎng)卡veth pair設(shè)備，veth pair設(shè)備是成對出現(xiàn)的，從而組成一個數(shù)據(jù)通道，數(shù)據(jù)從一個設(shè)備進入，就會從另一個設(shè)備出來。將veth pair設(shè)備的一端放在新創(chuàng)建的容器中，命名為eth0；另一端放在宿主機的docker0中，以veth為前綴的名字命名。通過 brctl show 命令查看放在docker0中的veth pair設(shè)備
1.2 外部訪問
bridge的docker0是虛擬出來的網(wǎng)橋，因此無法被外部的網(wǎng)絡(luò)訪問。因此需要在運行容器時通過-p和-P參數(shù)對將容器的端口映射到宿主機的端口。實際上Docker是采用 NAT的 方式，將容器內(nèi)部的服務(wù)監(jiān)聽端口與宿主機的某一個端口port 進行綁定，使得宿主機外部可以將網(wǎng)絡(luò)報文發(fā)送至容器。
1）通過-P參數(shù)，將容器的端口映射到宿主機的隨機端口：
2）通過-p參數(shù)，將容器的端口映射到宿主機的制定端口：
$ docker run -p {hostPort}:{containerPort} {images}2、K8S容器網(wǎng)絡(luò)
Kubernetes與Docker網(wǎng)絡(luò)有些不同。Kubernetes網(wǎng)絡(luò)需要解決下面的4個問題：
- 集群內(nèi)：
- 容器與容器之間的通信
- Pod和Pod之間的通信
- Pod和服務(wù)之間的通信
- 集群外：
- 外部應(yīng)用與服務(wù)之間的通信
因此，Kubernetes假設(shè)Pod之間能夠進行通訊，這些Pod可能部署在不同的宿主機上。每一個Pod都擁有自己的IP地址，因此能夠?qū)od看作為物理主機或者虛擬機，從而能實現(xiàn)端口設(shè)置、命名、服務(wù)發(fā)現(xiàn)、負載均衡、應(yīng)用配置和遷移。為了滿足上述需求，則需要通過集群網(wǎng)絡(luò)來實現(xiàn)。
2.1 同一個Pod中容器之間的通信 – localhost
這種場景對于Kubernetes來說沒有任何問題，根據(jù)Kubernetes的架構(gòu)設(shè)計。Kubernetes創(chuàng)建Pod時，首先會創(chuàng)建一個pause容器，為Pod指派一個唯一的IP地址。然后，以pause的網(wǎng)絡(luò)命名空間為基礎(chǔ)，創(chuàng)建同一個Pod內(nèi)的其它容器（–net=container:xxx）。因此，同一個Pod內(nèi)的所有容器就會共享同一個網(wǎng)絡(luò)命名空間，在同一個Pod之間的容器可以直接使用localhost進行通信。
2.2 單機不同Pod中容器之間的通信 – Veth Pair 設(shè)備 + 宿主機網(wǎng)橋
一個隔離的容器進程，該如何跟其他 Network Namespace 里的容器進程進行交互呢？
被限制在 Network Namespace 里的容器進程，實際上是通過 Veth Pair 設(shè)備 + 宿主機網(wǎng)橋的方式，實現(xiàn)了跟同其他容器的數(shù)據(jù)交換。
-
Docker 項目會默認在宿主機上創(chuàng)建一個名叫 docker0 的網(wǎng)橋，凡是連接在 docker0 網(wǎng)橋上的容器，就可以通過它來進行通信。
-
可是，我們又該如何把這些容器“連接”到 docker0 網(wǎng)橋上呢？這時候，我們就需要使用一種名叫 Veth Pair 的虛擬設(shè)備了。Veth Pair 設(shè)備的特點是：它被創(chuàng)建出來后，總是以兩張?zhí)摂M網(wǎng)卡（Veth Peer）的形式成對出現(xiàn)的。并且，從其中一個“網(wǎng)卡”發(fā)出的數(shù)據(jù)包，可以直接出現(xiàn)在與它對應(yīng)的另一張“網(wǎng)卡”上，哪怕這兩個“網(wǎng)卡”在不同的 Network Namespace 里。這就使得 Veth Pair 常常被用作連接不同 Network Namespace 的“網(wǎng)線”。
當你遇到容器連不通“外網(wǎng)”的時候，你都應(yīng)該先試試 docker0 網(wǎng)橋能不能 ping 通，然后查看一下跟 docker0 和 Veth Pair 設(shè)備相關(guān)的 iptables 規(guī)則是不是有異常，往往就能夠找到問題的答案了。
2.3 集群容器網(wǎng)絡(luò)–Overlay Network
萬變不離其宗。如果我們通過軟件的方式，創(chuàng)建一個整個集群“公用”的網(wǎng)橋，然后把集群里的所有容器都連接到這個網(wǎng)橋上，不就可以相互通信了嗎？
- 當 Node 1 上的 Container 1 要訪問 Node 2 上的 Container 3 的時候，Node 1 上的“特殊網(wǎng)橋”在收到數(shù)據(jù)包之后，能夠通過某種方式，把數(shù)據(jù)包發(fā)送到正確的宿主機
- 而 Node 2 上的“特殊網(wǎng)橋”在收到數(shù)據(jù)包后，也能夠通過某種方式，把數(shù)據(jù)包轉(zhuǎn)發(fā)給正確的容器，比如 Container 3。
在Kubernetes通過flannel、calic等網(wǎng)絡(luò)插件解決Pod間的通信問題。本文以flannel為例說明在Kubernetes中網(wǎng)絡(luò)模型，flannel是kubernetes默認提供網(wǎng)絡(luò)插件。Flannel是由CoreOS團隊開發(fā)社交的網(wǎng)絡(luò)工具，CoreOS團隊采用L3 Overlay模式設(shè)計flannel， 規(guī)定宿主機下各個Pod屬于同一個子網(wǎng)，不同宿主機下的Pod屬于不同的子網(wǎng)。
flannel會在每一個宿主機上運行名為flanneld代理，其負責為宿主機預(yù)先分配一個子網(wǎng)，并為Pod分配IP地址。Flannel使用Kubernetes或etcd來存儲網(wǎng)絡(luò)配置、分配的子網(wǎng)和主機公共IP等信息。數(shù)據(jù)包則通過VXLAN、UDP或host-gw這些類型的后端機制進行轉(zhuǎn)發(fā)。
2.4 Flannel 網(wǎng)絡(luò)組件
2.4.1 Flannel host-gw
hostgw是最簡單的backend，它的原理非常簡單，直接添加路由，將目的主機當做網(wǎng)關(guān)，直接路由原始封包。
例如，我們從etcd中監(jiān)聽到一個EventAdded事件subnet為10.1.15.0/24被分配給主機Public IP 192.168.0.100，hostgw要做的工作就是在本主機上添加一條目的地址為10.1.15.0/24，網(wǎng)關(guān)地址為192.168.0.100，輸出設(shè)備為上文中選擇的集群間交互的網(wǎng)卡即可。
優(yōu)點：簡單，直接，效率高
缺點：要求所有的pod都在一個子網(wǎng)中，如果跨網(wǎng)段就無法通信。
2.4.2 Flannel UDP
接下來我們講一下UDP模式。
2.4.2.1 網(wǎng)絡(luò)拓撲
- 宿主機 Node 1 上有一個容器 container-1，它的 IP 地址是 100.96.1.2，對應(yīng)的 docker0 網(wǎng)橋的地址是：100.96.1.1/24。
- 宿主機 Node 2 上有一個容器 container-2，它的 IP 地址是 100.96.2.3，對應(yīng)的 docker0 網(wǎng)橋的地址是：100.96.2.1/24。
我們現(xiàn)在的任務(wù)，就是讓 container-1 訪問 container-2。
2.4.2.2 報文發(fā)送流程
- container-1 容器里的進程發(fā)起的 IP 包，其源地址就是 100.96.1.2，目的地址就是 100.96.2.3。由于目的地址 100.96.2.3 并不在 Node 1 的 docker0 網(wǎng)橋的網(wǎng)段里，所以這個 IP 包會被交給默認路由規(guī)則
- Flannel 已經(jīng)在宿主機上創(chuàng)建出了一系列的路由規(guī)則
- 可以看到，由于我們的 IP 包的目的地址是 100.96.2.3，它匹配不到本機 docker0 網(wǎng)橋?qū)?yīng)的 100.96.1.0/24 網(wǎng)段，只能匹配到第二條、也就是 100.96.0.0/16 對應(yīng)的這條路由規(guī)則，從而進入到一個叫作 flannel0 的設(shè)備中。
- 而這個 flannel0 設(shè)備的類型就比較有意思了：它是一個 TUN 設(shè)備（Tunnel 設(shè)備）。在 Linux 中，TUN 設(shè)備是一種工作在三層（Network Layer）的虛擬網(wǎng)絡(luò)設(shè)備。TUN 設(shè)備的功能非常簡單，即：在操作系統(tǒng)內(nèi)核和用戶應(yīng)用程序之間傳遞 IP 包。
- 以 flannel0 設(shè)備為例：像上面提到的情況，當操作系統(tǒng)將一個 IP 包發(fā)送給 flannel0 設(shè)備之后，flannel0 就會把這個 IP 包，交給創(chuàng)建這個設(shè)備的應(yīng)用程序，也就是 Flannel 進程。這是一個從內(nèi)核態(tài)（Linux 操作系統(tǒng)）向用戶態(tài)（Flannel 進程–flanneld）的流動方向。
- flanneld 進程在處理由 flannel0 傳入的 IP 包時，就可以根據(jù)目的 IP 的地址（比如 100.96.2.3），匹配到對應(yīng)的子網(wǎng)（比如 100.96.2.0/24），從 Etcd 中找到這個子網(wǎng)對應(yīng)的宿主機的 IP 地址是 10.168.0.3
- flanneld 在收到 container-1 發(fā)給 container-2 的 IP 包之后，就會把這個 IP 包直接封裝在一個 UDP 包里，然后發(fā)送給 Node 2。不難理解，這個 UDP 包的源地址，就是 flanneld 所在的 Node 1 的地址，而目的地址，則是 container-2 所在的宿主機 Node 2 的地址。
- 這個請求得以完成的原因是，每臺宿主機上的 flanneld，都監(jiān)聽著一個 8285 端口，所以 flanneld 只要把 UDP 包發(fā)往 Node 2 的 8285 端口即可。
2.4.2.3 報文接收流程
- Node 2 上監(jiān)聽 8285 端口的進程也是 flanneld，所以這時候，flanneld 就可以從這個 UDP 包里解析出封裝在里面的、container-1 發(fā)來的原 IP 包。而接下來 flanneld 的工作就非常簡單了：flanneld 會直接把這個 IP 包發(fā)送給它所管理的 TUN 設(shè)備，即 flannel0 設(shè)備。
- TUN 設(shè)備的原理是一個從用戶態(tài)向內(nèi)核態(tài)的流動方向（Flannel 進程向 TUN 設(shè)備發(fā)送數(shù)據(jù)包），所以 Linux 內(nèi)核網(wǎng)絡(luò)棧就會負責處理這個 IP 包，具體的處理方法，就是通過本機的路由表來尋找這個 IP 包的下一步流向。
- 由于這個 IP 包的目的地址是 100.96.2.3，它跟第三條、也就是 100.96.2.0/24 網(wǎng)段對應(yīng)的路由規(guī)則匹配更加精確。所以，Linux 內(nèi)核就會按照這條路由規(guī)則，把這個 IP 包轉(zhuǎn)發(fā)給 docker0 網(wǎng)橋。
- docker0 網(wǎng)橋會扮演二層交換機的角色，將數(shù)據(jù)包發(fā)送給正確的端口，進而通過 Veth Pair 設(shè)備進入到 container-2 的 Network Namespace 里。
優(yōu)點：Pod能夠跨網(wǎng)段訪問
缺點：隔離性不夠，udp不能隔離兩個網(wǎng)段。
2.4.3 Flannel Vxlan
2.4.3.1 Flannel UDP的性能問題
Flannel UDP 模式有嚴重的性能問題，我們看一下Flannel UDP報文的流程：
- 第一次，用戶態(tài)的容器進程發(fā)出的 IP 包經(jīng)過 docker0 網(wǎng)橋進入內(nèi)核態(tài)；
- 第二次，IP 包根據(jù)路由表進入 TUN（flannel0）設(shè)備，從而回到用戶態(tài)的 flanneld 進程；
- 第三次，flanneld 進行 UDP 封包之后重新進入內(nèi)核態(tài)，將 UDP 包通過宿主機的 eth0 發(fā)出去。
在 Linux 操作系統(tǒng)中，上述這些用戶態(tài)和內(nèi)核態(tài)的切換，性能是非常低的。
2.4.3.2 Flannel VXLAN的改進方案
VXLAN，即 Virtual Extensible LAN（虛擬可擴展局域網(wǎng)），是 Linux 內(nèi)核本身就支持的一種網(wǎng)絡(luò)虛似化技術(shù)。
VXLAN 可以完全在內(nèi)核態(tài)實現(xiàn)上述封裝和解封裝。省去了一次上下文切換，提升了性能。
當初始化集群里，vxlan網(wǎng)絡(luò)的初始化工作：
主機B加入flannel網(wǎng)絡(luò)時,它會將自己的三個信息寫入etcd中，分別是：subnet 10.1.16.0/24、Public IP 192.168.0.101、vtep設(shè)備flannel.1的mac地址 MAC B。之后，主機A會得到EventAdded事件，并從中獲取上文中B添加至etcd的各種信息。這個時候，它會在本機上添加三條信息：
路由信息：所有通往目的地址10.1.16.0/24的封包都通過vtep設(shè)備flannel.1設(shè)備發(fā)出，發(fā)往的網(wǎng)關(guān)地址為10.1.16.0，即主機B中的flannel.1設(shè)備。
fdb信息：MAC地址為MAC B的封包，都將通過vxlan發(fā)往目的地址192.168.0.101，即主機B
3）arp信息：網(wǎng)關(guān)地址10.1.16.0的地址為MAC B
事實上，flannel只使用了vxlan的部分功能，由于VNI被固定為1，本質(zhì)上工作方式和udp backend是類似的，區(qū)別無非是將udp的proxy換成了內(nèi)核中的vxlan處理模塊。而原始負載由三層擴展到了二層，但是這對三層網(wǎng)絡(luò)方案flannel是沒有意義的，這么做也僅僅只是為了適配vxlan的模型。vxlan詳細的原理參見文后的參考文獻，其中的分析更為具體，也更易理解。
VXLAN 會在宿主機上設(shè)置一個特殊的網(wǎng)絡(luò)設(shè)備作為“隧道”的兩端。這個設(shè)備就叫作 VTEP，即：VXLAN Tunnel End Point（虛擬隧道端點）。
而 VTEP 設(shè)備的作用，其實跟前面的 flanneld 進程非常相似。只不過，它進行封裝和解封裝的對象，是二層數(shù)據(jù)幀（Ethernet frame）；而且這個工作的執(zhí)行流程，全部是在內(nèi)核里完成的（VXLAN 本身就是 Linux 內(nèi)核中的一個模塊）。
2.4.3.3 報文發(fā)送流程
- 我們的 container-1 的 IP 地址是 10.1.15.2，要訪問的 container-2 的 IP 地址是 10.1.16.3。
- 當 container-1 發(fā)出請求之后，這個目的地址是 10.1.16.3 的 IP 包，會先出現(xiàn)在 docker0 網(wǎng)橋。
- 然后被路由到本機 flannel.1 設(shè)備進行處理。也就是說，來到了“隧道”的入口
- 為了能夠?qū)ⅰ霸?IP 包”封裝并且發(fā)送到正確的宿主機，VXLAN 就需要找到這條“隧道”的出口，即：目的宿主機的 VTEP 設(shè)備。而這個設(shè)備的信息，正是每臺宿主機上的 flanneld 進程負責維護的
- flanneld 就會添加一條如下所示的路由規(guī)則：
- 凡是發(fā)往 10.1.16.0/24 網(wǎng)段的 IP 包，都需要經(jīng)過 flannel.1 設(shè)備發(fā)出，并且，它最后被發(fā)往的網(wǎng)關(guān)地址是：10.1.16.0。10.1.16.0 正是 Node 2 上的 VTEP 設(shè)備（也就是 flannel.1 設(shè)備）的 IP 地址。
- 這些 VTEP 設(shè)備之間，就需要想辦法組成一個虛擬的二層網(wǎng)絡(luò)，即：通過二層數(shù)據(jù)幀進行通信。在我們的例子中，“源 VTEP 設(shè)備”收到“原始 IP 包”后，就要想辦法把“原始 IP 包”加上一個目的 MAC 地址，封裝成一個二層數(shù)據(jù)幀，然后發(fā)送給“目的 VTEP 設(shè)備”。
- 根據(jù)前面的路由記錄，我們已經(jīng)知道了“目的 VTEP 設(shè)備”的 IP 地址。而要根據(jù)三層 IP 地址查詢對應(yīng)的二層 MAC 地址，這正是 ARP（Address Resolution Protocol ）表的功能。
- ARP 記錄，也是 flanneld 進程在 Node 2 節(jié)點啟動時，自動添加在 Node 1 上的。
- 然后，Linux 內(nèi)核會把這個數(shù)據(jù)幀封裝進一個 UDP 包里發(fā)出去。
2.4.3.4 報文接收流程
- Node 1 上的 flannel.1 設(shè)備就可以把這個數(shù)據(jù)幀從 Node 1 的 eth0 網(wǎng)卡發(fā)出去。這個幀會經(jīng)過宿主機網(wǎng)絡(luò)來到 Node 2 的 eth0 網(wǎng)卡。
- Node 2 的內(nèi)核網(wǎng)絡(luò)棧會發(fā)現(xiàn)這個數(shù)據(jù)幀里有 VXLAN Header，并且 VNI=1。所以 Linux 內(nèi)核會對它進行拆包，拿到里面的內(nèi)部數(shù)據(jù)幀，然后根據(jù) VNI 的值，把它交給 Node 2 上的 flannel.1 設(shè)備。
- flannel.1 設(shè)備則會進一步拆包，取出“原始 IP 包”。
- 接下來就回到單機容器網(wǎng)絡(luò)的處理流程。最終，IP 包就進入到了 container-2 容器的 Network Namespace 里。
總的來說，flannel更像是經(jīng)典的橋接模式的擴展。我們知道，在橋接模式中，每臺主機的容器都將使用一個默認的網(wǎng)段，容器與容器之間，主機與容器之間都能互相通信。要是，我們能手動配置每臺主機的網(wǎng)段，使它們互不沖突。接著再想點辦法，將目的地址為非本機容器的流量送到相應(yīng)主機：如果集群的主機都在一個子網(wǎng)內(nèi)，就搞一條路由轉(zhuǎn)發(fā)過去；若是不在一個子網(wǎng)內(nèi)，就搞一條隧道轉(zhuǎn)發(fā)過去。這樣以來，容器的跨網(wǎng)絡(luò)通信問題就解決了。而flannel做的，其實就是將這些工作自動化了而已。
存在的問題：
1.不支持pod之間的網(wǎng)絡(luò)隔離。Flannel設(shè)計思想是將所有的pod都放在一個大的二層網(wǎng)絡(luò)中，所以pod之間沒有隔離策略。
2.設(shè)備復(fù)雜，效率不高。Flannel模型下有三種設(shè)備，數(shù)量經(jīng)過多種設(shè)備的封裝、解析，勢必會造成傳輸效率的下降。
3、Kubernetes網(wǎng)絡(luò)模型與CNI網(wǎng)絡(luò)插件
3.1 網(wǎng)絡(luò)插件
對于K8S來說，Flannel其實就是一個網(wǎng)絡(luò)插件。
我們看到，用戶的容器都連接在 docker0 網(wǎng)橋上。而網(wǎng)絡(luò)插件則在宿主機上創(chuàng)建了一個特殊的設(shè)備（UDP 模式創(chuàng)建的是 TUN 設(shè)備，VXLAN 模式創(chuàng)建的則是 VTEP 設(shè)備），docker0 與這個設(shè)備之間，通過 IP 轉(zhuǎn)發(fā)（路由表）進行協(xié)作。
網(wǎng)絡(luò)插件要做的事情，就是通過某種方法，把不同宿主機上的特殊設(shè)備連通，從而達到容器跨主機通信的目的。
3.2 CNI接口
Kubernetes 是通過一個叫作 CNI 的接口，維護了一個單獨的網(wǎng)橋來代替 docker0。這個網(wǎng)橋的名字就叫作：CNI 網(wǎng)橋，它在宿主機上的設(shè)備名稱默認是：cni0。
需要注意的是，CNI 網(wǎng)橋只是接管所有 CNI 插件負責的、即 Kubernetes 創(chuàng)建的容器（Pod）。而此時，如果你用 docker run 單獨啟動一個容器，那么 Docker 項目還是會把這個容器連接到 docker0 網(wǎng)橋上。
3.3 k8s網(wǎng)絡(luò)模型
了解了 Kubernetes 中 CNI 網(wǎng)絡(luò)的實現(xiàn)原理后，你其實就很容易理解所謂的“Kubernetes 網(wǎng)絡(luò)模型”了：
-
所有容器都可以直接使用 IP 地址與其他容器通信，而無需使用 NAT。
-
所有宿主機都可以直接使用 IP 地址與所有容器通信，而無需使用 NAT。反之亦然。
-
容器自己“看到”的自己的 IP 地址，和別人（宿主機或者容器）看到的地址是完全一樣的。
參考鏈接： 1. https://blog.csdn.net/gengzhikui1992/article/details/114707765
? 2.https://www.cnblogs.com/ssgeek/p/11492150.html#24-%E6%95%B0%E6%8D%AE%E4%BC%A0%E9%80%92%E8%BF%87%E7%A8%8B
? 3. https://www.cnblogs.com/goldsunshine/p/10740928.html
總結(jié)
以上是生活随笔為你收集整理的Kubernetes容器网络及网络模型的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 如何优化Golang中重复的错误处理
- 下一篇： Kubernetes 中创建 Pod 时