一文明白calico的IPIP网络模式

网络 网络管理
本文主要分析k8s中网络组件calico的 IPIP网络模式。旨在理解IPIP网络模式下产生的calixxxx,tunl0等设备以及跨节点网络通信方式。

[[397426]]

前言

本文主要分析k8s中网络组件calico的 IPIP网络模式。旨在理解IPIP网络模式下产生的calixxxx,tunl0等设备以及跨节点网络通信方式。可能看着有点枯燥,但是请花几分钟时间坚持看完,如果看到后面忘了前面,请反复看两遍,这几分钟时间一定你会花的很值。

一、calico介绍

Calico是Kubernetes生态系统中另一种流行的网络选择。虽然Flannel被公认为是最简单的选择,但Calico以其性能、灵活性而闻名。Calico的功能更为全面,不仅提供主机和pod之间的网络连接,还涉及网络安全和管理。Calico CNI插件在CNI框架内封装了Calico的功能。

Calico是一个基于BGP的纯三层的网络方案,与OpenStack、Kubernetes、AWS、GCE等云平台都能够良好地集成。Calico在每个计算节点都利用Linux Kernel实现了一个高效的虚拟路由器vRouter来负责数据转发。每个vRouter都通过BGP1协议把在本节点上运行的容器的路由信息向整个Calico网络广播,并自动设置到达其他节点的路由转发规则。Calico保证所有容器之间的数据流量都是通过IP路由的方式完成互联互通的。Calico节点组网时可以直接利用数据中心的网络结构(L2或者L3),不需要额外的NAT、隧道或者Overlay Network,没有额外的封包解包,能够节约CPU运算,提高网络效率。

此外,Calico基于iptables还提供了丰富的网络策略,实现了Kubernetes的Network Policy策略,提供容器间网络可达性限制的功能。

calico官网:https://www.projectcalico.org/

二、calico架构及核心组件

架构图如下:

calico核心组件:

  • Felix:运行在每个需要运行workload的节点上的agent进程。主要负责配置路由及 ACLs(访问控制列表) 等信息来确保 endpoint 的连通状态,保证跨主机容器的网络互通;
  • etcd:强一致性、高可用的键值存储,持久存储calico数据的存储管理系统。主要负责网络元数据一致性,确保Calico网络状态的准确性;
  • BGP Client(BIRD):读取Felix设置的内核路由状态,在数据中心分发状态。
  • BGP Route Reflector(BIRD):BGP路由反射器,在较大规模部署时使用。如果仅使用BGP Client形成mesh全网互联就会导致规模限制,因为所有BGP client节点之间两两互联,需要建立N^2个连接,拓扑也会变得复杂。因此使用reflector来负责client之间的连接,防止节点两两相连。

三、calico工作原理

Calico把每个操作系统的协议栈认为是一个路由器,然后把所有的容器认为是连在这个路由器上的网络终端,在路由器之间跑标准的路由协议——BGP的协议,然后让它们自己去学习这个网络拓扑该如何转发。所以Calico方案其实是一个纯三层的方案,也就是说让每台机器的协议栈的三层去确保两个容器,跨主机容器之间的三层连通性。

四、calico的两种网络方式

1)IPIP

把 IP 层封装到 IP 层的一个 tunnel。它的作用其实基本上就相当于一个基于IP层的网桥!一般来说,普通的网桥是基于mac层的,根本不需 IP,而这个 ipip 则是通过两端的路由做一个 tunnel,把两个本来不通的网络通过点对点连接起来。ipip 的源代码在内核 net/ipv4/ipip.c 中可以找到。

2)BGP

边界网关协议(Border Gateway Protocol, BGP)是互联网上一个核心的去中心化自治路由协议。它通过维护IP路由表或‘前缀’表来实现自治系统(AS)之间的可达性,属于矢量路由协议。BGP不使用传统的内部网关协议(IGP)的指标,而使用基于路径、网络策略或规则集来决定路由。因此,它更适合被称为矢量性协议,而不是路由协议。

五、IPIP网络模式分析

