2. 多租户基础：租户模型设计、资源隔离策略与元数据管理

在多租户故障域隔离演练中，租户模型是容量预测与水位分析的基石。错误的租户模型会导致资源争抢不可控、监控数据混淆、容量预测偏差。本节从租户模型设计、资源隔离策略、租户标识与元数据管理三个维度展开，为后续的 Grafana 水位预测建立扎实的底层模型。

2.1 租户模型设计

租户模型决定了资源如何被抽象、分配和计量。常见的多租户模型分为三种：

2.2 资源隔离策略（CPU / 内存 / IO）

资源隔离是多租户系统的核心挑战。隔离策略直接影响容量突增时的故障域边界是否被突破。以下按资源维度逐一分析：

2.2.1 CPU 隔离

• CFS 配额（完全公平调度）： 通过 cpu.cfs_quota_us 限制租户 CPU 使用上限，适合软隔离场景。
• CPU Pin（绑核）： 将租户进程绑定到特定物理核心，实现硬隔离，但会降低 CPU 利用率。
• Burstable QoS： 允许租户在空闲时借用其他租户的 CPU 时间，但需设置 cpu.weight 保证公平。

2.2.2 内存隔离

• 硬限制（Hard Limit）： 通过 memory.limit_in_bytes 设置上限，超过即触发 OOM Kill。
• 软限制（Soft Limit）： 通过 memory.soft_limit_in_bytes 设置建议上限，仅在内存压力时生效。
• Swap 控制： 建议关闭租户级 Swap，避免容量突增时内存抖动影响故障域稳定性。

2.2.3 IO 隔离

• Blkio Cgroup： 限制租户对块设备的读写带宽和 IOPS，使用 blkio.throttle.read_bps_device 等参数。
• IOPS 权重： 通过 blkio.weight 在竞争场景下分配 IO 比例，适合共享存储架构。
• 文件系统配额： 针对日志、数据目录设置磁盘空间上限，防止单个租户写满磁盘导致全局故障。

2.3 租户标识与元数据管理

租户标识是 Grafana 水位预测中数据聚合与过滤的核心维度。元数据管理决定了容量预测模型能否准确区分不同租户的行为模式。

2.3.1 租户标识设计原则

• 全局唯一性： 租户 ID 必须在整个集群或组织中唯一，推荐使用 UUID 或 雪花算法 ID。
• 不可变性： 租户 ID 一旦分配，不应变更。变更会导致历史监控数据断裂，影响容量趋势预测。
• 可注入性： 租户 ID 必须能通过环境变量、HTTP Header 或标签注入到应用和基础设施层。

2.3.2 元数据管理模型

2.3.3 元数据注入与采集

在云原生架构中，推荐通过以下方式将租户元数据注入到监控链路：

# Kubernetes Pod 标签示例
metadata:
  labels:
    tenant.id: "tenant-abc-123"
    tenant.tier: "platinum"
    tenant.fault-domain: "az-1"

# Prometheus 指标标签示例（通过 relabel_config）
- source_labels: [__meta_kubernetes_pod_label_tenant_id]
  target_label: tenant_id
- source_labels: [__meta_kubernetes_pod_label_tenant_tier]
  target_label: tenant_tier

2.4 租户模型与容量预测的关联

在故障域隔离演练中，租户模型直接决定了容量预测的输入粒度：

• 独立部署模型： 每个租户对应独立的 Grafana Dashboard，水位预测按实例维度进行，模型简单但运维成本高。
• 共享进程模型： 需要在指标中注入 tenant_id 标签，Grafana 通过 group by 聚合水位，预测模型需考虑租户间资源争抢的噪声。
• 混合模型： 控制面指标（如 API 请求量）按全局预测，数据面指标（如 CPU 使用率）按租户独立预测，两者在 Grafana 中通过 fault_domain 标签关联。