大规模视频会议媒体节点基于 Cilium 与 eBPF 实现 L3/L4 网络策略零信任隔离部署指南

摘要：随着视频会议业务规模扩大，传统基于 IP 地址的网络边界防护难以满足动态、高并发的媒体节点安全需求。本文系统阐述如何利用 Cilium 与 eBPF 技术，在 Kubernetes 环境下为大规模视频会议媒体节点构建基于身份的 L3/L4 网络策略，实现零信任网络隔离，保障信令与媒体流传输安全。

一、 背景与挑战：为何视频会议媒体节点需要零信任网络隔离

1.1 业务架构特点与安全痛点

大规模视频会议系统通常采用 SFU（Selective Forwarding Unit） 或 MCU（Multipoint Control Unit） 架构，媒体节点承载海量实时音视频流（RTP/RTCP）及信令交互（SIP/WebSocket/HTTP）。此类业务具有以下显著特征：

• 极高并发与带宽敏感：单节点需维持数万级并发连接，丢包率、抖动直接影响用户体验（QoE）。
• 动态扩缩容频繁：根据会议峰值自动伸缩，Pod IP 频繁变更，传统防火墙基于 IP 的 ACL 维护成本极高，极易出现策略滞后或误拦截。
• 东西向流量占比高：媒体节点间、媒体节点与信令网关、录制服务、转码服务间存在大量东西向通信，传统北向边界防火墙无法有效覆盖。

1.2 传统方案局限性

• iptables/ipvs 模式 kube-proxy：规模化时规则链过长，导致延迟抖动，且仅支持 L3/L4 元组匹配，无法感知工作负载身份。
• Sidecar 代理模式（如 Envoy）：引入额外资源开销与延迟，对高性能媒体转发节点不友好。
• 宿主机防火墙/硬件防火墙：缺乏 Kubernetes 语义感知，无法实现“随 Pod 走”的微隔离。

1.3 零信任网络隔离的核心诉求

• 身份为中心：基于 Kubernetes Labels（标签）定义策略，而非脆弱的 IP 地址。
• 最小权限原则：媒体节点仅允许与必要的上下游组件通信（信令网关、录制服务、对端媒体节点），默认拒绝所有其他入站/出站流量。
• 内核级高性能：策略执行下沉至内核态，避免用户态拷贝开销，满足实时媒体流微秒级转发要求。

二、 技术选型：Cilium 与 eBPF 的核心优势解析

2.1 eBPF：内核可编程的基石

eBPF (extended Berkeley Packet Filter) 允许在不修改内核源码、不加载内核模块的前提下，在内核安全沙箱中运行字节码程序。其核心优势包括：

• XDP (eXpress Data Path)：在网卡驱动层面早期丢包，极低延迟处理 DDoS 或异常流量。
• TC (Traffic Control) / cgroup-bpf：精细控制 Pod 级别的入站/出站流量。
• Map 数据结构：高效存储身份映射、策略规则、连接追踪状态，支持百万级并发查找。

2.2 Cilium：云原生网络与安全的统一实现

Cilium 基于 eBPF 构建，提供了 CNI 网络插件、Service Mesh 能力（Sidecar-less）及 CiliumNetworkPolicy (CNP) / CiliumClusterwideNetworkPolicy (CCNP) 等 CRD 资源。

• L3/L4 策略原生支持：基于 endpointSelector、toEndpoints、toCIDR 等语义，直接映射 K8s Label。
• 身份分配机制：自动为 Pod 分配数值型 Security Identity，策略编译为 BPF Map 查找，规则更新无需重编译程序，实现纳秒级生效。
• 无 Sidecar 架构：媒体节点进程零侵入，避免额外上下文切换与内存占用，关键路径性能损耗可控制在 1%-3% 以内。

三、 部署架构设计：大规模媒体节点网络拓扑规划

3.1 网络平面划分建议

建议采用 双网卡/多网络平面 物理隔离或 VLAN 逻辑隔离：

