📚 课程目录第1章多租户概念与挑战

1. 多租户概念与挑战

多租户（Multi-Tenancy）是一种软件架构模式，指单个软件实例能够为多个独立的用户群体（租户）提供服务，同时确保每个租户的数据、配置、性能和访问权限相互隔离。在 Kubernetes 语境下，租户通常对应一个团队、项目、业务线或外部客户，共享同一套控制平面与工作节点资源。

  核心目标：在共享基础设施上实现“逻辑隔离”，达到近似物理隔离的安全效果，同时降低运维成本与资源碎片。

多租户隔离的四个关键维度：

维度	说明	K8s 原生手段
身份与认证	租户身份识别、用户认证	ServiceAccount、RBAC、OIDC
资源隔离	CPU/内存/存储的配额与限制	ResourceQuota、LimitRange
网络隔离	Pod 间流量控制、禁止跨租户通信	NetworkPolicy（原生能力有限）
安全边界	Pod 安全上下文、容器逃逸防护	PodSecurity Admission、AppArmor

Kubernetes 在设计之初并未将“多租户”作为一等公民，其原生隔离机制在面对企业级多租户需求时暴露出三大核心短板。

命名空间（Namespace）是 K8s 最基础的隔离单元，但它的隔离能力仅限于资源对象的逻辑分组，并非安全边界：

网络互通默认全开：任何 Pod 都可以通过 Cluster IP 或 DNS 访问其他命名空间的 Pod，无需显式授权。
集群范围资源不受限：ClusterRole、ClusterRoleBinding、Node、PersistentVolume 等资源不在命名空间作用域内，一个租户可能误操作影响全局。
共享节点内核：不同命名空间的 Pod 可能运行在同一工作节点上，共享 Linux 内核，存在容器逃逸与侧信道攻击风险。
无租户级配额聚合：ResourceQuota 只能按命名空间设置，无法对“一个租户下多个命名空间”进行总量控制。

常见误区：很多团队认为“一个租户一个 Namespace”就完成了多租户隔离。实际上，Namespace 只是“文件夹”，不是“保险箱”。

Kubernetes RBAC 提供了基于角色的访问控制，但在多租户场景下，配置与管理复杂度呈指数级增长：

问题	具体表现	影响
角色爆炸	每个租户需要独立 Role + RoleBinding，租户数量多时难以维护	配置错误率高，审计困难
权限粒度粗	RBAC 只能控制到 API 资源级别（如 pods、services），无法限制特定字段或特定标签的 Pod	租户可能创建违反安全策略的资源
跨命名空间授权混乱	ClusterRoleBinding 可能意外授予跨命名空间权限	权限泄露，租户越权访问
缺乏租户管理员自服务	租户管理员无法自主管理本租户的用户与权限，依赖平台团队	运维瓶颈，响应慢

这是多租户隔离中最棘手的问题。K8s 默认的“扁平网络”模型使得所有 Pod 可以自由通信，原生 NetworkPolicy 虽然能实现部分隔离，但存在严重局限：

策略作用范围有限：NetworkPolicy 只能控制 Pod 之间的流量，无法管控节点端口（NodePort）、负载均衡器入口、DNS 请求以及出口流量。
无租户级策略抽象：每个 NetworkPolicy 必须绑定到特定 Pod 标签，无法定义“租户 A 的所有 Pod 禁止被租户 B 访问”这样的高层策略。
性能与规模瓶颈：当集群中有数千个 NetworkPolicy 时，kube-proxy 和节点内核规则更新成为性能瓶颈。
缺乏加密与身份感知：原生 NetworkPolicy 不提供 mTLS 加密，也无法基于服务身份（而非 IP）做授权。

上述三个挑战并非孤立存在，它们相互叠加，形成多租户场景下的“隔离困境”：