k8s網絡之Calico網絡


一, 簡介

Calico 是一種容器之間互通的網絡方案。在虛擬化平台中,比如 OpenStack、Docker 等都需要實現 workloads 之間互連,但同時也需要對容器做隔離控制,就像在 Internet 中的服務僅開放80端口、公有雲的多租戶一樣,提供隔離和管控機制。而在多數的虛擬化平台實現中,通常都使用二層隔離技術來實現容器的網絡,這些二層的技術有一些弊端,比如需要依賴 VLAN、bridge 和隧道等技術,其中 bridge 帶來了復雜性,vlan 隔離和 tunnel 隧道則消耗更多的資源並對物理環境有要求,隨着網絡規模的增大,整體會變得越加復雜。我們嘗試把 Host 當作 Internet 中的路由器,同樣使用 BGP 同步路由,並使用 iptables 來做安全訪問策略,最終設計出了 Calico 方案。

 calico封裝類型:

Vxlan      數據包報頭大,在網絡密集型工作負載才能體現差異。

IP-in-IP   疊加模型,實現跨不同網段建立路由通信,可以在配置文件設置是否啟用IPIP,node節點跨網段需開啟。開啟時將Node路由之間做一個tuunel,再把兩個網絡連接起來的模式,會在各Node節點上創建一個名為tunl0的虛擬網絡接口。

BGP模式  直接使用物理機作為虛擬路由器(vRouter),不再創建額外的tunnel.   

#[calico]設置calico 網絡 backend: brid, vxlan, none

CALICO_NETWORKING_BACKEND:  "brid" #默認
flannel 默認vxlan
# [calico]設置 CALICO_IPV4POOL_IPIP=“off”,可以提高網絡性能,不能跨子網,條件限制詳見 docs/setup/calico.md
CALICO_IPV4POOL_IPIP:  "Always" #Calico工作模式     可跨子網,適用公司場景

適用場景:k8s環境中的pod之間需要隔離

設計思想:Calico 不使用隧道或 NAT 來實現轉發,而是巧妙的把所有二三層流量轉換成三層流量,並通過 host 上路由配置完成跨 Host 轉發。

設計優勢

1.更優的資源利用

二層網絡通訊需要依賴廣播消息機制,廣播消息的開銷與 host 的數量呈指數級增長,Calico 使用的三層路由方法,則完全抑制了二層廣播,減少了資源開銷。

另外,二層網絡使用 VLAN 隔離技術,天生有 4096 個規格限制,即便可以使用 vxlan 解決,但 vxlan 又帶來了隧道開銷的新問題。而 Calico 不使用 vlan 或 vxlan 技術,使資源利用率更高。

2.可擴展性

Calico 使用與 Internet 類似的方案,Internet 的網絡比任何數據中心都大,Calico 同樣天然具有可擴展性。

3.簡單而更容易 debug

因為沒有隧道,意味着 workloads 之間路徑更短更簡單,配置更少,在 host 上更容易進行 debug 調試。

4.更少的依賴

Calico 僅依賴三層路由可達。

5.可適配性

Calico 較少的依賴性使它能適配所有 VM、Container、白盒或者混合環境場景。

二 Calico架構

 

 

 

Calico網絡模型主要工作組件:

1.Felix:運行在每一台 Host 的 agent 進程,主要負責網絡接口管理和監聽、路由、ARP 管理、ACL 管理和同步、狀態上報等。

2.etcd:分布式鍵值存儲,主要負責網絡元數據一致性,確保Calico網絡狀態的准確性,可以與kubernetes共用;

3.BGP Client(BIRD):Calico 為每一台 Host 部署一個 BGP Client,使用 BIRD 實現,BIRD 是一個單獨的持續發展的項目,實現了眾多動態路由協議比如 BGP、OSPF、RIP 等。在 Calico 的角色是監聽 Host 上由 Felix 注入的路由信息,然后通過 BGP 協議廣播告訴剩余 Host 節點,從而實現網絡互通。

4.BGP Route Reflector:在大型網絡規模中,如果僅僅使用 BGP client 形成 mesh 全網互聯的方案就會導致規模限制,因為所有節點之間倆倆互聯,需要 N^2 個連接,為了解決這個規模問題,可以采用 BGP 的 Router Reflector 的方法,使所有 BGP Client 僅與特定 RR 節點互聯並做路由同步,從而大大減少連接數。

 

Felix

