Cilium 系列 -4-Cilium 本地路由

本文最后更新于：2024年7月24日晚上

系列文章

Cilium 系列文章

前言

在前文中我们提到, cilium install 默认安装后, Cilium 功能启用和禁用情况如下:

datapath mode: tunnel: 因为兼容性原因，Cilium 会默认启用 tunnel（基于 vxlan）的 datapatch 模式，也就是 overlay 网络结构。
KubeProxyReplacement: Disabled Cilium 是没有完全替换掉 kube-proxy 的，后面我们会出文章介绍如何实现替换。
IPv6 BIG TCP: Disabled 该功能要求 Linux Kernel >= 5.19, 所以在 Kernel 4.19.232 状态为禁用。
BandwidthManager: Disabled 该功能要求 Linux Kernel >= 5.1, 所以目前是禁用的
Host Routing: Legacy Legacy Host Routing 还是会用到 iptables, 性能较弱；但是 BPF-based host routing 需要 Linux Kernel >= 5.10
Masquerading: IPtables IP 伪装有几种方式：基于 eBPF 的，和基于 iptables 的。默认使用基于 iptables, 推荐使用基于 eBPF 的。
Hubble Relay: disabled 默认 Hubble 也是禁用的。

今天我们尝试关闭 tunnel 功能, 启用 本地路由 (Native-Routing) 功能以提升网络性能.

测试环境

Cilium 1.13.4
K3s v1.26.6+k3s1
OS
- 3 台 Ubuntu 23.04 VM, Kernel 6.2, x86

VXLan 封装

在未提供任何配置的情况下，Cilium 会自动以这种模式运行，因为这种模式 对底层网络基础设施的要求最低。

在这种模式下，所有集群节点都会使用基于 UDP 的封装协议 VXLAN 或 Geneve 形成网状隧道。Cilium 节点之间的所有流量都经过封装.

这种模式的缺点

MTU 开销

由于增加了封装头，有效载荷可用的 MTU 要低于本地路由（VXLAN 每个网络数据包 50 字节）。这导致特定网络连接的最大吞吐率降低。

本地路由(Native-Routing)

本地路由数据路径在 tunnel: disabled 时启用，并启用本机数据包转发模式。本机数据包转发模式利用 Cilium 运行网络的路由功能，而不是执行封装。

Native-Routing

在本地路由模式下，Cilium 会将所有未寻址到其他本地端点的数据包委托给 Linux 内核的路由子系统。这意味着，数据包的路由将如同本地进程发出数据包一样。因此，连接集群节点的网络必须能够路由 PodCIDR。

配置本地路由时，Cilium 会自动在 Linux 内核中启用 IP 转发。

网络需求

要运行本地路由模式，连接运行 Cilium 的主机的网络必须能够转发使用给 pod 或其他工作负载的地址的 IP 流量。
节点上的 Linux 内核必须知道如何转发所有运行 Cilium 的节点上 pod 或其他工作负载的数据包。这可以通过两种方式实现：
- 节点本身不知道如何路由所有 pod IP，但 网络上有路由器知道如何到达所有其他 pod。在这种情况下，Linux 节点被配置为包含指向此类路由器的默认路由。这种模式用于 云提供商网络集成。有关详细信息，请参阅 Google Cloud、AWS ENI 和 Azure IPAM。
- 每个节点都知道所有其他节点的所有 pod IP，并在 Linux 内核路由表 中插入路由来表示这一点。
  - 如果所有节点 共享一个 L2 网络 ，则可以启用选项 auto-direct-node-routes: true 来解决这个问题。 本次实验我们使用这种方式启用本地路由.
  - 否则，必须运行额外的系统组件（如 BGP 守护进程）来分发路由。有关如何使用 kube-router 项目实现这一目标，请参阅指南《使用 Kube-Router 运行 BGP》。

实战: 启用本地路由

从现在开始, 后续的 cilium 安装配置越来越复杂, 有很多定制的配置参数, 所以我们从现在开始使用 Helm Chart 方式安装 Cilium.

