3. 容器网络基础:CNI插件模型、Kubernetes网络策略(NetworkPolicy)原理、Pod网络命名空间

在深入OPA策略与网络可视化之前,必须理解Kubernetes网络的三大基石:Pod网络命名空间、CNI插件模型以及NetworkPolicy。这三者构成了容器网络的数据平面与控制平面基础,也是后续准入策略与流量路径分析的直接作用对象。

3.1 Pod网络命名空间:容器网络的原子单元

Kubernetes中,每个Pod拥有一个独立的网络命名空间(Network Namespace)。Pod内的所有容器共享该命名空间,这意味着它们共享同一个IP地址、端口范围、路由表以及网络设备(如eth0)。

关键特性: Pod网络命名空间是“单IP模型”的实现基础。Pod内的容器通过localhost直接通信,无需端口映射;而Pod之间必须通过真实的网络地址(Pod IP)进行通信。
特性 Pod网络命名空间 宿主机网络命名空间
IP地址 每个Pod拥有独立的Cluster内IP 宿主机拥有物理网络IP
网络设备 通常包含一个veth pair的Pod端(eth0) 包含物理网卡、bridge、路由表
路由表 默认路由指向CNI创建的网关 包含完整的宿主机路由策略
端口空间 独立,Pod内容器共享 全局,与宿主机进程共享

Pod网络命名空间的创建与销毁由kubelet与CNI插件协同完成。当Pod被调度到节点时,kubelet调用CNI插件为该Pod创建网络命名空间并分配网络资源。

3.2 CNI插件模型:网络配置的标准化接口

容器网络接口(CNI,Container Network Interface)是Kubernetes与网络插件之间的标准协议。它定义了如何为容器配置网络接口、分配IP地址以及管理网络连通性。

CNI插件的工作流程遵循“ADD/CHECK/DEL”三个核心操作,每次Pod生命周期变化时触发。

  1. ADD:kubelet调用CNI插件,传入Pod的网络命名空间路径、容器ID以及网络配置JSON。插件负责创建veth pair、连接bridge、分配IP并设置路由。
  2. CHECK:周期性或事件驱动地验证Pod网络配置是否仍然有效。
  3. DEL:Pod删除时,CNI插件清理网络资源,释放IP地址。
运维提示: 常见的CNI插件包括Calico(基于BGP,支持NetworkPolicy)、Flannel(基于VXLAN/Overlay,轻量)、Cilium(基于eBPF,高性能与可观测性)。选择CNI时需考虑网络策略支持、性能开销以及可观测性能力。

以下SVG图展示了CNI插件在Pod创建时的核心工作流程,包括kubelet、CNI插件、网络命名空间与底层网络设备之间的交互关系。

CNI插件模型工作流程 CNI插件模型:Pod网络创建流程 kubelet CNI配置 (JSON) CNI插件 Pod NetNS veth pair Bridge / 网关 流程说明: 1. kubelet 读取 CNI 配置,确定使用的插件与网络参数。 2. CNI 插件创建 veth pair,一端放入 Pod NetNS,另一端连接 bridge。 3. 插件通过 IPAM 分配 IP,设置路由,完成 Pod 网络接入。

3.3 Kubernetes NetworkPolicy:容器网络的访问控制

NetworkPolicy是Kubernetes原生的网络访问控制资源,用于定义Pod之间以及Pod与外部端点之间的流量规则。它工作在OSI模型的第3/4层(IP+端口),通过标签选择器(Label Selector)实现灵活的流量隔离。

NetworkPolicy的核心概念包括:

  • Pod Selector:通过标签选择目标Pod,策略将应用于这些Pod。
  • Policy Types:Ingress(入站流量)和Egress(出站流量)。
  • From/To:定义允许的源或目标,支持podSelector、namespaceSelector、ipBlock。
  • Ports:指定允许的端口与协议(TCP/UDP/SCTP)。
重要前提: NetworkPolicy必须由支持它的CNI插件(如Calico、Cilium、Weave Net)实现。如果使用Flannel(默认不支持NetworkPolicy),策略将被忽略,所有Pod默认全通。

以下是一个典型的NetworkPolicy YAML示例,用于限制“frontend”命名空间中带有app: web标签的Pod,仅允许来自“ingress-gateway”命名空间的流量访问80端口。

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

NetworkPolicy的默认行为遵循“白名单”原则:一旦任何NetworkPolicy选中了一个Pod,该Pod默认拒绝所有未显式允许的流量。如果没有任何NetworkPolicy选中Pod,则默认允许所有流量。

场景 默认行为 说明
无NetworkPolicy选中Pod 允许所有入站与出站流量 等同于“全通”模式,适用于开发环境
至少一个Ingress规则选中Pod 拒绝所有未显式允许的入站流量 白名单生效,必须显式声明允许的源
至少一个Egress规则选中Pod 拒绝所有未显式允许的出站流量 出站流量同样受控,防止数据外泄
同时存在Ingress与Egress规则 双向白名单,完全隔离 生产环境推荐,最小权限原则

以下SVG图展示了NetworkPolicy在Kubernetes集群中的流量控制逻辑,包括Pod选择器、Ingress/Egress规则以及流量路径的允许与拒绝决策。

Kubernetes NetworkPolicy 流量控制逻辑 NetworkPolicy 流量控制逻辑 外部流量 Ingress 规则 Pod 选择器 目标 Pod (app: web) Egress 规则 允许 / 拒绝决策 决策逻辑: • 入站流量:Ingress 规则检查源(namespaceSelector / podSelector / ipBlock)与端口。 • 出站流量:Egress 规则检查目标与端口,控制Pod对外访问。 • 默认拒绝:一旦有规则选中Pod,未匹配的流量被拒绝。 • 多规则叠加:多个NetworkPolicy的规则取并集,任一规则匹配即允许。

3.4 三者关系:从命名空间到策略执行

Pod网络命名空间、CNI插件与NetworkPolicy构成了Kubernetes容器网络的完整链路:

  • Pod网络命名空间是网络隔离的最小单元,为每个Pod提供独立的网络栈。
  • CNI插件负责创建并连接这些命名空间到集群网络,实现Pod间的连通性。
  • NetworkPolicy在CNI提供的数据平面上施加访问控制规则,实现微隔离。
可视化运维视角: 在后续章节中,我们将通过OPA策略对NetworkPolicy的创建进行准入控制,并通过流量路径可视化工具(如Cilium Hubble或Calico Flow)实时观察策略生效后的流量变化。理解这三者的关系是进行可视化运维的前提。