Felix會監聽ECTD中心的存儲,從它獲取事件,比如說用戶在這台機器上加了一個IP,或者是創建了一個容器等。用戶創建pod后,Felix負責將其網卡、IP、MAC都設置好,然后在內核的路由表里面寫一條,注明這個IP應該到這張網卡。同樣如果用戶制定了隔離策略,Felix同樣會將該策略創建到ACL中,以實現隔離。

 

BIRD

BIRD是一個標准的路由程序,它會從內核里面獲取哪一些IP的路由發生了變化,然后通過標准BGP的路由協議擴散到整個其他的宿主機上,讓外界都知道這個IP在這里,你們路由的時候得到這里來。

 

架構特點

由於Calico是一種純三層的實現,因此可以避免與二層方案相關的數據包封裝的操作,中間沒有任何的NAT,沒有任何的overlay,所以它的轉發效率可能是所有方案中最高的,因為它的包直接走原生TCP/IP的協議棧,它的隔離也因為這個棧而變得好做。因為TCP/IP的協議棧提供了一整套的防火牆的規則,所以它可以通過IPTABLES的規則達到比較復雜的隔離邏輯。

三 Calico 網絡Node之間兩種網絡

IPIP

從字面來理解,就是把一個IP數據包又套在一個IP包里,即把 IP 層封裝到 IP 層的一個 tunnel。它的作用其實基本上就相當於一個基於IP層的網橋!一般來說,普通的網橋是基於mac層的,根本不需 IP,而這個 ipip 則是通過兩端的路由做一個 tunnel,把兩個本來不通的網絡通過點對點連接起來。 

 

BGP

邊界網關協議(Border Gateway Protocol, BGP)是互聯網上一個核心的去中心化自治路由協議。它通過維護IP路由表或‘前綴’表來實現自治系統(AS)之間的可達性,屬於矢量路由協議。BGP不使用傳統的內部網關協議(IGP)的指標,而使用基於路徑、網絡策略或規則集來決定路由。因此,它更適合被稱為矢量性協議,而不是路由協議。BGP,通俗的講就是講接入到機房的多條線路(如電信、聯通、移動等)融合為一體,實現多線單IP,BGP 機房的優點:服務器只需要設置一個IP地址,最佳訪問路由是由網絡上的骨干路由器根據路由跳數與其它技術指標來確定的,不會占用服務器的任何系統。

四 IPIP工作模式

1,測試環境

一個msater節點,ip 172.171.5.95,一個node節點 ip 172.171.5.96 

 

 

創建一個daemonset的應用,pod1落在master節點上 ip地址為192.168.236.3,pod2落在node節點上 ip地址為192.168.190.203

 

 

 pod1 ping pod2

 

 

 2,ping包旅程

pod1上的路由信息

 

 

 

根據路由信息,ping 192.168.190.203,會匹配到第一條。第一條路由的意思是:去往任何網段的數據包都發往網管169.254.1.1,然后從eth0網卡發送出去。

路由表中Flags標志的含義:

U up表示當前為啟動狀態

H host表示該路由為一個主機,多為達到數據包的路由

G Gateway 表示該路由是一個網關,如果沒有說明目的地是直連的

D Dynamicaly 表示該路由是重定向報文修改

M 表示該路由已被重定向報文修改

 

master節點上的路由信息

 

 

 當ping包來到master節點上,會匹配到路由tunl0。該路由的意思是:去往192.169.190.192/26的網段的數據包都發往網關172.171.5.96。因為pod1在5.95,pod2在5.96。所以數據包就通過設備tunl0發往到node節點上。 

 

 node節點上路由信息

 

 

 當node節點網卡收到數據包之后,發現發往的目的ip為192.168.190.203,於是匹配到紅線的路由。該路由的意思是:192.168.190.203是本機直連設備,去往設備的數據包發往caliadce112d250。

 那么該設備是什么呢?如果到這里你能猜出來是什么,那說明你的網絡功底是不錯的。這個設備就是veth pair的一端。在創建pod2時calico會給pod2創建一個veth pair設備。一端是pod2的網卡,另一端就是我們看到的caliadce112d250。下面我們驗證一下。在pod2中安裝ethtool工具,然后使用ethtool -S eth0,查看veth pair另一端的設備號。

 

 

 pod2 網卡另一端的設備好號是18,在node上查看編號為18的網絡設備,可以發現該網絡設備就是caliadce112d250。

 

 

 所以,node上的路由,發送caliadce112d250的數據其實就是發送到pod2的網卡中。ping包的旅行到這里就到了目的地。

 

 

 

 查看一下pod2中的路由信息,發現該路由信息和pod1中是一樣的。

 

 

 