📚️Reference:

Helm Chart 方法适用于需要对 Cilium 安装进行 精细控制的高级安装和生产环境。它要求你为特定的 Kubernetes 环境手动选择最佳数据路径 (datapath) 和 IPAM 模式。

先使用 Helm Chart 进行最基本安装, 保证和前文的配置相同.

卸载 Cilium

首先卸载通过 cilium install 安装的 Cilium.

1 2	`export KUBECONFIG=/etc/rancher/k3s/k3s.yaml cilium uninstall`

Helm Chart 基本安装

然后, 使用 Helm Chart 进行基本安装, 保证和前文配置相同.

helm repo add cilium https://helm.cilium.io/

helm install cilium cilium/cilium --version 1.13.4 \
   --namespace kube-system \
   --set operator.replicas=1 \
   --set k8sServiceHost=192.168.2.43 \
   --set k8sServicePort=6443 \
   --set hubble.relay.enabled=true \
   --set hubble.ui.enabled=true

说明如下:

--namespace kube-system 和默认的 cilium install 保持一致, cilium 安装在 kube-system 下
operator.replicas=1 指定 Operator 副本数为 1, 默认为 2
k8sServiceHost k8sServicePort 显式指定 K8s 集群的 APIServer 的 IP 和端口
hubble.relay.enabled=true hubble.ui.enabled=true 启用 Hubble 可观察性.

重启未受管节点

如果你创建的集群中没有使用 node.cilium.io/agent-not-ready 污点的节点，则需要手动重启未托管的 pod。重启所有已运行但未以主机联网模式运行的 pod，以确保 Cilium 开始管理它们。这样做是为了确保所有在部署 Cilium 之前已经运行的 pod 都具有 Cilium 提供的网络连接，并且 NetworkPolicy 也适用于它们：

$ kubectl get pods --all-namespaces -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,HOSTNETWORK:.spec.hostNetwork --no-headers=true | grep '<none>' | awk '{print "-n "$1" "$2}' | xargs -L 1 -r kubectl delete pod
pod "helm-install-traefik-crd-wv67f" deleted
pod "helm-install-traefik-vt2zh" deleted
pod "svclb-traefik-c19bcc42-6jqxs" deleted
pod "coredns-59b4f5bbd5-qmn2k" deleted
pod "local-path-provisioner-76d776f6f9-mpct2" deleted
pod "traefik-57c84cf78d-jpx47" deleted
pod "metrics-server-68cf49699b-dxvnk" deleted
pod "hubble-ui-68fb44f6f5-z9w7c" deleted
pod "hubble-relay-5f68b89b76-s6xp5" deleted

Helm Chart 启用本地路由

helm upgrade cilium cilium/cilium \
   --namespace kube-system \
   --reuse-values \
   --set tunnel=disabled \
   --set autoDirectNodeRoutes=true \
   --set ipv4NativeRoutingCIDR=10.0.0.0/22

配置说明如下:

--reuse-values 复用上一次的 Helm Chart 安装配置
tunnel=disabled 启用本地路由模式
autoDirectNodeRoutes=true 每个节点都知道所有其他节点的所有 pod IP，并在 Linux 内核路由表 中插入路由来表示这一点。如果所有节点 共享一个 L2 网络，则可以启用选项 auto-direct-node-routes: true 来解决这个问题。
ipv4-native-routing-cidr: x.x.x.x/y 设置可执行本地路由的 CIDR。

至此, 本地路由就已经启用了. 可以再次运行相关命令来检查.

验证本地路由是否启用

首先, 未启用之前, 也就是通过 VXLan 封装时, 会有一个对应的 VXLan 网卡 cilium_vxlan. 示例如下:

5: cilium_vxlan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 52:5b:dd:37:f5:45 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::505b:ddff:fe37:f545/64 scope link
       valid_lft forever preferred_lft forever

可以查看 Cilium Agent 的日志:

