Cilium 系列 -4-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.

export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
cilium uninstall
BASH

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
BASH

说明如下:

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

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
BASH

配置说明如下:

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

可以查看 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
BASH

通过 --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
...
BASH

可以看到 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
...
BASH

性能测试

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

VM 间宽带

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

sudo apt install -y iperf3
BASH

测试 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.
TAP

结果为 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
YAML

结果如下:

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

使用容器内 iperf3 测试

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

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

kubectl exec -it iperf3-lnwfn -- iperf3 -s -f M
BASH

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

kubectl exec -it iperf3-g84hd -- iperf3 -c 10.0.1.39 -f M
BASH

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

结果为 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.
BASH

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

小结

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

总结

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

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

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

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

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

Cilium 系列 -4-Cilium 本地路由

前言

测试环境

VXLan 封装

这种模式的缺点

本地路由(Native-Routing)

网络需求

实战: 启用本地路由

卸载 Cilium

Helm Chart 基本安装

重启未受管节点

Helm Chart 启用本地路由

验证本地路由是否启用

性能测试

VM 间宽带

容器里部署 iperf3

使用容器内 iperf3 测试

VXLan 封装

本地路由

小结

总结

📚️参考文档

热门文章

最新文章

相关课程

相关电子书

相关实验场景