注意：Cilium 策略主要作用于 Signaling Plane 与 Media Plane 的 Pod 网络接口（通常为 eth0 或 net1），Management Plane 走宿主机网络或单独管理。

3.2 工作负载标签体系设计

统一的 Label 规范是策略生效的前提，建议采用以下维度：

labels:
  app.kubernetes.io/name: media-node          # 组件标识
  app.kubernetes.io/role: sfu                 # 角色: sfu/mcu/recorder/gateway
  topology.kubernetes.io/zone: cn-hangzhou-a  # 拓扑感知
  security.tier: "media-core"                 # 安全分级: media-core/signaling/edge
  version: v2.3.1                             # 版本灰度发布用

四、 核心策略实战：CiliumNetworkPolicy 编写与落地

4.1 基础策略模型：默认拒绝

首先在命名空间层面建立“默认拒绝所有入站/出站”基线，构建零信任起点。

# deny-all-baseline.yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: deny-all-baseline
  namespace: video-conferencing
spec:
  endpointSelector: {} # 选中命名空间内所有 Pod
  ingress:
  - {} # 空规则列表 = 拒绝所有入站
  egress:
  - {} # 空规则列表 = 拒绝所有出站

4.2 媒体节点入站策略：仅允许信令网关与对端媒体节点

媒体节点（SFU）入站流量来源明确：

1. 信令网关：下发会议控制指令（端口通常为 TCP 8080/8443）。
2. 对端媒体节点：转发 RTP/RTCP 流量（端口范围 UDP 20000-40000，需与业务配置一致）。
3. 健康检查/监控：K8s Probe、Prometheus Exporter。

# media-node-ingress.yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: media-node-ingress-allow
  namespace: video-conferencing
spec:
  endpointSelector:
    matchLabels:
      app.kubernetes.io/name: media-node
      app.kubernetes.io/role: sfu
  ingress:
  # 1. 允许信令网关访问控制平面端口
  - fromEndpoints:
    - matchLabels:
        app.kubernetes.io/name: signaling-gateway
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      - port: "8443"
        protocol: TCP
  # 2. 允许对端媒体节点转发媒体流 (UDP 大端口范围)
  - fromEndpoints:
    - matchLabels:
        app.kubernetes.io/name: media-node
        app.kubernetes.io/role: sfu
    toPorts:
    - ports:
      - port: "20000-40000"
        protocol: UDP
  # 3. 允许监控系统抓取指标
  - fromEndpoints:
    - matchLabels:
        app: prometheus
    toPorts:
    - ports:
      - port: "9090"
        protocol: TCP

4.3 媒体节点出站策略：访问录制、转码、外网网关

出站流量需严格限定目的地，防止节点被攻陷后横向移动或数据外泄。

# media-node-egress.yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: media-node-egress-allow
  namespace: video-conferencing
spec:
  endpointSelector:
    matchLabels:
      app.kubernetes.io/name: media-node
      app.kubernetes.io/role: sfu
  egress:
  # 1. 访问录制服务
  - toEndpoints:
    - matchLabels:
        app.kubernetes.io/name: recorder
    toPorts:
    - ports:
      - port: "5000"
        protocol: TCP
  # 2. 访问转码服务
  - toEndpoints:
    - matchLabels:
        app.kubernetes.io/name: transcoder
    toPorts:
    - ports:
      - port: "8000"
        protocol: TCP
  # 3. 访问 DNS (CoreDNS) - 必须显式放行，否则域名解析失败
  - toEndpoints:
    - matchLabels:
        k8s-app: kube-dns
    toPorts:
    - ports:
      - port: "53"
        protocol: UDP
      - port: "53"
        protocol: TCP
  # 4. 访问外网网关 (如需拉取镜像、上报日志) - 建议配合 toCIDR 限定网段
  - toCIDR:
    - 10.40.0.0/16 # External Plane CIDR
    toPorts:
    - ports:
      - port: "443"
        protocol: TCP
      - port: "80"
        protocol: TCP
  # 5. 允许节点间媒体流直连 (如果架构要求直连而非通过中转)
  - toEndpoints:
    - matchLabels:
        app.kubernetes.io/name: media-node
    toPorts:
    - ports:
      - port: "20000-40000"
        protocol: UDP