顧名思義,IPIP網絡就是將IP網絡封裝在IP網絡里。IPIP網絡的特點是所有pod的數據流量都從隧道tunl0發送,並且在tunl0這增加了一層傳輸層的封包。

在master網卡上抓包分析該過程。

 

 

 

 

 

 打開ICMP 285,pod1 ping pod2的數據包,能夠看到該數據包一共5層,其中IP所在的網絡層有兩個,分別是pod之間的網絡和主機之間的網絡封裝。

 

 

 

根據數據包的封裝順序,應該是在pod1 ping pod2的ICMP包外面多封裝了一層主機之間的數據包。

 

 

 

之所以要這樣做是因為tunl0是一個隧道端點設備,在數據到達時要加上一層封裝,便於發送到對端隧道設備中。 

 

 兩層IP封裝的具體內容

 

 

 IPIP的連接方式:

 

 

 

五 BGP工作模式

1,修改配置

 

 

 2,對比

BGP網絡相比較IPIP網絡,最大的不同之處就是沒有了隧道設備 tunl0。 前面介紹過IPIP網絡pod之間的流量發送tunl0,然后tunl0發送對端設備。BGP網絡中,pod之間的流量直接從網卡發送目的地,減少了tunl0這個環節。

master節點上路由信息。從路由信息來看,沒有tunl0設備。 

 

 同樣創建一個daemonset,pod1在master節點上,pod2在node節點上。

 

3 ping 包之旅

pod1 ping pod2。

 

 

根據pod1中的路由信息,ping包通過eth0網卡發送到master節點上。

master節點上路由信息。根據匹配到的 192.168.190.192 路由,該路由的意思是:去往網段192.168.190.192/26 的數據包,發送網段172.171.5.96。而5.96就是node節點。所以,該數據包直接發送了5.96節點。 

 

 node節點上的路由信息。根據匹配到的192.168.190.192的路由,數據將發送給 cali6fcd7d1702e設備,該設備和上面分析的是一樣,為pod2的veth pair 的一端。數據就直接發送給pod2的網卡。

 

 當pod2對ping包做出回應之后,數據到達node節點上,匹配到192.168.236.0的路由,該路由說的是:去往網段192.168.236.0/26 的數據,發送給網關 172.171.5.95。數據包就直接通過網卡ens160,發送到master節點上。

 

 通過在master節點上抓包,查看經過的流量,篩選出ICMP,找到pod1 ping pod2的數據包。

 

 可以看到BGP網絡下,沒有使用IPIP模式,數據包是正常的封裝。

 

 值得注意的是mac地址的封裝。192.168.236.0是pod1的ip,192.168.190.198是pod2的ip。而源mac地址是 master節點網卡的mac,目的mac是node節點的網卡的mac。這說明,在 master節點的路由接收到數據,重新構建數據包時,使用arp請求,將node節點的mac拿到,然后封裝到數據鏈路層。

 

 BGP的連接方式:

 

 

六 兩種網絡對比

IPIP網絡

流量:tunlo設備封裝數據,形成隧道,承載流量。

適用網絡類型:適用於互相訪問的pod不在同一個網段中,跨網段訪問的場景。外層封裝的ip能夠解決跨網段的路由問題。

效率:流量需要tunl0設備封裝,效率略低

BGP網絡

流量:使用路由信息導向流量

適用網絡類型:適用於互相訪問的pod在同一個網段,適用於大型網絡。

效率:原生hostGW,效率高

七 存在問題

(1) 缺點租戶隔離問題

Calico 的三層方案是直接在 host 上進行路由尋址,那么對於多租戶如果使用同一個 CIDR 網絡就面臨着地址沖突的問題。

 

(2) 路由規模問題

通過路由規則可以看出,路由規模和 pod 分布有關,如果 pod離散分布在 host 集群中,勢必會產生較多的路由項。

 

(3) iptables 規則規模問題

1台 Host 上可能虛擬化十幾或幾十個容器實例,過多的 iptables 規則造成復雜性和不可調試性,同時也存在性能損耗。

 

(4) 跨子網時的網關路由問題

當對端網絡不為二層可達時,需要通過三層路由機時,需要網關支持自定義路由配置,即 pod 的目的地址為本網段的網關地址,再由網關進行跨三層轉發。

 

 

原文鏈接: https://www.cnblogs.com/goldsunshine/p/10740928.html

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM