cilium透明加密（ipsec/wireguard）是节点级内核能力，工作在cni层，对go应用完全透明：加密/解密由ebpf在ip层自动完成，go代码无需修改tls配置、http客户端或证书逻辑，仅需通过ciliumnetworkpolicy或全局配置启用策略。

直接说结论：Cilium 的透明网络加密（IPSec/WireGuard）是节点级的内核层能力，和 Go 微服务代码零耦合——你不需要在 Go 里写任何加密逻辑，也不用改 HTTP 客户端或 net/http 配置。它工作在 CNI 层，对应用完全透明。

为什么 Go 代码里完全不用碰加密配置

Cilium 的透明加密作用于 pod-to-pod 流量的 IP 层（L3），所有加密/解密由 eBPF 程序在内核中完成。Go 应用发出的 http.Get("http://svc-a:8080") 或 grpc.Dial 请求，走的仍是明文语义的 socket 调用；底层数据包在离开网卡前才被自动封装进 IPSec ESP 或 WireGuard UDP 包。这意味着：

• 无需修改 Go 代码中的 TLS 配置、http.Transport 或证书加载逻辑
• http.ListenAndServeTLS 和 tls.Dial 仍照常工作，它们保护的是应用层到本机 socket 的链路，和 Cilium 保护的跨节点链路是正交叠加的
• 你看到的 tcpdump -i cilium_host 抓到的是加密后流量，但 tcpdump -i lo 或应用日志里仍是原始 HTTP/gRPC 明文

必须在 Go 服务部署 YAML 中显式启用加密策略

Cilium 不会默认开启加密，哪怕你已配置了 WireGuard 秘钥。必须通过 CiliumNetworkPolicy 或全局加密开关触发。常见错误是只跑了 cilium install --encryption wireguard，却没告诉 Cilium “哪些流量要加密”：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 全局启用（推荐测试环境）：cilium config set encryption.enabled true，然后重启 agent；此时所有跨节点 pod 流量自动走 WireGuard
• 按命名空间粒度控制：kubectl label namespace default io.cilium.encryption=true
• 精确到服务（需 Cilium v1.14+）：在 Service 的 annotation 中加 io.cilium.encryption: "true"
• 注意：IPSec 模式下必须额外指定 ipsec.key-directory 路径，且该目录需挂载进 cilium-agent 容器，否则 agent 启动失败并报错 "failed to load ipsec keys"

WireGuard 模式下 Go 服务的可观测性陷阱

WireGuard 加密后，传统抓包和策略调试方式会失效。你在 Go 服务里用 netstat -tuln 看不到加密端口，ss -tuln 也看不到 WireGuard 的 UDP 监听（它在内核态）。真正要查的不是 Go 进程，而是：

• 确认加密是否生效：cilium status --verbose | grep -A5 Encryption，输出中应含 Encryption: WireGuard 和 Key rotation: enabled
• 验证密钥分发：cilium wg list（类比 wg show），检查 peer 的 public key 和 latest handshake 时间
• 抓包位置必须选对：在 cilium_host 或物理网卡（如 eth0）上抓包，看到的是 UDP 目标端口 51820 的 WireGuard 流量；在 lxc* 或 cilium_net 上抓包，看到的是原始 TCP 流量
• 若 Go 服务间调用超时，先排除加密干扰：cilium connectivity test --encyption disabled 对比结果，而非立刻怀疑 Go 的 context.WithTimeout 设置

与 Go TLS 配置共存时的真实约束

当你的 Go 微服务既用了 Cilium 透明加密，又启用了 HTTPS（http.ListenAndServeTLS），实际链路是「TLS over WireGuard」。这没问题，但要注意两层加密的开销和故障点分离：

• WireGuard 失败表现：pod 间完全不通、cilium-health status 显示部分节点 unreachable、cilium wg list 中 handshake 时间停滞
• TLS 失败表现：HTTP 状态码 400/500、remote error: tls: bad certificate、客户端报 x509: certificate signed by unknown authority
• 不要试图让 Go 代码感知 WireGuard 状态——没有对应 API；Cilium 提供的是 cilium status 和 metrics（如 cilium_wireguard_encryption_errors_total），需通过 Prometheus+Grafana 告警，而非在 Go 的 healthz handler 里调用 exec.Command("cilium", "status")
• 密钥轮换时，WireGuard 秘钥变更不触发 Go 服务 reload，但若你把证书路径硬编码在 Go 里（如 "server.crt"），证书更新后必须重启 pod，这点和 Cilium 加密无关，纯 Go 部署惯例

最易被忽略的一点：Cilium 透明加密只保护 pod 间通信，不保护 pod 到外部 LB、Ingress 或集群外服务的流量。如果你的 Go 服务要调用 SaaS API（如 Stripe），那部分链路仍需靠 Go 自己的 http.Client 配置 TLS 证书校验，和 Cilium 完全无关。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！