K8s 上「平台团队 vs 业务团队」的边界到底画在哪？命名空间、准入、网络策略谁说了算

背景

我在一家中型公司带云原生平台组，集群规模从 30 节点长到 120 节点，业务方从 2 个团队长到 11 个。集群本身没出过大故障，但人和边界的问题越滚越大，最近三个月集中爆了三类矛盾，我越想越觉得这是个没有标准答案、但每个 K8s 团队都绕不开的题：

1. 命名空间归属：一开始按团队切 ns，后来出现"一个团队 3 个 ns、跨 ns 互相调用、Secret 到处拷"的乱象。有人主张按环境切（dev/staging/prod 各一个 ns，全公司共用），有人主张按团队切、环境用 label 区分，还有人主张「ns 无意义，一切靠 RBAC + NetworkPolicy」。
2. 准入控制归属：OPA/Kyverno 策略谁写？安全团队的"镜像必须来自内网仓库""禁止 privileged"是硬策略，但业务方经常拿"我们有个特殊场景"来破例。破例走 PR 审批还是走白名单配置？白名单清单半年从 5 条涨到 40 条的时候，策略等于不存在了。
3. 网络策略归属：默认全通 vs 默认拒绝。默认拒绝是"正确"的方向，但落地成本是业务方要自己画依赖图——他们画不出来，最后变成平台组替业务画，平台组就成了瓶颈单点。

我目前的倾向（欢迎打脸）

• ns 按团队切，环境用集群切（或至少用 ns 前缀强约束）。混合切法（按环境切 ns）在 RBAC 和网络策略上都会变复杂：同一个 ns 里混着 dev 和 prod 的 Pod，默认拒绝策略一开，dev 调 prod 的链路全断，排障成本极高。
• 硬策略平台管，软策略业务管，破例必须走代码（GitOps PR + 双人 review），不走配置白名单。白名单是腐烂最快的地方，PR 至少有审计轨迹。
• 默认拒绝分两步走：先只开"入方向"拒绝（ns 之间），出方向放行 3 个月，等依赖图稳定了再收紧。一步到位的默认拒绝，我见过两次把业务方的合法依赖（比如 metrics 采集、日志 agent）一起断了。

想听大家

1. 你们公司/团队 ns 的切法是什么？是按团队、按环境、还是按"业务域"？踩过什么坑？
2. 准入策略的"破例"机制你们怎么设计的？有没有见过白名单腐烂到策略形同虚设的情况？
3. NetworkPolicy 默认拒绝在你们这里落地了吗？如果没落地，卡在哪一步——是依赖图画不出来、是工具不好用、还是纯粹没人推？
4. 更根本的问题：平台组到底该做到哪一层？ 是"给集群 + 基础策略"就收手，还是要"管到每个业务的发布流程"？这两者的组织成本差一个数量级，你们是怎么说服（或没说服）管理层的？

不追求标准答案，就想把各家真实的做法和翻车点摊开看看。