native routing vs host-routing,区别?

native routing 就是 flannel 中的 host-gateway模式,纯路由模式
host-routing = ​​bpf_redict_peer()​​ 和 ​​bpf_redict_neigh()​​,跳过 iptables

这俩一个是路由,一个是绕过iptables
在 cilium 的这篇博客中,详细说了eBPF Host-Routing
https://cilium.io/blog/2021/05/11/cni-benchmark

native routing

​cilium-native-routing​

native routing 直接翻译过来就是本地路由
在官网的介绍中说的很明白,在 ​​tunnel: disabled​​ 的情况下,默认开启 native routing 的转发模式。native routing 模式利用了 Cilium 网络的路由能力,而不是二次封装的模式。

如图:Cilium 维护的是 Routing table,这意味着数据包将被路由,就和本地进程发出的数据包一样,所以连接集群节点的网络必须能都对 Pod CIDR 进行路由。
Cilium native-routing 跨节点通信_native-routing

部署为 native routing 模式

需要将之前生成的 yaml 文件修改如下图所示地方
需要先 delete 然后在 apply

# 修改tunnel 
tunnel: disabled

# 添加 pod CIDR,使 node 节点能对 pod CIDR 进行路由
native-routing-cidr: "10.0.0.0/16"

# 修改如下选项为 true
auto-direct-node-routes: "true"

Cilium native-routing 跨节点通信_native-routing_02

不同节点 pod 通信

node-1 192.168.0.120
node-2 192.168.0.130
pod1 10.0.0.85 in node-1
pod2 10.0.1.124 in node-2

root@master:~# kubectl get pod -o wide 
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
cni-test-777bbd57c8-2f986 1/1 Running 0 52s 10.0.0.85 node-1.whale.com <none> <none>
cni-test-777bbd57c8-d7wlv 1/1 Running 0 52s 10.0.1.124 node-2.whale.com <none> <none>

查看 pod1 的 ip 和mac 对应关系

root@master:~# kubectl -n kube-system exec -it cilium-5tsv8 -- cilium bpf endpoint list | grep "10.0.0.85"
10.0.0.85:0 id=1445 flags=0x0000 ifindex=34 mac=C6:6D:95:CD:34:A2 nodemac=2A:0A:D9:17:44:22

查看 pod2 的 ip 和 mac 对应关系

root@master:~# kubectl -n kube-system exec -it cilium-vrv2m -- cilium bpf endpoint list | grep "10.0.1.124"
10.0.1.124:0 id=1580 flags=0x0000 ifindex=26 mac=42:EF:F8:7A:9E:F7 nodemac=CA:0E:FA:6C:0F:30

pod 内部地址(32 位)和路由,会发现和 calico ipip 模式类似,32位的MAC地址,只能走三层路由转发。
Cilium native-routing 跨节点通信_cilium_03

宿主机路由

我们查看 node-1 路由表,目的地址为 node-2 网络的路由

root@node-1:~# route -n | grep "192.168.0.130"
10.0.1.0 192.168.0.130 255.255.255.0 UG 0 0 0 ens33

查看 node-2 路由表,目的地址为 node-1 网络的路由

root@node-2:~# route -n | grep "192.168.0.120"
10.0.0.0 192.168.0.120 255.255.255.0 UG 0 0 0 ens33

tcpdump 抓包

我们知道 pod 内部是一定会收到 request 的包和 reply 的包的
所以我们要监听 pod eth0 对应的 lxc 网卡,ens33
通过上边的 pod 和 node 网卡 对应关系

# pod1 对应的lxc 网卡
root@node-1:<sub># ip link show | grep "^34"
34: lxc449258345f59@if33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000

# pod2 对应的 lxc 网卡
root@node-2:</sub># ip link show | grep "^26"
26: lxc5f949d4fd7fa@if25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000

node-1 抓包

tcpdump -pne -i lxc449258345f59 -w pod1-lxc_native_routing.cap

tcpdump -pne -i ens33 -w node1_ens33.cap

node-2 抓包

tcpdump -pne -i lxc5f949d4fd7fa -w pod2-lxc_native_routing.cap

tcpdump -pne -i ens33 -w node2_ens33.cap

pod1 --> pod2

kubectl exec -it cni-test-777bbd57c8-2f986 -- ping -c 1 10.0.1.124

pod1-lxc_native_routing.cap

Cilium native-routing 跨节点通信_cilium_04

node1_ens33.cap