4.4 进阶：基于 L7 协议可见性的信令层防护 (可选)

若信令采用 HTTP/WebSocket，可启用 L7 策略进行深度检测（需 Cilium 启用 enable-l7-proxy: true），防止协议滥用。

# 示例：仅允许特定 HTTP Path 的信令请求
toPorts:
- ports:
  - port: "8080"
    protocol: TCP
  rules:
    http:
    - method: "POST"
      path: "/api/v1/conferences/*/join"
    - method: "GET"
      path: "/healthz"

五、 大规模场景性能调优与运维最佳实践

5.1 BPF Map 容量规划

大规模集群（节点 > 500，Pod > 50,000）需预调整 Map 大小，防止溢出导致丢包。
在 Cilium ConfigMap (cilium-config) 中设置：

# 预估最大 Endpoint 数 * 1.5 冗余
bpf-lb-map-max: "1048576"       # LB Map (Service/Endpoint)
bpf-policy-map-max: "262144"    # Policy Map (规则条目)
ipcache-size: "262144"          # IP -> Identity 映射表

验证命令：cilium bpf lb list | wc -l 观察当前条目数。

5.2 XDP 模式与驱动兼容性

• 推荐开启 XDP (Native/Generic)：在物理网卡驱动层卸载策略匹配，大幅降低 CPU 占用。
• 驱动白名单：确认网卡驱动支持 XDP (如 mlx5, ixgbe, i40e, ena)。云厂商虚拟网卡 (如 virtio_net, ena) 通常仅支持 Generic XDP，性能提升有限但仍有价值。
• 配置：enable-xdp: "true", xdp-mode: "native" (需内核 5.10+ 且驱动支持)。

5.3 连接追踪 优化

媒体流为长连接 UDP 流，默认 nf_conntrack 超时时间可能导致表项耗尽。

• 调整内核参数 (通过 DaemonSet 或节点初始化脚本)：

  复制

  net.netfilter.nf_conntrack_max = 2000000
  net.netfilter.nf_conntrack_udp_timeout = 60      # 非建立态
  net.netfilter.nf_conntrack_udp_timeout_stream = 300 # 已建立流

• Cilium 旁路：对于纯转发媒体流，可考虑 enable-ipv4-fragment-reassembly: "false" 及 bpf-ct-global-any-max: "0" (谨慎使用，需评估状态防火墙需求)。

5.4 滚动升级与策略灰度发布

• Canary 策略部署：新策略先打标签 policy.cilium.io/test: "true"，配合 cilium policy trace 验证流量路径，确认无误后再移除测试标签全量生效。
• Hubble 可观测性：必须部署 Hubble Relay & UI，实时监控 DROPPED 事件，设置告警规则（如：单节点 Drop 率 > 0.1% 触发报警）。

六、 常见问题排查与故障复盘案例

6.1 现象：会议加入成功但无音视频（黑屏/静音）

排查路径：

1. cilium policy get -n video-conferencing media-node-ingress-allow -o json 确认策略已下发至 Agent。
2. cilium endpoint list -n video-conferencing -l app.kubernetes.io/name=media-node 查看 POLICY (ingress) 状态为 Enforced。

3. 关键步骤：cilium policy trace -n video-conferencing --src-pod <signaling-gw-pod> --dst-pod <media-node-pod> --dport 20000 --protocol udp。

   • 若输出 VERDICT: DROPPED (Policy denied)，检查 fromEndpoints Label Selector 是否匹配源 Pod 当前 Label。
   • 若输出 VERDICT: FORWARDED 但业务不通，检查 宿主机防火墙/安全组/交换机 ACL 是否拦截 UDP 大端口。

