将 Kubernetes 的 CNI 从其他组件切换为 Cilium, 已经可以有效地提升网络的性能. 但是通过对 Cilium 不同模式的切换/功能的启用, 可以进一步提升 Cilium 的网络性能. 具体调优项包括不限于:
CONFIG_PREEMPT_NONE=y
tuned-adm profile network-latency
或 network-throughput
irqbalance
,将网卡中断引脚指向特定 CPU在网络/网卡设备/OS等条件满足的情况下, 我们尽可能多地启用这些调优选项, 相关优化项会在后续文章逐一更新. 敬请期待.
今天我们来调优 Cilium, 启用带宽管理器, 以更有效地管理网络流量,改善整体应用的延迟和吞吐量。
Cilium 的带宽管理器(Bandwidth Manager)负责更有效地管理网络流量,目的是改善整体应用的延迟和吞吐量。
除了原生支持 Kubernetes Pod bandwidth annotations 外,带宽管理器(首次在 Cilium 1.9 中引入)还在所有面向外部的网络设备上设置公平队列(FQ)队列规则,以支持 TCP 堆栈步调(例如 EDT/BBR),并为网络堆栈设置最佳的服务器级 sysctl 设置。
带宽管理器的功能主要集中在两个方面,即从上层协议和从队列规范的角度。
带宽管理器启用后,默认情况下会将 TCP 拥塞控制算法切换为 BBR,从而实现更高的带宽和更低的延迟,尤其是面向互联网的流量。它将内核网络堆栈配置为更面向服务器的 sysctl 设置,这些设置已在生产环境中证明是有益的。它还重新配置了流量控制队列规则(Qdisc)层,以便在 Cilium 使用的所有面向外部的网络设备上使用多队列 Qdiscs 和公平队列(FQ)。切换到公平队列后,带宽管理器还在 eBPF 的帮助下实现了对最早出发时间 Earliest Departure Time(EDT)速率限制的支持,并且现在原生支持 kubernetes.io/egress-bandwidth
Pod 注释。
这也消除了对带宽 CNI 插件链的需求,因为该插件使用了 TBF(Token Bucket Filter, 令牌桶过滤器),在可扩展性方面受到限制。通过基于 EDT 的模型,可以避免 Qdisc 层的全局锁定,尤其是在多队列网卡的情况下。Cilium 的 eBPF 数据路径会将网络流量分类到每个节点的聚合中,然后在将数据包传递到 FQ leaf Qdiscs 前不久,通过在出口的网络数据包上设置最早离开时间戳,执行用户定义的 kubernetes.io/egress-bandwidth
速率。Qdiscs 维护每个流的状态,并根据数据包的时间戳来安排数据包的离开时间,确保数据包不会在时间戳规定的时间之前被发送出去。通过 eBPF 的灵活性,对 Pod 聚合体的分类不仅适用于直接路由,也适用于隧道或使用 L7 代理的情况。
与 eBPF 和 FQ 相比,在使用 HTB(Hierarchical Token Bucket, 分层令牌桶)进行速率限制的情况下,对应用延迟进行的评估表明,在改善传输延迟的同时,CPU 利用率也能显著降低。当 eBPF 和 FQ 结合使用时,第 95 百分位的延迟降低了约 20 倍,第 99 百分位的延迟降低了约 10 倍。
要启用带宽管理器:
helm upgrade cilium cilium/cilium --version 1.13.4 \
--namespace kube-system \
--reuse-values \
--set bandwidthManager.enabled=true
要验证您的安装是否与带宽管理器一起运行,请在任何 Cilium pod 中运行 cilium status
,并查找报告 "BandwidthManager"状态的行,该行应显示 "EDT with BPF"。
具体如下:
$ kubectl -n kube-system exec ds/cilium -- cilium status | grep BandwidthManager
BandwidthManager: EDT with BPF [CUBIC] [eth0]
下面是一个应用 Pod 的部署示例,由于使用了 kubernetes.io/egress-bandwidth
注释,其出口带宽被限制为 50 Mbit/s:
cat << EOF | kubectl apply -f -
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: iperf3
labels:
app: iperf3
spec:
selector:
matchLabels:
app: iperf3
template:
metadata:
labels:
app: iperf3
annotations:
kubernetes.io/egress-bandwidth: '50M'
spec:
containers:
- name: iperf3
image: clearlinux/iperf:3
command: ['/bin/sh', '-c', 'sleep 1d']
ports:
- containerPort: 5201
EOF
结果如下:
$ k3s kubectl get pod -o wide -l app=iperf3
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
iperf3-g54rg 1/1 Running 0 2m9s 10.0.0.127 cilium-62-1 <none> <none>
iperf3-4fwnf 1/1 Running 0 97s 10.0.1.101 cilium-62-2 <none> <none>
iperf3-688m4 1/1 Running 0 65s 10.0.2.247 cilium-62-3 <none> <none>
选择一个 pod 作为 server(cilium-62-2 node 上的为 server), 另一个作为 client(cilium-62-3 node 上的为client).
Server (iperf3-4fwnf) 运行的命令为:
kubectl exec -it iperf3-4fwnf -- iperf3 -s -f M
Client (iperf3-688m4) 运行的命令为:
$ kubectl exec -it iperf3-688m4 -- iperf3 -c 10.0.1.101 -f m
Connecting to host 10.0.1.101, port 5201
[ 5] local 10.0.2.247 port 33300 connected to 10.0.1.101 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 7.51 MBytes 63.0 Mbits/sec 0 385 KBytes
[ 5] 1.00-2.00 sec 5.65 MBytes 47.4 Mbits/sec 0 385 KBytes
[ 5] 2.00-3.00 sec 5.65 MBytes 47.4 Mbits/sec 0 385 KBytes
[ 5] 3.00-4.00 sec 5.65 MBytes 47.4 Mbits/sec 0 385 KBytes
[ 5] 4.00-5.00 sec 5.65 MBytes 47.4 Mbits/sec 0 385 KBytes
[ 5] 5.00-6.00 sec 5.65 MBytes 47.4 Mbits/sec 0 385 KBytes
[ 5] 6.00-7.00 sec 5.65 MBytes 47.4 Mbits/sec 0 385 KBytes
[ 5] 7.00-8.00 sec 5.65 MBytes 47.4 Mbits/sec 0 385 KBytes
[ 5] 8.00-9.00 sec 5.65 MBytes 47.4 Mbits/sec 0 385 KBytes
[ 5] 9.00-10.00 sec 6.46 MBytes 54.2 Mbits/sec 0 385 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 59.2 MBytes 49.7 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 57.0 MBytes 47.8 Mbits/sec receiver
iperf Done.
实测带宽为: 49.7 Mbits/sec 47.8 Mbits/sec, 确实实现了 50 Mb/s 的带宽限制. 👍️👍️👍️
本文继续调优 Cilium, 启用带宽管理器, 以更有效地管理网络流量,改善整体应用的延迟和吞吐量。并实战验证了带宽限制的功能.
至此,性能调优已完成实战验证:
三人行, 必有我师; 知识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.