关键是以namespace为单元，配合resourcequota和limitrange实现可验证、可回滚的刚性限额：先隔离（专属命名空间+标签）、再配额（cpu/内存/对象数限制）、后收口（rbac权限管控+监控告警闭环）。
要将一个物理大集群平滑切分为多个逻辑租户，关键不是“一次性全拆”，而是以 Namespace 为单元，配合 ResourceQuota 做可验证、可回滚、有缓冲的刚性限额落地。核心在于：先隔离、再配额、后收口，避免业务中断或权限错配。
按部门/项目创建专属 Namespace 并打标
每个租户（如 finance、ai-platform、marketing）必须拥有独立 Namespace，禁止复用 default 或 kube-system。创建时同步添加语义化标签，便于后续策略批量管理：
- 用命令快速创建并打标：
kubectl create namespace finance && kubectl label namespace finance team=finance env=prod - 所有业务资源 YAML 必须显式声明
metadata.namespace: finance，或操作时统一加-n finance - 系统组件、中间件、共享服务应部署在专用 infra 命名空间，不与业务混用
为每个 Namespace 配置 ResourceQuota 实现总量刚性控制
ResourceQuota 是“不可绕过”的准入检查，一旦超出，Pod 创建直接失败并报 exceeded quota。配置要点如下：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 优先限制
requests.cpu和requests.memory，确保调度器能稳定分配，避免因 limit 过高但 request 不足导致调度失败 - 必须包含对象数量限制，如
pods: "30"、configmaps: "50"、secrets: "40"，防止单一租户耗尽元数据存储 - 示例中设置
requests.cpu: "8"表示该部门所有 Pod 的 CPU 请求总和不能超过 8 核，超限即拒绝新 Pod
搭配 LimitRange 防止单 Pod 吃光配额
仅靠 ResourceQuota 不够——如果一个 Pod 写了 requests.cpu: "8"，它就直接占满整个 finance 配额。LimitRange 可设默认值与上下限：
- 为 finance 设置默认 request/limit：
defaultRequest: {cpu: "500m", memory: "1Gi"}，避免开发漏写 resources 导致调度异常 - 同时设上限：
max: {cpu: "4", memory: "16Gi"}，阻止单个训练任务独占全部额度 - 二者叠加后，既保底线可用，又控风险上限
配套 RBAC + 监控告警完成闭环管控
配额只是防线之一，需结合权限与可观测性才能真正落地：
- 用 RoleBinding 绑定 ServiceAccount，确保 finance 团队只能读写自身 Namespace，无法跨空间 list pods 或 patch secrets
- 通过
kubectl describe quota -n finance或 Prometheus 查询resourcequota_status_hard指标，实时掌握余量 - 对配额使用率 >80% 的 Namespace 自动触发企业微信/钉钉告警，提醒负责人清理闲置资源或申请扩容
