将 Kubernetes 的 CNI 从其他组件切换为 Cilium, 已经可以有效地提升网络的性能. 但是通过对 Cilium 不同模式的切换/功能的启用, 可以进一步提升 Cilium 的网络性能. 具体调优项包括不限于:
CONFIG_PREEMPT_NONE=ytuned-adm profile network-latency 或 network-throughputirqbalance，将网卡中断引脚指向特定 CPU在网络/网卡设备/OS等条件满足的情况下, 我们尽可能多地启用这些调优选项, 相关优化项会在后续文章逐一更新. 敬请期待.
今天我们来调优 Cilium, 启用 XDP 加速, 以便能够直接从网络驱动层处理 NodePort 等入站请求，这有助于减少延迟和扩展服务。另外并对 Cilium 性能调优做阶段总结.
Cilium 内置了对 NodePort、LoadBalancer 服务和具有外部 IP 的服务的加速支持，以便在后端位于远程节点时，将到达的请求从该节点直接推回。该功能在 Cilium 1.8 版的 XDP（eXpress Data Path）层中引入，eBPF 直接在网络驱动程序中运行，而不是在更高层中运行。
在这种情况下，网络数据包不需要一直推送到上层网络堆栈，而是在 XDP 的帮助下，Cilium 能够直接从网络驱动层处理这些请求。鉴于单个节点的转发能力大幅提高，这有助于减少延迟和扩展服务。从 Cilium 1.8 版开始，XDP 层的 kube-proxy 将被替换。
要启用 XDP 加速，请查看 Cilium 的入门指南，其中还包含在公共云提供商上进行设置的说明。
该模式设置 loadBalancer.acceleration 允许通过 native 选项启用加速。禁用选项是默认选项，用于禁用加速。大多数支持 10G 或更高速率的驱动程序在最新内核上也支持 native XDP。对于基于云的部署，这些驱动程序中的大多数都有支持本地 XDP 的 SR-IOV 变体。对于内部部署，Cilium XDP 加速可与 Kubernetes 的负载平衡器服务实现（如 MetalLB）结合使用。加速功能只能在用于直接路由的单个设备上启用。
负载平衡器加速设置支持 DSR、SNAT 和混合模式.
为了了解 Cilium 的 XDP 服务加速在全局中的位置，下文简要介绍了 Cilium 1.8 的服务负载平衡架构:
可以看出，Cilium 在 eBPF 中的 kube-proxy 替代方案在高层上由两个主要部分组成：套接字层的 eBPF 和驱动层的 eBPF。
Cilium 的服务 XDP 加速目前支持直接路由模式，与我们的 tc eBPF 实现共享相同的核心代码。在 XDP 服务转换后，提供了三种将流量重定向到远程后端的选项：DSR、SNAT 和 Hybrid。
helm upgrade cilium cilium/cilium --version 1.13.4 \
--namespace kube-system \
--reuse-values \
--set loadBalancer.acceleration=native
要验证您的安装是否使用了 XDP 加速功能，请在任何一个 Cilium pod 中运行 cilium status，并查找报告 "XDP Acceleration"状态的行，其中应显示 "Native"。如下所示:
$ kubectl -n kube-system exec ds/cilium -- cilium status --verbose | grep XDP
XDP Acceleration: Native
请注意，在 XDP 层为处理 NodePort 而从设备推回的数据包在 tcpdump 中是看不到的，因为数据包抽头是在网络堆栈的较后阶段出现的。可以使用 Cilium 的监控命令或 metric counters 来获得可见性。
Cilium 进行了初步的基准测试，将单个服务部署到一个刚刚部署了 kubeadm 的节点上，该节点的内核为 5.7，使用基于 iptables 和 ipvs 的 kube-proxy 运行以获得基线，然后将 Cilium 的 kube-proxy 替换从 tc 和 XDP 端插入 eBPF，并将其置于 eBPF 的正前方：
初步结果显示，Cilium 的 kube-proxy 替代品的 XDP 加速能力大幅提升，能够最大限度地利用数据包生成器，将所有 1000 万个传入请求推送到远程服务后端，而使用 kube-proxy 时，被测节点每秒只能为同一服务转发约 210 万个请求，其余请求则会被丢弃。在 ipvs 中也观察到了类似的情况，尽管与 iptables 相比，ipvs 对大量服务的 "首包 "可扩展性更好，但每包成本似乎略高。将 kube-proxy 替换为 Cilium 的 tc eBPF 实现，不仅解决了 "第一数据包"可扩展性问题，还提高了性能，这一点从该节点每秒约 360 万次请求中可以看出，不过这仍然无法与 Cilium 在 XDP 层进行加速时获得的显著增益相比：
比较 kube-proxy 和 Cilium 的 XDP 实现在每秒 1000 万次请求下的火焰图，还显示了在驱动程序的轮询例程中加速服务处理的捷径。此外，与在 tc 下运行 eBPF 的 Cilium 以及在 iptables 和 ipvs 模式下的 kube-proxy 相比，在 softirq 环境下，XDP 加速转发所需的处理开销要少得多。下面的测试在原本空闲的系统上运行，节点的 CPU 仅用于处理 softirq。图中显示了可用的剩余 CPU 容量。从图中可以看出，即使在特定节点每秒约 100 万个请求的低速率下，CPU 也只将约 13% 的时间用于处理 XDP 的 softirq 上下文，因此还有 87% 的剩余容量可用于其他方面，而在 kube-proxy 情况下，CPU 至少将 60% 的时间用于服务 softirq 上下文，最多只有 40% 的剩余可用容量。在每秒约 200 万或 400 万个请求的情况下，kube-proxy 的情况会变得更糟，只有 1-2% 的空闲份额，而 CPU 要花 98% 的时间在 softirq 上下文中处理数据包：
简而言之，利用 Cilium 加速 XDP 下的 Kubernetes 服务处理，可大幅提高向远程后端推送数据包的性能，同时显著降低 CPU 开销。在默认外部流量策略（externalTrafficPolicy: Cluster）下，这也提高了集群的整体容量。这意味着，将服务扩展到更多后端只能达到单个节点向这些后端转发能力的上限。不过，即使 Kubernetes 部署不需要处理那么多数据包，这些 CPU 周期也可以释放出来，用于实际的用户工作负载。
本文继续调优 Cilium, 启用 XDP 加速, 以便能够直接从网络驱动层处理 NodePort 等入站请求. 具体收益为:
至此，性能调优已完成实战验证：
至此, 我们阶段性地完成了 Cilium 主要的性能优化点.
Cilium 调优分为以下几个大维度:
Cilium 调优包括:
底层网络调优包括:
Linux Kernel 优化和升级包括:
CONFIG_PREEMPT_NONE=y其他维度调优包括:
tuned-adm profile network-latency 或 network-throughputirqbalance，将网卡中断引脚指向特定 CPU根据个人经验, 推荐的 Cilium "性能模式" 配置为:
首先, Kernel >= 5.10, 这是最新的稳定版的内核, 可以启用对调优非常重要的"基于 BPF 的主机路由"功能, 可以启用 Cilium 的大部分功能, 如下:
| Cilium 功能 | 最小 Kernel 版本 |
|---|---|
| 带宽管理器 | >= 5.1 |
| Egress Gateway | >= 5.2 |
| VXLAN 隧道端点 (VTEP) 集成 | >= 5.2 |
| WireGuard 透明加密 | >= 5.6 |
| Session Affinity的完整支持 | >= 5.7 |
| 基于 BPF 的代理重定向 | >= 5.7 |
| pod netns 中的套接字级 LB 旁路 | >= 5.7 |
| L3 设备 | >= 5.8 |
| 基于 BPF 的主机路由 | >= 5.10 |
| Pod 的 BBR 拥塞控制 | >=5.18 |
| IPv6 BIG TCP 支持 | >= 5.19 |
之后, 推荐 Cilium 配置和功能包括:
绕过 iptables 连接跟踪(Bypass iptables Connection Tracking) 就是可选项了, 因为启用了"基于 BPF 模式的主机路由"后, 是没有必要设置改选项的.
启用 IPv6 BIG TCP 不建议启用, 一方面是对内核要求较高, 需要 Linux Kernel >= 5.19; 另一方面是 IPv6 在 Kubernetes 的使用还未大规模普及.
也不建议为了提升性能而禁用 Hubble, 因为可观察性比一点点的性能提升更重要.
不建议启用 Pod 的 BBR 拥塞控制, 也是因为其对内核要求较高, 需要 Kernel >= 5.18. 有条件的可以按需启用.
最终, 安装的命令如下:
helm install cilium cilium/cilium --version 1.13.4 \
--namespace kube-system \
--set operator.replicas=2 \
--set hubble.relay.enabled=true \
--set hubble.ui.enabled=true
--set tunnel=disabled \
--set kubeProxyReplacement=strict \
--set bpf.masquerade=true \
--set loadBalancer.mode=dsr \
--set bandwidthManager.enabled=true \
--set loadBalancer.acceleration=native \
--set k8sServiceHost=${API_SERVER_IP} \
--set k8sServicePort=${API_SERVER_PORT}
🐾Warning
- 本地路由需要添加更多 helm 参数, 请按照您的实际情况进行选择和添加.
loadBalancer.mode根据您的实际需求, 从 DSR 和 hybrid 中选择. (默认 SNAT 模式)
🎉🎉🎉
三人行, 必有我师; 知识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.