主機內(nèi)組網(wǎng)
k8s主機內(nèi)組網(wǎng)模型是veth pair+bridge的方式。
k8s使用veth pair將容器與主機的網(wǎng)絡協(xié)議棧連接起來凉翻，從而使數(shù)據(jù)包可以進出pod。容器放在主機根network namespace中，veth pair的一端連接到linux網(wǎng)橋泪勒，可以讓同一節(jié)點上的各pod之間相互通信跌前。
跨節(jié)點組網(wǎng)
k8s跨節(jié)點組網(wǎng)模型有bridge棕兼、overlay等。
bridge網(wǎng)絡本身不解決容器的跨節(jié)點通信抵乓，而是添加主機路由表伴挚，映射目標容器網(wǎng)段和主機IP的關(guān)系，集群內(nèi)如果有N個主機灾炭，則需要N-1條路由項茎芋。
overlay網(wǎng)絡構(gòu)建在物理網(wǎng)絡上的虛擬網(wǎng)絡，VXLAN是主流的overlay標準蜈出。VXLAN是用UDP包頭封裝二層幀田弥，即所謂的MAC in UDP。
為了讓多個Pod的網(wǎng)絡命名空間鏈接起來铡原，可以讓veth對的一端鏈接到root網(wǎng)絡命名空間（宿主機的）皱蹦，另一端鏈接到Pod的網(wǎng)絡命名空間煤杀。還需要Linux以太網(wǎng)橋，它是虛擬的二層網(wǎng)絡設備沪哺，把多個以太網(wǎng)段連接起來沈自，它維護轉(zhuǎn)發(fā)表，通過查看每個設備mac地址決定轉(zhuǎn)發(fā)辜妓，還是丟棄數(shù)據(jù)枯途。
跨節(jié)點通信
隧道方案（ Overlay Networking ）
隧道方案在IaaS層的網(wǎng)絡中應用也比較多，但隨著節(jié)點規(guī)模的增長籍滴，復雜度會提升酪夷，而且跟蹤網(wǎng)絡問題比較麻煩。
Weave：UDP廣播孽惰，本機建立新的BR晚岭，通過PCAP互通。
Open vSwitch（OVS）：基于VxLan和GRE協(xié)議勋功，但是性能方面損失比較嚴重坦报。
Flannel：UDP廣播，VxLan狂鞋。
overlay網(wǎng)絡是指在不改變現(xiàn)有網(wǎng)絡基礎設施的前提下片择，通過額外的網(wǎng)絡協(xié)議，把二層報文封裝在IP報文之上的新的數(shù)據(jù)格式骚揍，形成邏輯上的新網(wǎng)絡字管。這樣不但能夠充分利用成熟的ip路由協(xié)議進行數(shù)據(jù)分發(fā)，而且在overlay技術(shù)中采用擴展的隔離標識位數(shù)信不，能夠突破vlan的4000數(shù)量限制嘲叔，支持高達16M的用戶，并且在必要時將廣播流量轉(zhuǎn)化為組播流量抽活，避免廣播數(shù)據(jù)泛濫硫戈。
flannel插件
flannel為每個主機的docker deamon分配一個ip段，通過etcd維護一個跨主機的路由表酌壕，容器之間的ip是可以互相連通的掏愁，當兩個跨主機的容器要通信的時候，會在主機上修改數(shù)據(jù)包的header卵牍，修改目的地址和源地址果港，經(jīng)過路由表發(fā)送到目標主機后解封。封包的方式糊昙，支持udp/vxlan/host-gw等辛掠，但是如果一個容器要暴露服務，還是需要映射ip到主機側(cè)。
路由方案
一般是從3層或者2層實現(xiàn)隔離和跨主機容器互通的萝衩，出了問題也容易排查回挽。
Calico：基于BGP協(xié)議的路由方案，支持細粒度的ACL控制猩谊，對混合云親和度比較高千劈。
Macvlan：從邏輯和Kernel層來看隔離性和性能最優(yōu)的方案，基于二層隔離牌捷，所以需要二層路由器支持墙牌，大多數(shù)云服務商不支持，所以混合云上較難實現(xiàn)暗甥。
calico插件
Calico是基于BGP的純?nèi)龑拥木W(wǎng)絡方案喜滨。Calico可以應用在虛擬機，物理機撤防，容器環(huán)境中虽风。在Calico運行的主機上可以看到大量由linux路由組成的路由表，這是calico通過自有組件動態(tài)生成和管理的寄月。但BGP帶給它的好處的同時也帶給他的劣勢辜膝，BGP協(xié)議在企業(yè)內(nèi)部還很少被接受，企業(yè)網(wǎng)管不太愿意在跨網(wǎng)絡的路由器上開啟BGP協(xié)議剥懒。
基于BGP的純?nèi)龑拥木W(wǎng)絡方案内舟。Calico保證所有容器之間的數(shù)據(jù)流量都是通過IP路由的方式完成互聯(lián)互通合敦。Calico節(jié)點組網(wǎng)可以直接利用數(shù)據(jù)中心的網(wǎng)絡結(jié)構(gòu)（L2或L3）初橘，不需要額外的NAT、隧道或者overlay network充岛，沒有額外的封包解包保檐，節(jié)約CPU運算且提高網(wǎng)絡效率。容器的IP可以直接對外部訪問崔梗，可以直接分配到業(yè)務IP夜只，而且如果網(wǎng)絡設備支持BGP的話，可以用它實現(xiàn)大規(guī)模的容器網(wǎng)絡蒜魄。
calico插件可提供pod固定ip的解決方案扔亥。
三層（路由）和隧道的異同
相同之處是都實現(xiàn)了跨主機容器的三層互通，都是通過對目的 MAC 地址的操作來實現(xiàn)的谈为。
不同之處是三層通過配置下一條主機的路由規(guī)則來實現(xiàn)互通旅挤，隧道是通過通過在 IP 包外再封裝一層 MAC 包頭來實現(xiàn)。
三層的優(yōu)點：少了封包和解包的過程伞鲫，性能更高粘茄。
三層的缺點：需要自己維護路由規(guī)則。
隧道的優(yōu)點：簡單，原因是大部分工作都是已由 Linux 內(nèi)核的模塊實現(xiàn)柒瓣，應用層工作量較少儒搭。
隧道的缺點：性能低。
CNI
在k8s平臺上芙贫，通過CNI插件的方式部署容器網(wǎng)絡搂鲫。
Container Networking Interface（CNI）定義的是容器運行環(huán)境與網(wǎng)絡插件之間的接口規(guī)范，僅關(guān)心容器創(chuàng)建時的網(wǎng)絡配置和容器被銷毀時網(wǎng)絡資源的釋放磺平。容器可以通過綁定多個CNI插件加入多個網(wǎng)絡中默穴。
與CRI之于k8s的runtime類似。CNI是pod網(wǎng)絡的標準接口褪秀，通過JSON描述容器網(wǎng)絡配置蓄诽，是k8s與底層網(wǎng)絡插件之間的抽象層。
要使用CNI網(wǎng)絡驅(qū)動則需要配置參數(shù)--network-plugin=cni媒吗。k8s從--cni-conf-dir（默認為/etc/cni/net.d）中讀取文件的CNI配置來配置每個pod網(wǎng)絡仑氛。CNI插件二進制文件的目錄通過kubelet的--cni-bin-dir參數(shù)配置（默認為/otp/cni/bin）。
CNI從v1.11版本開始支持控制pod的帶寬闸英。
網(wǎng)絡互通
- pod到pod锯岖， 三層網(wǎng)絡的連通。 通過CNI實現(xiàn)甫何。
- pod到service出吹， 四層負載均衡器。 通過kube-proxy實現(xiàn)辙喂。
- pod到k8s外捶牢， 通過SNAT實現(xiàn)。
- 主機到pod巍耗，
IP轉(zhuǎn)發(fā)
內(nèi)核態(tài)設置秋麸，允許將一個接口的流量轉(zhuǎn)發(fā)到另一個接口。該配置是linux內(nèi)核將流量從容器路由到外部所必須的炬太。ipv4 forwarding灸蟆。
橋接
k8s通過bridge-netfilter配置使iptables規(guī)則應用到linux網(wǎng)橋上。該配置對linux內(nèi)核進行宿主機和容器之間數(shù)據(jù)包的地址轉(zhuǎn)換是必須的亲族。否則pod進行外部服務網(wǎng)絡請求時會出現(xiàn)目標主機不可達或者連接拒絕的錯誤炒考。
tips
“單pod單ip”網(wǎng)絡模型。實現(xiàn)k8s扁平化網(wǎng)絡霎迫。容器之間直接通信斋枢，不需要額外NAT。node與容器網(wǎng)絡直連女气，不需要額外NAT杏慰。
扁平化網(wǎng)絡的優(yōu)點：沒有NAT帶來的性能損耗，可以追溯源地址，為網(wǎng)絡策略做鋪墊缘滥，降低網(wǎng)絡排錯難度轰胁。
pod中docker容器和pod在同一個網(wǎng)絡命名空間內(nèi)，所以ip和端口等網(wǎng)絡配置都和pod一樣朝扼，是docker的網(wǎng)絡模式是container赃阀，即和已經(jīng)存在的容器（pause容器）共享網(wǎng)絡。
參考
- 《Kubernetes 權(quán)威指南》
- 《Kubernetes 網(wǎng)絡權(quán)威指南》
- k8s網(wǎng)絡--竹徑風聲
