NetworkPolicy 落地需统一建模、分层校验与持续验证：通过 CRD 扩展语义、GitOps 管控策略注入；实施静态、动态、运行时三阶校验；适配多集群与混合环境；构建可观测闭环。
容器编排环境中的网络策略（NetworkPolicy）要真正落地生效，关键不在写几条规则，而在于统一建模、分层校验和持续验证。Kubernetes 原生 NetworkPolicy 本身是命名空间粒度的声明式资源，但跨集群、多租户、混合工作负载（如带 hostNetwork 的 Pod 或外部接入服务）下，策略容易出现语义冲突、范围遗漏或执行失效——这些恰恰是标准化实施中最常被忽略的环节。
策略定义阶段：用 CRD 扩展语义，避免纯 YAML 拼凑
Kubernetes 原生 NetworkPolicy 不支持标签选择器跨命名空间精确匹配、不支持 FQDN 级别出口控制、也不支持按服务账户或运行时行为（如是否启用 SELinux）做策略判定。直接堆砌大量基础 NetworkPolicy 往往导致策略碎片化、难以复用。
- 引入社区成熟 CRD（如 Cilium 的 ClusterwideNetworkPolicy 或 Calico 的 GlobalNetworkSet），将“允许数据库访问”这类业务意图抽象为可复用的策略模板
- 所有策略必须通过 GitOps 流水线注入，禁止 kubectl apply -f 手动部署；YAML 中禁止硬编码 IP、端口或命名空间名，全部替换为 Helm value 或 Kustomize patch 变量
- 每个策略需附带注解：policy.kubernetes.io/owner（团队标识）、policy.kubernetes.io/scope（dev/staging/prod）、policy.kubernetes.io/impact（low/medium/high）
一致性检查：三阶校验机制不可跳过
单靠 kubectl get networkpolicy 查看列表毫无意义。真正的一致性体现在策略与实际流量路径、Pod 网络身份、CNI 插件能力三者对齐。
- 静态校验：用 Kyverno 或 Gatekeeper 检查策略是否满足组织基线（例如：默认拒绝未显式放行的 ingress/egress；所有 prod 命名空间必须有至少一条 egress 策略）
- 动态校验：在 CI 阶段启动轻量级测试集群（如 kind + Cilium），运行 netassert 脚本，验证策略生效前后 Pod 间连通性变化是否符合预期
- 运行时校验：通过 CNI 提供的指标（如 Cilium 的 cilium_network_policy_enforcement_status）或 eBPF trace 工具（如 Tetragon）确认策略是否真实拦截/放行对应连接
跨集群与混合环境适配要点
当集群接入 Service Mesh（如 Istio）或存在裸金属节点、Windows 节点、边缘 IoT 工作负载时，原生 NetworkPolicy 会失效或行为不一致。
- Istio Sidecar 注入后，L7 流量由 Envoy 控制，NetworkPolicy 仅管控 L3/L4 层；此时需明确策略边界——NetworkPolicy 管南北向基础隔离，Sidecar 策略管东西向应用级访问
- hostNetwork: true 的 Pod 绕过 CNI 网络栈，NetworkPolicy 对其完全无效；必须通过节点级防火墙（如 nftables 规则）或主机安全策略补位
- 多集群场景下，避免依赖 Kubernetes 内置的 NetworkPolicy 同步机制（它不跨集群）；改用联邦式策略控制器（如 Istio Multi-Primary 或 KubeFed 的策略扩展）集中下发
可观测性闭环：让策略“看得见、可追溯、能归因”
策略上线后若无日志与追踪，等于没有策略。尤其当某次发布后出现服务不可达，必须快速区分是策略误拦、DNS 解析失败，还是上游服务宕机。
- 开启 CNI 的 policy audit 日志（如 Cilium 的 --enable-policy-audit-mode），将被拒绝连接记录到 Loki 或 ES，字段至少含 source_pod, destination_service, rule_name, timestamp
- 在 Prometheus 中建立告警规则：当某策略连续 5 分钟无匹配事件（cilium_network_policy_matched_total 为 0），提示该策略可能已失效或范围过窄
- 将策略变更与 Argo CD commit hash、Git tag 关联，在 Grafana 中点击任一异常连接，可下钻查看当时生效的策略版本及 diff
