2. 多租户基础概念：租户定义、租户隔离模型与资源配额设计

在多租户故障域隔离演练中，清晰定义“租户”是后续所有策略与指标采集的起点。租户不仅是逻辑上的用户分组，更是资源边界、故障边界与安全边界的统一抽象。本节从租户定义出发，逐步展开隔离模型、配额机制与命名空间设计，为后续 OPA 策略注入提供基础语义。

2.1 租户定义：从业务实体到资源边界

在云原生环境中，租户（Tenant）是一个拥有独立资源视图、独立访问控制、独立故障域的逻辑实体。租户可以对应一个组织、一个部门、一个项目组，甚至一个微服务。租户的核心属性包括：

• 身份标识：全局唯一的租户 ID（如 tenant-001），用于资源标签与审计。
• 资源配额：CPU、内存、存储、网络带宽等上限。
• 策略域：OPA 策略作用范围，如允许的镜像仓库、网络策略、Pod 安全标准。
• 故障域：租户内故障不应扩散到其他租户，如节点亲和性、Pod 反亲和、AZ 分布。

2.2 租户隔离模型：SaaS vs PaaS

隔离模型决定了租户之间共享基础设施的程度，直接影响故障域半径和 OPA 策略复杂度。下表对比了两种主流模型：

在故障域隔离演练中，SaaS 模型更考验 OPA 策略的精细度与告警分层能力，因为一个节点故障可能波及多个租户，需要快速定位“哪个租户的哪些工作负载”受到影响。

2.3 租户资源配额与命名空间设计

命名空间（Namespace）是 Kubernetes 中实现租户隔离的基本单元。合理的命名空间设计需要同时满足资源配额、策略绑定与故障域隔离三个目标。

2.3.1 命名空间命名规范

建议采用分层命名，便于 OPA 策略通过正则匹配：

# 格式：<tenant-id>-<environment>-<workload-type>
tenant-001-prod-frontend
tenant-001-prod-backend
tenant-001-staging-frontend
tenant-002-prod-database

2.3.2 资源配额模板

每个租户的命名空间应绑定 ResourceQuota 与 LimitRange，防止单个租户资源滥用导致其他租户故障。以下是一个典型配额配置：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: tenant-001-prod-frontend
spec:
  hard:
    requests.cpu: "8"
    requests.memory: "16Gi"
    limits.cpu: "16"
    limits.memory: "32Gi"
    persistentvolumeclaims: "5"
    pods: "50"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: tenant-limits
  namespace: tenant-001-prod-frontend
spec:
  limits:
  - max:
      cpu: "2"
      memory: "4Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
    default:
      cpu: "500m"
      memory: "1Gi"
    defaultRequest:
      cpu: "200m"
      memory: "512Mi"
    type: Container

2.3.3 故障域隔离设计

在命名空间层面，通过 Pod 反亲和与拓扑分布约束实现故障域隔离：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-frontend
  namespace: tenant-001-prod-frontend
spec:
  replicas: 3
  template:
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - frontend
            topologyKey: "kubernetes.io/hostname"
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "topology.kubernetes.io/zone"
        whenUnsatisfiable: DoNotSchedule

2.4 租户隔离模型与命名空间关系图

下图展示了 SaaS 模型下租户、命名空间、资源配额与故障域之间的逻辑关系：

2.5 租户资源配额与 OPA 策略联动

OPA 策略在资源配额管理中扮演“准入控制器”角色，确保每个命名空间在创建时即绑定合规的配额配置。以下是一个 OPA 策略片段，强制要求命名空间必须包含 ResourceQuota：

package kubernetes.admission

# 拒绝没有 ResourceQuota 的命名空间
deny[msg] {
  input.request.kind.kind == "Namespace"
  input.request.operation == "CREATE"
  not has_resource_quota(input.request.object.metadata.name)
  msg := sprintf("命名空间 %v 必须绑定 ResourceQuota，请先创建配额对象", [input.request.object.metadata.name])
}

has_resource_quota(ns_name) {
  quota := data.resource_quotas[_]
  quota.metadata.namespace == ns_name
}

2.6 租户隔离模型对比总结