6.2 现象：节点扩容后新 Pod 网络不通

根因：Cilium Identity 分配延迟 或 IPAM 耗尽。
对策：

• 检查 cilium-operator 日志，确认 kvstore (etcd/consul) 连接正常。
• 监控 cilium_ipam_allocate_failures_total 指标。
• 预分配 IP 池：ipam: "cluster-pool", cluster-pool-ipv4-cidr: "10.30.0.0/16", cluster-pool-ipv4-mask-size: "24"。

6.3 现象：CPU 飙升，媒体丢包率上升

定位：

1. top -H -p $(pidof cilium-agent) 定位高 CPU 线程。
2. cilium bpf ct list global 查看连接追踪表项数量是否达上限。
3. 开启 debug: "true" 短期采集 cilium-dbg 数据包，分析是否存在异常流量攻击（如 UDP Flood），配合 XDP 早期丢包策略缓解。

七、 合规与安全加固清单（上线前必检）

八、 总结与演进展望

基于 Cilium 与 eBPF 的 L3/L4 零信任隔离方案，通过身份标签驱动策略、内核态高性能执行、全流量可观测性三大核心能力，有效解决了大规模视频会议媒体节点动态性强、性能敏感、攻击面广的网络安全难题。

后续演进方向建议：

1. L7 策略深度治理：对信令层（SIP/HTTP/gRPC）实施语义级访问控制，防御应用层漏洞利用。
2. 网络策略即代码：将 CNP/CCNP 纳入 GitOps 流程，实现策略变更的代码审查、自动化测试与灰度发布。
3. 服务网格融合：利用 Cilium Service Mesh 能力，替代 Sidecar 实现 mTLS 双向认证与流量治理，进一步降低资源开销。
4. 多集群联邦隔离：结合 ClusterMesh 实现跨地域、跨云厂商的媒体节点统一安全域管理。

通过持续的工程化沉淀与运维体系建设，该方案可支撑百万级并发会议规模下的网络安全合规底座，为实时通信业务提供坚实可靠的基础设施保障。

版权声明：本文为技术方案分享，旨在提供参考架构与配置示例。实际生产环境部署前，请务必结合企业等保测评要求、网络拓扑现状及业务流量基线进行充分压测与验证。文中涉及的端口、CIDR、Label 等参数需根据实际情况调整，切勿直接复制上线。

大规模视频会议媒体节点基于 Cilium 与 eBPF 实现 L3/L4 网络策略零信任隔离部署指南（进阶篇）

接上篇：本文聚焦于多集群联邦治理、数据面加密落地、安全运营体系建设、工程化交付流水线、IPv6 双栈适配及容量规划模型六大进阶实战领域，解决生产环境规模化演进中的“最后一公里”难题。

九、 多集群联邦场景下的零信任策略一致性保障

大规模视频会议常采用 “中心控制面 + 边缘媒体节点” 多集群架构（如：北京/上海/广州三地活跃集群 + 边缘 POP 点集群）。单集群策略无法满足跨地域媒体节点互通与隔离需求。

9.1 ClusterMesh 网络互联与身份统一

核心原则：全网唯一的 Security Identity 命名空间，避免不同集群相同 Label 产生身份冲突。

# cilium-config (全集群统一配置)
cluster-name: "cn-beijing-prod"          # 全局唯一集群名
cluster-id: 1                            # 全局唯一 ID (1-255)
identity-allocation-mode: "kvstore"      # 必须使用分布式 KVStore (etcd/consul)
kvstore: "etcd"
kvstore-opt:
  etcd.address: "https://etcd.global.infra:2379"
  etcd.config: "/etc/cilium/etcd-config.yaml"

关键动作：

