Cilium 系列 -11- 启用带宽管理器

简介: Cilium 系列 -11- 启用带宽管理器

前言

将 Kubernetes 的 CNI 从其他组件切换为 Cilium, 已经可以有效地提升网络的性能. 但是通过对 Cilium 不同模式的切换 / 功能的启用, 可以进一步提升 Cilium 的网络性能. 具体调优项包括不限于:

  • 启用本地路由(Native Routing)
  • 完全替换 KubeProxy
  • IP 地址伪装 (Masquerading) 切换为基于 eBPF 的模式
  • Kubernetes NodePort 实现在 DSR(Direct Server Return) 模式下运行
  • 绕过 iptables 连接跟踪(Bypass iptables Connection Tracking)
  • 主机路由 (Host Routing) 切换为基于 BPF 的模式 (需要 Linux Kernel >= 5.10)
  • 启用 IPv6 BIG TCP (需要 Linux Kernel >= 5.19)
  • 禁用 Hubble(但是不建议, 可观察性比一点点的性能提升更重要)
  • 修改 MTU 为巨型帧(jumbo frames) (需要网络条件允许)
  • 启用带宽管理器(Bandwidth Manager) (需要 Kernel >= 5.1)
  • 启用 Pod 的 BBR 拥塞控制 (需要 Kernel >= 5.18)
  • 启用 XDP 加速 (需要 支持本地 XDP 驱动程序)
  • (高级用户可选)调整 eBPF Map Size
  • Linux Kernel 优化和升级
  • CONFIG_PREEMPT_NONE=y
  • 其他:
  • tuned network-* profiles, 如: tuned-adm profile network-latencynetwork-throughput
  • CPU 调为性能模式
  • 停止 irqbalance,将网卡中断引脚指向特定 CPU

在网络 / 网卡设备 /OS 等条件满足的情况下, 我们尽可能多地启用这些调优选项, 相关优化项会在后续文章逐一更新. 敬请期待.

今天我们来调优 Cilium, 启用带宽管理器, 以更有效地管理网络流量,改善整体应用的延迟和吞吐量。

测试环境

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

带宽管理器

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 代理的情况。

Bandwidth Manager

与 eBPF 和 FQ 相比,在使用 HTB(Hierarchical Token Bucket, 分层令牌桶)进行速率限制的情况下,对应用延迟进行的评估 表明,在改善传输延迟的同时,CPU 利用率也能显著降低。当 eBPF 和 FQ 结合使用时,第 95 百分位的延迟降低了约 20 倍,第 99 百分位的延迟降低了约 10 倍。

需求

  • Kernel >= 5.1
  • Direct-routing 配置 或 隧道
  • 基于 eBPF 的 kube-proxy 替换

实战: 启用带宽管理器

要启用带宽管理器:

helm upgrade cilium cilium/cilium --version 1.13.4 \
  --namespace kube-system \
  --reuse-values \
  --set bandwidthManager.enabled=true 
BASH

验证

状态验证

要验证您的安装是否与带宽管理器一起运行,请在任何 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]
BASH

带宽管理器功能验证

下面是一个应用 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
BASH

结果如下:

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

选择一个 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
BASH

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

实测带宽为: 49.7 Mbits/sec 47.8 Mbits/sec, 确实实现了 50 Mb/s 的带宽限制. 👍️👍️👍️

总结

本文继续调优 Cilium, 启用带宽管理器, 以更有效地管理网络流量,改善整体应用的延迟和吞吐量。并实战验证了带宽限制的功能.

至此,性能调优已完成实战验证:

  • ✔️ 启用本地路由 (Native Routing)
  • ✔️ 完全替换 KubeProxy
  • ✔️ IP 地址伪装 (Masquerading) 切换为基于 eBPF 的模式
  • ✔️ Kubernetes NodePort 实现在 DSR(Direct Server Return) 模式下运行
  • ✔️ 绕过 iptables 连接跟踪 (Bypass iptables Connection Tracking)
  • ✔️ 主机路由 (Host Routing) 切换为基于 BPF 的模式 (需要 Linux Kernel >= 5.10)
  • ❌ 启用 IPv6 BIG TCP (需要 Linux Kernel >= 5.19, 支持的 NICs: mlx4, mlx5)
  • 由于没有支持的网卡, 无法完成验证
  • ❌ 修改 MTU 为巨型帧 (jumbo frames) (需要网络条件允许)
  • ✔️ 启用带宽管理器 (Bandwidth Manager) (需要 Kernel >= 5.1)
  • 启用 Pod 的 BBR 拥塞控制 (需要 Kernel >= 5.18)
  • 启用 XDP 加速 (需要 支持本地 XDP 驱动程序)

📚️参考文档


相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
uniapp拖动排序实现思路
uniapp拖动排序实现思路
437 0
|
人工智能 供应链 小程序
软件外包众包平台为何没有前途?深度剖析行业顽疾优雅草卓伊凡
软件外包众包平台为何没有前途?深度剖析行业顽疾优雅草卓伊凡
484 2
软件外包众包平台为何没有前途?深度剖析行业顽疾优雅草卓伊凡
|
Kubernetes 安全 Linux
在K8S中,calico和cilium这两种cni有什么区别?cailico的ipip模型和ciliume的vxlan模型,两种不通模型性能也不同,它们怎么处理数据的?
在K8S中,calico和cilium这两种cni有什么区别?cailico的ipip模型和ciliume的vxlan模型,两种不通模型性能也不同,它们怎么处理数据的?
|
Kubernetes 网络协议 Linux
Cilium 系列 -13- 启用 XDP 加速及 Cilium 性能调优总结
Cilium 系列 -13- 启用 XDP 加速及 Cilium 性能调优总结
|
算法 测试技术 开发者
测试驱动开发(TDD)实战:从理论到实践
【5月更文挑战第8天】TDD实战指南:先测试后开发,确保代码质量与可维护性。核心思想是编写测试用例→实现代码→验证→重构。优点包括提高代码质量、促进设计思考和增强可测试性。实战步骤包括编写独立、明确的测试用例,遵循最小可用原则编写代码,运行测试并分析失败原因,以及在验证通过后进行代码重构与优化。通过TDD,开发者能提升编程技能和项目成功率。
1413 3
|
Kubernetes Unix Linux
kubernetes 1.27.1 最新版集群部署
k8s最新版国内环境部署
4150 2
|
存储 关系型数据库 MySQL
失物招领|基于Web的校园失物招领系统的设计与实现
失物招领|基于Web的校园失物招领系统的设计与实现
2124 0
|
JSON 中间件 Go
给Go的Gin web框架增加 WebSocket 功能,让WebSocket 更好用
给Go的Gin web框架增加 WebSocket 功能,让WebSocket 更好用
|
存储 SQL Oracle
超大型金融机构国产数据库全面迁移成功实践
2021年9月,某超大型金融机构圆满实现最后一个规模高达20TB+核心数据库的全面迁移改造工作,也为后续向云原生多活架构演进打下了坚实的基础。该核心系统数据库全量迁移项目的成功上线,树立了金融行业践行科技强国的标杆实践。将历时一年的迁移全过程完整步骤及技术攻略做提炼梳理,便完整沉淀成了独一无二的干货、本文的全部内容。“实践出真知”,阿里云走出了助力超大型金融机构国产数据库全面迁移坚实的一步,积累了弥足珍贵的经验。
超大型金融机构国产数据库全面迁移成功实践

热门文章

最新文章