3. Kubernetes 网络策略回顾：NetworkPolicy 资源定义，Ingress/Egress 规则，Pod 选择器与命名空间隔离
在深入 Calico 准入策略性能基准测试之前，必须牢固掌握 Kubernetes 原生网络策略（NetworkPolicy）的核心机制。NetworkPolicy 是 Kubernetes 中用于控制 Pod 间网络访问的声明式防火墙规则，它通过标签选择器实现细粒度的流量管控，是构建零信任网络架构的基础单元。
3.1 NetworkPolicy 资源定义结构
NetworkPolicy 是一个命名空间级别的 Kubernetes 资源，其 API 版本为 networking.k8s.io/v1。一个完整的 NetworkPolicy 定义包含以下核心字段：
| 字段路径 | 类型 | 说明 |
|---|---|---|
spec.podSelector |
LabelSelector | 选择策略生效的目标 Pod，空选择器匹配命名空间下所有 Pod |
spec.policyTypes |
[]PolicyType | 声明策略类型：Ingress、Egress 或两者都包含 |
spec.ingress |
[]IngressRule | 入站流量规则列表，每个规则定义允许的来源和端口 |
spec.egress |
[]EgressRule | 出站流量规则列表，每个规则定义允许的目标和端口 |
以下是一个典型的 NetworkPolicy 示例，它允许 frontend 命名空间中带有 role: api 标签的 Pod 接收来自 monitoring 命名空间中 app: prometheus 的 TCP 8080 流量：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-prometheus-to-api
namespace: frontend
spec:
podSelector:
matchLabels:
role: api
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: monitoring
podSelector:
matchLabels:
app: prometheus
ports:
- protocol: TCP
port: 80803.2 Ingress 与 Egress 规则详解
Ingress 和 Egress 规则分别控制入站和出站流量。每条规则由 来源/目标选择器 和 端口列表 组成，支持多种选择器组合方式：
- podSelector：选择同一命名空间内的 Pod 作为来源或目标。
- namespaceSelector：选择整个命名空间作为来源或目标，匹配命名空间自身的标签。
- ipBlock：基于 CIDR 地址段匹配集群外部 IP，支持
except排除特定子网。
规则中的多个选择器之间是 OR 关系，即满足任一选择器即视为匹配。同一选择器内的多个标签是 AND 关系，必须同时满足。
| 规则类型 | 选择器组合示例 | 语义 |
|---|---|---|
| Ingress | from: [podSelector, namespaceSelector] |
允许来自本命名空间特定 Pod 或 其他命名空间所有 Pod 的流量 |
| Egress | to: [ipBlock, podSelector] |
允许访问集群外部 CIDR 段 或 本命名空间特定 Pod |
| Ingress | from: [namespaceSelector + podSelector] |
允许来自特定命名空间中特定 Pod 的流量（跨命名空间精确控制） |
ipBlock 规则的匹配效率通常高于 podSelector + namespaceSelector 组合，因为前者仅需 CIDR 匹配，后者需要遍历 etcd 中的 Pod 和 Namespace 对象。大规模集群下应优先使用 ipBlock 或扁平化标签设计。
3.3 Pod 选择器与命名空间隔离机制
Pod 选择器基于标签（Label）进行匹配，这是 Kubernetes 网络策略实现动态隔离的核心。命名空间隔离则通过 namespaceSelector 实现，允许策略跨命名空间生效。
下图展示了 NetworkPolicy 中 Pod 选择器与命名空间选择器的协同工作方式：
3.4 命名空间隔离的默认行为与最佳实践
Kubernetes 默认允许所有 Pod 间通信，NetworkPolicy 的引入改变了这一行为。理解命名空间隔离的默认规则对于设计性能测试场景至关重要：
- 无策略时：所有 Pod 可以自由通信，无论命名空间。
- 有策略时：匹配策略的 Pod 仅允许符合规则的流量，其他流量被拒绝。
- 多策略叠加：多个 NetworkPolicy 作用于同一 Pod 时，规则取 OR 并集，即任一策略允许则放行。
policyTypes 字段，避免因策略类型缺失导致非预期的流量阻断。
下表总结了不同隔离策略组合下的流量行为：
| 场景 | Ingress 策略 | Egress 策略 | 入站流量 | 出站流量 |
|---|---|---|---|---|
| 无策略 | 无 | 无 | 全部允许 | 全部允许 |
| 仅 Ingress | 有 | 无 | 仅允许规则匹配 | 全部允许 |
| 仅 Egress | 无 | 有 | 全部拒绝 | 仅允许规则匹配 |
| Ingress + Egress | 有 | 有 | 仅允许规则匹配 | 仅允许规则匹配 |
3.5 性能基准测试中的 NetworkPolicy 考量
在后续章节的 Calico 准入策略性能测试中，NetworkPolicy 的以下特性将直接影响测试设计和结果分析：
- 规则数量与匹配延迟：每个 Pod 关联的 NetworkPolicy 数量越多，iptables/IPVS 规则链越长，数据包匹配延迟线性增加。
- 选择器复杂度：
podSelector与namespaceSelector的组合查询需要访问 API Server 或本地缓存，影响策略生效速度。 - 策略变更频率：频繁创建/更新 NetworkPolicy 会触发数据平面规则重载，造成短暂的连接中断或延迟抖动。
- 命名空间数量：跨命名空间策略需要维护更多的路由规则，大规模多租户场景下性能下降尤为明显。