1. 全局 etcd 部署：建议部署跨地域高可用 etcd 集群（或使用云厂商托管 etcd），作为身份分配与服务发现的单一事实来源。
2. 节点 CIDR 无重叠：通过 cluster-pool-ipv4-cidr 为每个集群分配不重叠的 Pod CIDR 块（如 10.100.0.0/16, 10.101.0.0/16），确保跨集群 Pod IP 直接路由可达（依赖 VPC 对等连接/云企业网/专线）。

9.2 跨集群网络策略：CiliumClusterwideNetworkPolicy (CCNP) 实战

使用 CiliumClusterwideNetworkPolicy 定义全局基线策略，配合 nodeSelector 实现地域级隔离。

场景：仅允许“华东媒体节点”访问“华东信令网关”，禁止跨地域直连媒体流（强制走中心转发或就近接入），满足数据合规与延迟优化。

# global-media-isolation-ccnp.yaml
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: global-media-geo-isolation
spec:
  description: "跨地域媒体节点强制隔离，仅允许同地域及中心控制面通信"
  endpointSelector:
    matchLabels:
      app.kubernetes.io/name: media-node
      app.kubernetes.io/role: sfu
  ingress:
  # 1. 允许同集群内信令网关
  - fromEndpoints:
    - matchLabels:
        app.kubernetes.io/name: signaling-gateway
        io.cilium.k8s.policy.cluster: "cn-beijing-prod"  # 显式指定集群名
    toPorts:
    - ports: [{port: "8443", protocol: TCP}]
  # 2. 允许同地域对端媒体节点 (通过 cluster 名称匹配)
  - fromEndpoints:
    - matchLabels:
        app.kubernetes.io/name: media-node
        io.cilium.k8s.policy.cluster: "cn-beijing-prod"
    toPorts:
    - ports: [{port: "20000-40000", protocol: UDP}]
  # 3. 允许中心控制面集群 (管理集群) 下发指令
  - fromEndpoints:
    - matchLabels:
        app.kubernetes.io/name: media-controller
        io.cilium.k8s.policy.cluster: "global-management"
    toPorts:
    - ports: [{port: "9090", protocol: TCP}]
  # 默认拒绝其他所有跨集群入站

9.3 服务发现与负载均衡一致性

• Global Service (ServiceAffinity)：为跨集群服务（如录制服务、转码服务）创建 io.cilium/global-service: "true" 的 Service，Cilium 自动同步 EndpointSlice 至所有集群，实现就近访问。
• 外部流量入口：边缘集群部署 Cilium Ingress/Gateway API，配合 hostPort 或 LoadBalancer 模式，终结外部信令/TLS，内部再通过零信任策略转发至媒体节点。

十、 媒体平面透明加密：WireGuard 与 IPsec 零性能损落地

零信任核心假设“网络不可信”，媒体平面（RTP/RTCP）跨宿主机、跨 VPC 传输必须加密。Cilium 基于 eBPF 实现的 WireGuard 或 IPsec 透明加密，对应用零侵入，性能损耗 < 5%。

10.1 WireGuard 模式部署（推荐：现代内核、高性能、配置简单）

前置条件：

• 内核版本 ≥ 5.6 (原生 WireGuard 支持) 或安装 wireguard-dkms。
• 所有 Worker 节点开启 IP_FORWARD，关闭 rp_filter (宽松模式)。

配置步骤：

1. 生成预共享密钥 (PSK) - 生产环境建议轮换机制：

   复制

   # 由运维侧统一生成分发，存入 Kubernetes Secret
   wg genpsk > /tmp/wg-psk.key
   kubectl create secret generic cilium-wg-psk -n kube-system --from-file=psk=/tmp/wg-psk.key

2. 启用加密配置 (ConfigMap cilium-config)：

   复制

   encryption: "wireguard"
   wireguard-key-rotation: "3600"      # 密钥轮换周期(秒)，建议 1 小时
   wireguard-persistent-keepalive: "25" # NAT 穿透保活间隔
   # 可选：指定加密接口，媒体平面建议绑定专用网卡 (eth1)
   # encryption-interface: "eth1" 

