calico的核心組件
（1）Felix：Calico的客戶端，跑在每台node節點上，主要負責配置路由及ACLs等信息來確保各pod之間的連通狀態
（2）etcd：分布式鍵值存儲，主要負責網絡元數據一致性，確保Calico網絡狀態的准確性；
（3）BGPClient：主要負責把Felix寫入kernel的路由信息分發到當前Calico網絡，確保節點間通信的有效性；
（4）BGPRoute Reflector(BIRD，BGP路由反射器)：大規模部署時使用，通過一個或者多個BGPRoute Reflector來完成集中式的路由分發。
calico原理
calico是一個純三層的虛擬網絡，它沒有復用docker的docker0網橋，而是自己實現的， calico網絡不對數據包進行額外封裝，不需要NAT和端口映射，擴展性和性能都很好。Calico網絡提供了DockerDNS服務， 容器之間可以通過hostname訪問，Calico在每一個計算節點利用LinuxKernel實現了一個高效的vRouter（虛擬路由）來負責數據轉發，它會為每個容器分配一個ip，每個節點都是路由，把不同host的容器連接起來，從而實現跨主機間容器通信。而每個vRouter通過BGP協議（邊界網關協議）負責把自己節點的路由信息向整個Calico網絡內傳播——小規模部署可以直接互聯，大規模下可通過指定的BGProute reflector來完成；Calico基於iptables還提供了豐富而靈活的網絡策略，保證通過各個節點上的ACLs來提供多租戶隔離、安全組以及其他可達性限制等功能。
Calico網絡模式
1.IPIP
把一個IP數據包又套在一個IP包里，即把IP層封裝到IP層的一個 tunnel，它的作用其實基本上就相當於一個基於IP層的網橋，一般來說，普通的網橋是基於mac層的，根本不需要IP，而這個ipip則是通過兩端的路由做一個tunnel，把兩個本來不通的網絡通過點對點連接起來。
2.BGP
邊界網關協議（BorderGateway Protocol, BGP）是互聯網上一個核心的去中心化的自治路由協議。它通過維護IP路由表或‘前綴’表來實現自治系統（AS）之間的可達性，屬於矢量路由協議。BGP不使用傳統的內部網關協議（IGP）的指標，而是基於路徑、網絡策略或規則集來決定路由。因此，它更適合被稱為矢量性協議，而不是路由協議，通俗的說就是將接入到機房的多條線路（如電信、聯通、移動等）融合為一體，實現多線單IP；
BGP 機房的優點：服務器只需要設置一個IP地址，最佳訪問路由是由網絡上的骨干路由器根據路由跳數與其它技術指標來確定的，不會占用服務器的任何系統。
calico的ip-ip網絡模式
1.ip-ip模式的特點
calico以ipip模式部署完畢后，node上會有一個tunl0的網卡設備，這是ipip做隧道封裝用的,也是一種overlay模式的網絡。當我們把節點下線，calico容器都停止后，這個設備依然還在，執行 rmmodipip命令可以將它刪除。
2.開啟/禁用ip-ip
官方提供的calico.yaml模板里，默認打開了ip-ip功能，該功能會在node上創建一個設備tunl0，容器的網絡數據會經過該設備被封裝一個ip頭再轉發。這里，calico.yaml中通過修改calico-node的環境變量：CALICO_IPV4POOL_IPIP來實現ipip功能的開關：默認是Always，表示開啟；Off表示關閉ipip;calico.yaml文件的部分內容參考備注。
3.演示calico的ipip模式的ping包走向
1）測試環境
master1：172.16.0.1 node1：172.16.0.4 node2：172.16.0.5
master1節點執行如下命令，查看宿主機創建的pod有哪些
master1節點的窗口1：
kubectl get pods -o wide 顯示如下
用node1節點上的pod（nfs-provisioner-8d6dbc584-cdfxz）ping node2節點上的pod（fierce-body-redis-metrics-6cf79f9d64-v6zs2）
master1節點操作：
kubectl exec -it nfs-provisioner-8d6dbc584-cdfxz -- /bin/sh
#ping 10.244.4.188
2）ping包的旅程
查看node1節點pod上的路由信息：
master1節點新打開一個窗口2：
kubectl exec -it nfs-provisioner-8d6dbc584-cdfxz -- /bin/sh
#route -n
根據路由信息，ping 10.244.4.188，會匹配到第一條路由，第一條的路由意思是：去往任何網段的數據包都發往網關169.254.1.1，然后從eth0網卡發送出去。
路由表中Flags標志的含義：
Uup 表示當前為啟動狀態
Hhost 表示該路由是到一個主機
GGateway 表示該路由是到一個網關，如果沒有說明目的地是直連的
DDynamicaly 表示該路由是由重定向報文創建的
M 表示該路由已被重定向報文修改
node1節點上的路由信息
node1節點操作：route -n
當ping包來到node1節點上，會匹配到路由tunl0。該路由的意思是：去往10.244.4.0/24的網段的數據包都發往網關172.16.0.5。因為pod1（nfs-provisioner-8d6dbc584-cdfxz ）在172.16.0.4上，pod2（fierce-body-redis-metrics-6cf79f9d64-v6zs2 ）在172.16.0.5上。所以數據包就通過設備tunl0發往到node2節點上。
node2節點上的路由信息
node2節點操作：
route -n
當node2節點網卡收到數據包之后，發現發往的目的ip是10.244.4.188，於是匹配到藍線的路由。該路由的意思是：10.244.4.188是本機直連設備，去往設備的數據包發往cali52e15d97942。
那么該設備是什么呢？如果到這里你能猜出來是什么，那說明你的網絡功底是不錯的。這個設備就是vethpair的一端，在創建pod2（fierce-body-redis-metrics-6cf79f9d64-v6zs2 ）時calico會給pod2創建一個veth pair設備。一端是pod2的網卡，另一端就是我們看到的cali52e15d97942。下面我們驗證一下，在pod2中安裝ethtool工具，然后使用ethtool -S eth0,查看veth pair另一端的設備號。
master1節點新打開一個窗口3：
kubectl exec -it fierce-body-redis-metrics-6cf79f9d64-v6zs2 -- /bin/sh
#ethtool -S eth0
pod2網卡另一端的設備號是193，在node2上查看編號為193的網絡設備，可以發現該網絡設備就是cali52e15d97942 。
node2上操作 #ipaddr 顯示如下
所以，node2上的路由，發送cali52e15d97942的數據其實就是發送到pod2的網卡中。ping包的旅行到這里就到了目的地
查看一下pod2中的路由信息，發現該路由信息和pod1中是一樣的。
master1節點新打開一個窗口4：
kubectl exec -it fierce-body-redis-metrics-6cf79f9d64-v6zs2 -- /bin/sh
#route -n
顧名思義，IPIP網絡就是將IP網絡封裝在IP網絡里，IPIP網絡的特點是所有pod的數據流量都從隧道tunl0發送，並且在tunl0這增加了一層傳輸層的封包。
在node1節點上抓包分析該過程：
node1節點操作：tcpdump -i ens160 -vvv–w ipip.pcap
node1節點操作：把ipip.pcap上傳到桌面上，用wireshark打開分析數據包
10.244.3.14：pod1（nfs-provisioner-8d6dbc584-cdfxz ）
10.244.4.188：pod2（fierce-body-redis-metrics-6cf79f9d64-v6zs2 ）
打開ICMP 32，pod1 ping pod2的數據包，能夠看到該數據包一共5層，其中IP所在的網絡層有兩個，分別是pod之間的網絡和主機之間的網絡封裝。
根據數據包的封裝順序，應該是在pod1 ping pod2的ICMP包外面多封裝了一層主機之間的數據包。
之所以要這樣做是因為tunl0是一個隧道端點設備，在數據到達時要加上一層封裝，便於發送到對端隧道設備中。
兩層IP封裝的具體內容
IPIP的連接方式：
calico的BGP網絡模式
1.BGP網絡模式
邊界網關協議（Border Gateway Protocol, BGP）是互聯網上一個核心的去中心化自治路由協議。它通過維護IP路由表或‘前綴’表來實現自治系統（AS）之間的可達性，屬於矢量路由協議。BGP不使用傳統的內部網關協議（IGP）的指標，而使用基於路徑、網絡策略或規則集來決定路由。因此，它更適合被稱為矢量性協議，而不是路由協議；BGP，通俗的講就是將接入到機房的多條線路（如電信、聯通、移動等）融合為一體，實現多線單IP；
BGP機房的優點：服務器只需要設置一個IP地址，最佳訪問路由是由網絡上的骨干路由器根據路由跳數與其它技術指標來確定的，不會占用服務器的任何系統。世紀互聯BGP技術具備動態優選路由的能力，一點接入，輕松部署，創造無界的互聯網絡；並可多線互備，智能選路，線路互為冗余，具有較高的可靠性；隨着客戶業務的不斷增加，可方便擴充線路，保障客戶業務持續需求。
1）開啟BGP網絡模式
修改calico.yaml文件，把IPIP模式禁用即可
-name: CALICO_IPV4POOL_IPIP
value: off
2）對比
BGP網絡相比較IPIP網絡，最大的不同之處就是沒有了隧道設備 tunl0。前面介紹過IPIP網絡pod之間的流量發送tunl0，然后tunl0發送對端設備。BGP網絡中，pod之間的流量直接從網卡發送目的地，減少了tunl0這個環節。
node1節點上路由信息。從路由信息來看，沒有tunl0設備
2.測試環境
master1：172.16.0.1 node1：172.16.0.4 node2：172.16.0.5
master1節點執行如下命令，查看宿主機創建的pod有哪些
master1節點的窗口1：
kubectl get pods -o wide 顯示如下
用node1節點上的pod（nfs-provisioner-8d6dbc584-cdfxz）ping node2節點上的pod（fierce-body-redis-metrics-6cf79f9d64-v6zs2）
master1節點操作：
kubectl exec -it nfs-provisioner-8d6dbc584-cdfxz -- /bin/sh
#ping 10.244.4.188
1）ping包的走向
查看node1節點pod上的路由信息：
master1節點新打開一個窗口2：
kubectl exec -it nfs-provisioner-8d6dbc584-cdfxz -- /bin/sh
#route -n
根據node1節點上pod的路由信息，ping包通過eth0網卡發送到node1節點上。
node1節點操作：route -n 顯示如下
上面是node1節點上的路由信息。根據匹配到的10.244.4.0路由，該路由的意思是：去往網段10.244.4.0/24 的數據包都發往網關172.16.0.5。而172.16.0.5就是node2節點。所以，該數據包直接發送到了node2節點。
node2上操作： route–n 顯示如下
上面是node2節點上的路由信息。根據匹配到的10.244.4.188的路由，數據將發送給 cali52e15d97942設備，該設備和上面分析的是一樣，為node2節點上的pod2（fierce-body-redis-metrics-6cf79f9d64-v6zs2 ）的vethpair 的一端。數據就直接發送給pod2的網卡。
當pod2對ping包做出回應之后，數據到達node2節點上，匹配到10.244.3.0的路由，該路由說的是：去往網段10.244.3.0/24 的數據，發送給網關 172.16.0.4。數據包就直接通過網卡ens160，發送到node1節點上。
通過在node1節點上抓包，查看經過的流量，篩選出ICMP，找到pod1 ping pod2的數據包。
node1節點上操作：
tcpdump -i ens160 -vvv-wbgp.pcap
把上面的bgp.pcap上傳到桌面
可以看到BGP網絡下，沒有使用IPIP模式，數據包是正常的封裝。
值得注意的是mac地址的封裝。10.244.3.14是pod1的ip，10.244.4.188是pod2的ip。而源mac地址是node1節點網卡的mac，目的mac是node2節點的網卡的mac。這說明，在node1節點的路由接收到數據，重新構建數據包時，使用arp請求，將node2節點的mac拿到，然后封裝到數據鏈路層。
2）BGP的連接方式：
3.calico的兩種網絡模式對比
IPIP網絡：
流量：tunlo設備封裝數據，形成隧道，承載流量。
適用網絡類型：適用於互相訪問的pod不在同一個網段中，跨網段訪問的場景，外層封裝的ip能夠解決跨網段的路由問題。
效率：流量需要tunl0設備封裝，效率略低
BGP網絡：
流量：使用路由信息導向流量
適用網絡類型：適用於互相訪問的pod在同一個網段，適用於大型網絡。
效率：原生host-gw，效率高
4.Calico網絡優點
1）在網絡連接過程中性能高：
Calico配置第3層網絡，該網絡使用BGP路由協議在主機之間路由數據包，不需要將數據包包裝在額外的封裝層中。
2）支持網絡策略：
網絡策略是其最受追捧的功能之一。此外，Calico還可以與服務網格Istio集成，以便在服務網格層和網絡基礎架構層中解釋和實施集群內工作負載的策略，這意味着用戶可以配置強大的規則，描述Pod應如何發送和接受流量，提高安全性並控制網絡環境。
5.Calico網絡缺點
(1) 缺點租戶隔離問題
Calico 的三層方案是直接在 host 上進行路由尋址，那么對於多租戶如果使用同一個pod網絡就面臨着地址沖突的問題。
(2) 路由規模問題
通過路由規則可以看出，路由規模和 pod 分布有關，如果 pod離散分布在host 集群中，勢必會產生較多的路由項。
(3) iptables 規則規模問題
1台Host 上可能虛擬化十幾或幾十個容器實例，過多的 iptables 規則造成復雜性和不可調試性，同時也存在性能損耗。
6.flannel和calico網絡性能分析，官方指標如下
flannel host-gw = flannel vxlan-directrouting = calico bgp> calico ipip > flannel vxlan-vxlan>flannel-udp
官方推薦使用的網絡方案：
所有節點在同一個網段推薦使用calico的bgp模式和flannel的host-gw模式
性能總結分析：
Flannel的vxlan模式：封包解包采用的是內置在linux內核里的標准協議，雖然它的封包結構比UDP模式復雜，但由於所有數據封包、解包過程均在內核中完成，實際的傳輸速度要比UDP模式快許多
Flannel的host-gw模式：Flannel通過在各個節點上的Agent進程，將容器網絡的路由信息刷到主機的路由表上，這樣一來所有的主機就都有整個容器網絡的路由數據了；Host-gw的方式沒有引入像Overlay中的額外裝包解包操作，完全是普通的網絡路由機制，它的效率與虛擬機直接的通信相差無幾，但是要求所有host在二層互聯
https://mp.weixin.qq.com/s/DgidS4n9rnkOX_2vJ7MrRg
https://docs.projectcalico.org/getting-started/kubernetes/quickstart calico官網
https://www.dazhuanlan.com/2019/12/09/5dee30a8f208b/ 不錯，有待整理