3. 租户隔离模型设计：基于命名空间的租户隔离、基于标签的租户路由、多租户数据面隔离策略

在 API 弃用场景的蓝绿部署中，租户隔离是保障升级安全与故障隔离的核心前提。本章聚焦三种互补的隔离模型：命名空间级隔离提供物理/逻辑边界，标签路由实现细粒度流量调度，数据面隔离确保存储与网络互不干扰。三者组合形成“边界 + 路由 + 数据”的立体隔离架构。

3.1 基于命名空间的租户隔离

Kubernetes 命名空间（Namespace）是租户隔离的第一道防线。每个租户拥有独立的命名空间，资源配额、网络策略、RBAC 权限均以命名空间为粒度生效。

3.2 基于标签的租户路由

命名空间提供静态边界，而标签（Label）与选择器（Selector）实现动态路由。在 API 弃用场景中，通过为每个租户的 Pod 打上 tenant-id 和 api-version 标签，Ingress/Service Mesh 可根据请求中的租户标识将流量精确导向目标版本。

# 租户 Pod 标签示例
apiVersion: v1
kind: Pod
metadata:
  name: api-v2-pod-tenant-001
  namespace: acmecorp-prod-green
  labels:
    tenant-id: "tenant-001"
    api-version: "v2"
    app: "customer-api"
spec:
  containers:
  - name: api
    image: registry.example.com/customer-api:v2.0.0
    ports:
    - containerPort: 8080

路由规则示例（基于 Istio VirtualService）：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: customer-api-routing
  namespace: acmecorp-prod
spec:
  hosts:
  - api.acmecorp.com
  http:
  - match:
    - headers:
        x-tenant-id:
          exact: "tenant-001"
    route:
    - destination:
        host: customer-api-v2
        port:
          number: 8080
      weight: 100
  - route:
    - destination:
        host: customer-api-v1
        port:
          number: 8080
      weight: 100

3.3 多租户数据面隔离策略

数据面隔离涵盖存储、网络、配置三个层面。在 API 弃用蓝绿部署中，新旧两版 API 可能访问不同的数据库 schema 或缓存实例，必须确保租户数据不交叉污染。

3.3.1 存储隔离

• Schema 版本隔离：旧版 API 使用 v1_ 前缀表，新版使用 v2_ 前缀表，通过数据库迁移工具逐步同步。
• 连接池隔离：每个租户独立配置数据库连接池最大连接数，防止某租户的蓝绿升级耗尽连接。
• 缓存隔离：Redis 使用 {tenant}:{version}: 键前缀，或为每个租户分配独立 Redis DB 编号。

3.3.2 网络隔离

• Service 隔离：每个租户的旧版/新版 API 分别创建独立的 Kubernetes Service，名称包含 -v1 和 -v2 后缀。
• mTLS 隔离：启用 Istio 双向 TLS，仅允许同一租户命名空间内的服务互相调用。
• 出口流量隔离：通过 Egress Gateway 控制租户对外部 API 的访问，避免弃用期间误调用已下线的外部依赖。

3.3.3 配置隔离

• 使用 ConfigMap 和 Secret 按命名空间隔离，每个租户的 API 版本拥有独立的配置副本。
• 配置变更通过 GitOps 流程审批，避免某租户误修改全局配置影响其他租户。

3.4 隔离模型架构总览

下图展示三种隔离模型在蓝绿部署中的协同关系：命名空间提供租户边界，标签路由实现流量调度，数据面隔离保障存储与网络互不干扰。

3.5 隔离策略选择矩阵

根据租户规模和 API 弃用阶段，推荐以下组合策略：