北京住房城乡建设部网站首页,怎么做网络推广优化,广州市网站集约化建设工作要求,广西建设教育学会网站系列文章
Cilium 系列文章
前言
将 Kubernetes 的 CNI 从其他组件切换为 Cilium, 已经可以有效地提升网络的性能. 但是通过对 Cilium 不同模式的切换/功能的启用, 可以进一步提升 Cilium 的网络性能. 具体调优项包括不限于:
启用本地路由(Native Routing)完全替换 KubeProx…系列文章
Cilium 系列文章
前言
将 Kubernetes 的 CNI 从其他组件切换为 Cilium, 已经可以有效地提升网络的性能. 但是通过对 Cilium 不同模式的切换/功能的启用, 可以进一步提升 Cilium 的网络性能. 具体调优项包括不限于:
启用本地路由(Native Routing)完全替换 KubeProxyIP 地址伪装(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 SizeLinux Kernel 优化和升级 CONFIG_PREEMPT_NONEy 其他: tuned network-* profiles, 如: tuned-adm profile network-latency 或 network-throughputCPU 调为性能模式停止 irqbalance将网卡中断引脚指向特定 CPU
在网络/网卡设备/OS等条件满足的情况下, 我们尽可能多地启用这些调优选项, 相关优化项会在后续文章逐一更新. 敬请期待.
今天我们来调优 Cilium, 启用 XDP 加速, 以便能够直接从网络驱动层处理 NodePort 等入站请求这有助于减少延迟和扩展服务。另外并对 Cilium 性能调优做阶段总结.
XDP 加速
Cilium 内置了对 NodePort、LoadBalancer 服务和具有外部 IP 的服务的加速支持以便在后端位于远程节点时将到达的请求从该节点直接推回。该功能在 Cilium 1.8 版的 XDPeXpress Data Path层中引入eBPF 直接在网络驱动程序中运行而不是在更高层中运行。
在这种情况下网络数据包不需要一直推送到上层网络堆栈而是在 XDP 的帮助下Cilium 能够直接从网络驱动层处理这些请求。鉴于单个节点的转发能力大幅提高这有助于减少延迟和扩展服务。从 Cilium 1.8 版开始XDP 层的 kube-proxy 将被替换。
要求
Kernel 4.19.57, 5.1.16, 5.2支持原生的 XDP 驱动程序具体请查看 Cilium 的驱动程序列表Direct-routing 配置基于 eBPF 的 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 管理节点之间的服务流量仅在内核的套接字层处理在此之前不会为数据包元数据分配内存。在这一点上执行可使 Cilium 消除服务转换的每包成本。南北流量即从外部源到 Cilium 管理节点的所有入站服务流量都在尽可能靠近驱动层的地方进行处理在单个接口上进行入口和出口操作。这样就能非常快速地处理转发甚至可以在堆栈上层进行任何昂贵的操作之前将流量丢弃或反射回入站接口。处理南北流量的后一个组件则通过 XDP 进行加速。
Cilium 的服务 XDP 加速目前支持直接路由模式与我们的 tc eBPF 实现共享相同的核心代码。在 XDP 服务转换后提供了三种将流量重定向到远程后端的选项DSR、SNAT 和 Hybrid。
实施
helm upgrade cilium cilium/cilium --version 1.13.4 \--namespace kube-system \--reuse-values \--set loadBalancer.accelerationnative
验证
要验证您的安装是否使用了 XDP 加速功能请在任何一个 Cilium pod 中运行 cilium status并查找报告 XDP Acceleration状态的行其中应显示 Native。如下所示:
$ kubectl -n kube-system exec ds/cilium -- cilium status --verbose | grep XDPXDP 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 等入站请求. 具体收益为:
大幅提高向远程后端推送数据包的性能显著降低 CPU 开销提高集群的整体容量
至此性能调优已完成实战验证
✔️ 启用本地路由 (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 驱动程序
Cilium 性能调优总结
至此, 我们阶段性地完成了 Cilium 主要的性能优化点.
Cilium 调优分为以下几个大维度:
Cilium 调优底层网络调优Linux Kernel 优化和升级其他维度调优
Cilium 调优
Cilium 调优包括:
启用本地路由(Native Routing)完全替换 KubeProxyIP 地址伪装(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(但是不建议, 可观察性比一点点的性能提升更重要)启用带宽管理器(Bandwidth Manager) (需要 Kernel 5.1)启用 Pod 的 BBR 拥塞控制 (需要 Kernel 5.18)启用 XDP 加速 (需要 支持本地 XDP 驱动程序)(高级用户可选)调整 eBPF Map Size
底层网络调优
底层网络调优包括:
修改 MTU 为巨型帧(jumbo frames) (需要网络条件允许)
Linux Kernel 优化和升级
Linux Kernel 优化和升级包括:
CONFIG_PREEMPT_NONEy
其他维度调优
其他维度调优包括:
tuned network-* profiles, 如: tuned-adm profile network-latency 或 network-throughputCPU 调为性能模式停止 irqbalance将网卡中断引脚指向特定 CPU
Cilium 终极优化配置
根据个人经验, 推荐的 Cilium 性能模式 配置为:
首先, Kernel 5.10, 这是最新的稳定版的内核, 可以启用对调优非常重要的基于 BPF 的主机路由功能, 可以启用 Cilium 的大部分功能, 如下:
Cilium 功能最小 Kernel 版本带宽管理器 5.1Egress Gateway 5.2VXLAN 隧道端点 (VTEP) 集成 5.2WireGuard 透明加密 5.6Session Affinity的完整支持 5.7基于 BPF 的代理重定向 5.7pod netns 中的套接字级 LB 旁路 5.7L3 设备 5.8基于 BPF 的主机路由 5.10Pod 的 BBR 拥塞控制5.18IPv6 BIG TCP 支持 5.19
之后, 推荐 Cilium 配置和功能包括:
禁用隧道, 禁用加密启用本地路由(Native Routing)完全替换 KubeProxyIP 地址伪装(Masquerading)切换为基于 eBPF 的模式Kubernetes NodePort 实现在 DSR(Direct Server Return) 模式下运行主机路由(Host Routing)切换为基于 BPF 的模式 (需要 Linux Kernel 5.10)启用带宽管理器(Bandwidth Manager) (需要 Kernel 5.1)启用 XDP 加速 (需要 支持本地 XDP 驱动程序, 但是大部分 10G/40G 网卡, 包括虚拟网卡以及云供应商已经支持了.)
绕过 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.replicas2 \--set hubble.relay.enabledtrue \--set hubble.ui.enabledtrue--set tunneldisabled \--set kubeProxyReplacementstrict \--set bpf.masqueradetrue \--set loadBalancer.modedsr \--set bandwidthManager.enabledtrue \--set loadBalancer.accelerationnative \--set k8sServiceHost${API_SERVER_IP} \--set k8sServicePort${API_SERVER_PORT} Warning 本地路由需要添加更多 helm 参数, 请按照您的实际情况进行选择和添加.loadBalancer.mode 根据您的实际需求, 从 DSR 和 hybrid 中选择. (默认 SNAT 模式) ️参考文档
LoadBalancer NodePort XDP Acceleration - Kubernetes Without kube-proxy — Cilium 1.13.4 documentationCilium 1.8: XDP Load Balancing, Cluster-wide Flow Visibility, Host Network Policy, Native GKE Azure modes, Session Affinity, CRD-mode Scalability, Policy Audit mode, ...Tuning Guide — Cilium 1.13.4 documentation 三人行, 必有我师; 知识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.