$ k3s kubectl logs -f cilium-nxbsn -n kube-system|grep datapath
Defaulted container "cilium-agent" out of: cilium-agent, config (init), mount-cgroup (init), apply-sysctl-overwrites (init), mount-bpf-fs (init), clean-cilium-state (init), install-cni-binaries (init)
level=info msg="  --datapath-mode='veth'" subsys=daemon
level=info msg="clang (10.0.0) and kernel (6.2.0) versions: OK!" subsys=linux-datapath
level=info msg="linking environment: OK!" subsys=linux-datapath
level=info msg="Restored 1 node IDs from the BPF map" subsys=linux-datapath
level=info msg="Detected devices" devices="[]" subsys=linux-datapath
level=info msg="Setting up BPF datapath" bpfClockSource=jiffies bpfInsnSet=v3 subsys=datapath-loader

通过 --datapath-mode='veth' 可以判断已经成功启用本地路由.

也可以查看网卡的 mtu, cilium 的 vslan 网卡没有了, 如下:

$ ip a
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:02:20:22 brd ff:ff:ff:ff:ff:ff
    inet 172.17.236.121/20 brd 172.17.239.255 scope global dynamic noprefixroute eth0
       valid_lft 84958sec preferred_lft 84958sec
    inet6 fe80::e4ed:31d3:3101:3265/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: cilium_net@cilium_host: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether f6:e6:97:fa:8a:d9 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::f4e6:97ff:fefa:8ad9/64 scope link
       valid_lft forever preferred_lft forever
4: cilium_host@cilium_net: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 72:f7:bb:f9:31:0b brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.172/32 scope global cilium_host
       valid_lft forever preferred_lft forever
    inet6 fe80::70f7:bbff:fef9:310b/64 scope link
       valid_lft forever preferred_lft forever
15: lxca13b12696333@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether de:89:24:7b:86:e0 brd ff:ff:ff:ff:ff:ff link-netns cni-0253f30e-07bc-2273-640c-7ec96f0a30dd
    inet6 fe80::dc89:24ff:fe7b:86e0/64 scope link
       valid_lft forever preferred_lft forever
...

可以看到 cilium 和 lxc 相关的网卡, mtu 已经和 eth0 保持一致, 为: mtu 1500. 而在没启用之前, mtu 1280.

没启用本地路由, 使用 VXLan 封装的 mtu 如下:

$ ip a
...
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether aa:94:b7:b4:25:ac brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.44/24 brd 192.168.2.255 scope global dynamic noprefixroute eth0
       valid_lft 74264sec preferred_lft 74264sec
    inet6 240e:3a1:166d:dd70:4ea1:7c0c:13de:aa3/64 scope global dynamic noprefixroute
       valid_lft 208339sec preferred_lft 121939sec
    inet6 fe80::b0:3f98:e4e1:1d16/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
6: cilium_net@cilium_host: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UP group default qlen 1000
    link/ether be:0f:af:14:c7:05 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::bc0f:afff:fe14:c705/64 scope link
       valid_lft forever preferred_lft forever
7: cilium_host@cilium_net: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UP group default qlen 1000
    link/ether 1e:96:a5:af:3c:a3 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.109/32 scope global cilium_host
       valid_lft forever preferred_lft forever
    inet6 fe80::1c96:a5ff:feaf:3ca3/64 scope link
       valid_lft forever preferred_lft forever
98: lxc_health@if97: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc noqueue state UP group default qlen 1000
    link/ether 1a:41:2c:3b:18:0b brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::1841:2cff:fe3b:180b/64 scope link
       valid_lft forever preferred_lft forever
...

性能测试

通过 iperf 测试网络吞吐量. 来验证启用本地路由带来的性能提升. 我们使用 iperf3 来进行测试.

VM 间宽带

测试 VM 间原生带宽, apt 安装 iperf3:

1	`sudo apt install -y iperf3`

测试 VM 间宽带. 结果为:

