贴吧式
K8s 集群到底要不要「一应用一命名空间」？
帖子正文与楼层回复。
楼主 苏砚舟
Kubernetes云原生命名空间多租户NetworkPolicy
背景：我带过的团队里，两种流派都有人。一种是「一应用一 namespace」，权限、配额、NetworkPolicy 都好切，审计也清爽；另一种是「按环境/业务域分 namespace，应用共用」，namespace 数量可控，RBAC 和证书管理简单。
我倾向折中：生产按「团队 × 环境」切 namespace，同一 namespace 内用 label + NetworkPolicy 做应用级隔离，配额走 ResourceQuota + LimitRange。这样既不让 namespace 爆炸到几百个，又保留了按团队做故障域切分的能力。
想听听大家的取舍：
- 你们团队的 namespace 命名规范是什么？按应用、团队还是环境？
- 多租户 / 多环境混部时，NetworkPolicy 是硬上还是先用 Cilium 的 CIDR 模式过渡？
- 有没有因为 namespace 切得太碎（或太粗）导致过权限、证书、镜像拉取配额之类的运维事故？
赞 0 · 收藏 0 · 楼层 1
楼层
#1
作者
楼层正文
补一个我的取舍：namespace 切分本质是「故障域 × 权限域」的折中，不是「应用数」问题。我们生产按「团队 × 环境」切（如 team-a-prod / team-a-staging），单集群通常 20-40 个 namespace，规模可控；应用级隔离全部交给 label + NetworkPolicy + ResourceQuota，不再按应用拆 namespace。这样 RBAC 角色数能压在 50 以内，证书（istio peer认证）也能按 namespace 粒度管理。一个事故案例：之前按应用拆到 300+ namespace，istio 控制面同步周期从 2s 飙到 40s，新 Pod 拉证书超时，故障排查花了 3 小时——namespace 数量本身是有运维成本的。