3. 验证加密生效：

   复制

   # 1. 查看节点间 WireGuard 接口
   cilium status | grep -A 5 "Encryption"
   # 输出应包含: Encryption: WireGuard (Enabled)
   
   # 2. 抓包验证 (媒体平面网卡)
   tcpdump -i eth1 udp port 20000 -vv | grep -i "wireguard"
   # 应看到 Encapsulated Packet 而非明文 RTP 负载

10.2 IPsec 模式部署（兼容性兜底：老旧内核、硬件加速卡）

若内核 < 5.6 或需利用 Intel QAT/QuickAssist 硬件加速卡，选用 IPsec (XFRM)。

encryption: "ipsec"
ipsec-key-file: "/etc/cilium/ipsec.keys"  # 需通过 DaemonSet 分发密钥文件
# 启用 XFRM 卸载 (需网卡驱动支持)
enable-ipsec-xfrm-offload: "true"

密钥管理：建议集成 Vault Agent Injector 或 SealedSecrets，实现 IPsec 密钥的自动轮换与分发，避免静态密钥泄露风险。

10.3 媒体流加密性能基线测试指标

运维提示：加密开启后，cilium-agent 会自动管理 wg0/cilium_ipsec 接口及路由规则，严禁手动修改宿主机路由表或 iptables，否则导致加密隧道断裂。

十一、 基于 Hubble 的流量基线建模与动态异常检测体系

静态策略只能解决“已知合规”，动态检测解决“未知威胁”与“策略漏洞挖掘”。

11.1 Hubble 全流量可观测性架构

graph LR
    A[Cilium Agent (eBPF)] -->|Ring Buffer / Perf Event| B[Hubble Server (gRPC)]
    B --> C[Hubble Relay (聚合)]
    C --> D[Hubble UI (可视化)]
    C --> E[Prometheus (指标)]
    C --> F[Kafka/Vector (日志归档)]
    F --> G[SIEM / ClickHouse / Elasticsearch]
    G --> H[异常检测引擎 / 规则引擎]

生产级部署建议：

• 采样率控制：媒体平面流量巨大，全量导出会压垮监控链路。配置 hubble.flow-sampling: "0.01" (1% 采样) 或基于 verdict:DROPPED 全量导出、允许流量采样导出。
• 元数据富化：开启 hubble.metrics.enable: ["dns", "drop", "tcp", "flow", "port-distribution", "icmp", "httpV2"]，并配置 hubble.labels: "app.kubernetes.io/name,app.kubernetes.io/role,security.tier" 确保流日志携带业务语义。

11.2 媒体业务流量基线画像模型

建立“正常行为基线”，作为零信任策略收敛与异常告警的依据。

11.3 自动化策略收敛闭环

1. 审计模式：新上线服务先部署 CiliumNetworkPolicy 设置 action: Audit (仅记录不拦截)。
2. 基线学习：运行 1-2 个业务周期，通过 Hubble 导出 Audit 日志，自动生成 fromEndpoints/toEndpoints 白名单草案。
3. 人工复核 & 发布：安全团队确认白名单无遗漏业务依赖，将 action 改为 Deny (默认) 或显式 Allow。
4. 持续漂移检测：定时任务对比“当前策略允许集合”与“实际观测通信集合”，发现新增通信自动工单告警。

十二、 CI/CD 流水线集成：网络策略即代码与自动化门禁

将网络策略纳入 GitOps 管理，防止“人工手改策略导致生产故障”。

12.1 策略代码化目录结构

