Cilium 系列 -4-Cilium 本地路由

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: Cilium 系列 -4-Cilium 本地路由

前言

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

  1. datapath mode: tunnel: 因为兼容性原因,Cilium 会默认启用 tunnel(基于 vxlan)的 datapatch 模式,也就是 overlay 网络结构。
  2. KubeProxyReplacement: Disabled Cilium 是没有完全替换掉 kube-proxy 的,后面我们会出文章介绍如何实现替换。
  3. IPv6 BIG TCP: Disabled 该功能要求 Linux Kernel >= 5.19, 所以在 Kernel 4.19.232 状态为禁用。
  4. BandwidthManager: Disabled 该功能要求 Linux Kernel >= 5.1, 所以目前是禁用的
  5. Host Routing: Legacy Legacy Host Routing 还是会用到 iptables, 性能较弱;但是 BPF-based host routing 需要 Linux Kernel >= 5.10
  6. Masquerading: IPtables IP 伪装有几种方式:基于 eBPF 的,和基于 iptables 的。默认使用基于 iptables, 推荐使用 基于 eBPF 的。
  7. 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 CloudAWS ENIAzure 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 测试, 也确实证明启用本地路由可以提升吞吐量.💪

📚️参考文档

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
6月前
|
Kubernetes 安全 API
Cilium 系列 -3-Cilium 的基本组件和重要概念
Cilium 系列 -3-Cilium 的基本组件和重要概念
|
6月前
|
Kubernetes 网络协议 Linux
Cilium 系列 -7-Cilium 的 NodePort 实现从 SNAT 改为 DSR
Cilium 系列 -7-Cilium 的 NodePort 实现从 SNAT 改为 DSR
|
11月前
|
canal Kubernetes 网络架构
K8s CNI 网络最强对比:Flannel、Calico、Canal 和 Weave
Kubernetes 采用的 CNI 标准,让 Kubernetes 生态系统中的网络解决方案百花齐放。更多样的选择,意味着大多数用户将能够找到适合其当前需求和部署环境的 CNI 插件,同时还可以在环境发生变化时也能找到新的解决方案。
1930 1
|
3月前
|
Kubernetes 负载均衡 安全
Cilium使用 (Cilium 3)
Cilium使用 (Cilium 3)
81 6
|
3月前
|
监控 网络协议 Linux
Cilium架构
Cilium架构
54 5
|
3月前
|
存储 Kubernetes API
在K8S中,calico有哪些组件?都是做什么的?
在K8S中,calico有哪些组件?都是做什么的?
|
3月前
|
存储 Kubernetes 监控
在K8S中,calico有哪些组件?
在K8S中,calico有哪些组件?
|
6月前
|
Kubernetes 网络协议 Linux
Cilium 系列 -2-Cilium 快速安装
Cilium 系列 -2-Cilium 快速安装
|
6月前
|
Kubernetes 数据可视化 定位技术
Cilium 系列 -14-Cilium NetworkPolicy 简介
Cilium 系列 -14-Cilium NetworkPolicy 简介
|
6月前
|
Kubernetes 网络协议 Linux
Cilium 系列 -5-Cilium 替换 KubeProxy
Cilium 系列 -5-Cilium 替换 KubeProxy