2. Kubernetes 网络基础回顾：Pod网络、Service网络、CNI插件与网络策略的关系
在深入Helm Chart的网络策略编排之前，必须厘清Kubernetes网络模型中的三个核心抽象层：Pod网络、Service网络以及网络策略（NetworkPolicy）。这三者通过CNI插件实现落地，共同构成了集群内通信的规则骨架。理解它们之间的层级关系与数据流，是编写跨命名空间Chart通信规则的前提。
2.1 三层网络模型概览
Kubernetes网络模型强制遵循以下基本原则：
- Pod间直接通信：每个Pod拥有独立的IP地址，无需NAT即可跨节点通信。
- Service抽象层：通过虚拟IP（ClusterIP）提供稳定的访问入口，后端自动负载均衡到一组Pod。
- 网络策略：基于标签选择器定义Pod间或Pod与外部端点之间的流量访问规则，默认拒绝所有入站流量。
下表总结了三个网络层的核心差异：
| 网络层 | IP分配范围 | 通信范围 | 生命周期 | 是否受NetworkPolicy控制 |
|---|---|---|---|---|
| Pod网络 | 集群CIDR（如10.244.0.0/16） | 跨节点、跨命名空间 | 随Pod创建/销毁 | 是（直接作用于Pod） |
| Service网络 | Service CIDR（如10.96.0.0/12） | 集群内部虚拟IP | 持久化（除非删除Service） | 否（策略作用于Pod，而非Service IP） |
| 网络策略 | 无独立IP | 基于标签选择器 | 持久化（除非删除策略） | —（策略本身是规则定义） |
关键理解：网络策略不直接作用于Service的ClusterIP。当流量通过Service转发到后端Pod时，策略在Pod网络层生效。这意味着即使Service允许访问，如果目标Pod的入站策略拒绝该来源，连接仍会被阻断。
2.2 CNI插件：网络模型的实现者
CNI（Container Network Interface）插件负责为Pod分配IP、配置网络接口并实现跨节点路由。不同的CNI插件对网络策略的支持程度不同，这直接影响Helm Chart中NetworkPolicy资源的生效范围。
主流CNI插件对比：
| CNI插件 | 网络模式 | 原生NetworkPolicy支持 | 跨命名空间策略 | 性能特征 |
|---|---|---|---|---|
| Calico | BGP路由 / VXLAN | 完全支持（包括GlobalNetworkPolicy） | 支持（通过namespaceSelector） | 高吞吐，低延迟 |
| Cilium | eBPF | 完全支持（增强版） | 支持（支持DNS/FQDN策略） | 极高，内核级转发 |
| Flannel | VXLAN / host-gw | 不支持 | 不适用 | 中等，简单稳定 |
| Weave Net | VXLAN + 快速路径 | 支持（基础版） | 支持 | 中等，加密可选 |
重要提示：如果集群使用Flannel作为CNI，则NetworkPolicy资源会被API Server接受但不会生效。在Helm Chart中部署网络策略前，必须确认集群CNI支持策略执行。建议在Chart的values.yaml中增加
.Values.networkPolicy.enabled开关，并配合条件判断。
2.3 网络策略的核心结构
一个标准的NetworkPolicy资源包含三个关键部分：podSelector（目标Pod）、policyTypes（入站/出站）、ingress/egress规则。以下是一个允许跨命名空间访问的示例：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-from-monitoring
namespace: production
spec:
podSelector:
matchLabels:
app: web-server
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: monitoring
podSelector:
matchLabels:
app: prometheus
ports:
- protocol: TCP
port: 9090该策略的含义：
- 作用范围：仅作用于
production命名空间中标签为app: web-server的Pod。 - 允许来源：来自
monitoring命名空间中标签为app: prometheus的Pod。 - 端口限制：仅允许TCP 9090端口的入站流量。
2.4 Pod网络、Service网络与策略的数据流关系
下图展示了客户端通过Service访问目标Pod时，网络策略在哪个层级生效：
2.5 跨命名空间通信的关键约束
当Helm Chart需要跨命名空间发布网络策略时，必须注意以下三个约束：
- namespaceSelector必须显式匹配：策略中的
namespaceSelector需要与目标命名空间的标签匹配。Kubernetes 1.22+推荐使用kubernetes.io/metadata.name标签。 - 出站策略同样重要：如果客户端命名空间启用了默认拒绝出站策略，即使目标端允许入站，流量仍会被客户端侧阻断。
- 策略的累加性：多个NetworkPolicy作用于同一组Pod时，规则是或的关系——只要有一个策略允许，流量即被放行。
Helm实践提示：在Chart模板中，建议将
namespaceSelector和podSelector的值抽取为.Values.networkPolicy.allowedNamespaces和.Values.networkPolicy.allowedPods，通过循环渲染多个from规则，避免硬编码。
2.6 网络策略与CNI插件的协同架构
下图展示了CNI插件如何将NetworkPolicy资源转换为底层数据平面规则：
2.7 本章小结
- Pod网络是通信的基础，每个Pod拥有独立IP，跨节点可达。
- Service网络提供稳定的虚拟IP，但网络策略不直接作用于Service IP。
- CNI插件是网络策略的执行者，不同插件对策略的支持程度差异巨大。
- 跨命名空间策略依赖
namespaceSelector与podSelector的组合，必须同时考虑入站和出站规则。