由于个人环境中使用的是IPIP模式,因此接下来这里分析一下这种模式。

  1. # kubectl get po -o wide -n paas | grep hello 
  2. demo-hello-perf-d84bffcb8-7fxqj   1/1     Running   0          9d      10.20.105.215   node2.perf  <none>           <none> 
  3. demo-hello-sit-6d5c9f44bc-ncpql   1/1     Running   0          9d      10.20.42.31     node1.sit   <none>           <none> 

进行ping测试

这里在demo-hello-perf这个pod中ping demo-hello-sit这个pod。

  1. root@demo-hello-perf-d84bffcb8-7fxqj:/# ping 10.20.42.31 
  2. PING 10.20.42.31 (10.20.42.31) 56(84) bytes of data. 
  3. 64 bytes from 10.20.42.31: icmp_seq=1 ttl=62 time=5.60 ms 
  4. 64 bytes from 10.20.42.31: icmp_seq=2 ttl=62 time=1.66 ms 
  5. 64 bytes from 10.20.42.31: icmp_seq=3 ttl=62 time=1.79 ms 
  6. ^C 
  7. --- 10.20.42.31 ping statistics --- 
  8. 3 packets transmitted, 3 received, 0% packet loss, time 6ms 
  9. rtt min/avg/max/mdev = 1.662/3.015/5.595/1.825 ms 

进入pod demo-hello-perf中查看这个pod中的路由信息

  1. root@demo-hello-perf-d84bffcb8-7fxqj:/# route -n 
  2. Kernel IP routing table 
  3. Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
  4. 0.0.0.0         169.254.1.1     0.0.0.0         UG    0      0        0 eth0 
  5. 169.254.1.1     0.0.0.0         255.255.255.255 UH    0      0        0 eth0 

根据路由信息,ping 10.20.42.31,会匹配到第一条。

第一条路由的意思是:去往任何网段的数据包都发往网关169.254.1.1,然后从eth0网卡发送出去。

demo-hello-perf所在的node node2.perf 宿主机上路由信息如下:

  1. # route -n 
  2. Kernel IP routing table 
  3. Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
  4. 0.0.0.0         172.16.36.1     0.0.0.0         UG    100    0        0 eth0 
  5. 10.20.42.0      172.16.35.4     255.255.255.192 UG    0      0        0 tunl0 
  6. 10.20.105.196   0.0.0.0         255.255.255.255 UH    0      0        0 cali4bb1efe70a2 
  7. 169.254.169.254 172.16.36.2     255.255.255.255 UGH   100    0        0 eth0 
  8. 172.16.36.0     0.0.0.0         255.255.255.0   U     100    0        0 eth0 
  9. 172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0 

可以看到一条Destination为 10.20.42.0的路由。

意思是:当ping包来到master节点上,会匹配到路由tunl0。该路由的意思是:去往10.20.42.0/26的网段的数据包都发往网关172.16.35.4。因为demo-hello-perf的pod在172.16.36.5上,demo-hello-sit的pod在172.16.35.4上。所以数据包就通过设备tunl0发往到node节点上。

demo-hello-sit所在的node node1.sit 宿主机上路由信息如下:

  1. # route -n 
  2. Kernel IP routing table 
  3. Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
  4. 0.0.0.0         172.16.35.1     0.0.0.0         UG    100    0        0 eth0 
  5. 10.20.15.64     172.16.36.4     255.255.255.192 UG    0      0        0 tunl0 
  6. 10.20.42.31     0.0.0.0         255.255.255.255 UH    0      0        0 cali04736ec14ce 
  7. 10.20.105.192   172.16.36.5     255.255.255.192 UG    0      0        0 tunl0 

当node节点网卡收到数据包之后,发现发往的目的ip为10.20.42.31,于是匹配到Destination为10.20.42.31的路由。

该路由的意思是:10.20.42.31是本机直连设备,去往设备的数据包发往cali04736ec14ce

为什么这么奇怪会有一个名为cali04736ec14ce的设备呢?这是个啥玩意儿呢?

