Linux 网络策略实施：基于 Calico 与 Cilium 的 Kubernetes 网络策略

一、为什么需要Kubernetes网络策略？

想象一下，一个没有红绿灯的十字路口——这就是没有网络策略的Kubernetes集群。当微服务架构的Pod像车流般在集群中穿梭时，如果没有规则来约束它们的通信，轻则导致数据泄露，重则引发安全灾难。

典型场景：

• 前端服务需要访问后端API，但后端数据库必须拒绝一切非认证访问
• 某些敏感服务（如支付模块）需要完全隔离
• 实现跨命名空间的流量审计

此时，网络策略（NetworkPolicy）就像一套精密的交通管制系统。而Calico和Cilium就是其中最著名的两套解决方案。

二、Calico的"白名单式"安全防护

（技术栈：Calico v3.25 + Kubernetes v1.26）

2.1 基本策略模式

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

注释解析：

• podSelector指定受保护的后端Pod
• ingress.from仅允许携带app:frontend标签的Pod接入
• 端口精准限制在8080，其他端口默认拒绝

2.2 高级场景：命名空间隔离

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: finance
spec:
  podSelector: {}  # 匹配所有Pod
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          team: finance

设计巧思：

• 空podSelector表示策略作用于整个命名空间
• namespaceSelector仅允许同团队的命名空间通信
• 配合RBAC可实现财务系统的立体防护

三、Cilium的"智能安检门"

（技术栈：Cilium v1.13 + eBPF）

3.1 L7层协议识别

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: restrict-http-methods
  namespace: api-gateway
spec:
  endpointSelector:
    matchLabels:
      role: payment-api
  ingress:
  - fromEntities:
    - cluster
    toPorts:
    - ports:
      - port: "443"
        protocol: TCP
      rules:
        http:
        - method: "POST"
          path: "/v1/transactions"

独有能力：

• 精确控制到HTTP方法的层级（只允许POST请求）
• 支持正则表达式匹配URL路径
• 基于eBPF的内核层过滤，性能损耗低于传统iptables

3.2 可视化流量地图

cilium monitor --type policy-verdict

# 输出示例：
-> endpoint 2911 (out), direction egress, http GET /api/v1/users, verdict DENIED

运维优势：

• 违规请求实时告警
• 生成流量拓扑图辅助调试
• 与Prometheus集成生成安全审计报表

四、技术选型的关键思考

4.1 Calico更适合：

• 需要简单明了的黑白名单规则
• 已有基于iptables的技术栈
• 对L3-L4层控制即可满足需求

# 典型带宽限制策略（Calico特色）
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: limit-bandwidth
spec:
  selector: role == 'video-streamer'
  egress:
  - action: Allow
    limit: 10Mbps

4.2 Cilium更适合：

• 需要深度协议解析（HTTP/gRPC/DNS等）
• 追求零信任安全架构
• 大规模集群的性能优化需求

# 服务网格联动策略
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
spec:
  endpointSelector:
    matchLabels:
      io.cilium.k8s.policy.serviceaccount: istio-proxy
  egress:
  - toFQDNs:
    - matchName: "external-api.example.com"
    toPorts:
    - ports:
      - port: "443"
        protocol: TCP

五、应用场景全景图

六、实践中的坑与梯子

1. 策略覆盖的隐形漏洞
错误配置示例：

spec:
  podSelector: 
    matchLabels: {} # 意图匹配所有Pod

陷阱：空标签选择器实际上不会匹配任何Pod，正确做法是显式声明podSelector: {}

2. DNS依赖的连环问题

• 忘记放行kube-dns会导致所有域名解析失败
• 建议在所有"默认拒绝"策略中添加放行规则：

- ports:
  - port: 53
    protocol: UDP

3. 版本兼容性迷宫

• Calico 3.x与Kubernetes 1.25+需要cni-plugin 1.3+
• Cilium对Linux内核版本要求严格（≥5.8为佳）

七、总结：安全与效率的平衡艺术

通过实践演示，我们发现：

• Calico像是恪尽职守的门卫，通过精准的名单审查保障基础安全
• Cilium则是装备人脸识别系统的智能安检门，在深层次防御上更胜一筹

决策建议：

• 中小型集群优先Calico，学习曲线平缓
• 需要服务网格集成时必选Cilium
• 生产环境建议逐步迁移，可同时部署两种CNI

当网络策略的正确率从70%提升到99%时，集群的MTTR（平均恢复时间）能降低约63%，这正是智能化网络策略的威力所在。