AWS上的Cilium网络拓扑和流量路径

Table of Contents1准备1.1测试环境1.2容器网和nsenter1.3验证基本连接2个出口：Pod->主机-> VPC网络2.1容器内部网络1.2 Veth对连接到主机1.3出口BPF代码1.4主机路由表2入口2.1主机路由表2.2入口BPF代码2.3集装箱收货3小结参考文献相关阅读发表于2019-10-26 |最后更新2019-10-26这篇文章探讨了在AWS上由C

rtoax

900人浏览 · 2020-10-30 21:16:33

rtoax · 2020-10-30 21:16:33 发布

Table of Contents

1准备

1.1测试环境

我们有两个K8S主机：

节点1： 10.5.2.48
节点2： 10.5.2.58

和两个豆荚：

节点110.5.2.11上的pod1
10.5.2.22node2上的pod2

节点和Pod在同一VPC中，带有VPC网关10.5.2.1。

注意：出于安全原因以及易于理解，我用伪造的IP / MAC地址代替了真实的IP / MAC地址。这不应破坏此职位的意义。

1.2容器网和 `nsenter`

我们将使用nsenter工具工具在主机上容器的网络名称空间中执行命令，格式为：

$ nsenter -t <pid> -n <command>

哪里，

-t <pid>：目标过程 <pid>
-n：输入网络名称空间
<command>：执行命令

这等效于docker exec <container> <command>，但比后者更灵活，因为通常缺少网络工具或容器内部没有特权，因此在主机上执行命令没有此限制。

获取容器进程ID：

root@node1 # docker inspect 04d740a33726 | grep Pid
            "Pid": 75869,

75869就是pid我们想要的。

1.3验证基本连接

从pod1 ping pod2，确保其可访问：

root@node1 # nsenter -t 75869 -n ping 10.5.2.22 -c 2
64 bytes from 10.5.2.22: icmp_seq=1 ttl=61 time=0.248 ms
64 bytes from 10.5.2.22: icmp_seq=2 ttl=61 time=0.208 ms

好！接下来，我们将探索这些数据包的确切路径，即网络设备，路由表，arp表，BPF挂钩。

2个出口：Pod->主机-> VPC网络

2.1容器内部网络

从pod1开始我们的旅程。检查pod1内的网络设备：

root@node1 # nsenter -t 75869 -n ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    ...
42: eth0@if43: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP
    link/ether ee:14:d3:9a:62:42 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.5.2.11/32 brd 10.5.2.11 scope global eth0

可以看出，它具有一个loopbak接口lo和一个eth0 IP地址为IP的网络接口10.5.2.11。

请注意42: eth0@if43，此特殊符号表示eth0具有 ifindex编号42，并且设备带有ifindex 42并43 组成veth对。这ifindex在主机（在本例中为node1）中是唯一的，稍后我们将再次看到。

接下来，检查容器内的路由表：

root@node1 # nsenter -t 75869 -n route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.5.2.191   0.0.0.0         UG    0      0        0 eth0
10.5.1.191   0.0.0.0         255.255.255.255 UH    0      0        0 eth0

可以看出，该Pod的网关为10.5.1.191，所有出口流量都将转发到该网关。在主机上查找网关：

root@node1 # ip a | grep 10.5.2.191 -B 2
31: cilium_host@cilium_net: <...> mtu 9001 ... qlen 1000
    link/ether 0a:ee:d6:5f:6c:32 brd ff:ff:ff:ff:ff:ff
    inet 10.5.2.191/32 scope link cilium_host

我们可以看到容器网关是由device持有的cilium_host。其实 cilium_host并cilium_net撰写另一VETH对，他们都对主机的网络空间，并将于纤毛代理开始创建。

接下来，检查容器内的ARP表：

root@node1 # nsenter -t 75869 -n arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
10.5.2.191            ether   86:05:d4:99:a9:f5   C                     eth0
10.5.2.48             ether   86:05:d4:99:a9:f5   C                     eth0

可以看出，容器的网关和主机IP都指向相同的MAC地址86:05:d4:99:a9:f5。让我们进一步确定哪个设备拥有该地址。

1.2 Veth对连接到主机

root@node1 # ip link | grep 86:05:d4:99:a9:f5 -B 1
43: lxc050ba70e11a8@if42: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc ... qlen 1000
    link/ether 86:05:d4:99:a9:f5 brd ff:ff:ff:ff:ff:ff link-netnsid 1

而已！设备lxc050ba70e11a8持有它。请注意43: lxc050ba70e11a8@if42符号，并回想一下容器的eth0实际持有ifindex=42，因此我们现在确保：

pod1通过veth对（if42 <--> if43或名称表示eth0 <--> lxc050ba70e11a8）连接到主机
Pod中的默认网关指向cilium_host主机上的设备
Pod生成流量的下一个L3跃点是 cilium_host
Pod产生流量的下一个L2跳是第ve对（lxc050ba70e11a8）的主机端

这正是Pod出口流量从容器流向主机的方式。

1.3出口BPF代码

Cilium的强大功能之一是动态流量操纵。它通过利用BPF来实现。关于此主题的详细说明不在本文的范围之内，如果您有兴趣的话，请参阅官方文档《BPF和XDP参考指南》（如果您可以阅读中文，请参阅我的翻译）。

Cilium使用tcBPF过滤容器的进出流量。让我们看一下出口部分：

root@node1:~  # tc filter show dev lxc050ba70e11a8 egress
filter protocol all pref 1 bpf
filter protocol all pref 1 bpf handle 0x1 bpf_lxc.o:[from-container] direct-action not_in_hw tag db59e2ea8177ded3