其实这个设备就是veth pair的一端。在创建demo-hello-sit 时calico会给demo-hello-sit创建一个veth pair设备。一端是demo-hello-sit 的网卡,另一端就是我们看到的cali04736ec14ce

接着验证一下。我们进入demo-hello-sit 的pod,查看到 4 号设备后面的编号是:122964

  1. root@demo-hello-sit--6d5c9f44bc-ncpql:/# ip a 
  2. 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 
  3.     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
  4.     inet 127.0.0.1/8 scope host lo 
  5.        valid_lft forever preferred_lft forever 
  6. 2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000 
  7.     link/ipip 0.0.0.0 brd 0.0.0.0 
  8. 4: eth0@if122964: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1380 qdisc noqueue state UP group default  
  9.     link/ether 9a:7d:b2:26:9b:17 brd ff:ff:ff:ff:ff:ff link-netnsid 0 
  10.     inet 10.20.42.31/32 brd 10.20.42.31 scope global eth0 
  11.        valid_lft forever preferred_lft forever 

然后我们登录到demo-hello-sit这个pod所在的宿主机查看

  1. # ip a | grep -A 5 "cali04736ec14ce" 
  2. 122964: cali04736ec14ce@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1380 qdisc noqueue state UP group default  
  3.     link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 16 
  4.     inet6 fe80::ecee:eeff:feee:eeee/64 scope link  
  5.        valid_lft forever preferred_lft forever 
  6. 120918: calidd1cafcd275@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1380 qdisc noqueue state UP group default  
  7.     link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 2 

发现pod demo-hello-sit中 的另一端设备编号和这里在node上看到的cali04736ec14ce编号122964是一样的

所以,node上的路由,发送cali04736ec14ce网卡设备的数据其实就是发送到了demo-hello-sit的这个pod中去了。到这里ping包就到了目的地。

注意看 demo-hello-sit这个pod所在的宿主机的路由,有一条 Destination为10.20.105.192的路由

  1. # route -n 
  2. Kernel IP routing table 
  3. Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
  4. ... 
  5. 0.0.0.0         172.16.35.1     0.0.0.0         UG    100    0        0 eth0 
  6. 10.20.105.192   172.16.36.5     255.255.255.192 UG    0      0        0 tunl0 
  7. ... 

再查看一下demo-hello-sit的pod中路由信息,和demo-hello-perf的pod中是一样的。

所以综合上述例子来看,IPIP的网络模式就是将IP网络封装了一层。特点就是所有pod的数据流量都从隧道tunl0发送,并且tunl0这里增加了一层传输层的封包操作。

六、抓包分析

在demo-hello-perf这个pod中ping demo-hello-sit这个pod,接着在demo-hello-sit这个pod所在的宿主机进行tcpdump

  1. # tcpdump  -i eth0 -nn -w icmp_ping.cap 
  2. tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 

在demo-hello-perf这个pod中进行ping demo-hello-sit的操作

  1. root@demo-hello-perf-d84bffcb8-7fxqj:/# ping 10.20.42.31 
  2. PING 10.20.42.31 (10.20.42.31) 56(84) bytes of data. 
  3. 64 bytes from 10.20.42.31: icmp_seq=1 ttl=62 time=5.66 ms 
  4. 64 bytes from 10.20.42.31: icmp_seq=2 ttl=62 time=1.68 ms 
  5. 64 bytes from 10.20.42.31: icmp_seq=3 ttl=62 time=1.61 ms 
  6. ^C 
  7. --- 10.20.42.31 ping statistics --- 
  8. 3 packets transmitted, 3 received, 0% packet loss, time 6ms 
  9. rtt min/avg/max/mdev = 1.608/2.983/5.659/1.892 ms 

结束抓包后下载icmp_ping.cap到本地windows进行抓包分析

能看到该数据包一共5层,其中IP(Internet Protocol)所在的网络层有两个,分别是pod之间的网络和主机之间的网络封装。

红色框选的是两个pod所在的宿主机,蓝色框选的是两个pod的ip,src表示发起ping操作的pod所在的宿主机ip以及发起ping操作的pod的ip,dst表示被ping的pod所在的宿主机ip及被ping的pod的ip

