4、金融级网络方案：CNI插件选型（Calico、Cilium）、网络策略与安全组、多租户隔离

金融行业的网络，说白了就是命根子。我见过太多因为网络抖动导致交易中断的案例，所以每次做容器化网络方案，我都格外谨慎。今天咱们聊聊金融级网络方案的核心——CNI插件选型、网络策略与多租户隔离。

4.1 CNI插件选型：Calico vs Cilium

CNI插件是Kubernetes网络的基石。金融场景下，我主要推荐两个：Calico和Cilium。为什么？因为它们都支持网络策略，性能也够硬。

4.1.1 Calico：老牌劲旅

Calico是我最早接触的CNI插件。它基于BGP协议，纯三层网络，没有overlay开销。说白了，就是直接路由。

• 优点：性能稳定，社区成熟，文档齐全。我2018年做第一个金融容器项目时用的就是它，跑了三年没出过大问题。
• 缺点：网络策略基于iptables，规则多了性能下降明显。我记得有一次客户配了2000条策略，节点上iptables规则数直接爆炸，CPU飙升到80%。
• 适用场景：传统金融企业，对eBPF不熟悉，或者内核版本较低（3.10+即可）。

4.1.2 Cilium：后起之秀

Cilium基于eBPF，性能比Calico高一个量级。我去年帮某券商做容器化改造，从Calico切到Cilium后，网络延迟降低了40%。

• 优点：网络策略性能极高，支持L7策略（HTTP/gRPC），可观测性强。你想想看，能直接看到每个Pod的TCP连接数、延迟分布，多爽。
• 缺点：依赖内核版本（至少4.19，推荐5.10+）。有些老旧金融系统还在用CentOS 7，内核3.10，那就没法用。
• 适用场景：对性能要求高的交易系统、微服务架构、需要L7策略的场景。

特性	Calico	Cilium
数据平面	iptables / eBPF（可选）	eBPF（原生）
网络策略性能	中等（规则多时下降明显）	高（规则多时几乎无影响）
L7策略支持	有限（需额外组件）	原生支持（HTTP/gRPC/Kafka等）
内核要求	3.10+	4.19+（推荐5.10+）
运维复杂度	低	中（需理解eBPF）

4.2 网络策略与安全组

金融场景下，网络策略不是可选项，是必选项。为什么？因为监管要求。银保监会明确要求：不同业务系统之间必须网络隔离。

4.2.1 Kubernetes NetworkPolicy

Kubernetes原生NetworkPolicy只支持L3/L4，说白了就是IP+端口。但金融场景往往需要更细粒度的控制。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: finance-api-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: finance-api
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: gateway
    - podSelector:
        matchLabels:
          app: api-gateway
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: finance-db
    ports:
    - protocol: TCP
      port: 3306

这段配置的意思是：只允许gateway命名空间下的api-gateway Pod访问finance-api的8080端口，同时finance-api只能访问finance-db的3306端口。嗯，这里要注意：默认拒绝所有流量，只放行明确允许的。这是金融安全的基本原则。

4.2.2 Cilium NetworkPolicy（L7策略）

如果你用Cilium，可以玩L7策略。比如只允许GET请求，拒绝DELETE请求。这在金融场景下非常有用。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: finance-api-l7
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: finance-api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: api-gateway
    toPorts:
    - ports:
      - port: '8080'
        protocol: TCP
      rules:
        http:
        - method: GET
          path: '/api/v1/accounts/.*'
        - method: POST
          path: '/api/v1/transactions'

你看，这样就能精确控制API的访问权限。说白了，就是给网络策略加了一层应用防火墙。

4.3 多租户隔离

金融云上，多租户隔离是刚需。不同部门、不同业务线、甚至不同客户，都要严格隔离。我总结了三层隔离方案：

4.3.1 第一层：命名空间隔离

Kubernetes命名空间是最基础的隔离手段。但光靠命名空间不够，因为默认情况下，不同命名空间的Pod可以互相访问。

• 做法：为每个租户创建独立命名空间，配合NetworkPolicy实现默认拒绝。
• 注意：命名空间不是安全边界，只是逻辑分组。真正的隔离靠网络策略。

4.3.2 第二层：网络策略隔离

这是核心。我一般会配三层策略：

1. 全局默认拒绝：所有命名空间默认拒绝所有入站和出站流量。
2. 租户内部允许：同一租户内的Pod可以互相访问（通过标签选择器）。
3. 跨租户白名单：只有明确允许的跨租户流量才能通过（比如日志收集、监控系统）。

4.3.3 第三层：节点级隔离（可选）

对于高安全要求的场景（比如核心交易系统），我建议用节点级隔离。说白了，就是把不同租户的Pod调度到不同节点上，配合节点安全组。

• 做法：使用节点亲和性（nodeAffinity）和污点（Taints/Tolerations）实现。
• 优点：物理隔离，即使Kubernetes层面出问题，网络也不通。
• 缺点：资源利用率低，运维复杂。

4.4 知识体系图

下面这张图总结了金融级网络方案的核心逻辑，我画了很久，希望能帮你理清思路。

这张图展示了金融级网络方案的三个层次：底层选好CNI插件，中间配好网络策略，上层做好多租户隔离。每一层都不可或缺。