文档中心

容器服务

网络

NetworkPolicy 网络访问控制最佳实践

本文介绍 VKE 集群 NetworkPolicy 的设计与配置实践，涵盖最小权限控制、标签与选择器、默认拒绝、容量规划、可观测性及渐进式发布等，帮助您在集群中安全、稳定地实施网络隔离。

适用范围

NetworkPolicy 支持基于 Pod、命名空间、IP 网段和端口控制三层、四层流量。使用该能力前，请确保集群已安装支持 NetworkPolicy 的网络插件。

未被任何 NetworkPolicy 选中的 Pod，其入站和出站流量默认放行。标准 NetworkPolicy 不支持显式拒绝规则和策略优先级；同一方向存在多条策略时，允许规则取并集。若要默认拒绝某一方向的流量，可在 policyTypes 中声明该方向，并将对应的允许规则留空。

要成功建立连接，源 Pod 的出站策略和目标 Pod 的入站策略必须同时允许；未被策略隔离的方向默认放行。更多介绍，请参见官方文档。

使用前提

在 VKE 中使用 NetworkPolicy，需要满足的条件，如下表所示。更多功能介绍和使用详情，请参见使用 NetworkPolicy 实现网络访问控制。

检查项	要求	检查方式
网络模型	使用 VPC-CNI 网络模型。	进入集群详情页，查看集群的网络模型。
vpc-cni 版本	建议高于 v1.8.11 的版本。	在组件管理的网络页签中查看当前版本；版本不符合要求时，请先升级组件。
功能状态	已申请并启用 NetworkPolicy。	该功能当前处于邀测阶段。请先申请开通，并在 vpc-cni 配置中确认 NetworkPolicy 已启用。详情请参见 vpc-cni。
工作负载类型	适用于普通 VKE Pod。	VCI Pod 使用独立的网络策略方案，不适用本文所述流程。更多详情，请参见使用 NetworkPolicy 实现 VCI Pod 网络访问控制。
变更窗口	建议选择业务低峰期。	启用或关闭 NetworkPolicy 会重启相关组件，配置约 1 分钟后生效。

警告

请勿直接在生产命名空间中配置默认拒绝策略。启用默认拒绝后，策略选中的 Pod 在相应方向上，未被显式允许的流量均会被拒绝。若放行规则遗漏 DNS、健康检查或上游服务等必要依赖，可能导致业务立即中断。建议先在测试命名空间中验证策略，确认必要依赖均已放行后，再按工作负载或业务范围分批应用到生产环境。

核心字段和注意事项

在集群中配置 NetworkPolicy 时，常见的核心字段说明和注意事项，如下表所示。

核心字段	说明
podSelector	选择 NetworkPolicy 的作用对象。空选择器 {}表示选中当前命名空间中的所有 Pod。
policyTypes	指定策略控制的流量方向，包括 Ingress（入站）、Egress（出站）或两者。未被选中的方向保持默认放行。
from/to 对端选择器	podSelector：选择与 NetworkPolicy 位于同一命名空间的 Pod。 namespaceSelector：通过命名空间标签选择目标命名空间，并匹配其中的所有 Pod。
选择器组合规则	在同一个对端配置项中同时配置 namespaceSelector 和 podSelector 时，两者为“与”关系，即同时匹配命名空间标签和 Pod 标签；将它们配置为两个并列的对端项时，两者为“或”关系。
ipBlock	静态 CIDR 网段，用于指定集群外部的 IP 地址。注意 ipBlock 仅用于匹配集群外部 IP 地址。VKE 不支持使用 ipBlock 匹配 Pod、Service 或节点等集群内部地址。此外，Service 地址转换和源地址转换可能导致策略实际识别的源 IP 或目标 IP 与预期不一致。升级注意事项：将 vpc-cni 组件升级至 v1.8.0 及以上版本时，NetworkPolicy 对节点 IP 的匹配逻辑会发生如下变化：升级前，ipBlock可以匹配节点 IP；升级后，ipBlock 将忽略节点 IP。升级组件前，请检查现有 NetworkPolicy 是否使用 ipBlock 匹配节点 IP。如果存在，请先修改相关策略并完成验证，再升级 vpc-cni，避免相关流量被意外阻断。配置使用原则：确保 ipBlock.cidr 不与 Pod、Service 或节点网段重叠。配置外部依赖时，优先使用范围明确且稳定的小网段，避免使用大网段配合大量 except。涉及负载均衡、SNAT 或跨集群访问时，请先确认策略实际识别的源 IP 和目标 IP，再配置规则。

设计原则

NetworkPolicy 的设计目标是遵循最小权限原则，明确并验证业务所需的网络访问关系，而非一次性阻断命名空间内的所有流量。建议遵循以下原则进行设计。

使用稳定标签

使用 app.kubernetes.io/name、app.kubernetes.io/component、environment 等稳定标签标识应用、组件和环境。

避免将 Pod 名称、发布批次、哈希值等频繁变化的值用作 NetworkPolicy 的长期选择条件。

修改工作负载标签前，请检查现有 NetworkPolicy 的选择范围，避免滚动发布期间新旧 Pod 因标签不同而获得不一致的网络访问权限。

在 vpc-cni 组件的 Cilium 参数中，可以配置 Cilium 识别的 Pod 标签范围。下图展示未启用 NetworkPolicy 时的 labels 配置示例。启用 NetworkPolicy 后，请根据策略实际依赖的稳定标签调整该配置，避免直接沿用示例值。

