Cilium、Hubble 与 Kubernetes eBPF 网络生产运维实战
Cilium 使用 eBPF 实现容器网络、Service 负载均衡、网络策略和流量可观测，Hubble 则将内核数据路径转化为可查询的连接与安全事件。它能简化部分 iptables 路径并提供更细粒度的身份策略，但也要求运维人员理解路由、隧道、BPF Map、内核、MTU、Conntrack 和 Kubernetes 身份。本文建立从架构选型到生产排障的完整方法。
CNI、kube-proxy replacement、路由模式、加密和 MTU 都属于高风险集群网络变更。生产切换前必须在同版本测试集群演练，准备节点回滚、工作负载迁移和控制面访问的备用路径。
一、先理解数据路径
Pod veth
↓ eBPF 程序与策略
节点网络设备
├─ 同节点 Pod
├─ 跨节点直连路由 / 隧道
├─ Service 负载均衡
└─ 出入口、NodePort、LoadBalancer
Cilium Agent 以 DaemonSet 运行，Operator 处理部分集群级任务；Hubble Relay 汇聚节点事件，Hubble UI 提供可视化。BPF Map 保存 Service、Endpoint、策略、连接等运行状态。
二、规划前必须确认
- 内核版本、BTF 与 eBPF 能力；
- Pod CIDR、Service CIDR、节点网段和现有路由；
- 直连路由、VXLAN/Geneve 隧道或云厂商原生路由；
- 节点防火墙、MTU、网卡 Offload 和多网卡；
- 是否替换 kube-proxy；
- NetworkPolicy 默认行为；
- 出入口、IPv6、BGP、加密和带宽限制需求；
- 峰值连接数、Service 数与 BPF Map 容量。
不要复制别人的 Helm 参数直接上线。不同云、裸金属、虚拟化和网络设备的可达性约束差异很大。
三、隧道与原生路由
隧道模式将 Pod 流量封装后在节点间传输，底层只需节点互通，部署简单但增加封装开销和 MTU 复杂度。原生路由让底层网络知道 Pod CIDR，路径更直接，但需要路由器、云路由表或 BGP 配合。
选择依据：
- 现有网络是否能发布 Pod 路由；
- 是否跨三层、可用区或复杂防火墙；
- MTU 与性能要求；
- 运维团队是否能管理 BGP；
- 故障时能否快速定位底层与 Pod 路由。
四、MTU 计算与黑洞
封装、WireGuard/IPsec、云网络都会消耗额外头部。MTU 过大可能出现小包通、大包卡住；过小则降低效率。
ip link show
ip route get <peer-node-ip>
ping -M do -s 1400 <target-ip>
tracepath <target-ip>
验证 Pod 到 Pod、Pod 到 Service、Pod 到外部和外部到入口的实际路径。不要只在节点上 Ping。
五、kube-proxy Replacement
Cilium 可使用 eBPF 实现 ClusterIP、NodePort、LoadBalancer 等 Service 转发，减少 iptables/IPVS 依赖。启用前应核对：
- Kubernetes 与 Cilium 版本兼容；
- API Server 地址可从所有节点稳定访问；
- HostPort、ExternalIPs、NodePort 和 DSR 需求；
- Source IP 保留；
- 健康检查与云负载均衡行为；
- 现有 kube-proxy 规则和切换顺序。
cilium status --wait
cilium connectivity test
kubectl -n kube-system exec ds/cilium -- cilium-dbg service list
只有连通性测试通过还不够，应回放真实入口、长连接、UDP、DNS 和跨节点流量。
六、Endpoint 与身份
Cilium 策略以安全身份而非易变 IP 为核心。标签变化可能导致身份和策略重新计算。
kubectl -n kube-system exec ds/cilium -- cilium-dbg endpoint list
kubectl -n kube-system exec ds/cilium -- cilium-dbg identity list
kubectl -n kube-system exec ds/cilium -- cilium-dbg policy get
排障先确认 Pod 是否被 Cilium 管理、Endpoint 是否 Ready、身份是否正确，再看策略是否允许。
七、NetworkPolicy 设计
Kubernetes NetworkPolicy、CiliumNetworkPolicy 与 CiliumClusterwideNetworkPolicy 的作用域不同。生产建议：
- 盘点真实依赖；
- 先观察流量；
- 从单 Namespace 灰度；
- 建立 DNS、监控、时间、镜像仓库和控制面基础允许；
- 再启用默认拒绝；
- 使用自动测试验证关键路径。
策略示意：
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: api-ingress
namespace: payment
spec:
endpointSelector:
matchLabels:
app: api
ingress:
- fromEndpoints:
- matchLabels:
k8s:io.kubernetes.pod.namespace: gateway
toPorts:
- ports:
- port: "8080"
protocol: TCP
标签键和 Namespace 匹配需按实际版本验证。
八、L7 策略的边界
L7 策略可按 HTTP 方法、路径、DNS 等控制，但需要代理参与，会增加资源与故障面。TLS 加密内容无法在没有终止 TLS 的情况下直接检查。
只对真正需要的高风险接口启用 L7 策略，监控代理延迟、拒绝、连接和资源。不要把所有内部流量都强制经过复杂 L7 规则。
九、Hubble 流量观测
Hubble 能查询 Allow/Deny、源/目标身份、协议、端口、DNS、HTTP 和丢弃原因。
hubble status
hubble observe --namespace payment --follow
hubble observe --verdict DROPPED --since 10m
hubble observe --from-pod payment/api-0 --to-port 5432
Hubble 事件属于网络观测，不等同于完整应用 Trace。使用时间、Pod UID、Service、Trace ID 和应用日志做关联。
十、流量丢弃排查
常见 Drop 原因：策略拒绝、无路由、Conntrack、无效来源、端点未就绪、MTU、邻居解析、宿主机防火墙或 BPF Map 不一致。
kubectl -n kube-system exec ds/cilium -- cilium-dbg monitor --type drop
hubble observe --verdict DROPPED
kubectl -n kube-system exec ds/cilium -- cilium-dbg status --verbose
先确定丢弃发生在哪个节点和方向，再检查该节点。不要同时重启全部 Agent，因为这会破坏现场并扩大影响。
十一、DNS 故障
DNS 问题可能来自 CoreDNS、本地缓存、策略、UDP 分片、Conntrack 或上游解析。
排查顺序：Pod 内解析、CoreDNS Service、Endpoint、Hubble DNS 流、CoreDNS 日志、上游 DNS、TCP/UDP 53 策略和延迟。FQDN 策略依赖 DNS 可见性与缓存，需要理解短 TTL、多 IP、CNAME 和失效行为。
十二、BPF Map 与连接规模
高并发、短连接和大量 Service 可能逼近 Map 容量。观察：
kubectl -n kube-system exec ds/cilium -- cilium-dbg bpf ct list global
kubectl -n kube-system exec ds/cilium -- cilium-dbg bpf map list
Map 满时不能只扩大参数，还应治理连接复用、超时、异常扫描和客户端重试。扩大 Map 会增加锁定内存和节点资源。
十三、带宽管理与 BBR
Cilium Bandwidth Manager 可使用 EDT 对 Pod 流量整形，并可配合 BBR。启用前验证内核、BPF Host Routing、网卡队列和业务公平性。
kubectl annotate pod demo kubernetes.io/egress-bandwidth=50M
kubectl -n kube-system exec ds/cilium -- cilium-dbg status | grep BandwidthManager
带宽限制应通过真实并发和长短流压测，不要只运行单条 iperf。
十四、加密
WireGuard/IPsec 可加密节点间 Pod 流量。需要评估 CPU、MTU、密钥轮换、节点加入和不在加密范围内的流量。启用后比较吞吐、P99 延迟和重传，并确认 Host 流量、NodePort、外部出口是否符合预期。
十五、BGP 与出口
BGP 可将 Pod CIDR、Service VIP 等发布到网络设备。生产必须设置 Prefix 白名单、最大路由数、对等体认证、路由策略和撤销流程。
出口策略需考虑 SNAT、出口 IP、高可用、返回路径和外部防火墙白名单。出口节点失效时应验证连接迁移与旧会话行为。
十六、升级与回滚
升级前：
- 阅读版本兼容和弃用项；
- 备份 Helm Values 与自定义策略；
- 检查内核与 Kubernetes；
- 运行连接测试；
- 在少量节点灰度；
- 监控 Agent、Operator、Endpoint、Drop 和业务 SLO。
升级过程中避免同时驱逐大量节点。回滚不仅是 Helm 版本回退，还要确认 CRD、BPF State 和数据路径兼容。
十七、节点故障处理
节点 NotReady 后检查 Agent、内核、磁盘、路由和控制面连接。替换节点前确认 IP/CIDR 回收与云路由清理。对残留 CiliumNode、Endpoint 或路由必须按官方流程处理，避免新节点继承冲突状态。
十八、监控告警
至少监控 Agent/Operator 可用性、Endpoint Ready、策略导入失败、Drop 原因、Conntrack/Map 使用、Hubble 丢事件、路由/BGP 会话、DNS 延迟、Service 转发、加密错误、节点网络延迟和 CNI 创建失败。
十九、上线清单
- 内核、MTU、路由和防火墙经过验证；
- 数据路径模式有明确选择依据；
- kube-proxy Replacement 完成真实业务回放；
- 默认拒绝策略分阶段启用；
- Hubble 事件可关联应用与节点；
- Map 容量、DNS、BGP、出口和加密均有告警；
- 节点升级、单 Agent 故障和回滚完成演练；
- 保留不依赖集群网络的管理访问路径。
参考资料
- Cilium Documentation：
https://docs.cilium.io/en/stable/ - Hubble Observability：
https://docs.cilium.io/en/stable/observability/hubble/ - Cilium Bandwidth Manager：
https://docs.cilium.io/en/stable/network/kubernetes/bandwidth-manager/