主機(jī)內(nèi)組網(wǎng)

k8s主機(jī)內(nèi)組網(wǎng)模型是veth pair+bridge的方式。
k8s使用veth pair將容器與主機(jī)的網(wǎng)絡(luò)協(xié)議棧連接起來(lái)，從而使數(shù)據(jù)包可以進(jìn)出pod。容器放在主機(jī)根network namespace中，veth pair的一端連接到linux網(wǎng)橋，可以讓同一節(jié)點(diǎn)上的各pod之間相互通信。

跨節(jié)點(diǎn)組網(wǎng)

k8s跨節(jié)點(diǎn)組網(wǎng)模型有bridge、overlay等。
bridge網(wǎng)絡(luò)本身不解決容器的跨節(jié)點(diǎn)通信，而是添加主機(jī)路由表，映射目標(biāo)容器網(wǎng)段和主機(jī)IP的關(guān)系，集群內(nèi)如果有N個(gè)主機(jī)，則需要N-1條路由項(xiàng)。
overlay網(wǎng)絡(luò)構(gòu)建在物理網(wǎng)絡(luò)上的虛擬網(wǎng)絡(luò)，VXLAN是主流的overlay標(biāo)準(zhǔn)。VXLAN是用UDP包頭封裝二層幀，即所謂的MAC in UDP。
為了讓多個(gè)Pod的網(wǎng)絡(luò)命名空間鏈接起來(lái)，可以讓veth對(duì)的一端鏈接到root網(wǎng)絡(luò)命名空間（宿主機(jī)的），另一端鏈接到Pod的網(wǎng)絡(luò)命名空間。還需要Linux以太網(wǎng)橋，它是虛擬的二層網(wǎng)絡(luò)設(shè)備，把多個(gè)以太網(wǎng)段連接起來(lái)，它維護(hù)轉(zhuǎn)發(fā)表，通過(guò)查看每個(gè)設(shè)備mac地址決定轉(zhuǎn)發(fā)，還是丟棄數(shù)據(jù)。

跨節(jié)點(diǎn)通信

隧道方案（ Overlay Networking ）

隧道方案在IaaS層的網(wǎng)絡(luò)中應(yīng)用也比較多，但隨著節(jié)點(diǎn)規(guī)模的增長(zhǎng)，復(fù)雜度會(huì)提升，而且跟蹤網(wǎng)絡(luò)問(wèn)題比較麻煩。
Weave：UDP廣播，本機(jī)建立新的BR，通過(guò)PCAP互通。
Open vSwitch（OVS）：基于VxLan和GRE協(xié)議，但是性能方面損失比較嚴(yán)重。
Flannel：UDP廣播，VxLan。

overlay網(wǎng)絡(luò)是指在不改變現(xiàn)有網(wǎng)絡(luò)基礎(chǔ)設(shè)施的前提下，通過(guò)額外的網(wǎng)絡(luò)協(xié)議，把二層報(bào)文封裝在IP報(bào)文之上的新的數(shù)據(jù)格式，形成邏輯上的新網(wǎng)絡(luò)。這樣不但能夠充分利用成熟的ip路由協(xié)議進(jìn)行數(shù)據(jù)分發(fā)，而且在overlay技術(shù)中采用擴(kuò)展的隔離標(biāo)識(shí)位數(shù)，能夠突破vlan的4000數(shù)量限制，支持高達(dá)16M的用戶，并且在必要時(shí)將廣播流量轉(zhuǎn)化為組播流量，避免廣播數(shù)據(jù)泛濫。

flannel插件
flannel為每個(gè)主機(jī)的docker deamon分配一個(gè)ip段，通過(guò)etcd維護(hù)一個(gè)跨主機(jī)的路由表，容器之間的ip是可以互相連通的，當(dāng)兩個(gè)跨主機(jī)的容器要通信的時(shí)候，會(huì)在主機(jī)上修改數(shù)據(jù)包的header，修改目的地址和源地址，經(jīng)過(guò)路由表發(fā)送到目標(biāo)主機(jī)后解封。封包的方式，支持udp/vxlan/host-gw等，但是如果一個(gè)容器要暴露服務(wù)，還是需要映射ip到主機(jī)側(cè)。

路由方案

一般是從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)。

calico插件
Calico是基于BGP的純?nèi)龑拥木W(wǎng)絡(luò)方案。Calico可以應(yīng)用在虛擬機(jī)，物理機(jī)，容器環(huán)境中。在Calico運(yùn)行的主機(jī)上可以看到大量由linux路由組成的路由表，這是calico通過(guò)自有組件動(dòng)態(tài)生成和管理的。但BGP帶給它的好處的同時(shí)也帶給他的劣勢(shì)，BGP協(xié)議在企業(yè)內(nèi)部還很少被接受，企業(yè)網(wǎng)管不太愿意在跨網(wǎng)絡(luò)的路由器上開(kāi)啟BGP協(xié)議。
基于BGP的純?nèi)龑拥木W(wǎng)絡(luò)方案。Calico保證所有容器之間的數(shù)據(jù)流量都是通過(guò)IP路由的方式完成互聯(lián)互通。Calico節(jié)點(diǎn)組網(wǎng)可以直接利用數(shù)據(jù)中心的網(wǎng)絡(luò)結(jié)構(gòu)（L2或L3），不需要額外的NAT、隧道或者overlay network，沒(méi)有額外的封包解包，節(jié)約CPU運(yùn)算且提高網(wǎng)絡(luò)效率。容器的IP可以直接對(duì)外部訪問(wèn)，可以直接分配到業(yè)務(wù)IP，而且如果網(wǎng)絡(luò)設(shè)備支持BGP的話，可以用它實(shí)現(xiàn)大規(guī)模的容器網(wǎng)絡(luò)。
calico插件可提供pod固定ip的解決方案。

