1. 多租户概念与挑战
1.1 什么是多租户
多租户（Multi-Tenancy）是一种软件架构模式，指单个软件实例能够同时为多个独立的“租户”（Tenant）提供服务。每个租户在逻辑上相互隔离，彼此无法感知对方的存在，但共享同一套基础设施、平台或应用实例。
在云原生环境中，租户可以是一个部门、一个项目组、一个外部客户，甚至是一个微服务。多租户的核心目标是资源复用最大化与运营成本最小化，同时保证每个租户的独立性与安全性。
关键特征：
- 共享性：多个租户共用同一套计算、存储、网络资源池。
- 隔离性：租户之间的数据、流量、配置互不干扰。
- 可扩展性：新增租户无需重新部署整套系统。
- 可计量性：每个租户的资源消耗可被精确追踪与计费。
1.2 多租户在云原生中的核心挑战
云原生架构（Kubernetes、Service Mesh、CNI 插件等）天然支持多租户，但实际落地时面临三大核心挑战：隔离性、安全性、性能争抢。这三者相互关联，任何一项出现短板都会导致整体多租户方案失效。
| 挑战维度 | 核心问题 | 典型风险 | 云原生影响范围 |
|---|---|---|---|
| 隔离性 | 租户间网络、存储、命名空间是否完全隔离 | 租户 A 误操作导致租户 B 服务中断 | K8s Namespace、NetworkPolicy、CNI 插件 |
| 安全性 | 租户间数据泄露、权限越界、流量嗅探 | 恶意租户通过旁路攻击窃取其他租户数据 | RBAC、mTLS、加密隧道、Pod 安全策略 |
| 性能争抢 | 共享资源（带宽、CPU、内存）的公平分配 | “吵闹邻居”租户耗尽集群带宽，导致其他租户延迟飙升 | CNI 带宽管理、QoS、资源配额（ResourceQuota） |
常见误区：很多团队认为只要创建不同的 Kubernetes Namespace 就实现了多租户隔离。实际上，Namespace 仅提供逻辑分组，不提供网络隔离。默认情况下，不同 Namespace 的 Pod 可以互相通信，必须配合 NetworkPolicy 或 CNI 插件才能实现真正的租户隔离。
1.3 多租户隔离模型对比
根据隔离的严格程度，多租户模型可分为三种：
- 软隔离（Soft Multi-Tenancy）：租户共享同一集群，通过 Namespace、RBAC、NetworkPolicy 实现逻辑隔离。成本低，但隔离强度有限，适合内部开发环境。
- 硬隔离（Hard Multi-Tenancy）：每个租户拥有独立的虚拟集群（如 vCluster）或物理节点，网络层面使用 VLAN/VXLAN 或独立 CNI 插件。隔离性强，但资源利用率下降。
- 混合隔离（Hybrid Multi-Tenancy）：关键业务租户使用硬隔离，非关键租户使用软隔离，在成本与安全之间取得平衡。
1.4 隔离性：从 Namespace 到网络边界
隔离性是多租户的基石。在云原生网络中，隔离性体现在以下层级：
- 控制面隔离：租户拥有独立的 RBAC 权限、ServiceAccount、配额管理。
- 数据面隔离：租户的 Pod 流量必须经过 NetworkPolicy 或 CNI 策略的过滤。
- 网络边界隔离：使用 VPC、VXLAN、IPVLAN 等技术将租户网络划分为独立的 L2/L3 域。
- DNS 与服务发现隔离：租户只能发现本租户内的 Service，避免跨租户服务调用。
最佳实践：在 Kubernetes 中，建议为每个租户创建独立的 Namespace，并配合以下策略实现网络隔离：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
namespace: tenant-a
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
1.5 安全性：防止租户间攻击
安全性挑战主要来自以下场景：
- 数据泄露：Pod 间未加密通信，恶意租户通过抓包获取其他租户敏感数据。
- 权限越界：RBAC 配置不当，租户 A 的 ServiceAccount 可以读取租户 B 的 Secret。
- DNS 劫持：租户 A 创建同名 Service，诱导租户 B 的流量错误路由。
- 资源耗尽攻击：租户 A 创建大量 Pod 或 Service，耗尽集群 IP 池或 DNS 记录数。
应对措施包括：启用 mTLS 加密（如 Istio）、严格 RBAC 绑定、使用 CNI 插件（如 Calico）的租户级安全策略、限制每个租户的 Service 与 Endpoint 数量。
1.6 性能争抢：“吵闹邻居”问题
性能争抢是多租户网络中最棘手的问题。当多个租户共享同一物理网络链路或节点时，一个租户的突发流量会挤占其他租户的带宽，导致延迟抖动和丢包。
| 争抢资源 | 影响范围 | 典型表现 | 缓解方案 |
|---|---|---|---|
| 节点带宽 | 同节点 Pod 间通信 | 租户 A 大量下载，租户 B 请求超时 | CNI 带宽插件（bandwidth）、TC 限速 |
| 集群网络带宽 | 跨节点 Pod 通信 | 租户 A 大数据任务导致集群网络拥塞 | QoS 队列、VLAN 优先级标记 |
| DNS 解析 | 所有租户共享 CoreDNS | 租户 A 高并发 DNS 查询导致其他租户解析延迟 | CoreDNS 限流、独立 DNS 实例 |
| API Server | 控制面请求 | 租户 A 频繁 List/Watch 导致 API Server 过载 | APF（API Priority and Fairness） |
1.7 本章小结
多租户是云原生网络拓扑选型的起点。理解隔离性、安全性、性能争抢这三大挑战，是后续章节中对比不同网络方案（Flannel、Calico、Cilium、Kube-OVN 等）的基础。在进入具体选型之前，建议先明确以下问题：
- 你的租户之间是否需要隔离（如金融级合规）？
- 你的租户流量模型是否包含突发大数据传输？
- 你的团队是否有能力维护复杂的网络策略（如 eBPF、IPVS）？