合理配置网络策略

不合理的网络策略可能产生大量 policy_map 表项，增加数据写入量，降低策略同步性能，甚至超出 policy_map 默认的 16384 条容量限制。配置网络策略时，请重点关注以下场景：

组合使用 cidr 和 except：except 可能将一个较大的 CIDR 拆分为多个较小的 CIDR，每个拆分后的 CIDR 都会分配对应的 Cilium Identity。拆分数量过多时，将占用较多的 policy_map 容量。因此，应避免使用大网段配合大量 except 的复杂规则。

放行整个命名空间：使用 NetworkPolicy 放行整个命名空间时需谨慎。该配置会将命名空间内所有 Pod 对应的 ID 下发至 policy_map。配置前，请根据 Pod 规模评估 policy_map 的容量是否充足。

如果优化网络策略后仍需扩大 policy_map 容量，或需要更多技术支持，可提交工单随时联系我们。

容量与可观测性

启用 NetworkPolicy 会增加网络组件和 API Server 的资源消耗。在大规模集群中，应重点关注网络组件资源使用情况、策略和身份规模，以及控制面的访问压力。

控制标签与规则规模

从安全身份的计算范围中排除与访问控制无关、基数较高的标签，避免产生过多 CiliumIdentity。

优先按应用或组件精确放行，避免使用大范围的命名空间放行规则。选择范围越大，策略计算量和下发量通常越高。

减少复杂的 CIDR 拆分和大量 except 配置，确保规则规模可控，并便于审计和测试。

Service 和 NetworkPolicy 均依赖 Cilium BPF Map。随着规则数量增加，相关 Map 可能达到容量上限。建议通过以下指标监控 Map 使用率：

cilium_bpf_map_pressure{map_name=~"(policy|lb).*"}

规划大规模集群时，请提前提交工单进行容量评估，避免直接沿用小规模集群的配置。更多信息，请参见大规模集群版本和配置。

大规模集群配置

集群节点数超过 500 时，建议在 vpc-cni 组件中独立部署 Cilium Operator，并配置 3～5 个副本。同时，应结合 Cilium Operator 的 CPU、内存使用情况和 API Server 负载评估资源配置。Pod 数量超过 50000 时，请按照大规模集群配置建议进行调整。更多信息，请参见大规模集群版本和配置。

集群节点数超过 1000 时，每个节点上的 Cello 都会通过 List-Watch 机制监听集群内的所有 CiliumEndpoint，可能增加 API Server 的访问压力。如果不使用 NetworkPolicy，请保持该功能关闭（默认关闭）；如需启用，请合理配置 Cilium 标签，缩小身份识别范围。

对于更大规模的集群，应提前评估 Cilium policy_map 的容量。如需协助，请联系 VKE 技术支持。

建议观测项

建议重点监控以下指标和状态：

vpc-cni 相关 Pod 的 Ready 状态、重启次数、CPU 和内存使用情况。

API Server 的请求量、请求延迟和限流情况。

CiliumIdentity 资源数量。

策略创建或更新后的生效耗时。

DNS 解析失败、连接超时、连接拒绝和业务错误率。

说明

建议开启集群审计日志和网络组件日志采集。出现问题时，请至少准备以下诊断信息：集群 ID、问题发生时间范围、命名空间、源 Pod 和目标 Pod、源 IP 和目标 IP、协议与端口、策略 YAML，以及问题复现命令。

常见限制与误区

现象或做法	原因	建议
NetworkPolicy 已创建，但流量未受限制。	NetworkPolicy 功能未开启、网络组件未就绪，或 podSelector 未选中目标 Pod。	检查 vpc-cni 配置和组件状态，并确认策略所在命名空间及目标 Pod 标签是否符合选择条件。
启用默认拒绝策略后，应用请求全部超时。	放行规则遗漏了 DNS、上游服务入口或必要的出站依赖。	优先恢复 DNS 访问，再根据业务依赖清单逐项添加最小范围的放行规则。
使用 ipBlock 放行 Pod 或节点。	VKE 中的 ipBlock 仅用于匹配集群外部地址；地址转换也可能导致实际匹配结果与预期不一致。	Pod 间访问应使用 Pod 或命名空间选择器；节点访问场景应单独设计放行规则。
在不同环境中复用同一标签。	选择器范围过大，可能将测试环境和生产环境的工作负载识别为同一类对象。	分别使用环境、应用和组件等稳定标签，并通过多个标签组合限定选择范围。
仅使用 Ping 验证策略。	Ping 只能验证 ICMP 连通性，无法代表实际的 TCP、UDP 业务链路，也无法验证端口规则。	使用 curl、nc、dig 或业务客户端，按照实际协议和端口验证连通性。
一次性在所有生产环境中启用默认拒绝策略。	未识别的业务依赖可能同时中断，影响范围难以控制。	按工作负载、命名空间或业务域分阶段启用，并在每个阶段完成连通性验证。

说明

NetworkPolicy 在以下场景中存在使用限制：通过 ipBlock 的 except 排除部分 IP 网段、配置的网段存在重叠、Pod 更新后应用网络策略，以及部分 UDP 和 SCTP 通信场景。如果您的配置涉及这些场景，请先查阅使用 NetworkPolicy 实现网络访问控制中的功能限制，再在实际使用的集群版本和环境中测试，确认网络策略能按预期允许或阻止流量。

最近更新时间：2026.11.05 20:08:30

这个页面对您有帮助吗？

有用

无用