3. 容器网络基础：Kubernetes网络模型、CNI插件与Service通信原理
在深入Velero备份恢复与蓝绿发布漂移告警复测之前，必须牢固掌握Kubernetes容器网络的核心原理。本章将围绕Kubernetes网络模型、主流CNI插件（Calico/Flannel）以及Service与Pod之间的通信机制展开，为后续网络策略备份、漂移检测和恢复验证奠定基础。
3.1 Kubernetes网络模型：IP-per-Pod与扁平网络
Kubernetes网络模型的核心设计原则是“每个Pod拥有一个独立的IP地址”，并且所有Pod之间可以直接通信，无需NAT转换。这一模型被称为IP-per-Pod模型，它极大地简化了容器网络的设计和运维。
该模型要求集群网络满足以下三个基本条件：
- Pod间直接通信：任意两个Pod（无论是否在同一节点）可以直接通过IP地址通信，不经过NAT。
- Node与Pod通信：集群中的每个节点（Node）可以直接与任意Pod通信。
- Pod内容器共享网络：同一个Pod内的所有容器共享同一个网络命名空间（Network Namespace），包括IP地址和端口空间。
下表总结了Kubernetes网络模型与传统虚拟化网络模型的差异：
| 特性 | Kubernetes网络模型 | 传统虚拟化网络 |
|---|---|---|
| IP分配粒度 | Pod（一组容器） | 虚拟机或物理机 |
| 通信方式 | 直接IP通信，无NAT | 通常需要NAT或路由 |
| 网络隔离 | 通过NetworkPolicy实现 | 通过VLAN/安全组实现 |
| IP地址生命周期 | 随Pod创建/销毁而动态变化 | 相对固定 |
3.2 CNI插件：Calico与Flannel对比
CNI（Container Network Interface）是Kubernetes与容器运行时之间的网络配置接口标准。CNI插件负责为Pod分配IP地址、配置网络接口以及实现网络连通性。在生产环境中，Calico和Flannel是最常用的两种CNI插件。
3.2.1 Flannel：简单高效的覆盖网络
Flannel是一个轻量级的覆盖网络（Overlay Network）解决方案，它通过VXLAN或host-gw模式在集群节点间建立二层网络隧道，实现Pod跨节点通信。Flannel不提供网络策略（NetworkPolicy）支持，适合对网络隔离要求不高的场景。
3.2.2 Calico：功能丰富的网络与安全方案
Calico基于BGP（Border Gateway Protocol）协议实现纯三层网络，无需封装，性能较高。Calico原生支持Kubernetes NetworkPolicy，提供细粒度的网络访问控制。在蓝绿发布和漂移告警场景中，Calico的网络策略能力是保障应用安全的关键。
下表对比了Calico与Flannel的核心差异：
| 对比维度 | Calico | Flannel |
|---|---|---|
| 网络模式 | 纯三层（BGP） | 覆盖网络（VXLAN/host-gw） |
| 性能 | 高（无封装开销） | 中等（有封装开销） |
| NetworkPolicy支持 | 原生支持，功能丰富 | 不支持 |
| IP地址管理 | 支持IP池、IP预留 | 简单IP分配 |
| 适用场景 | 生产环境、安全敏感、多租户 | 开发测试、简单集群 |
3.3 Service与Pod网络通信原理
Service是Kubernetes中用于暴露Pod服务的抽象层。由于Pod IP是动态变化的，Service通过标签选择器（Label Selector）动态关联后端Pod，并提供稳定的虚拟IP（ClusterIP）和DNS名称。
3.3.1 Service类型与流量路径
Kubernetes支持多种Service类型，每种类型对应不同的流量入口和网络路径：
- ClusterIP：集群内部虚拟IP，仅集群内可访问。
- NodePort：在每个节点上开放一个静态端口，外部流量通过节点IP+端口访问。
- LoadBalancer：云厂商提供的负载均衡器，外部流量通过LB访问。
- ExternalName：将Service映射到外部DNS名称。
3.3.2 kube-proxy与负载均衡
kube-proxy是运行在每个节点上的网络代理组件，负责实现Service的负载均衡。kube-proxy支持三种模式：
- userspace模式（已弃用）：用户态代理，性能较差。
- iptables模式：利用Linux iptables规则实现随机或轮询负载均衡，是目前最常用的模式。
- IPVS模式：利用Linux IPVS模块实现高性能负载均衡，支持更多调度算法（如最少连接、加权轮询）。
下图展示了Service、kube-proxy与Pod之间的通信流程：
3.4 网络策略（NetworkPolicy）与安全隔离
NetworkPolicy是Kubernetes中用于控制Pod间网络流量的资源对象。它通过标签选择器定义哪些Pod可以相互通信，实现微服务间的安全隔离。在蓝绿发布和漂移告警场景中，NetworkPolicy的正确性直接影响应用的安全性和可用性。
一个典型的NetworkPolicy示例：
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: 80803.5 本章小结
本章系统梳理了Kubernetes容器网络的基础知识，包括IP-per-Pod模型、CNI插件（Calico与Flannel）的对比、Service与Pod的通信原理以及NetworkPolicy的作用。这些知识是理解后续Velero备份恢复、蓝绿发布和漂移告警复测流程的前提。在下一阶段，我们将基于这些网络基础，深入探讨如何利用Velero备份和恢复网络策略，以及如何在漂移告警后验证网络连通性。