4. 租户命名空间策略:命名空间命名规范、标签体系设计、基于标签的租户归属识别、资源配额管理

在多租户 Kubernetes 集群中,命名空间(Namespace)是租户隔离的第一道物理边界。然而,仅靠命名空间本身无法支撑大规模、动态的租户管理。必须建立一套从命名规范、标签体系到配额管控的完整策略,才能让集群运维人员快速识别租户归属、实施批量策略并防止资源争抢。

4.1 命名空间命名规范

命名空间的名称是租户在集群中的唯一标识符。建议采用三段式或四段式结构,确保名称具备自解释性且便于脚本解析。

层级 字段 示例 说明
1 租户类型 prod / dev / test 环境标识,区分生产与非生产
2 租户短名 fin / ecom / ai 业务线或团队缩写,2~6 字符
3 应用域 api / worker / web 可选字段,用于细分同一租户下的子域
4 序号/区域 001 / cn 可选字段,用于多区域或多副本场景
推荐格式:{env}-{tenant}-{domain}[-{suffix}]
示例:prod-fin-api、dev-ecom-worker、test-ai-cn

4.2 标签体系设计

标签(Label)是 Kubernetes 原生的关联机制。通过统一的标签体系,可以将命名空间、Pod、Service 等资源与租户身份绑定,为后续的网络策略、监控告警、成本分摊提供数据基础。

4.2.1 核心标签定义

标签键 标签值示例 用途
tenant.id fin-001 租户唯一 ID,用于策略匹配
tenant.name financial 租户可读名称,用于 UI 展示
tenant.environment prod 环境隔离,区分生产/预发/测试
tenant.tier gold / silver 服务等级,用于资源配额差异化
app.kubernetes.io/name api-gateway 应用名称,遵循 Kubernetes 推荐标签

4.2.2 标签继承与自动化

建议在集群初始化阶段,通过 Namespace 准入控制器(Admission Webhook) 自动为新建命名空间注入上述标签。例如,当用户创建 prod-fin-api 命名空间时,Webhook 自动添加:

metadata:
  labels:
    tenant.id: "fin-001"
    tenant.name: "financial"
    tenant.environment: "prod"
    tenant.tier: "gold"
最佳实践:将标签注入逻辑封装为 Kyverno 策略 或 OPA/Gatekeeper 约束模板,确保所有命名空间创建时都经过标签校验,避免遗漏。

4.3 基于标签的租户归属识别

有了统一的标签体系,Cilium 网络策略、监控系统、成本分析工具都可以通过标签选择器(Label Selector)快速识别租户归属。下图展示了从命名空间标签到策略匹配的完整链路。

基于标签的租户归属识别流程 命名空间创建请求 准入 Webhook 注入标签 标签校验通过 CiliumNetworkPolicy 标签选择器匹配 策略生效/拒绝 监控/成本标签继承 租户资源聚合查询 租户级告警路由 说明:标签选择器是 Cilium 策略匹配的核心,通过 tenant.id 可精确控制租户间流量

4.4 资源配额管理

资源配额(ResourceQuota)是防止租户资源滥用、保障集群稳定性的关键手段。结合标签体系,可以实现按租户等级差异化分配。

4.4.1 配额模板设计

租户等级 CPU 限制 内存限制 Pod 数量 存储卷数
Gold 32 核 128 Gi 200 50
Silver 16 核 64 Gi 100 30
Bronze 8 核 32 Gi 50 15

4.4.2 自动化配额注入

通过 Kyverno 策略,根据命名空间的 tenant.tier 标签自动创建对应的 ResourceQuota 对象:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: auto-resourcequota
spec:
  rules:
  - name: inject-quota
    match:
      resources:
        kinds:
        - Namespace
    preconditions:
      any:
      - key: "{{ request.object.metadata.labels.\"tenant.tier\" }}"
        operator: Equals
        value: "gold"
    generate:
      kind: ResourceQuota
      name: tenant-quota
      namespace: "{{ request.object.metadata.name }}"
      synchronize: true
      data:
        spec:
          hard:
            limits.cpu: "32"
            limits.memory: "128Gi"
            pods: "200"
            persistentvolumeclaims: "50"
注意:ResourceQuota 仅限制命名空间内的资源总量,无法限制单个 Pod 的资源请求。建议配合 LimitRange 一起使用,为每个 Pod 设置默认资源上下限。

4.5 策略实施检查清单

  • 命名规范:统一使用 {env}-{tenant}-{domain} 格式,禁止随意命名。
  • 标签强制:通过准入控制器确保每个命名空间都包含 tenant.id、tenant.name、tenant.environment 标签。
  • 配额差异化:根据 tenant.tier 标签自动生成不同规格的 ResourceQuota。
  • 策略匹配:Cilium 网络策略使用 tenant.id 标签选择器,避免硬编码命名空间名称。
  • 审计与监控:定期扫描命名空间标签完整性,缺失标签的命名空间应触发告警。
生产建议:将命名空间创建权限收归到 GitOps 流水线或自助服务平台,用户只能通过模板创建命名空间,从源头保证命名规范和标签体系的统一。