3. 租户网络拓扑概述：VPC、子网、安全组、ACL 与 NetPolicy 的关系

在云原生租户环境中，网络策略并非孤立存在，而是叠加在多层网络抽象之上的最终访问控制层。理解 VPC、子网、安全组、ACL 与 NetPolicy 的层级关系与职责边界，是准确核算策略命中率与误报的前提。本节从逻辑分层、功能对比和协作流程三个维度进行拆解。

3.1 五层网络抽象模型

租户网络拓扑通常遵循从物理网络到应用工作负载的逐层抽象。下表总结了各层的核心职责与典型对象：

3.2 核心组件职责边界

为避免策略冲突与误报，必须明确各组件的作用域：

• VPC（虚拟私有云）： 提供租户级网络隔离。不同 VPC 之间默认不通，NetPolicy 无法跨越 VPC 边界生效。VPC 是策略命中的“大前提”——跨 VPC 流量在底层即被丢弃，不会进入 NetPolicy 评估流程。
• 子网： 是 VPC 内的 IP 地址段划分，通常对应一个可用区或一层业务分组。子网本身不提供安全过滤，但它是 ACL 的绑定目标，也是 Pod 网络 IP 的分配池。
• 安全组： 有状态防火墙，作用于实例（如云服务器、弹性网卡）。安全组规则基于 IP 和端口，常用于控制南北向流量（外部访问实例）及实例间的东西向流量。安全组允许的流量，NetPolicy 仍可拒绝；安全组拒绝的流量，NetPolicy 无需评估。
• ACL（网络访问控制列表）： 无状态防火墙，作用于子网级别。ACL 规则需同时配置入站和出站方向，且按序号顺序匹配。ACL 常用于粗粒度子网隔离，NetPolicy 在其之上做细粒度 Pod 级控制。
• NetPolicy（网络策略）： 基于 Kubernetes 原生 API 的声明式策略，使用标签选择器匹配源/目标 Pod，支持 Ingress 和 Egress 规则。NetPolicy 只控制 Pod 之间的流量，不控制 Pod 与外部服务或节点端口的流量。

3.3 策略评估协作流程

当一个数据包在租户网络内传输时，各层安全机制按固定顺序执行检查。下图展示了从物理端口到 Pod 容器的完整评估链路：

3.4 策略冲突场景与命中率影响

在实际运维中，以下场景容易导致 NetPolicy 命中率失真或误报率升高：

• 安全组过于宽松： 安全组放行了所有 Pod 间流量，NetPolicy 的拒绝规则被“架空”，导致 NetPolicy 命中率偏低（流量未到达策略层）。
• ACL 与 NetPolicy 规则矛盾： ACL 拒绝某子网段，但 NetPolicy 允许该子网内的 Pod 互访。此时 NetPolicy 规则虽被创建，但流量在 ACL 层即被丢弃，形成“假命中”。
• 跨 VPC 策略无效： 在 VPC A 中创建 NetPolicy 试图控制 VPC B 的 Pod，策略永远无法命中，应直接标记为配置错误。
• 子网 CIDR 变更未同步： 子网扩缩容后，ACL 规则未更新，导致合法流量被 ACL 拦截，NetPolicy 无法正常评估。

3.5 推荐的最佳实践

1. 分层收敛原则： ACL 做子网级粗粒度黑白名单，安全组做实例级端口管控，NetPolicy 做 Pod 级微隔离。各层职责不重叠、不替代。
2. 策略基线先行： 在部署 NetPolicy 前，先确认安全组和 ACL 已按最小权限原则配置，避免下层过度放行导致 NetPolicy 失效。
3. 审计日志关联分析： 将 VPC 流日志、安全组日志、NetPolicy 审计日志进行时间戳和五元组关联，精准定位流量是在哪一层被丢弃。
4. 定期策略复核： 每季度执行一次全量策略映射，检查 NetPolicy 规则是否与下层 ACL/安全组规则存在矛盾或冗余。