3. 多租户概念与模型：租户隔离模型、身份标识与资源配额
在多租户 Istio 网格中，租户 是一个逻辑隔离单元，代表一组具有独立权限、资源配额和网络策略的用户或服务集合。本章节将深入剖析 Istio 多租户的核心模型，包括三种隔离粒度、租户身份标识机制以及资源配额管理策略。
3.1 租户隔离模型：命名空间 / 集群 / 网格
Istio 支持三种层次的租户隔离模型，每种模型在隔离性、管理复杂度和资源利用率上各有取舍。下表对比了三种模型的核心差异：
| 隔离模型 | 隔离粒度 | 网络策略范围 | 控制面共享 | 典型场景 |
|---|---|---|---|---|
| 命名空间级 | Kubernetes Namespace | Namespace 内 | 共享 Istiod | 开发/测试环境，轻量租户 |
| 集群级 | Kubernetes Cluster | 集群内 | 独立 Istiod | 生产环境，强隔离需求 |
| 网格级 | Istio Mesh | 跨集群 | 独立控制面 | 多集群联邦，全球部署 |
最佳实践： 在签名链路性能调优场景中，推荐使用 命名空间级 隔离作为默认模型，配合细粒度的 AuthorizationPolicy 实现租户间安全隔离，同时保持控制面共享带来的低延迟优势。
下图展示了三种隔离模型的架构对比：
3.2 租户身份标识
租户身份标识是多租户隔离的基础。Istio 通过以下机制实现租户身份的绑定与传递：
- Kubernetes Namespace 标签： 为每个租户的 Namespace 打上
tenant: <tenant-id>标签，作为最基础的标识。 - ServiceAccount 绑定： 每个租户下的服务使用独立的 ServiceAccount，Istio 通过 SPIFFE 标准将 ServiceAccount 映射为身份证书。
- 自定义请求头： 在入口网关处注入
X-Tenant-ID请求头，用于在网格内传递租户上下文。 - JWT 声明： 在 JWT 令牌中嵌入
tenant声明，实现端到端的身份验证。
身份标识配置示例： 以下 YAML 展示了如何为租户 A 的 Namespace 打标签并绑定 ServiceAccount。
apiVersion: v1
kind: Namespace
metadata:
name: tenant-a
labels:
tenant: "tenant-a"
istio-injection: enabled
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: sa-tenant-a
namespace: tenant-a
---
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: strict-mtls
namespace: tenant-a
spec:
mtls:
mode: STRICT
selector:
matchLabels:
tenant: "tenant-a"3.3 租户资源配额
资源配额确保单个租户不会过度占用网格资源，影响其他租户的服务质量。在多租户签名链路中，需要重点管理以下配额：
| 资源类型 | 配额维度 | 影响范围 | 推荐配置策略 |
|---|---|---|---|
| Envoy 代理内存 | Pod 级别 | 签名延迟 | 限制 256Mi - 512Mi |
| Envoy 代理 CPU | Pod 级别 | 签名吞吐量 | 限制 500m - 1000m |
| Istiod 连接数 | Namespace 级别 | 控制面稳定性 | 每租户最大 1000 连接 |
| 配置更新频率 | Namespace 级别 | XDS 推送延迟 | 每秒最多 10 次更新 |
| 服务条目数 | Namespace 级别 | 网格规模 | 每租户最多 500 个 ServiceEntry |
下图展示了租户资源配额管理的流程：
性能调优警告： 在签名链路中，Envoy 代理的内存配额不足会导致频繁的 TLS 握手重试，增加签名延迟。建议为每个租户的 Envoy 代理预留至少 256Mi 内存，并监控实际使用量动态调整。
3.4 隔离模型选择决策树
在实际项目中，选择哪种隔离模型取决于以下因素：
- 安全等级要求： 金融、医疗等强合规场景优先选择集群级或网格级隔离。
- 运维成本： 命名空间级隔离运维成本最低，适合快速迭代。
- 性能敏感度： 签名链路对延迟敏感，共享控制面可减少 XDS 推送延迟。
- 资源利用率： 命名空间级隔离资源利用率最高，网格级最低。
下表总结了不同场景下的推荐隔离模型：
| 场景 | 推荐模型 | 理由 |
|---|---|---|
| 开发/测试环境 | 命名空间级 | 快速部署，低成本 |
| 生产环境（单集群） | 命名空间级 + 严格 mTLS | 平衡隔离与性能 |
| 生产环境（多集群） | 集群级 | 物理隔离，故障域独立 |
| 全球多区域部署 | 网格级 | 跨集群服务发现与流量管理 |
关键结论： 多租户隔离模型的选择直接影响签名链路的性能与安全。命名空间级隔离配合细粒度的 AuthorizationPolicy 和 ResourceQuota，是大多数场景下的最优解。集群级和网格级隔离适用于对安全合规有更高要求的场景，但需要接受更高的资源开销和管理复杂度。