容器集群多租户核心在于隔离清晰、管控有效、核算精准：需结合namespace、rbac、resourcequota、networkpolicy、storageclass等实现资源隔离，并通过prometheus、dcgm、csi指标等穿透式成本核算，隔离与核算必须联动设计。
容器集群做多租户，核心不是“能不能分”，而是“分得清不清、管得住不住、算得准不准”。资源隔离和成本核算是一体两面：隔离不到位，成本就分不公；成本没厘清，隔离就难持续。
资源隔离不能只靠命名空间
Namespace 是起点，不是终点。它提供逻辑边界，但不构成安全或性能边界。
- 权限必须绑定到命名空间：RBAC 规则要限定在 namespace 级别，避免 clusterrole 被误用；ServiceAccount 和 token 不能跨租户复用。
- 资源配额必须硬约束：ResourceQuota 控制总量，LimitRange 控制单 Pod 上限，两者缺一不可。比如限制 tenant-a 最多用 8 核 CPU、16Gi 内存，且每个 Pod 最多申请 2 核 4Gi——否则一个 Pod 就可能吃光 quota。
- 网络和存储也要隔离：NetworkPolicy 按 label 限制 pod 间通信；StorageClass 需为租户专属（如 tenant-a-fast-ssd），配合 PVC 的 storageClassName 和 namespace 绑定，防止共享底层卷。
真正的隔离强度取决于底层机制
不同场景需要不同层级的隔离能力，选错方案容易“省小钱、赔大钱”。
- 轻量级业务（内部工具、测试环境）：Namespace + ResourceQuota + NetworkPolicy 即可，运维成本低，适合快速交付。
- 中等敏感度业务（SaaS 应用、部门级平台）：建议引入 vCluster 或 Karmada 类虚拟集群，每个租户拥有独立的 kube-apiserver 实例，故障和配置变更互不影响。
- 高合规要求业务（金融、医疗）：物理集群隔离仍是底线选择。哪怕用 IaC 自动化部署，也要接受运维人力翻倍的现实——某银行在 PCI-DSS 合规审计后，将 12 个关键租户全部迁入独占集群，故障平均恢复时间从 17 分钟降至 2.3 分钟。
成本核算必须穿透到底层资源
只按 Pod 数量或 Namespace 计费，等于没算。真实成本来自 CPU 时间、内存驻留、GPU 显存占用、IOPS、网络出向流量等维度。
- CPU 和内存：用 Prometheus 抓取 container_cpu_usage_seconds_total 和 container_memory_working_set_bytes，按租户 label 聚合，结合实际使用率而非 request/limit 值计费。
- GPU 资源：NVIDIA DCGM 指标（如 dcgm_gpu_utilization、dcgm_fb_used）配合 MIG 实例 ID，可精确到毫秒级显存与算力消耗，避免整卡分配导致的成本虚高。
- 存储与网络：CSI 插件需支持用量上报（如 csi-hostpath-driver 的 metrics 端点）；云厂商 SLB/ALB 日志可解析出 per-tenant 出向带宽，再乘以对应单价。
隔离与核算要联动设计
孤立做隔离或孤立做核算，都会失效。比如：
- 没打租户 label 的 Pod，监控数据就无法归属，成本自然算不准；
- 没启用 CGroup v2 的节点，CPU throttling 数据缺失，会导致“低负载但响应慢”的账算不明白；
- 没在 admission webhook 中校验 storageClassName 是否合规，租户就可能偷偷挂载共享 NFS，既破坏隔离，又让存储成本分摊失真。