三層（路由）和隧道的異同

相同之處是都實(shí)現(xiàn)了跨主機(jī)容器的三層互通，都是通過(guò)對(duì)目的 MAC 地址的操作來(lái)實(shí)現(xiàn)的。
不同之處是三層通過(guò)配置下一條主機(jī)的路由規(guī)則來(lái)實(shí)現(xiàn)互通，隧道是通過(guò)通過(guò)在 IP 包外再封裝一層 MAC 包頭來(lái)實(shí)現(xiàn)。
三層的優(yōu)點(diǎn)：少了封包和解包的過(guò)程，性能更高。
三層的缺點(diǎn)：需要自己維護(hù)路由規(guī)則。
隧道的優(yōu)點(diǎn)：簡(jiǎn)單，原因是大部分工作都是已由 Linux 內(nèi)核的模塊實(shí)現(xiàn)，應(yīng)用層工作量較少。
隧道的缺點(diǎn)：性能低。

CNI

在k8s平臺(tái)上，通過(guò)CNI插件的方式部署容器網(wǎng)絡(luò)。
Container Networking Interface（CNI）定義的是容器運(yùn)行環(huán)境與網(wǎng)絡(luò)插件之間的接口規(guī)范，僅關(guān)心容器創(chuàng)建時(shí)的網(wǎng)絡(luò)配置和容器被銷(xiāo)毀時(shí)網(wǎng)絡(luò)資源的釋放。容器可以通過(guò)綁定多個(gè)CNI插件加入多個(gè)網(wǎng)絡(luò)中。
與CRI之于k8s的runtime類似。CNI是pod網(wǎng)絡(luò)的標(biāo)準(zhǔn)接口，通過(guò)JSON描述容器網(wǎng)絡(luò)配置，是k8s與底層網(wǎng)絡(luò)插件之間的抽象層。
要使用CNI網(wǎng)絡(luò)驅(qū)動(dòng)則需要配置參數(shù)--network-plugin=cni。k8s從--cni-conf-dir（默認(rèn)為/etc/cni/net.d）中讀取文件的CNI配置來(lái)配置每個(gè)pod網(wǎng)絡(luò)。CNI插件二進(jìn)制文件的目錄通過(guò)kubelet的--cni-bin-dir參數(shù)配置（默認(rèn)為/otp/cni/bin）。
CNI從v1.11版本開(kāi)始支持控制pod的帶寬。

網(wǎng)絡(luò)互通

• pod到pod， 三層網(wǎng)絡(luò)的連通。 通過(guò)CNI實(shí)現(xiàn)。
• pod到service， 四層負(fù)載均衡器。 通過(guò)kube-proxy實(shí)現(xiàn)。
• pod到k8s外， 通過(guò)SNAT實(shí)現(xiàn)。
• 主機(jī)到pod，

IP轉(zhuǎn)發(fā)

內(nèi)核態(tài)設(shè)置，允許將一個(gè)接口的流量轉(zhuǎn)發(fā)到另一個(gè)接口。該配置是linux內(nèi)核將流量從容器路由到外部所必須的。ipv4 forwarding。

橋接

k8s通過(guò)bridge-netfilter配置使iptables規(guī)則應(yīng)用到linux網(wǎng)橋上。該配置對(duì)linux內(nèi)核進(jìn)行宿主機(jī)和容器之間數(shù)據(jù)包的地址轉(zhuǎn)換是必須的。否則pod進(jìn)行外部服務(wù)網(wǎng)絡(luò)請(qǐng)求時(shí)會(huì)出現(xiàn)目標(biāo)主機(jī)不可達(dá)或者連接拒絕的錯(cuò)誤。

tips

“單pod單ip”網(wǎng)絡(luò)模型。實(shí)現(xiàn)k8s扁平化網(wǎng)絡(luò)。容器之間直接通信，不需要額外NAT。node與容器網(wǎng)絡(luò)直連，不需要額外NAT。
扁平化網(wǎng)絡(luò)的優(yōu)點(diǎn)：沒(méi)有NAT帶來(lái)的性能損耗，可以追溯源地址，為網(wǎng)絡(luò)策略做鋪墊，降低網(wǎng)絡(luò)排錯(cuò)難度。

pod中docker容器和pod在同一個(gè)網(wǎng)絡(luò)命名空間內(nèi)，所以ip和端口等網(wǎng)絡(luò)配置都和pod一樣，是docker的網(wǎng)絡(luò)模式是container，即和已經(jīng)存在的容器（pause容器）共享網(wǎng)絡(luò)。

參考

• 《Kubernetes 權(quán)威指南》
• 《Kubernetes 網(wǎng)絡(luò)權(quán)威指南》
• k8s網(wǎng)絡(luò)--竹徑風(fēng)聲