Cilium native-routing 跨节点通信

Posted 2022-05-07 whale_life

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 进行路由。

部署为 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"

不同节点 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地址，只能走三层路由转发。

宿主机路由

我们查看 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

node1_ens33.cap

pod2-lxc_native_routing.cap

node2_ens33.cap

发现

我们发现，在 ens33 上传输的包并没有经过二次封装，而是 pod 的原始包，说明这是经过了 node 的路由，因为我们也看到宿主机的路由表中也含有到目的地址的包
也就是报文流向如下图所示：
cilium 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

2. 通过这我们可以看和 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

ICMP reply 报文

3. 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

4. 和上边一样，也是直接路由的方式，没有经过二次封装。

------------------------------------------------------------------------------
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
------------------------------------------------------------------------------