點(diǎn)擊上方“開源Linux”,選擇“設(shè)為星標(biāo)”
回復(fù)“學(xué)習(xí)”獲取獨(dú)家整理的學(xué)習(xí)資料!
在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ò)棧。

一個(gè)Linux容器的網(wǎng)絡(luò)棧是被隔離在它自己的Network Namespace中,Network Namespace包括了:網(wǎng)卡(Network Interface),回環(huán)設(shè)備(Lookback Device),路由表(Routing Table)和iptables規(guī)則,對(duì)于服務(wù)進(jìn)程來講這些就構(gòu)建了它發(fā)起請(qǐng)求和相應(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è)備對(duì)的引入是為了實(shí)現(xiàn)在不同網(wǎng)絡(luò)命名空間的通信,總是以兩張?zhí)摂M網(wǎng)卡(veth peer)的形式成對(duì)出現(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í)候,會(huì)使用路由表來決定發(fā)往哪里
基于以上的基礎(chǔ),同宿主機(jī)的容器時(shí)間如何通信呢?我們可以簡(jiǎn)單把他們理解成兩臺(tái)主機(jī),主機(jī)之間通過網(wǎng)線連接起來,如果要多臺(tái)主機(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)橋上。docker?run?-d?--name?c1?hub.pri.ibanyu.com/devops/alpine:v3.8?/bin/sh
docker?exec?-it?c1??/bin/sh
/?#?ifconfig
eth0??????Link?encap:Ethernet??HWaddr?02:42:AC:11:00:02
??????????inet?addr:172.17.0.2??Bcast:172.17.255.255??Mask:255.255.0.0
??????????UP?BROADCAST?RUNNING?MULTICAST??MTU:1500??Metric:1
??????????RX?packets:14?errors:0?dropped:0?overruns:0?frame:0
??????????TX?packets:0?errors:0?dropped:0?overruns:0?carrier:0
??????????collisions:0?txqueuelen:0
??????????RX?bytes:1172?(1.1?KiB)??TX?bytes:0?(0.0?B)
lo????????Link?encap:Local?Loopback
??????????inet?addr:127.0.0.1??Mask:255.0.0.0
??????????UP?LOOPBACK?RUNNING??MTU:65536??Metric:1
??????????RX?packets:0?errors:0?dropped:0?overruns:0?frame:0
??????????TX?packets:0?errors:0?dropped:0?overruns:0?carrier:0
??????????collisions:0?txqueuelen:1000
??????????RX?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)路由出口。所有對(duì)172.17.0.0/16網(wǎng)段的請(qǐng)求都會(huì)從eth0出去。我們?cè)賮砜碫eth peer的另一端,我們查看宿主機(jī)的網(wǎng)絡(luò)設(shè)備:ifconfig
docker0:?flags=4163??mtu?1500
????????inet?172.17.0.1??netmask?255.255.0.0??broadcast?172.17.255.255
????????inet6?fe80::42:6aff:fe46:93d2??prefixlen?64??scopeid?0x20
????????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?0
????????TX?packets?8??bytes?656?(656.0?B)
????????TX?errors?0??dropped?0?overruns?0??carrier?0??collisions?0
eth0:?flags=4163??mtu?1500
????????inet?10.100.0.2??netmask?255.255.255.0??broadcast?10.100.0.255
????????inet6?fe80::5400:2ff:fea3:4b44??prefixlen?64??scopeid?0x20
????????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?0
????????TX?packets?5512037??bytes?9512685850?(8.8?GiB)
????????TX?errors?0??dropped?0?overruns?0??carrier?0??collisions?0
lo:?flags=73??mtu?65536
????????inet?127.0.0.1??netmask?255.0.0.0
????????inet6?::1??prefixlen?128??scopeid?0x10
????????loop??txqueuelen?1000??(Local?Loopback)
????????RX?packets?32??bytes?2592?(2.5?KiB)
????????RX?errors?0??dropped?0??overruns?0??frame?0
????????TX?packets?32??bytes?2592?(2.5?KiB)
????????TX?errors?0??dropped?0?overruns?0??carrier?0??collisions?0
veth20b3dac:?flags=4163??mtu?1500
????????inet6?fe80::30e2:9cff:fe45:329??prefixlen?64??scopeid?0x20
????????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?0
????????TX?packets?8??bytes?656?(656.0?B)
????????TX?errors?0??dropped?0?overruns?0??carrier?0??collisions?0
我們可以看到,容器對(duì)應(yīng)的Veth peer另一端是宿主機(jī)上的一塊虛擬網(wǎng)卡叫veth20b3dac,并且可以通過brctl查看網(wǎng)橋信息看到這張網(wǎng)卡是在docker0上。#?brctl?show
docker0??8000.02426a4693d2?no??veth20b3dac
然后我們?cè)賳?dòng)一個(gè)容器,從第一個(gè)容器是否能ping通第二個(gè)容器。docker?run?-d?--name?c2?-it?hub.pri.ibanyu.com/devops/alpine:v3.8?/bin/sh
?docker?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í),會(huì)匹配到我們的路由表第二條規(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)橋,它會(huì)廣播到所有連接它的veth peer虛擬網(wǎng)卡去,然后正確的虛擬網(wǎng)卡收到后會(huì)響應(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)你在一臺(tái)宿主機(jī)上,訪問該宿主機(jī)上的容器的IP地址時(shí),這個(gè)請(qǐng)求的數(shù)據(jù)包,也是先根據(jù)路由規(guī)則到達(dá)docker0網(wǎng)橋,然后被轉(zhuǎn)發(fā)到對(duì)應(yīng)的Veth Pair設(shè)備,最后出現(xiàn)在容器里。

