3. Cilium 通信模型：基于 Identity 的安全通信、Service Mesh 集成、L3/L4/L7 策略

Cilium 的核心通信模型摒弃了传统的基于 IP 地址的安全策略，转而采用基于 Identity（身份） 的通信模型。这一模型与 Kubernetes 的声明式管理、动态扩缩容特性天然契合，是构建服务目录平台安全通信基座的基石。本章将深入解析 Identity 机制、L3/L4/L7 策略的编排方式，以及 Cilium 如何与 Service Mesh 集成，实现更精细的流量管控。

3.1 基于 Identity 的安全通信模型

在传统 Kubernetes 网络策略中，安全规则通常绑定到 Pod 的 IP 地址或 CIDR 范围。然而，在微服务架构中，Pod 的 IP 是动态变化的，这导致策略维护成本极高。Cilium 通过 eBPF 实现了一个全局的 Identity 分配与同步机制，将安全策略与工作负载的逻辑身份（如标签、服务账户）绑定，而非物理 IP。

Identity 的分配流程如下：

1. 标签提取： Cilium Agent 监听 Kubernetes API Server，获取 Pod 的 Labels、Namespace、ServiceAccount 等元数据。
2. 身份计算： 根据用户定义的 CiliumNetworkPolicy 或 CiliumClusterwideNetworkPolicy 中的 endpointSelector 规则，计算出一个唯一的 24 位数字 Identity。
3. BPF 映射注入： 将 Identity 注入到节点本地的 BPF 映射表中，并与该 Pod 的网络端点（Endpoint）关联。
4. 策略执行： 当数据包到达节点时，Cilium 的 BPF 程序会先解析数据包的源/目的 IP，查询 BPF 映射表获取对应的 Identity，然后根据策略规则决定允许或拒绝。

3.2 L3/L4/L7 网络策略详解

Cilium 的策略模型覆盖了从网络层到应用层的完整通信栈。在服务目录平台中，不同场景需要不同层级的策略控制：

以下是一个同时包含 L3/L4/L7 策略的 CiliumNetworkPolicy 示例：

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: secure-order-api
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: order-service
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: api-gateway
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/v1/orders"
        - method: "POST"
          path: "/api/v1/orders"
  egress:
  - toEndpoints:
    - matchLabels:
        app: payment-service
    toPorts:
    - ports:
      - port: "9090"
        protocol: TCP

3.3 Service Mesh 集成：Cilium 与 Istio 的协同

Cilium 并非要取代 Service Mesh，而是通过 eBPF 技术增强 Service Mesh 的数据面性能。在服务目录平台中，Cilium 可以与 Istio 深度集成，形成 “Cilium 负责 L3/L4 安全 + Istio 负责 L7 流量管理” 的分层架构。

集成模式的核心要点：

• Socket-Level 负载均衡： Cilium 通过 eBPF 在 socket 层面实现负载均衡，绕过传统的 iptables 规则，将 Istio Sidecar 的流量拦截延迟降低 30-50%。
• Identity 共享： Cilium 可以将 Kubernetes ServiceAccount 的 Identity 直接传递给 Istio，使 Istio 的授权策略（AuthorizationPolicy）能够基于 Cilium 的身份标识进行决策，避免重复的身份解析。
• 透明代理加速： Cilium 的 kube-proxy replacement 功能可以完全替代 kube-proxy，减少 Service Mesh 数据路径中的网络跳数。

3.4 回滚场景下的通信策略一致性

在服务目录平台的流水线中，回滚操作可能导致服务版本快速切换。Cilium 的 Identity 模型天然支持这种动态变化：

• 策略不变性： 回滚后的 Pod 如果具有相同的 Labels，Cilium 会为其分配相同的 Identity，已有的网络策略无需任何修改。
• 连接断开处理： 如果回滚导致服务接口不兼容（例如新版本删除了某个 API），Cilium 的 L7 策略会立即拒绝不符合规则的请求，防止错误数据传播。
• 渐进式回滚： 结合 Cilium 的 CiliumNetworkPolicy 中的 matchLabels 和 Kubernetes 的 rollout 策略，可以实现金丝雀回滚——只将部分流量导向旧版本，同时保持安全策略不变。