$ iperf3 -c 192.168.2.3 -f M
Connecting to host 192.168.2.3, port 5201
[5] local 192.168.2.26 port 32930 connected to 192.168.2.3 port 5201
[ID] Interval           Transfer     Bitrate         Retr  Cwnd
[5]   0.00-1.00   sec  1.02 GBytes  1047 MBytes/sec    0   3.12 MBytes
[5]   1.00-2.00   sec  1.13 GBytes  1161 MBytes/sec    0   3.12 MBytes
[5]   2.00-3.00   sec  1.12 GBytes  1150 MBytes/sec    0   3.12 MBytes
[5]   3.00-4.00   sec  1.08 GBytes  1107 MBytes/sec    0   3.12 MBytes
[5]   4.00-5.00   sec  1.17 GBytes  1194 MBytes/sec    0   3.12 MBytes
[5]   5.00-6.00   sec  1.09 GBytes  1120 MBytes/sec    0   3.12 MBytes
[5]   6.00-7.00   sec  1.10 GBytes  1128 MBytes/sec    0   3.12 MBytes
[5]   7.00-8.00   sec  1.10 GBytes  1131 MBytes/sec    0   3.12 MBytes
[5]   8.00-9.00   sec  1.18 GBytes  1211 MBytes/sec    0   3.12 MBytes
[5]   9.00-10.00  sec  1.11 GBytes  1133 MBytes/sec    0   3.12 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ID] Interval           Transfer     Bitrate         Retr
[5]   0.00-10.00  sec  11.1 GBytes  1138 MBytes/sec    0             sender
[5]   0.00-10.00  sec  11.1 GBytes  1138 MBytes/sec                  receiver

iperf Done.

结果为 1138 MBytes/sec 带宽.

容器里部署 iperf3

测试 Cilium vxlan 封装和本地路由模式, 将 iperf3 部署为 Daemonset:

apiVersion: apps/v1
kind: DaemonSet
metadata:
   name: iperf3
   labels:
      app: iperf3
spec:
   selector:
      matchLabels:
        app: iperf3
   template:
      metadata:
         labels:
            app: iperf3
      spec:
         containers:
         -  name: iperf3
            image: clearlinux/iperf:3
            command: ['/bin/sh', '-c', 'sleep 1d']
            ports:
            - containerPort: 5201

结果如下:

$ k3s kubectl get pod -o wide
NAME           READY   STATUS    RESTARTS   AGE   IP           NODE          NOMINATED NODE   READINESS GATES
iperf3-dmqzb   1/1     Running   0          30s   10.0.0.13    cilium-62-1   <none>           <none>
iperf3-g84hd   1/1     Running   0          30s   10.0.2.239   cilium-62-3   <none>           <none>
iperf3-lnwfn   1/1     Running   0          30s   10.0.1.39    cilium-62-2   <none>           <none>

使用容器内 iperf3 测试

选择一个 pod 作为 server(cilium-62-2 node 上的为 server), 另一个作为 client(cilium-62-3 node 上的为 client).

Server (iperf3-lnwfn) 运行的命令为:

1	`kubectl exec -it iperf3-lnwfn -- iperf3 -s -f M`

Client (iperf3-g84hd) 运行的命令为:

1	`kubectl exec -it iperf3-g84hd -- iperf3 -c 10.0.1.39 -f M`

VXLan 封装

VXLan 封装的情况:

$ kubectl exec -it iperf3-g84hd -- iperf3 -c 10.0.1.39 -f M
Connecting to host 10.0.1.39, port 5201
[5] local 10.0.2.239 port 38102 connected to 10.0.1.39 port 5201
[ID] Interval           Transfer     Bitrate         Retr  Cwnd
[5]   0.00-1.00   sec   377 MBytes   377 MBytes/sec   46   1.19 MBytes
[5]   1.00-2.00   sec   458 MBytes   457 MBytes/sec    0   1.31 MBytes
[5]   2.00-3.00   sec   538 MBytes   538 MBytes/sec   46   1.43 MBytes
[5]   3.00-4.00   sec   538 MBytes   537 MBytes/sec    0   1.49 MBytes
[5]   4.00-5.00   sec   525 MBytes   525 MBytes/sec   14   1.50 MBytes
[5]   5.00-6.00   sec   494 MBytes   494 MBytes/sec    0   1.51 MBytes
[5]   6.00-7.00   sec   494 MBytes   494 MBytes/sec    0   1.51 MBytes
[5]   7.00-8.00   sec   494 MBytes   494 MBytes/sec   33   1.52 MBytes
[5]   8.00-9.00   sec   528 MBytes   528 MBytes/sec    0   1.53 MBytes
[5]   9.00-10.00  sec   495 MBytes   495 MBytes/sec   46   1.54 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ID] Interval           Transfer     Bitrate         Retr
[5]   0.00-10.00  sec  4.82 GBytes   494 MBytes/sec  185             sender
[5]   0.00-10.00  sec  4.82 GBytes   493 MBytes/sec                  receiver