根据数据包的封装顺序,应该是在demo-hello-perf ping demo-hello-sit的ICMP包外面多封装了一层主机之间的数据包。

可以看到每个数据报文共有两个IP网络层,内层是Pod容器之间的IP网络报文,外层是宿主机节点的网络报文(2个node节点)。之所以要这样做是因为tunl0是一个隧道端点设备,在数据到达时要加上一层封装,便于发送到对端隧道设备中。

两层封包的具体内容如下:

Pod间的通信经由IPIP的三层隧道转发,相比较VxLAN的二层隧道来说,IPIP隧道的开销较小,但其安全性也更差一些。

七、pod到svc的访问

查看service

  1. # kubectl get svc -o wide -n paas | grep hello 
  2. demo-hello-perf              ClusterIP   10.10.255.18    <none>        8080/TCP              10d    appEnv=perf,appName=demo-hello 
  3. demo-hello-sit               ClusterIP   10.10.48.254    <none>        8080/TCP              10d    appEnv=sit,appName=demo-hello 

在pod demo-hello-sit 的宿主机上抓包

  1. # tcpdump -i eth0 -nn -w svc.cap 
  2. tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 

测试访问,在demo-hello-sit中curl demo-hello-perf的svc的地址和端口

  1. root@demo-hello-perf-d84bffcb8-7fxqj:/# curl -I http://10.10.48.254:8080/actuator/health 
  2. HTTP/1.1 200 
  3. Content-Type: application/vnd.spring-boot.actuator.v3+json 
  4. Transfer-Encoding: chunked 
  5. Date: Fri, 30 Apr 2021 01:42:56 GMT 
  6.  
  7. root@demo-hello-perf-d84bffcb8-7fxqj:/# curl -I http://10.10.48.254:8080/actuator/health 
  8. HTTP/1.1 200 
  9. Content-Type: application/vnd.spring-boot.actuator.v3+json 
  10. Transfer-Encoding: chunked 
  11. Date: Fri, 30 Apr 2021 01:42:58 GMT 
  12.  
  13. root@demo-hello-perf-d84bffcb8-7fxqj:/# curl -I http://10.10.48.254:8080/actuator/health 
  14. HTTP/1.1 200 
  15. Content-Type: application/vnd.spring-boot.actuator.v3+json 
  16. Transfer-Encoding: chunked 
  17. Date: Fri, 30 Apr 2021 01:42:58 GMT 

结束抓包,下载svc.cap文件放到wireshark中打开查看


可以看到wireshark中Src和Dst的结果。任然是和上面pod中访问pod的ip地址一样。这里Src和Dst任然是两个pod的宿主机的内网ip和两个pod自己的ip地址。是用ipip的方式进行通信的。

通过以上例子演示,应该就看明白了IPIP网络模式的通信方式了吧!

 

责任编辑:姜华 来源: 运维开发故事
相关推荐

2022-05-05 16:47:24

Docker网络空间容器

2020-07-10 08:03:35

DNS网络ARPAne

2024-01-29 12:22:07

设计模式策略模式

2024-02-26 11:52:38

代理模式设计

2024-02-19 13:11:38

门面模式系统

2023-05-22 13:27:17

2024-02-21 12:24:33

模板设计模式框架

2024-02-23 12:11:53

装饰器模式对象

2024-01-30 13:15:00

设计模式责任链

2019-08-27 14:46:59

ElasticSearES数据库

2016-08-18 00:21:12

网络爬虫抓取网络

2022-07-05 06:30:54

云网络网络云原生

2021-12-29 18:00:19

无损网络网络通信网络

2023-03-09 08:02:30

C语言java区域

2024-02-04 12:04:17

2024-02-27 11:59:12

享元模式对象

2024-02-22 12:13:49

适配器模式代码

2024-02-18 12:36:09

2023-04-18 08:45:28

MongoDB部署模式

2023-05-29 08:45:45

Java注解数据形式
点赞
收藏

51CTO技术栈公众号