3. 环境规划与资源隔离：基于 Kubernetes Namespace 的物理隔离 vs 基于 Label 的逻辑隔离，资源配额（ResourceQuota）配置

在多租户可观测性平台中，环境规划与资源隔离是保障数据安全、性能稳定与成本分摊的基石。Kubernetes 提供了两种核心隔离模式：基于 Namespace 的物理隔离与基于 Label 的逻辑隔离。前者通过独立的 API 对象与网络策略实现强边界，后者通过标签选择器实现灵活的软隔离。本章将深入对比两种模式的适用场景，并详细讲解 ResourceQuota 的配置策略。

3.1 隔离模式对比：物理隔离 vs 逻辑隔离

在可观测性场景中，隔离不仅涉及计算资源，还涉及数据存储、API 访问权限与监控指标的可视范围。下表从多个维度对比两种隔离模式：

3.2 基于 Namespace 的物理隔离架构

物理隔离通过独立的 Namespace 为每个租户创建完整的 Kubernetes 资源边界。每个 Namespace 拥有独立的 ConfigMap、Secret、ServiceAccount 以及可观测性组件实例。下图展示了典型的多租户物理隔离架构：

3.3 基于 Label 的逻辑隔离架构

逻辑隔离通过 Kubernetes Label 和 Selector 实现租户资源的软划分。所有租户共享同一套可观测性基础设施，通过标签进行数据路由与权限控制。这种模式特别适合内部团队或开发测试环境。

3.4 ResourceQuota 配置实践

ResourceQuota 是 Kubernetes 原生资源隔离机制，用于限制 Namespace 级别的资源消耗。在可观测性场景中，需要为每个租户的 Namespace 配置合理的配额，防止单个租户的监控数据采集或查询行为影响整个集群。

3.4.1 核心 ResourceQuota 配置示例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: observability-quota
  namespace: tenant-a
spec:
  hard:
    # 计算资源
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    # 存储资源
    requests.storage: "100Gi"
    persistentvolumeclaims: "5"
    # 核心对象数量
    pods: "20"
    services: "10"
    configmaps: "15"
    secrets: "15"
    # 可观测性专用
    count/prometheuses.monitoring.coreos.com: "2"
    count/alertmanagers.monitoring.coreos.com: "1"
    count/grafanainstances.grafana.integreatly.org: "1"

3.4.2 参数调优建议

3.4.3 配额监控与告警

ResourceQuota 本身不会触发告警，需要结合 Prometheus 和 kube-state-metrics 来监控配额使用率。以下是一个典型的告警规则：

groups:
  - name: resourcequota-alerts
    rules:
      - alert: ResourceQuotaNearLimit
        expr: |
          kube_resourcequota{type="hard", resource="requests.cpu"}
          - kube_resourcequota{type="used", resource="requests.cpu"}
          < 0.5
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Namespace {{ $labels.namespace }} CPU 配额即将耗尽"
          description: "剩余 CPU 配额不足 0.5 核，当前使用率 {{ $value | humanizePercentage }}"

3.5 隔离模式选择决策树

在实际项目中，选择哪种隔离模式取决于多个因素。以下决策树可以帮助你快速判断：

1. 是否有合规/审计要求？ → 是 → 选择 Namespace 物理隔离
2. 租户数量是否超过 20 个？ → 是 → 优先考虑 Label 逻辑隔离（降低运维成本）
3. 是否需要跨租户数据聚合？ → 是 → 选择 Label 逻辑隔离（共享 Thanos/Thanos Query）
4. 租户间是否有严格的网络隔离需求？ → 是 → 选择 Namespace 物理隔离 + NetworkPolicy
5. 预算是否有限？ → 是 → 选择 Label 逻辑隔离（节省资源开销）