3. 容器网络基础：CNI插件原理、容器网络模型与常见CNI

3.1 容器网络模型：从单机到集群的抽象

容器网络的核心挑战在于：如何为动态创建、销毁的容器提供一致的网络标识（IP地址）和连通性。Kubernetes 采用 IP-per-Pod 模型，即集群中每个 Pod 都拥有一个独立的、可路由的 IP 地址，Pod 内的所有容器共享该 IP 和网络命名空间。这一模型简化了端口映射和容器间通信，但要求底层网络基础设施必须支持大规模、高动态的 IP 分配与路由。

3.2 CNI 插件原理：标准接口与生命周期

容器网络接口（Container Network Interface, CNI）是 Kubernetes 与网络实现之间的标准协议。它定义了一组规范，用于配置容器网络。CNI 插件本质上是可执行文件，由容器运行时（如 containerd、CRI-O）在创建或删除 Pod 时调用。

CNI 核心操作流程：

1. ADD 操作： 运行时调用 CNI 插件，传入网络配置（JSON）和容器 ID。插件负责创建 veth pair，一端放入容器网络命名空间，另一端连接到宿主机网络（如 bridge、overlay 隧道）。插件还需分配 IP 地址并设置路由。
2. DEL 操作： 删除 Pod 时，运行时调用 CNI 插件清理网络资源，释放 IP 地址，拆除 veth pair。
3. CHECK 操作： 可选操作，用于验证容器网络状态是否符合预期。

{
  "cniVersion": "0.4.0",
  "name": "my-cni-net",
  "type": "bridge",
  "bridge": "cni0",
  "isGateway": true,
  "ipMasq": true,
  "ipam": {
    "type": "host-local",
    "ranges": [
      [{"subnet": "10.244.0.0/16"}]
    ],
    "routes": [{"dst": "0.0.0.0/0"}]
  }
}

3.3 容器网络模型：Overlay vs Underlay

根据网络封装与路由方式，容器网络模型主要分为 Overlay 和 Underlay 两种。选择哪种模型取决于性能要求、网络基础设施和运维复杂度。

3.4 常见 CNI 插件对比：Calico / Flannel / Weave

Kubernetes 生态中有数十种 CNI 插件，其中 Calico、Flannel 和 Weave 是最具代表性的三种。它们在设计哲学、网络模型和功能特性上各有侧重。

3.5 网络策略与安全准入

容器网络不仅仅是连通性，还包括安全隔离。Kubernetes NetworkPolicy 是一种资源对象，用于控制 Pod 之间的网络流量。CNI 插件必须实现 NetworkPolicy 才能生效。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress: []

网络策略最佳实践：

• 默认拒绝： 创建默认的 Deny-All 策略，然后按需开放白名单规则。
• 最小权限： 只允许必要的端口和协议（如 TCP 80、443），避免使用 0.0.0.0/0。
• 命名空间隔离： 使用命名空间级别的策略，防止跨命名空间未授权访问。
• 审计与监控： 结合网络流量日志（如 Calico 的 FlowLogs）进行策略效果验证。