infra/network-policies/
├── base/                    # 基础设施层 (CoreDNS, Monitoring, Ingress)
│   ├── deny-all-baseline.yaml
│   └── allow-dns.yaml
├── apps/                    # 业务应用层 (按微服务拆分)
│   ├── media-node/
│   │   ├── ingress.yaml
│   │   ├── egress.yaml
│   │   └── kustomization.yaml
│   ├── signaling-gateway/
│   └── recorder/
├── clusters/                # 集群差异化覆盖
│   ├── cn-beijing-prod/
│   │   └── media-node-egress-patch.yaml (如特有外网网关 CIDR)
│   └── cn-shanghai-prod/
└── global/                  # 跨集群全局策略 (CCNP)
    └── global-media-isolation.yaml

12.2 流水线门禁阶段设计

12.3 策略变更影响分析自动化

开发内部 CLI 工具 netpol-diff：

# 对比当前集群策略与 Git 目标策略
netpol-diff --live --target ./infra/network-policies --namespace video-conferencing

# 输出示例：
# [CHANGED] media-node-ingress: 新增允许来自 transcoder-v2 的 TCP/8000
# [REMOVED] recorder-egress: 移除对旧存储集群 10.50.0.0/16 的访问
# [RISK]    发现 3 个 Pod 将失去对外网 8.8.8.8:53 的访问 (需确认 DNS 策略已生效)

十三、 IPv6 双栈环境下的零信任策略兼容性实战

运营商/政企项目强制要求 IPv6 单栈或双栈支持。Cilium 原生支持双栈，但策略编写需显式兼容。

13.1 双栈网络前置配置

# cilium-config 关键参数
enable-ipv4: "true"
enable-ipv6: "true"
ipv6-node-addr: "auto"              # 自动获取节点 IPv6 地址
ipam: "cluster-pool"
cluster-pool-ipv4-cidr: "10.100.0.0/16"
cluster-pool-ipv4-mask-size: "24"
cluster-pool-ipv6-cidr: "fd00:10:100::/48"  # ULA 地址或公网 IPv6
cluster-pool-ipv6-mask-size: "112"
# Service 双栈
service-ipv4-cidr: "10.96.0.0/12"
service-ipv6-cidr: "fd00:10:96::/112"

13.2 双栈感知的网络策略编写规范

错误示范：仅指定 toCIDR: 10.20.0.0/16 (仅 IPv4)，导致 IPv6 流量被默认拒绝。
正确示范：显式声明双栈 CIDR，或使用 Label Selector (推荐，协议无关)。

# 正确：基于 Label 的策略自动兼容 IPv4/IPv6
toEndpoints:
- matchLabels:
    app.kubernetes.io/name: signaling-gateway

# 必须用 CIDR 时：显式双栈并列
toCIDR:
- 10.20.0.0/16        # IPv4 信令平面
- fd00:10:20::/48     # IPv6 信令平面
toCIDRSet:
- cidr: 10.20.0.0/16
  except:
  - 10.20.255.0/24    # 排除网关保留段
- cidr: fd00:10:20::/48
  except:
  - fd00:10:20:ff::/64

13.3 IPv6 专项验证清单

1. Pod 双栈就绪：kubectl get pod -o wide 显示双 IP；cilium endpoint get <id> 显示 IPv4 与 IPv6 状态均为 ready。
2. 策略双栈生效：cilium policy get <name> -o jsonpath='{.spec.ipv6}' 确认策略对象包含 IPv6 规则编译产物。
3. 媒体流连通性：iperf3 -c <IPv6_Pod_IP> -u -b 50M -t 60 -B <Src_IPv6> 验证 UDP 媒体流 IPv6 路径吞吐与丢包。
4. 加密双栈：WireGuard/IPsec 隧道建立在 IPv6 底层网络上 (encryption-interface 指定 IPv6 网卡)，验证 wg show 端点地址为 IPv6。

十四、 容量规划数学模型与成本优化指南

将网络策略开销量化为可计算的资源模型，指导集群扩容与成本控制。

14.1 核心资源消耗模型

14.2 大规模场景参数推算示例 (500 节点, 50k Pods, 200k 并发连接)

• Agent 资源配额建议：requests: {memory: "2Gi", cpu: "500m"}, limits: {memory: "4Gi", cpu: "2000m"}。