iperf Done.

结果为 493 MBytes/sec 左右带宽, 直接少了一半.

本地路由

$ kubectl exec -it iperf3-g84hd -- iperf3 -c 10.0.1.39 -f M
Connecting to host 10.0.1.39, port 5201
[5] local 10.0.2.239 port 39518 connected to 10.0.1.39 port 5201
[ID] Interval           Transfer     Bitrate         Retr  Cwnd
[5]   0.00-1.00   sec  1.01 GBytes  1030 MBytes/sec   33   1.53 MBytes
[5]   1.00-2.00   sec  1.16 GBytes  1191 MBytes/sec    0   2.01 MBytes
[5]   2.00-3.00   sec  1.31 GBytes  1339 MBytes/sec    0   2.45 MBytes
[5]   3.00-4.00   sec  1.28 GBytes  1312 MBytes/sec    0   2.79 MBytes
[5]   4.00-5.00   sec  1.25 GBytes  1283 MBytes/sec    0   3.00 MBytes
[5]   5.00-6.00   sec  1.28 GBytes  1310 MBytes/sec    0   3.00 MBytes
[5]   6.00-7.00   sec  1.26 GBytes  1292 MBytes/sec    0   3.01 MBytes
[5]   7.00-8.00   sec  1.31 GBytes  1337 MBytes/sec    0   3.01 MBytes
[5]   8.00-9.00   sec  1.23 GBytes  1260 MBytes/sec    0   3.01 MBytes
[5]   9.00-10.00  sec  1.28 GBytes  1308 MBytes/sec   92   3.01 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ID] Interval           Transfer     Bitrate         Retr
[5]   0.00-10.00  sec  12.4 GBytes  1266 MBytes/sec  125             sender
[5]   0.00-10.00  sec  12.4 GBytes  1266 MBytes/sec                  receiver

iperf Done.

结果为 1266 MBytes/sec. 和原生的相差无几.

小结

👍️ 禁用封装(隧道 tunnel)(本次测试为 VXLAN 封装模式), 启用本地路由, 确实可以提升网络最大吞吐量.

总结

在未提供任何配置的情况下，Cilium 会自动以封装 (隧道 tunnel) 模式运行，因为这种模式 对底层网络基础设施的要求最低。

在这种模式下，所有集群节点都会使用基于 UDP 的封装协议 VXLAN 或 Geneve 形成网状隧道。

由于增加了封装头，有效载荷可用的 MTU 要低于本地路由, 这导致特定网络连接的最大吞吐率降低。

启用本地路由 (Native-Routing) 可以避免这种情况, 但是启用对本地网络有一定要求. 本次我们通过 autoDirectNodeRoutes=true 方式来进行启用.

通过 iperf 测试, 也确实证明启用本地路由可以提升吞吐量.💪

📚️参考文档

CloudNative

#CloudNative #安全 #Kubernetes #CNI #Cilium #eBPF #Observability #最佳实践 #Kernel #网络

Cilium 系列 -4-Cilium 本地路由

https://ewhisper.cn/posts/47083/

作者

东风微鸣

发布于

2023年7月21日

许可协议

Cilium 系列 -5-Cilium 替换 KubeProxy 上一篇

Cilium 系列 -3-Cilium 的基本组件和重要概念下一篇