K8s 默认拒绝 NetworkPolicy 灰度上线：白名单顺序怎么排、怎么避免切断隐藏东西向流量？

【背景】 我负责一个 32 节点（16C64G，Kubernetes 1.28.4，Cilium 1.14，containerd 1.7）的生产集群，约 40 个 Service、8 个命名空间，混合部署（Java/Go/Node.js）。当前没有任何 NetworkPolicy，东西向流量默认全通。安全基线要求"90 天内落地 default-deny + 白名单"，我主导实施。

【现象 / 卡点】

1. 隐藏调用：很多服务不走 Service 发现，直接拿 Pod IP 互调（早期用 fabric8 k8s client 时养成的习惯），还有 sidecar、批处理 Job、CronJob 之间的调用——这些调用在 Service 层面完全不可见，default-deny 一上就断；
2. 流量基线噪声大：用 Cilium Hubble 抓了 72 小时 flow log，去重后仍有 200 万+ 条，其中 kubelet 健康探测、Prometheus 抓取、kube-dns 解析占了 60% 以上，有效业务流量淹没其中；
3. Cilium 没有 NetworkPolicy 的 log-only 模式（不像 Istio 可以 logOnly），cilium monitor 输出量大且不适合做生产审计，我没法先"观察再拒绝"；
4. 静默降级风险：部分服务对下游调用失败时走 fallback（feature flag 关闭、缓存兜底），不会 500，断流后没人报警，可能"安静地坏一周"；
5. 灰度粒度：按命名空间灰度？按服务灰度？先上叶子节点还是先上最隔离的 namespace？没有现成 SOP。

【已尝试的排查与结果】

• 用 hubble observe + 脚本过滤（排除 kube-system、排除 10250/10255 端口、排除 DNS 53），噪声降到约 30 万条，但仍难以人工逐条确认；
• 试了 cilium-cli policy verify，它只验证策略语法和一致性，不验证"实际流量是否被覆盖"；
• 搜了 Cilium 官方文档和 K8s 社区最佳实践，有 default-deny 的 YAML 模板，但没有灰度上线顺序和静默失败检测的工程方案；
• 试了在一个最隔离的 namespace（batch-jobs，3 个 CronJob）先上 default-deny，结果 CronJob 内部互相调用（A 调 B 的 Pod IP）直接断了，回滚花了 20 分钟——说明"先上最隔离的"这个直觉并不完全可靠。

【期望得到的答案形态】 希望有实际落地过 default-deny 的同学给出可复现的工程方案：

1. 灰度顺序：namespace / service 的优先级排序原则（为什么这么排），每个灰度阶段的观察窗口建议（几天？看什么指标？）；
2. 流量基线自动化：从 Hubble flow log 自动生成 NetworkPolicy 的脚本思路（过滤规则、去重逻辑、Pod IP → Service 的映射处理）；
3. NetworkPolicy YAML 模板：default-deny-all + allow-dns + allow-metrics-scrape + allow-specific-service，带注释；
4. 静默失败检测：上线后如何验证"有没有服务实际断了但没人报警"（比如对比流量基线、监控 fallback 指标、canary 探测）；
5. 回滚 SOP：单 namespace 快速禁用 default-deny 的操作步骤，以及"白名单遗漏"的应急放行通道设计。

我这边可以贴出当前 Hubble 过滤脚本和 batch-jobs namespace 的 NetworkPolicy 草稿，方便大家给具体改法。谢谢！