《5.首届eBPF大会_eBPF技术在服务网格场景应用经验总结与展望.pptx》由会员分享,可在线阅读,更多相关《5.首届eBPF大会_eBPF技术在服务网格场景应用经验总结与展望.pptx(10页珍藏版)》请在三个皮匠报告上搜索。
1、首届中国首届中国eBPFeBPF研讨会研讨会eBPF技术在服务网格场景应用经验总结与展望首届中国首届中国eBPFeBPF研讨会研讨会服务治理发展历程服务治理发展历程第一代:第一代:服务治理能力内嵌在业务代码中典型技术:SOA、ESB第二代:第二代:服务治理能力抽象到统一SDK实现典型技术:Spring Cloud、Dubbo第三代:第三代:服务治理能力归一到服务网格Node 1服务1业务逻辑服务治理Node 2服务2业务逻辑服务治理服务总线服务发现负载均衡熔断容错动态路由优势优势 简单使用依赖少 代码重复少 治理逻辑代码和业务代码分开 独立进程,用户业务非侵入、语言无关 治理逻辑升级业务无感知
2、 可以渐进的微服务化劣势劣势 代码耦合 代码重复高 运维复杂 解耦差,开发要求高 SDK语言绑定、代码侵入 基于SDK开发学习门槛高 在用系统改造代价大 治理能力升级影响用户业务 代理的性能和资源开销Node 1服务1自身业务SDK服务治理Node 2服务2自身业务SDK服务治理服务总线服务发现负载均衡熔断容错动态路由Node 1服务1自身业务服务网格服务网格服务治理Node 2服务2自身业务服务网格服务网格服务治理通信基础服务发现负载均衡熔断容错动态路由基础设施层基础设施层业务层业务层首届中国首届中国eBPFeBPF研讨会研讨会服务网格架构及问题服务网格架构及问题sidecar架构存在明显的
3、时延底噪开销,已成为业界共识的痛点问题架构存在明显的时延底噪开销,已成为业界共识的痛点问题网格数据面存在的挑战:网格数据面存在的挑战:时延性能差:时延性能差:服务访问单跳增加23ms,无法满足时延敏感应用诉求 资源占用大:资源占用大:代理节点占用大量CPU/MEM开销,业务容器部署密度低 观测运维能力不足观测运维能力不足:观测运维信息只能体现sidecar之间的部分,无法实现E2E观测运维;三方协议治理支持不足三方协议治理支持不足:只支持主流协议,协议扩展性不足https:/istio.io/latest/docs/ops/deployment/performance-and-scalabil
4、ity/时延开销大首届中国首届中国eBPFeBPF研讨会研讨会sockmapsockmap加速网格数据面加速网格数据面sockmap是linux在4.14引入的一个bpf特性,可实现socket间数据流的重定向,而无需经过复杂的内核协议栈,优化链路上socket间的数据转发性能;sockmap加速服务网格需要注意的问题:加速服务网格需要注意的问题:NAT场景场景sockmap无法配对无法配对:envoy通过iptables实现流量透明劫持(inbound:15006/outbound:15001),NAT后tcp链路两端的socket信息无法通过sockmap直接配对;社区解法:envoy的i
5、nbound/outbound端口可以事先获得,因此可以在sockmap程序中“写死”,但这并不优雅,且无法推广到其他NAT场景;首届中国首届中国eBPFeBPF研讨会研讨会sockmapsockmap加速网格数据面加速网格数据面NAT场景的基本思路:场景的基本思路:新增bpf helper bpf_sk_original_addr1,支持获取NAT前的目的地址信息;增加nat_map表,记录NAT信息;sockmap实施具体步骤:实施具体步骤:BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB状态添加client侧sockmap记录;BPF_SOCK_OPS_PASSIVE
6、_ESTABLISHED_CB状态添加server侧sockmap记录,并调用bpf_sk_original_addr获取NAT前目的地址信息,并构造正反两条nat_map记录;send流程,结合nat_map查找要redirect的目的地址信息,调用bpf_msg_redirect_hash进行redirect;close阶段在sockops hook中,清理两个map信息;1bpf helper:bpf_sk_original_addr openEuler 2209已原生支持,正在推kernel社区首届中国首届中国eBPFeBPF研讨会研讨会sockmapsockmap加速网格数据面效果加
7、速网格数据面效果在同一个节点上部署fortio的客户端以及服务端,启用或禁用sockmap进行加速。服务端运行:kubectl exec-it kubectl get pod|grep fortio|awk print$1-c fortio-/usr/bin/fortio server-http-port$ip:port/客户端运行:kubectl exec-it kubectl get pod|grep fortio|awk print$1-c fortio-/usr/bin/fortio load-c$线程数-t 30s-qps 0-jitter=true http:$ip:port/注:
8、fortio命令均是在pod内执行;测试结果:60长链接场景,平均时延相比原生网格降低时延相比原生网格降低10%15%。首届中国首届中国eBPFeBPF研讨会研讨会sockmapsockmap方案实施总结方案实施总结sockmap方案实施总结:方案实施总结:特性还不够成熟:异常场景下存在panic、内存泄漏、软狗等bug 1;机制缺陷:控制流/数据流存在时序问题,且与TFO等内核机制无法兼容2;加速效果有限:同host 15%|跨host 10%sockmap对解决网格数据面的时延底噪问题收效甚微,sidecar架构才是问题的根本所在;1 修复PR已提交kernel社区:https:/ 已提交
9、社区讨论:https:/lore.kernel.org/bpf/633492fb8ddc2_2944220881john.notmuch/问题案例:sockmap加速scp,时序错乱导致密钥认证失败clientserverSYNSYN ACKT1:bpf prog添加sockmap记录,唤醒用户进程T2:发送数据,此时sockmap无法找到对端,走tcp stack发送T3:触发bpf prog,添加sockmap记录(此时sockmap中记录完整),建链完成,唤醒用户进程ACKdata1T5:接收数据流程中,sockmap场景优先从ingress_msg获取数据data2,导致数据混乱进sk
10、_receive_queue进ingress_msgdata2T4:发送数据,此时在sockmap中找到对端socket,redirect首届中国首届中国eBPFeBPF研讨会研讨会业界探索:数据面软件百花齐放,多种技术路线并存业界探索:数据面软件百花齐放,多种技术路线并存1 https:/ meshebpf+envoy实现高性能sidecarless网格数据面观点:观点:ebpf目前存在诸多限制,能否满足网格诉求社区存在争议1本质上是per-node模式,需要解决治理的故障隔离问题路线路线3:gRPC Proxyless service MeshgRPC原生支持xds协议,实现网格能力ist
11、io新模式:新模式:ambient meshztunnel+waypoint proxy,按需部署网格L7治理能力观点:观点:缺乏断路器/故障注入等高级治理能力时延底噪问题仍然存在观点:观点:架构上退回到耦合模式,选择该网格方案就需要面对业务耦合、接口绑定、升级耦合、故障半径扩大等问题观点:观点:L7治理场景下时延底噪反而增加,且同时支持sidecar模式,使得控制面/运维变得更复杂首届中国首届中国eBPFeBPF研讨会研讨会X X网格:网格:ebpf+可编程内核实现下一代网格数据面可编程内核实现下一代网格数据面业务痛点:在google推动下,服务网格已经成为云原生基础设施之一,但是当前sid
12、ecar架构存在高时延,高底噪等问题。EnvoyCiliumMosnLinkerd-proxy控制面数据面Istiolinkerd2grpcX网格服务A流量治理服务B流量管理OS(ipstack+iptables)服务治理传统服务:耦合,单跳服务A流量治理OS(ipstack+iptables)服务治理服务B流量治理网格服务:解耦,多跳目标:回归云原生需求本源,实现应用透明、高效、低底噪的服务网格基础设施,提供业界性能最优网格数据面。面临的挑战:ebpf编程限制:循环、verify、指令数等,对于安全加密、认证等实现难度较大;能否实现零开销的网格数据面:时延性能能否达到直通访问效果;能否实现E2E的观测运维能力:网格运维能否将业务容器纳管进来;X网格 相关特性 逐步开源,敬请期待。技术效果:1/5算力资源下,HTTP转发性能7倍优于业界方案istio网格X网格非网格场景16.916.9倍倍qpsqps时延降低时延降低7.77.7倍倍首届中国首届中国eBPFeBPF研讨会研讨会 联系我们: