2、多租户基础：租户隔离模型（SaaS vs PaaS）、命名空间隔离策略、资源配额管理

2.1 租户隔离模型：SaaS 与 PaaS 的核心差异

在云原生架构中，多租户（Multi-Tenancy）是指单个软件实例或平台实例为多个独立用户群体（租户）提供服务的能力。租户隔离模型的选择直接决定了 Istio 控制面与数据面的配置策略。根据服务交付模式，主要分为 SaaS（Software as a Service） 和 PaaS（Platform as a Service） 两种隔离模型。

2.2 命名空间隔离策略

Kubernetes 命名空间（Namespace）是 Istio 多租户隔离的基本单元。通过合理的命名空间设计，结合 Istio 的 Sidecar、AuthorizationPolicy 和 PeerAuthentication 资源，可以实现不同粒度的租户隔离。

2.2.1 命名空间设计模式

• 按租户划分： 每个租户独占一个命名空间，命名空间名称包含租户标识（如 tenant-a-prod）。
• 按环境划分： 同一租户下按环境拆分命名空间（如 tenant-a-dev、tenant-a-staging）。
• 按功能划分： 在 PaaS 模型中，按业务功能或团队划分命名空间（如 data-platform、ml-training）。

2.2.2 隔离策略配置清单

2.2.3 命名空间隔离策略示例

# 禁止命名空间 tenant-b 访问 tenant-a 的服务
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-tenant-b
  namespace: tenant-a
spec:
  action: DENY
  rules:
  - from:
    - source:
        namespaces: ["tenant-b"]
    to:
    - operation:
        methods: ["*"]

# 限制 tenant-a 命名空间内的 Sidecar 只能发现本命名空间的服务
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: restrict-sidecar
  namespace: tenant-a
spec:
  egress:
  - hosts:
    - "tenant-a/*"

2.3 资源配额管理

资源配额管理确保每个租户不会过度消耗集群资源，影响其他租户的稳定性。在 Istio 多租户环境中，资源配额分为两个层面：Kubernetes 原生资源配额 和 Istio 代理资源配额。

2.3.1 Kubernetes 资源配额（ResourceQuota）

通过 ResourceQuota 对象限制每个命名空间的 CPU、内存、Pod 数量等资源上限。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a-quota
  namespace: tenant-a
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    pods: "50"
    services: "20"

2.3.2 Istio 代理资源配额

Sidecar 代理（Envoy）本身也会消耗资源。需要为每个租户的 Sidecar 设置合理的资源请求和限制，避免代理成为性能瓶颈。

2.3.3 全局配额与租户配额联动

在大型集群中，建议使用 LimitRange 设置命名空间级别的默认资源约束，再结合 ResourceQuota 做总量控制。Istio 的 MeshConfig 中可以配置全局的 Sidecar 默认资源，但每个租户可以通过 PodAnnotation 覆盖。

# 在 MeshConfig 中设置全局 Sidecar 默认资源
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: "true"
      concurrency: 2
      # 全局 Sidecar 资源默认值
      proxyResources:
        requests:
          cpu: 100m
          memory: 128Mi
        limits:
          cpu: 500m
          memory: 512Mi

2.4 隔离模型选择决策树

在实际项目中，选择 SaaS 还是 PaaS 隔离模型，需要根据业务需求、安全合规和运维成本综合判断。以下决策树可以帮助快速定位：

1. 是否需要数据层完全隔离？ 是 → SaaS 模型；否 → 进入下一步。
2. 租户之间是否允许共享服务？ 是 → PaaS 模型；否 → SaaS 模型。
3. 是否有合规审计要求（如金融、医疗）？ 是 → SaaS 模型 + 独立命名空间 + 独立 Istio 控制面。
4. 运维团队规模是否有限？ 是 → PaaS 模型 + 共享控制面 + 自动化策略注入。