weave开启fast datapath后加密失效，因其绕过内核网络栈，而加密依赖iptables+ipsec路径；二者不兼容，导致加密逻辑无法介入。
fast datapath 开启后为什么加密失效
Weave 的 fast datapath 默认绕过内核网络栈，直接在 eBPF 或内核模块层面转发流量，而 Weave 的加密（weave encrypt）依赖于 iptables + IPsec（或用户态封装）路径。两者不兼容——加密逻辑压根没机会介入 fast datapath 的包处理流程。
常见错误现象：weave status 显示 Encryption: enabled，但抓包发现所有 pod 间流量明文；或启用加密后，fast datapath 自动退回到 sleeve 模式（日志里出现 Using sleeve mode instead of fastdp）。
- 必须二选一：要么关掉
fast datapath（加--no-fastdp启动 weave），要么放弃加密 - Weave 2.8+ 尝试在 fastdp 中支持加密，但仅限于特定内核版本（≥5.10）+ eBPF 支持完整（
bpf_jit_enable=1）+ 启用--ipalloc-range与--rewrite-hosts等隐式依赖项，实际生产环境极少稳定启用 - 检查是否误启用了
--trusted-subnets：该选项会跳过加密，且与 fastdp 共存时更难排查
如何验证当前 weave 实际走的是 fastdp 还是 sleeve
不能只看启动参数或 weave status 输出，得看运行时行为。fastdp 会在内核创建 weave 类型的 eBPF 程序或加载 weave-kube 模块，而 sleeve 完全走用户态 weaver 进程 + UDP 封包。
实操建议：
- 执行
lsmod | grep weave：有输出说明 fastdp 模块已加载（sleeve 模式下为空） - 运行
bpftool prog list | grep weave：有 bpf 程序则确认 fastdp 正在用 eBPF 转发 - 查日志：
journalctl -u weave | grep -i "using.*fastdp\|sleeve"，注意首次连接建立时的协商结果 - 对比延迟：fastdp 下 pod 间 ping 延迟通常 0.5ms（尤其高并发时）
加密模式下性能下降主要卡在哪
不是加密算法本身慢（AES-GCM 硬件加速后开销极小），而是加密强制 weave 回退到 sleeve 模式后，整个链路变重：UDP 封包/解包、用户态线程调度、额外内存拷贝、conntrack 表压力上升。
典型瓶颈点：
- 每个包都要进用户态
weaver进程处理，无法利用 XDP 或 eBPF offload - sleeve 使用单个 UDP 端口承载所有节点间流量，高吞吐下容易触发
udp_recvq_overflow（查netstat -s | grep -i "packet receive errors"） - 加密密钥分发依赖 gossip，节点多于 50 时密钥同步延迟升高，新 pod 加入后短暂出现未加密通信
-
weave expose或 hostport 映射在 sleeve 模式下需额外 DNAT 规则，和加密叠加后规则冲突概率上升
生产环境推荐组合与避坑点
没有“既快又安全”的默认方案。权衡必须基于你的威胁模型和可观测能力。
- 内网可信环境（如 AWS VPC 内、K8s 集群独占物理网络）：无条件启用
fast datapath，禁用加密（--no-encrypt），这是 weave 性能基准 - 需要加密的场景（如混合云、边缘节点接入）：主动禁用 fastdp（
--no-fastdp），并确保weave进程 CPU limit ≥ 2 核，避免 sleeve 成为瓶颈 - 别指望
--password-file和--ipalloc-range同时生效还能开启 fastdp：后者要求 CNI 插件提前分配 IP，前者触发加密握手，二者在 fastdp 初始化阶段就冲突 - 升级 weave 前务必验证：新版本可能默认启用 fastdp，而旧配置文件没显式关掉它，上线后加密静默失效
最常被忽略的一点：Weave 的加密只保护 pod 到 pod 流量，NodePort、Ingress、hostNetwork pod 的出向流量都不加密——这点和 fastdp 无关，但很多人误以为开了加密就“全链路安全”了。
