3. 多租户模型：租户隔离策略、命名空间隔离与资源配额管理

在多集群签名链路中，多租户模型是保障安全性与公平性的基石。每个租户（Tenant）对应一个独立的业务单元或组织，其签名请求、密钥材料、调用频率和故障域必须严格隔离。本章围绕三种核心隔离机制展开：租户隔离策略定义逻辑边界，命名空间隔离实现资源分组，资源配额管理确保服务质量。

3.1 租户隔离策略

租户隔离策略决定了签名链路中“谁可以访问什么”。在基于多集群的架构中，隔离策略通常分为三个层次：

3.2 命名空间隔离设计

命名空间（Namespace）是 Kubernetes 中实现多租户隔离的基本单元。在签名链路中，每个租户拥有独立的命名空间，包含签名服务、密钥存储、审计日志和配置映射。命名空间隔离的核心要素包括：

• 网络隔离：通过 NetworkPolicy 限制跨命名空间的 Pod 通信，仅允许签名网关所在命名空间与租户命名空间建立连接。
• 权限隔离：使用 RBAC（Role-Based Access Control）为每个租户绑定独立的 ServiceAccount，禁止跨命名空间的 Secret 读取。
• 密钥隔离：签名私钥存储在租户命名空间的 Secret 或外部 KMS 中，通过命名空间标签实现密钥策略绑定。
• 日志隔离：审计日志按命名空间分流，每个租户只能查询本命名空间的签名记录。

3.3 资源配额管理

资源配额（ResourceQuota）防止单个租户的签名请求耗尽集群资源，导致其他租户签名超时或失败。在多集群签名链路中，资源配额管理需要覆盖以下维度：

3.4 配额管理实现示例

以下是一个典型的命名空间资源配额 YAML 配置，适用于签名链路中的生产租户：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: sign-tenant-quota
  namespace: sign-tenant-a-prod
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    persistentvolumeclaims: "5"
    pods: "50"
    secrets: "100"
    configmaps: "50"
    count/signatures.tenant.example.com: "1000"  # 自定义签名请求配额
---
apiVersion: v1
kind: LimitRange
metadata:
  name: sign-tenant-limits
  namespace: sign-tenant-a-prod
spec:
  limits:
  - max:
      cpu: "2"
      memory: "4Gi"
    min:
      cpu: "0.5"
      memory: "512Mi"
    default:
      cpu: "1"
      memory: "2Gi"
    defaultRequest:
      cpu: "0.5"
      memory: "1Gi"
    type: Container

3.5 多集群场景下的配额同步

当签名链路跨多个 Kubernetes 集群时，资源配额管理面临新的挑战：

• 配额一致性：同一租户在不同集群的配额配置应保持一致，避免因集群间配额差异导致签名路由倾斜。
• 全局限流：租户的签名请求可能被路由到多个集群，需要全局 QPS 限流，而非仅依赖单集群配额。
• 故障转移：当主集群资源耗尽时，签名请求应自动转移到备用集群，备用集群需预留足够的配额缓冲。

3.6 隔离策略的故障恢复影响

良好的租户隔离策略直接影响故障恢复的效率和范围：