在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在啟動(dòng)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)萜骰ネㄖ饕腔诼酚杀泶蛲ǎ瑹o需在主機(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í),會(huì)匹配到如下的路由表規(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)系,F(xiàn)lannel保存在etcd或者Kubernetes中。Flannel只需要watch這些數(shù)據(jù)的變化來動(dòng)態(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提供的類似,也會(huì)在每臺(tái)宿主機(jī)添加如下格式的路由規(guī)則:<目標(biāo)容器IP網(wǎng)段>?via?<網(wǎng)關(guān)的IP地址>?dev?eth0
其中網(wǎng)關(guān)的IP地址不同場(chǎng)景有不同的意思,如果宿主機(jī)是二層可達(dá)那么就是目的容器所在的宿主機(jī)的IP地址,如果是三層不同局域網(wǎng)那么就是本機(jī)宿主機(jī)的網(wǎng)關(guān)IP(交換機(jī)或者路由器地址)。不同于Flannel通過Kubernetes或者etcd存儲(chǔ)的數(shù)據(jù)來維護(hù)本機(jī)路由信息的做法,Calico是通過BGP動(dòng)態(tài)路由協(xié)議來分發(fā)整個(gè)集群路由信息。BGP全稱是Border Gateway Protocol邊界網(wǎng)關(guān)協(xié)議,Linxu原生支持的、專門用于在大規(guī)模數(shù)據(jù)中心為不同的自治系統(tǒng)之間傳遞路由信息。只要記住BGP簡(jiǎn)單理解其實(shí)就是實(shí)現(xiàn)大規(guī)模網(wǎng)絡(luò)中節(jié)點(diǎn)路由信息同步共享的一種協(xié)議。而BGP這種協(xié)議就能代替Flannel維護(hù)主機(jī)路由表功能。Calico CNI插件:主要負(fù)責(zé)與kubernetes對(duì)接,供kubelet調(diào)用使用。
Felix:負(fù)責(zé)維護(hù)宿主機(jī)上的路由規(guī)則、FIB轉(zhuǎn)發(fā)信息庫等。
BIRD:負(fù)責(zé)分發(fā)路由規(guī)則,類似路由器。
Confd:配置管理組件。
除此之外,Calico還和flannel host-gw不同之處在于,它不會(huì)創(chuàng)建網(wǎng)橋設(shè)備,而是通過路由表來維護(hù)每個(gè)Pod的通信,如下圖所示:可以看到Calico的CNI插件會(huì)為每個(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包就會(huì)通過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,這種模式下,每臺(tái)宿主機(jī)的BGP client都會(huì)跟集群所有的節(jié)點(diǎn)BGP client進(jìn)行通信交換路由。這樣一來,隨著節(jié)點(diǎn)規(guī)模數(shù)量N的增加,連接會(huì)以N的2次方增長,會(huì)集群網(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)我們有兩臺(tái)宿主機(jī),一臺(tái)是10.100.0.2/24,節(jié)點(diǎn)上容器網(wǎng)絡(luò)是10.92.204.0/24;另外一臺(tái)是10.100.1.2/24,節(jié)點(diǎn)上容器網(wǎng)絡(luò)是10.92.203.0/24,此時(shí)兩臺(tái)機(jī)器因?yàn)椴辉谕瑐€(gè)二層所以需要三層路由通信,這時(shí)Calico就會(huì)在節(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會(huì)在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ū)動(dòng)實(shí)現(xiàn)。會(huì)將容器的IP包直接封裝宿主機(jī)網(wǎng)絡(luò)的IP包中,這樣到達(dá)node2以后再經(jīng)過IPIP驅(qū)動(dòng)拆包拿到原始容器IP包,然后通過路由規(guī)則發(fā)送給veth pair設(shè)備到達(dá)目標(biāo)容器。以上盡管可以解決非二層網(wǎng)絡(luò)通信,但是仍然會(huì)因?yàn)榉獍徒獍鼘?dǎo)致性能下降。如果Calico能夠讓宿主機(jī)之間的router設(shè)備也學(xué)習(xí)到容器路由規(guī)則,這樣就可以直接三層通信了。比如在路由器添加如下的路由表:10.92.203.0/24?via?10.100.1.2?dev?interface1
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ò)方案了,在公有云場(chǎng)景下一般用云廠商提供的或者使用flannel host-gw這種更簡(jiǎn)單,而私有物理機(jī)房環(huán)境中,Calico項(xiàng)目更加適合。根據(jù)自己的實(shí)際場(chǎng)景,再選擇合適的網(wǎng)絡(luò)方案。原文鏈接:https://tech.ipalfish.com/blog/2020/03/06/kubernetes_container_network/
關(guān)注「開源Linux」加星標(biāo),提升IT技能