Cilium native-routing 跨节点通信_native-routing_05

pod2-lxc_native_routing.cap

Cilium native-routing 跨节点通信_cilium_06

node2_ens33.cap

Cilium native-routing 跨节点通信_native-routing_07

发现

我们发现,在 ens33 上传输的包并没有经过二次封装,而是 pod 的原始包,说明这是经过了 node 的路由,因为我们也看到宿主机的路由表中也含有到目的地址的包
也就是报文流向如下图所示:
Cilium native-routing 跨节点通信_cilium_08cilium mointor 抓包

# 准备抓包
kubectl -n kube-system exec -it cilium-vrv2m -- cilium monitor -vv > pod1.text

# ping 1个包
kubectl exec -it cni-test-777bbd57c8-2f986 -- ping -c 1 10.0.1.124

关键部分 ICMP request

  1. 第一个 Conntrack lookup 是 pod1 内部的 iptables 封装的

CPU 03: MARK 0x0 FROM 1580 DEBUG: Conntrack lookup 1/2: src=10.0.0.85:3072 dst=10.0.1.124:0
CPU 03: MARK 0x0 FROM 1580 DEBUG: Conntrack lookup 2/2: nexthdr=1 flags=0
CPU 03: MARK 0x0 FROM 1580 DEBUG: CT verdict: New, revnat=0
CPU 03: MARK 0x0 FROM 1580 DEBUG: Conntrack create: proxy-port=0 revnat=0 src-identity=3352 lb=0.0.0.0
  1. 通过这我们可以看和 Vxlan 的跨节点通信不一样的是,本次并没进行二次封装 iptables,而是直接路由到目的地址。
Ethernet  {Contents=[..14..] Payload=[..86..] SrcMAC=ca:0e:fa:6c:0f:30 DstMAC=42:ef:f8:7a:9e:f7 EthernetType=IPv4 Length=0}
IPv4 {Contents=[..20..] Payload=[..64..] Version=4 IHL=5 TOS=0 Length=84 Id=45716 Flags=DF FragOffset=0 TTL=62 Protocol=ICMPv4 Checksum=29764 SrcIP=10.0.0.85 DstIP=10.0.1.124 Options=[] Padding=[]}
ICMPv4 {Contents=[..8..] Payload=[..56..] TypeCode=EchoRequest Checksum=20861 Id=3072 Seq=0}
Failed to decode layer: No decoder for layer type Payload
CPU 03: MARK 0x0 FROM 1580 to-endpoint: 98 bytes (98 captured), state new, interface lxc5f949d4fd7fa, , identity 3352->3352, orig-ip 10.0.0.85, to endpoint 1580

Cilium native-routing 跨节点通信_native-routing_09
ICMP reply 报文

  1. Conntrack lookup 依旧还是 pod 内部的转发
CPU 03: MARK 0x0 FROM 1580 DEBUG: Conntrack lookup 1/2: src=10.0.1.124:0 dst=10.0.0.85:3072
CPU 03: MARK 0x0 FROM 1580 DEBUG: Conntrack lookup 2/2: nexthdr=1 flags=1
CPU 03: MARK 0x0 FROM 1580 DEBUG: CT entry found lifetime=16836113, revnat=0
CPU 03: MARK 0x0 FROM 1580 DEBUG: CT verdict: Reply, revnat=0
CPU 03: MARK 0x0 FROM 1580 DEBUG: Successfully mapped addr=10.0.0.85 to identity=3352
  1. 和上边一样,也是直接路由的方式,没有经过二次封装。
------------------------------------------------------------------------------
Ethernet {Contents=[..14..] Payload=[..86..] SrcMAC=00:0c:29:8f:2d:28 DstMAC=00:0c:29:79:54:d3 EthernetType=IPv4 Length=0}
IPv4 {Contents=[..20..] Payload=[..64..] Version=4 IHL=5 TOS=0 Length=84 Id=48973 Flags= FragOffset=0 TTL=63 Protocol=ICMPv4 Checksum=42635 SrcIP=10.0.1.124 DstIP=10.0.0.85 Options=[] Padding=[]}
ICMPv4 {Contents=[..8..] Payload=[..56..] TypeCode=EchoReply Checksum=22909 Id=3072 Seq=0}
Failed to decode layer: No decoder for layer type Payload
CPU 03: MARK 0x0 FROM 385 to-network: 98 bytes (98 captured), state new, orig-ip 0.0.0.0
------------------------------------------------------------------------------