• BPF Map 预分配：

  复制

  bpf-policy-map-max: "524288"   # 50k Pods * 平均 10 条规则
  ipcache-size: "131072"         # 50k Pods * 2 (IPv4/IPv6) + 冗余
  bpf-ct-global-any-max: "524288" # 200k 连接 * 2 (双向) + 冗余

• etcd 规格：建议 3 节点，每节点 8 vCPU / 32 GiB / 500 GiB SSD，磁盘 IOPS > 10k。

14.3 成本优化策略

1. 策略合并：将多个单端口规则合并为端口范围 (20000-40000)，减少 PolicyMap 条目数 90%+。
2. CIDR 聚合：toCIDR 使用聚合后的超网掩码，减少 IPCache 条目。
3. 连接追踪精简：媒体平面纯转发流量，若安全审计允许，可设置 bpf-ct-global-any-max: 0 禁用 CT，节省 72Bytes/连接 内存，但将失去状态防火墙能力 (无法匹配 state: established)，需极其谨慎评估。
4. Sidecar-less Service Mesh：利用 Cilium L7/L4 LB 替代 Istio/Linkerd Sidecar，每节点节省 1-2 核 CPU 与 2-4 GiB 内存。

十五、 灾难恢复演练与合规审计自动化

15.1 网络策略故障注入演练

纳入 Chaos Engineering 体系，定期验证零信任隔离的有效性。

15.2 等保 2.0 / GDPR 合规自动化取证报告

开发合规扫描器 netpol-compliance-scanner，每日定时生成报告：

## 每日网络零信任合规扫描报告 (2024-05-20)

### 1. 默认拒绝覆盖率: 100% (32/32 Namespace)
- ✅ 所有业务命名空间均存在 `deny-all-baseline` 策略。

### 2. 过度授权策略审计: 发现 2 项风险
- [HIGH] `media-node-egress` 允许 `toCIDR: 0.0.0.0/0` on port 443 (建议收敛至具体外网网关 CIDR)
- [MEDIUM] `recorder-ingress` 缺少 `fromEndpoints` 限制，当前允许全集群访问 (建议限定 media-node Label)

### 3. 加密合规性: 100% (WireGuard Enabled)
- 所有节点间媒体平面流量已加密，密钥轮换周期 1h 合规。

### 4. 审计日志完整性: 正常
- Hubble 流日志已推送至合规存储，保留 180 天，无丢包。

### 5. 变更管理追溯: 通过
- 近 24h 策略变更 3 条，均关联 Jira 变更单 (CRQ-20240520-001/002/003)，经安全审批通过。

十六、 总结：构建可演进的云原生网络安全基座

从单集群 L3/L4 策略落地，到多集群联邦治理、透明加密、流量基线建模、GitOps 工程化、IPv6 双栈适配、容量成本建模，再到混沌演练与合规自动化，Cilium + eBPF 零信任网络体系的建设是一个持续演进的系统工程，而非一次性的配置交付。

给架构师与运维团队的三点核心建议：

1. 策略即基础设施代码：网络策略必须像应用代码一样经历 Code Review -> CI Test -> Canary Deploy -> Observability 全生命周期管理，拒绝手工 kubectl apply 运维模式。
2. 可观测性先行：没有 Hubble 可观测性的零信任策略是盲飞。优先投入建设流量基线画像能力，用数据驱动策略收敛与异常发现。
3. 性能与安全同权重：媒体节点对延迟极度敏感。每一次策略收敛、加密开启、版本升级，必须配备自动化性能基线对比测试，确保安全增强不以业务体验损耗为代价。

通过本指南两篇文章的系统性实践，您的视频会议媒体节点网络将具备：身份感知的微隔离、内核级的高性能执行、全域的加密保护、自动化的合规闭环，支撑业务从十万级向百万级并发规模平滑演进，构建经得起实战检验的云原生网络安全基座。