注意：如果以上命令的输出未显示该 bpf_lxc.o:[from-container] direct-action not_in_hw tag db59e2ea8177ded3 信息，则可能是您的iproute2软件包太旧了，请尝试升级到新版本。

列出此主机（节点1）上所有已加载的BPF程序：

root@node1:~  # bpftool prog
288: sched_cls  tag a390cb0eda39ede9
        loaded_at Oct 22/10:48  uid 0
        xlated 808B  jited 637B  memlock 4096B  map_ids 182,169
...
294: sched_cls  tag 596c1921e0319e72
        loaded_at Oct 22/10:48  uid 0
        xlated 176B  jited 157B  memlock 4096B
297: sched_cls  tag db59e2ea8177ded3
        loaded_at Oct 22/10:48  uid 0
        xlated 19144B  jited 11706B  memlock 20480B  map_ids 285,169,171,286,287,172,277,183,283,173,179,167,180

让我们进一步了解BPF代码/规则是什么样的。转储解释的BPF代码：

root@node1:~  # bpftool prog dump xlated id 297
   0: (bf) r6 = r1
   1: (b7) r7 = 0
   2: (63) *(u32 *)(r6 +60) = r7
   3: (63) *(u32 *)(r6 +56) = r7
   4: (63) *(u32 *)(r6 +52) = r7
   5: (63) *(u32 *)(r6 +48) = r7
   6: (63) *(u32 *)(r6 +64) = r7
   7: (18) r2 = 0xffffff5a
   9: (79) r1 = *(u64 *)(r6 +80)
  10: (79) r8 = *(u64 *)(r6 +216)
   ...

转储JITed BPF代码：

root@node1:~  # bpftool prog dump jited id 297
   0:   push   %rbp
   1:   mov    %rsp,%rbp
   4:   sub    $0x228,%rsp
   b:   sub    $0x28,%rbp
   f:   mov    %rbx,0x0(%rbp)
  13:   mov    %r13,0x8(%rbp)
  17:   mov    %r14,0x10(%rbp)
  1b:   mov    %r15,0x18(%rbp)
  1f:   xor    %eax,%eax
  21:   mov    %rax,0x20(%rbp)
  ...

好的，无需进一步挖掘。如果出口流量没有被BPF代码/规则丢弃，它将到达主机，主机路由设施将对其进行处理。

1.4主机路由表

查看主机路由表：

root@node1:~  # ip rule list
9:      from all fwmark 0x200/0xf00 lookup 2004
100:    from all lookup local
32766:  from all lookup main
32767:  from all lookup default

我们看到，有4个路由表：2004，local，main，default。检查每个内容：

root@node1:~  # ip route show table 2004
local default dev lo scope host

root@node1 $ ip route show table main
default via 10.5.2.1 dev eth0
10.5.2.0/24 dev eth0 proto kernel scope link src 10.5.2.48

来自Pod1的出口流量将到达main桌面。

注意：更具体地说，Pod IP是从ENI分配的，每个ENI都有自己的路由表以用于出口流量。在我的情况下，Pod1的IP来自节点1的默认ENI（eth0），因此流量将到达main表中。如果您有多个ENI，则此处的路由应该有所不同。

该main路由表也是节点1的默认路由表（不要”由误导default表上方，它只是一个名称表default，而不是主机的默认表）。

node1的默认网关为10.5.2.1（VPC网关）。因此，pod1的出口流量最终将被发送到VPC网关。

这样就完成了我们的交通旅程的出口部分。

2入口

如果VPC网络将流量正确路由到Node2（供应商的责任），则这些数据包将到达Node2的相应ENI。让我们来看看如何处理这些数据包。

2.1主机路由表

root@node2:~  # ip rule list
9:      from all fwmark 0x200/0xf00 lookup 2004
100:    from all lookup local
32766:  from all lookup main
32767:  from all lookup default

root@node2:~  # ip route show table 2004
local default dev lo scope host

node2 $ ip route show table main
default via 10.5.1.1 dev eth0
10.5.2.22 dev lxcd86fc95bf974 scope link
...

可以看出，Pod2有一条专用的路由：

10.5.2.22 dev lxcd86fc95bf974 scope link

这意味着所有发10.5.2.22往的流量都将转发到 lxcd86fc95bf974。

2.2入口BPF代码

Cilium将lxcxx为其创建的每个设备注入入口BPF规则。让我们检查一下这个：

root@node2:~  # tc filter show dev lxcd86fc95bf974 ingress
filter protocol all pref 1 bpf
filter protocol all pref 1 bpf handle 0x1 bpf_lxc.o:[from-container] direct-action not_in_hw tag c17fab4b3f874a54

如果您对确切的BPF代码感兴趣，那么以下步骤与我们之前的出口部分大致相同：

root@node2:~  # bpftool prog
156: sched_cls  tag a390cb0eda39ede9
        loaded_at Oct 22/10:59  uid 0
        xlated 808B  jited 637B  memlock 4096B  map_ids 46,33
...
165: sched_cls  tag c17fab4b3f874a54
        loaded_at Oct 22/10:59  uid 0
        xlated 19144B  jited 11706B  memlock 20480B  map_ids 155,33,35,156,157,36,147,47,153,37,43,31,44

root@node2:~  # bpftool prog dump xlated id 165 | head -n 10
   0: (bf) r6 = r1
   1: (b7) r7 = 0
   2: (63) *(u32 *)(r6 +60) = r7
   3: (63) *(u32 *)(r6 +56) = r7
   4: (63) *(u32 *)(r6 +52) = r7
   5: (63) *(u32 *)(r6 +48) = r7
   6: (63) *(u32 *)(r6 +64) = r7
   7: (18) r2 = 0xffffff5a
   9: (79) r1 = *(u64 *)(r6 +80)
  10: (79) r8 = *(u64 *)(r6 +216)