Kubernetes NetworkPolicy网络隔离策略与Cilium eBPF流量管控

Kubernetes集群默认允许任意Pod之间通信，缺乏网络层面的租户隔离和数据流控制。网络策略（NetworkPolicy）是K8s原生的网络隔离机制，通过标签选择器定义Pod间通信许可。CNI插件Cilium进一步引入eBPF技术，在内核层实现高性能流量过滤、L7协议感知和可观测性，相比传统iptables方案在大规模集群中性能优势显著。

Kubernetes NetworkPolicy默认拒绝与白名单机制

NetworkPolicy采用默认拒绝模型：一旦命名空间中任何Pod被某个NetworkPolicy的podSelector匹配，该Pod的入站和出站流量默认全部拒绝，只有策略中明确允许的规则才放行。这种白名单模式确保最小权限原则。

# 基础网络策略：数据库Pod仅允许应用层Pod访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: postgres-access-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres
      tier: database
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        # 仅允许同一命名空间中app=api的Pod
        - podSelector:
            matchLabels:
              app: api
              tier: backend
      ports:
        - protocol: TCP
          port: 5432
    - from:
        # 允许特定命名空间的Pod访问
        - namespaceSelector:
            matchLabels:
              env: monitoring
          podSelector:
            matchLabels:
              app: postgres-exporter
      ports:
        - protocol: TCP
          port: 9187
  egress:
    # 允许DNS解析
    - to:
        - namespaceSelector: {}
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
    # 允许访问外部S3
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 10.0.0.0/8
              - 172.16.0.0/12
              - 192.168.0.0/16
      ports:
        - protocol: TCP
          port: 443

命名空间级别的全局默认策略，为所有未配置策略的Pod提供兜底隔离：

# 默认拒绝所有入站
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress

---
# 默认拒绝所有出站
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Egress

Cilium eBPF数据路径与L7策略扩展

传统CNI插件（如Calico iptables模式）在每个Node上维护数千条iptables规则，规则匹配复杂度为O(n)。Cilium使用eBPF程序在内核网络栈挂载点执行过滤逻辑，复杂度接近O(1)，且无需数据包从内核态到用户态的上下文切换。

安装Cilium并替换默认CNI：

# 使用Helm安装Cilium
helm repo add cilium https://helm.cilium.io/
helm repo update

helm install cilium cilium/cilium   --version 1.16.0   --namespace kube-system   --set kubeProxyReplacement=true   --set k8sServiceHost=API_SERVER_IP   --set k8sServicePort=6443   --set hubble.enabled=true   --set hubble.relay.enabled=true   --set hubble.ui.enabled=true   --set l7Proxy.enabled=true

# 验证Cilium状态
kubectl -n kube-system get pods -l app.kubernetes.io/name=cilium
cilium status --wait

Cilium的CiliumNetworkPolicy扩展了标准NetworkPolicy，支持L7协议级（HTTP/gRPC/Kafka）流量控制：

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-l7-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              # 仅允许GET和POST请求
              - method: GET
                path: "/api/v1/.*"
              - method: POST
                path: "/api/v1/users"
              # 阻止访问内部管理端点
              # 未列出的请求默认拒绝

Kafka流量控制示例——限制消费者组仅能读取特定Topic：

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: kafka-client-policy
  namespace: messaging
spec:
  endpointSelector:
    matchLabels:
      app: kafka-client
  egress:
    - toEndpoints:
        - matchLabels:
            app: kafka-broker
      toPorts:
        - ports:
            - port: "9092"
              protocol: TCP
          rules:
            kafka:
              - role: produce
                topic: "^orders-.*"
              - role: consume
                topic: "^events-.*"
                clientID: "^order-consumer-.*"

Hubble可观测性与流量审计

Cilium内置的Hubble组件提供实时流量可视化，基于eBPF采集数据包元数据，无需额外Agent注入：

# 查看所有流量
hubble observe -n production

# 过滤特定服务的流量
hubble observe --pod production/api --verdict DROPPED

# 查看被策略拒绝的流量（策略调试核心命令）
hubble observe --verdict DROPPED --type ingress

# 实时监控某Pod的HTTP请求
hubble observe --pod production/api --protocol http

# 输出示例:
# Aug 11 03:22:15.452 production/frontend-xxx:42334 -> production/api-xxx:8080 #   HTTP GET /api/v1/users HTTP/1.1 200 OK (58.2KB)
# Aug 11 03:22:16.103 production/unknown-xxx:51234 -> production/api-xxx:8080 #   HTTP POST /admin/delete FORWARDED (DROPPED by policy)

Hubble UI提供服务依赖图，直观展示命名空间内Pod之间的流量关系和策略生效状态。被拒绝的流量在图中以红色标注，便于快速定位策略配置问题。

策略调试与生产部署要点

策略上线前使用audit模式避免意外中断业务。Cilium支持策略审计模式——记录被拒绝的流量但不实际阻断：

# 启用策略审计模式
kubectl -n kube-system annotate configmap cilium-config   cilium.io/policy-audit-mode=true

# 重启Cilium Agent使配置生效
kubectl -n kube-system rollout restart ds/cilium

# 观察Hubble中被标记为"audited"的流量
hubble observe --verdict DROPPED --type ingress | grep audited

# 确认审计流量无业务影响后关闭审计模式
kubectl -n kube-system annotate configmap cilium-config   cilium.io/policy-audit-mode=false
kubectl -n kube-system rollout restart ds/cilium

生产部署Cilium需注意内核版本要求——eBPF功能需要Linux 5.4以上内核，kubeProxyReplacement需要5.6以上。CentOS 7等老旧系统需先升级内核。大型集群（500+ Node）建议为Hubble配置持久化存储，避免Relay重启后丢失流量历史。Cilium的ClusterMesh功能可实现跨集群网络策略统一管理，多集群场景下各集群Cilium配置需保持版本一致。