深入理解Kubernetes容器网络
在Kubernetes中要保證容器之間網(wǎng)絡(luò)互通，網(wǎng)絡(luò)至關(guān)重要。而Kubernetes本身并沒有自己實(shí)現(xiàn)容器網(wǎng)絡(luò)，而是通過插件化的方式自由接入進(jìn)來。在容器網(wǎng)絡(luò)接入進(jìn)來需要滿足如下基本原則：
Pod無論運(yùn)行在任何節(jié)點(diǎn)都可以互相直接通信，而不需要借助NAT地址轉(zhuǎn)換實(shí)現(xiàn)。
Node與Pod可以互相通信，在不限制的前提下，Pod可以訪問任意網(wǎng)絡(luò)。
Pod擁有獨(dú)立的網(wǎng)絡(luò)棧，Pod看到自己的地址和外部看見的地址應(yīng)該是一樣的，并且同個(gè)Pod內(nèi)所有的容器共享同個(gè)網(wǎng)絡(luò)棧。
容器網(wǎng)絡(luò)基礎(chǔ)
一個(gè)Linux容器的網(wǎng)絡(luò)棧是被隔離在它自己的Network Namespace中，Network Namespace包括了：網(wǎng)卡（Network Interface），回環(huán)設(shè)備（Lookback Device），路由表（Routing Table）和iptables規(guī)則，對于服務(wù)進(jìn)程來講這些就構(gòu)建了它發(fā)起請求和相應(yīng)的基本環(huán)境。而要實(shí)現(xiàn)一個(gè)容器網(wǎng)絡(luò)，離不開以下Linux網(wǎng)絡(luò)功能：
網(wǎng)絡(luò)命名空間：將獨(dú)立的網(wǎng)絡(luò)協(xié)議棧隔離到不同的命令空間中，彼此間無法通信
Veth Pair：Veth設(shè)備對的引入是為了實(shí)現(xiàn)在不同網(wǎng)絡(luò)命名空間的通信，總是以兩張?zhí)摂M網(wǎng)卡（veth peer）的形式成對出現(xiàn)的。并且，從其中一端發(fā)出的數(shù)據(jù)，總是能在另外一端收到
Iptables/Netfilter：Netfilter負(fù)責(zé)在內(nèi)核中執(zhí)行各種掛接的規(guī)則（過濾、修改、丟棄等），運(yùn)行在內(nèi)核中；Iptables模式是在用戶模式下運(yùn)行的進(jìn)程，負(fù)責(zé)協(xié)助維護(hù)內(nèi)核中Netfilter的各種規(guī)則表；通過二者的配合來實(shí)現(xiàn)整個(gè)Linux網(wǎng)絡(luò)協(xié)議棧中靈活的數(shù)據(jù)包處理機(jī)制
網(wǎng)橋：網(wǎng)橋是一個(gè)二層網(wǎng)絡(luò)虛擬設(shè)備，類似交換機(jī)，主要功能是通過學(xué)習(xí)而來的Mac地址將數(shù)據(jù)幀轉(zhuǎn)發(fā)到網(wǎng)橋的不同端口上
路由: Linux系統(tǒng)包含一個(gè)完整的路由功能，當(dāng)IP層在處理數(shù)據(jù)發(fā)送或轉(zhuǎn)發(fā)的時(shí)候，會使用路由表來決定發(fā)往哪里
基于以上的基礎(chǔ)，同宿主機(jī)的容器時(shí)間如何通信呢？
我們可以簡單把他們理解成兩臺主機(jī)，主機(jī)之間通過網(wǎng)線連接起來，如果要多臺主機(jī)通信，我們通過交換機(jī)就可以實(shí)現(xiàn)彼此互通，在Linux中，我們可以通過網(wǎng)橋來轉(zhuǎn)發(fā)數(shù)據(jù)。
在容器中，以上的實(shí)現(xiàn)是通過docker0網(wǎng)橋，凡是連接到docker0的容器，就可以通過它來進(jìn)行通信。要想容器能夠連接到docker0網(wǎng)橋，我們也需要類似網(wǎng)線的虛擬設(shè)備Veth Pair來把容器連接到網(wǎng)橋上。
我們啟動一個(gè)容器：
docker?run?-d?--name?c1?hub.pri.ibanyu.com/devops/alpine:v3.8?/bin/sh然后查看網(wǎng)卡設(shè)備：
docker?exec?-it?c1??/bin/sh /?#?ifconfig eth0??????Link?encap:Ethernet??HWaddr?02:42:AC:11:00:02inet?addr:172.17.0.2??Bcast:172.17.255.255??Mask:255.255.0.0UP?BROADCAST?RUNNING?MULTICAST??MTU:1500??Metric:1RX?packets:14?errors:0?dropped:0?overruns:0?frame:0TX?packets:0?errors:0?dropped:0?overruns:0?carrier:0collisions:0?txqueuelen:0RX?bytes:1172?(1.1?KiB)??TX?bytes:0?(0.0?B)lo????????Link?encap:Local?Loopbackinet?addr:127.0.0.1??Mask:255.0.0.0UP?LOOPBACK?RUNNING??MTU:65536??Metric:1RX?packets:0?errors:0?dropped:0?overruns:0?frame:0TX?packets:0?errors:0?dropped:0?overruns:0?carrier:0collisions:0?txqueuelen:1000RX?bytes:0?(0.0?B)??TX?bytes:0?(0.0?B)/?#?route?-n Kernel?IP?routing?table Destination?????Gateway?????????Genmask?????????Flags?Metric?Ref????Use?Iface 0.0.0.0?????????172.17.0.1??????0.0.0.0?????????UG????0??????0????????0?eth0 172.17.0.0??????0.0.0.0?????????255.255.0.0?????U?????0??????0????????0?eth0可以看到其中有一張eth0的網(wǎng)卡，它就是veth peer其中的一端的虛擬網(wǎng)卡。然后通過route -n 查看容器中的路由表，eth0也正是默認(rèn)路由出口。所有對172.17.0.0/16網(wǎng)段的請求都會從eth0出去。
我們再來看Veth peer的另一端，我們查看宿主機(jī)的網(wǎng)絡(luò)設(shè)備：
ifconfig docker0:?flags=4163<UP,BROADCAST,RUNNING,MULTICAST>??mtu?1500inet?172.17.0.1??netmask?255.255.0.0??broadcast?172.17.255.255inet6?fe80::42:6aff:fe46:93d2??prefixlen?64??scopeid?0x20<link>ether?02:42:6a:46:93:d2??txqueuelen?0??(Ethernet)RX?packets?0??bytes?0?(0.0?B)RX?errors?0??dropped?0??overruns?0??frame?0TX?packets?8??bytes?656?(656.0?B)TX?errors?0??dropped?0?overruns?0??carrier?0??collisions?0eth0:?flags=4163<UP,BROADCAST,RUNNING,MULTICAST>??mtu?1500inet?10.100.0.2??netmask?255.255.255.0??broadcast?10.100.0.255inet6?fe80::5400:2ff:fea3:4b44??prefixlen?64??scopeid?0x20<link>ether?56:00:02:a3:4b:44??txqueuelen?1000??(Ethernet)RX?packets?7788093??bytes?9899954680?(9.2?GiB)RX?errors?0??dropped?0??overruns?0??frame?0TX?packets?5512037??bytes?9512685850?(8.8?GiB)TX?errors?0??dropped?0?overruns?0??carrier?0??collisions?0lo:?flags=73<UP,LOOPBACK,RUNNING>??mtu?65536inet?127.0.0.1??netmask?255.0.0.0inet6?::1??prefixlen?128??scopeid?0x10<host>loop??txqueuelen?1000??(Local?Loopback)RX?packets?32??bytes?2592?(2.5?KiB)RX?errors?0??dropped?0??overruns?0??frame?0TX?packets?32??bytes?2592?(2.5?KiB)TX?errors?0??dropped?0?overruns?0??carrier?0??collisions?0veth20b3dac:?flags=4163<UP,BROADCAST,RUNNING,MULTICAST>??mtu?1500inet6?fe80::30e2:9cff:fe45:329??prefixlen?64??scopeid?0x20<link>ether?32:e2:9c:45:03:29??txqueuelen?0??(Ethernet)RX?packets?0??bytes?0?(0.0?B)RX?errors?0??dropped?0??overruns?0??frame?0TX?packets?8??bytes?656?(656.0?B)TX?errors?0??dropped?0?overruns?0??carrier?0??collisions?0我們可以看到，容器對應(yīng)的Veth peer另一端是宿主機(jī)上的一塊虛擬網(wǎng)卡叫veth20b3dac，并且可以通過brctl查看網(wǎng)橋信息看到這張網(wǎng)卡是在docker0上。
#?brctl?show docker0??8000.02426a4693d2?no??veth20b3dac然后我們再啟動一個(gè)容器，從第一個(gè)容器是否能ping通第二個(gè)容器。
docker?run?-d?--name?c2?-it?hub.pri.ibanyu.com/devops/alpine:v3.8?/bin/shdocker?exec?-it?c1?/bin/sh /?#?ping?172.17.0.3 PING?172.17.0.3?(172.17.0.3):?56?data?bytes 64?bytes?from?172.17.0.3:?seq=0?ttl=64?time=0.291?ms 64?bytes?from?172.17.0.3:?seq=1?ttl=64?time=0.129?ms 64?bytes?from?172.17.0.3:?seq=2?ttl=64?time=0.142?ms 64?bytes?from?172.17.0.3:?seq=3?ttl=64?time=0.169?ms 64?bytes?from?172.17.0.3:?seq=4?ttl=64?time=0.194?ms ^C ---?172.17.0.3?ping?statistics?--- 5?packets?transmitted,?5?packets?received,?0%?packet?loss round-trip?min/avg/max?=?0.129/0.185/0.291?ms可以看到，能夠ping通，其原理就是我們ping目標(biāo)IP172.17.0.3時(shí)，會匹配到我們的路由表第二條規(guī)則，網(wǎng)關(guān)為0.0.0.0，這就意味著是一條直連路由，通過二層轉(zhuǎn)發(fā)到目的地。要通過二層網(wǎng)絡(luò)到達(dá)172.17.0.3，我們需要知道它的Mac地址，此時(shí)就需要第一個(gè)容器發(fā)送一個(gè)ARP廣播，來通過IP地址查找Mac。此時(shí)Veth peer另外一段是docker0網(wǎng)橋，它會廣播到所有連接它的veth peer虛擬網(wǎng)卡去，然后正確的虛擬網(wǎng)卡收到后會響應(yīng)這個(gè)ARP報(bào)文，然后網(wǎng)橋再回給第一個(gè)容器。
以上就是同宿主機(jī)不同容器通過docker0通信，如下圖所示：
默認(rèn)情況下，通過network namespace限制的容器進(jìn)程，本質(zhì)上是通過Veth peer設(shè)備和宿主機(jī)網(wǎng)橋的方式，實(shí)現(xiàn)了不同network namespace的數(shù)據(jù)交換。
與之類似地，當(dāng)你在一臺宿主機(jī)上，訪問該宿主機(jī)上的容器的IP地址時(shí)，這個(gè)請求的數(shù)據(jù)包，也是先根據(jù)路由規(guī)則到達(dá)docker0網(wǎng)橋，然后被轉(zhuǎn)發(fā)到對應(yīng)的Veth Pair設(shè)備，最后出現(xiàn)在容器里。
跨主機(jī)網(wǎng)絡(luò)通信
在Docker的默認(rèn)配置下，不同宿主機(jī)上的容器通過IP地址進(jìn)行互相訪問是根本做不到的。為了解決這個(gè)問題，社區(qū)中出現(xiàn)了很多網(wǎng)絡(luò)方案。同時(shí)Kubernetes為了更好的控制網(wǎng)絡(luò)的接入，推出了CNI即容器網(wǎng)絡(luò)的API接口。它是Kubernetes中標(biāo)準(zhǔn)的一個(gè)調(diào)用網(wǎng)絡(luò)實(shí)現(xiàn)的接口，kubelet通過這個(gè)API來調(diào)用不同的網(wǎng)絡(luò)插件以實(shí)現(xiàn)不同的網(wǎng)絡(luò)配置，實(shí)現(xiàn)了這個(gè)接口的就是CNI插件，它實(shí)現(xiàn)了一系列的CNI API接口。目前已經(jīng)有的包括Flannel、Calico、Weave、Contiv等等。
實(shí)際上CNI的容器網(wǎng)絡(luò)通信流程跟前面的基礎(chǔ)網(wǎng)絡(luò)一樣，只是CNI維護(hù)了一個(gè)單獨(dú)的網(wǎng)橋來代替 docker0。這個(gè)網(wǎng)橋的名字就叫作：CNI 網(wǎng)橋，它在宿主機(jī)上的設(shè)備名稱默認(rèn)是：cni0。cni的設(shè)計(jì)思想，就是：Kubernetes在啟動Infra容器之后，就可以直接調(diào)用CNI網(wǎng)絡(luò)插件，為這個(gè)Infra容器的Network Namespace，配置符合預(yù)期的網(wǎng)絡(luò)棧。
CNI插件三種網(wǎng)絡(luò)實(shí)現(xiàn)模式：
Overlay模式是基于隧道技術(shù)實(shí)現(xiàn)的，整個(gè)容器網(wǎng)絡(luò)和主機(jī)網(wǎng)絡(luò)獨(dú)立，容器之間跨主機(jī)通信時(shí)將整個(gè)容器網(wǎng)絡(luò)封裝到底層網(wǎng)絡(luò)中，然后到達(dá)目標(biāo)機(jī)器后再解封裝傳遞到目標(biāo)容器。不依賴與底層網(wǎng)絡(luò)的實(shí)現(xiàn)。實(shí)現(xiàn)的插件有Flannel（UDP、vxlan）、Calico（IPIP）等等
三層路由模式中容器和主機(jī)也屬于不通的網(wǎng)段，他們?nèi)萜骰ネㄖ饕腔诼酚杀泶蛲?#xff0c;無需在主機(jī)之間建立隧道封包。但是限制條件必須依賴大二層同個(gè)局域網(wǎng)內(nèi)。實(shí)現(xiàn)的插件有Flannel（host-gw）、Calico（BGP）等等
Underlay網(wǎng)絡(luò)是底層網(wǎng)絡(luò)，負(fù)責(zé)互聯(lián)互通。容器網(wǎng)絡(luò)和主機(jī)網(wǎng)絡(luò)依然分屬不同的網(wǎng)段，但是彼此處于同一層網(wǎng)絡(luò)，處于相同的地位。整個(gè)網(wǎng)絡(luò)三層互通，沒有大二層的限制，但是需要強(qiáng)依賴底層網(wǎng)絡(luò)的實(shí)現(xiàn)支持.實(shí)現(xiàn)的插件有Calico（BGP）等等
我們看下路由模式的一種實(shí)現(xiàn)flannel Host-gw：
如圖可以看到當(dāng)node1上container-1要發(fā)數(shù)據(jù)給node2上的container2時(shí),會匹配到如下的路由表規(guī)則：
10.244.1.0/24?via?10.168.0.3?dev?eth0表示前往目標(biāo)網(wǎng)段10.244.1.0/24的IP包，需要經(jīng)過本機(jī)eth0出去發(fā)往的下一跳IP地址為10.168.0.3(node2)，然后到達(dá)10.168.0.3以后再通過路由表轉(zhuǎn)發(fā)CNI網(wǎng)橋，進(jìn)而進(jìn)入到container2。
以上可以看到host-gw工作原理，其實(shí)就是在每個(gè)Node節(jié)點(diǎn)配置到每個(gè)Pod網(wǎng)段的下一跳為Pod網(wǎng)段所在的Node節(jié)點(diǎn)IP，Pod網(wǎng)段和Node節(jié)點(diǎn)IP的映射關(guān)系，Flannel保存在etcd或者Kubernetes中。Flannel只需要watch這些數(shù)據(jù)的變化來動態(tài)更新路由表即可。
這種網(wǎng)絡(luò)模式最大的好處就是避免了額外的封包和解包帶來的網(wǎng)絡(luò)性能損耗。缺點(diǎn)我們也能看見主要就是容器IP包通過下一跳出去時(shí)，必須要二層通信封裝成數(shù)據(jù)幀發(fā)送到下一跳。如果不在同個(gè)二層局域網(wǎng)，那么就要交給三層網(wǎng)關(guān)，而此時(shí)網(wǎng)關(guān)是不知道目標(biāo)容器網(wǎng)絡(luò)的（也可以靜態(tài)在每個(gè)網(wǎng)關(guān)配置Pod網(wǎng)段路由）。所以flannel host-gw必須要求集群宿主機(jī)是二層互通的。
而為了解決二層互通的限制性，Calico提供的網(wǎng)絡(luò)方案就可以更好的實(shí)現(xiàn)，Calico大三層網(wǎng)絡(luò)模式與Flannel提供的類似，也會在每臺宿主機(jī)添加如下格式的路由規(guī)則：
<目標(biāo)容器IP網(wǎng)段>?via?<網(wǎng)關(guān)的IP地址>?dev?eth0其中網(wǎng)關(guān)的IP地址不通場景有不同的意思，如果宿主機(jī)是二層可達(dá)那么就是目的容器所在的宿主機(jī)的IP地址，如果是三層不同局域網(wǎng)那么就是本機(jī)宿主機(jī)的網(wǎng)關(guān)IP（交換機(jī)或者路由器地址）。
不同于Flannel通過Kubernetes或者etcd存儲的數(shù)據(jù)來維護(hù)本機(jī)路由信息的做法，Calico是通過BGP動態(tài)路由協(xié)議來分發(fā)整個(gè)集群路由信息。
BGP全稱是Border Gateway Protocol邊界網(wǎng)關(guān)協(xié)議，Linxu原生支持的、專門用于在大規(guī)模數(shù)據(jù)中心為不同的自治系統(tǒng)之間傳遞路由信息。只要記住BGP簡單理解其實(shí)就是實(shí)現(xiàn)大規(guī)模網(wǎng)絡(luò)中節(jié)點(diǎn)路由信息同步共享的一種協(xié)議。而BGP這種協(xié)議就能代替Flannel維護(hù)主機(jī)路由表功能。
Calico主要由三個(gè)部分組成：
Calico CNI插件：主要負(fù)責(zé)與kubernetes對接，供kubelet調(diào)用使用。
Felix：負(fù)責(zé)維護(hù)宿主機(jī)上的路由規(guī)則、FIB轉(zhuǎn)發(fā)信息庫等。
BIRD：負(fù)責(zé)分發(fā)路由規(guī)則，類似路由器。
Confd：配置管理組件。
除此之外，Calico還和flannel host-gw不同之處在于，它不會創(chuàng)建網(wǎng)橋設(shè)備，而是通過路由表來維護(hù)每個(gè)Pod的通信，如下圖所示：
可以看到Calico的CNI插件會為每個(gè)容器設(shè)置一個(gè)veth pair設(shè)備，然后把另一端接入到宿主機(jī)網(wǎng)絡(luò)空間，由于沒有網(wǎng)橋，CNI插件還需要在宿主機(jī)上為每個(gè)容器的veth pair設(shè)備配置一條路由規(guī)則，用于接收傳入的IP包，路由規(guī)則如下：
10.92.77.163?dev?cali93a8a799fe1?scope?link以上表示發(fā)送10.92.77.163的IP包應(yīng)該發(fā)給cali93a8a799fe1設(shè)備，然后到達(dá)另外一段容器中。
有了這樣的veth pair設(shè)備以后，容器發(fā)出的IP包就會通過veth pair設(shè)備到達(dá)宿主機(jī)，然后宿主機(jī)根據(jù)路有規(guī)則的下一條地址，發(fā)送給正確的網(wǎng)關(guān)（10.100.1.3），然后到達(dá)目標(biāo)宿主機(jī)，在到達(dá)目標(biāo)容器。
10.92.160.0/23?via?10.106.65.2?dev?bond0?proto?bird這些路由規(guī)則都是Felix維護(hù)配置的，而路由信息則是calico bird組件基于BGP分發(fā)而來。Calico實(shí)際上是將集群里所有的節(jié)點(diǎn)都當(dāng)做邊界路由器來處理，他們一起組成了一個(gè)全互聯(lián)的網(wǎng)絡(luò)，彼此之間通過BGP交換路由，這些節(jié)點(diǎn)我們叫做BGP Peer。
需要注意的是Calico維護(hù)網(wǎng)絡(luò)的默認(rèn)模式是node-to-node mesh，這種模式下，每臺宿主機(jī)的BGP client都會跟集群所有的節(jié)點(diǎn)BGP client進(jìn)行通信交換路由。這樣一來，隨著節(jié)點(diǎn)規(guī)模數(shù)量N的增加，連接會以N的2次方增長，會集群網(wǎng)絡(luò)本身帶來巨大壓力。
所以一般這種模式推薦的集群規(guī)模在50節(jié)點(diǎn)左右，超過50節(jié)點(diǎn)推薦使用另外一種RR（Router Reflector）模式，這種模式下，Calico可以指定幾個(gè)節(jié)點(diǎn)作為RR，他們負(fù)責(zé)跟所有節(jié)點(diǎn)BGP client建立通信來學(xué)習(xí)集群所有的路由，其他節(jié)點(diǎn)只需要跟RR節(jié)點(diǎn)交換路由即可。這樣大大降低了連接數(shù)量，同時(shí)為了集群網(wǎng)絡(luò)穩(wěn)定性，建議RR>=2。
以上的工作原理依然是在二層通信，當(dāng)我們有兩臺宿主機(jī)，一臺是10.100.0.2/24，節(jié)點(diǎn)上容器網(wǎng)絡(luò)是10.92.204.0/24；另外一臺是10.100.1.2/24，節(jié)點(diǎn)上容器網(wǎng)絡(luò)是10.92.203.0/24，此時(shí)兩臺機(jī)器因?yàn)椴辉谕瑐€(gè)二層所以需要三層路由通信，這時(shí)Calico就會在節(jié)點(diǎn)上生成如下路由表：
10.92.203.0/23?via?10.100.1.2?dev?eth0?proto?bird這時(shí)候問題就來了，因?yàn)?0.100.1.2跟我們10.100.0.2不在同個(gè)子網(wǎng)，是不能二層通信的。這之后就需要使用Calico IPIP模式，當(dāng)宿主機(jī)不在同個(gè)二層網(wǎng)絡(luò)時(shí)就是用Overlay網(wǎng)絡(luò)封裝以后再發(fā)出去。如下圖所示：
IPIP模式下在非二層通信時(shí)，Calico會在Node節(jié)點(diǎn)添加如下路由規(guī)則：
10.92.203.0/24?via?10.100.1.2?dev?tunnel0可以看到盡管下一條任然是Node的IP地址，但是出口設(shè)備卻是tunnel0，其是一個(gè)IP隧道設(shè)備，主要有Linux內(nèi)核的IPIP驅(qū)動實(shí)現(xiàn)。會將容器的IP包直接封裝宿主機(jī)網(wǎng)絡(luò)的IP包中，這樣到達(dá)node2以后再經(jīng)過IPIP驅(qū)動拆包拿到原始容器IP包，然后通過路由規(guī)則發(fā)送給veth pair設(shè)備到達(dá)目標(biāo)容器。
以上盡管可以解決非二層網(wǎng)絡(luò)通信，但是仍然會因?yàn)榉獍徒獍鼘?dǎo)致性能下降。如果Calico能夠讓宿主機(jī)之間的router設(shè)備也學(xué)習(xí)到容器路由規(guī)則，這樣就可以直接三層通信了。比如在路由器添加如下的路由表：
10.92.203.0/24?via?10.100.1.2?dev?interface1而node1添加如下的路由表：
10.92.203.0/24?via?10.100.1.1?dev?tunnel0那么node1上的容器發(fā)出的IP包，基于本地路由表發(fā)送給10.100.1.1網(wǎng)關(guān)路由器，然后路由器收到IP包查看目的IP，通過本地路由表找到下一跳地址發(fā)送到node2，最終到達(dá)目的容器。這種方案，我們是可以基于underlay 網(wǎng)絡(luò)來實(shí)現(xiàn)，只要底層支持BGP網(wǎng)絡(luò)，可以和我們RR節(jié)點(diǎn)建立EBGP關(guān)系來交換集群內(nèi)的路由信息。
以上就是Kubernetes常用的幾種網(wǎng)絡(luò)方案了，在公有云場景下一般用云廠商提供的或者使用flannel host-gw這種更簡單，而私有物理機(jī)房環(huán)境中，Calico項(xiàng)目更加適合。根據(jù)自己的實(shí)際場景，再選擇合適的網(wǎng)絡(luò)方案。
原文鏈接：
https://tech.ipalfish.com/blog/2020/03/06/kubernetes_container_network/
- END -
看完一鍵三連在看，轉(zhuǎn)發(fā)，點(diǎn)贊
是對文章最大的贊賞，極客重生感謝你
推薦閱讀
圖解Linux 內(nèi)核TCP/IP 協(xié)議棧實(shí)現(xiàn)|Linux網(wǎng)絡(luò)硬核系列
網(wǎng)絡(luò)排障全景指南手冊v1.0精簡版pdf
一個(gè)奇葩的網(wǎng)絡(luò)問題
總結(jié)
以上是生活随笔為你收集整理的深入理解Kubernetes容器网络的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 知乎热榜：如何获得高并发的经验？
- 下一篇： 大厂中秋礼盒大PK！祝大家中秋快乐，送大