📚 课程目录第3章多租户架构基础

3. 多租户架构基础：租户隔离模型、Namespace隔离、RBAC策略、资源配额管理

多租户（Multi-Tenancy）是云原生基础设施的核心能力，尤其在基于 CAPI 的集群快速创建与发布场景中，租户隔离直接决定了平台的安全性、可审计性与资源公平性。本章从隔离模型出发，逐层深入 Kubernetes 原生的 Namespace 隔离、RBAC 策略与资源配额管理，为后续多租户集群的自动化创建奠定理论基础。

3.1 租户隔离模型：从共享到硬隔离

在多租户架构中，租户可以是团队、项目、客户或业务线。根据隔离强度与资源开销，常见的隔离模型分为以下三种：

隔离模型	隔离粒度	资源开销	适用场景
软隔离（Soft Multi-Tenancy）	Kubernetes Namespace + RBAC + ResourceQuota	低（共享集群）	开发/测试环境、内部团队协作
硬隔离（Hard Multi-Tenancy）	独立集群 + 虚拟集群（vCluster）	中（每个租户一个控制面）	生产环境、合规敏感业务
混合隔离（Hybrid Multi-Tenancy）	CAPI 管理集群 + 租户集群 + Namespace 子隔离	高（管理集群 + 多个工作集群）	大规模 SaaS 平台、多客户托管

实践建议：在 CAPI 多租户场景中，推荐采用混合隔离模型——管理集群负责全局调度与策略下发，每个租户拥有独立的工作集群（CAPI Cluster），工作集群内部再通过 Namespace 做二级隔离。这样既保证了租户间的强隔离，又保留了集群内的资源细分能力。

3.2 Namespace 隔离：租户的虚拟边界

Namespace 是 Kubernetes 实现软隔离的基础单元。在 CAPI 多租户架构中，每个租户集群内部通过 Namespace 划分不同的工作负载域。Namespace 隔离的核心能力包括：

资源可见性隔离：Pod、Service、ConfigMap、Secret 等资源默认仅在同一 Namespace 内可见。
网络策略隔离：结合 NetworkPolicy，可以控制 Namespace 之间的流量进出。
资源配额隔离：通过 ResourceQuota 限制每个 Namespace 的 CPU、内存、存储等总量。
权限隔离：RBAC 绑定可以精确到 Namespace 级别，实现最小权限原则。

  关键设计原则：在 CAPI 多租户平台中，建议为每个租户集群创建以下标准 Namespace 集合：ns-{tenant}-dev、ns-{tenant}-staging、ns-{tenant}-prod、ns-{tenant}-system。命名规范统一，便于自动化工具批量管理。

3.3 RBAC 策略：精细化权限控制

RBAC（Role-Based Access Control）是 Kubernetes 原生的授权机制。在多租户场景中，RBAC 策略需要覆盖三个维度：

维度	对象	典型绑定
集群级别	ClusterRole / ClusterRoleBinding	集群管理员、监控组件、CAPI 控制器
Namespace 级别	Role / RoleBinding	租户开发者（只读/读写）、CI/CD 服务账号
跨 Namespace 级别	ClusterRole + RoleBinding（引用）	日志采集器、服务网格控制面

以下是一个典型的租户开发者 RBAC 配置示例：

# 创建 Namespace 级别的 Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: ns-tenant-a-dev
  name: tenant-developer-role
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps", "secrets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets", "daemonsets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
# 绑定到用户或服务账号
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: ns-tenant-a-dev
  name: tenant-developer-binding
subjects:
- kind: User
  name: "alice@tenant-a.com"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: tenant-developer-role
  apiGroup: rbac.authorization.k8s.io

常见陷阱：不要将 ClusterRoleBinding 直接授予租户用户，否则该用户将拥有整个集群的权限，破坏多租户隔离。始终使用 RoleBinding 将权限限定在特定 Namespace 内。对于需要跨 Namespace 访问的场景（如日志查看），应创建专用的 ClusterRole，然后通过 RoleBinding 引用。

3.4 资源配额管理：保障公平与稳定性

ResourceQuota 和 LimitRange 是 Kubernetes 控制资源消耗的两大工具。在多租户集群中，资源配额管理直接关系到租户间的公平性和集群稳定性。

3.4.1 ResourceQuota：总量控制

ResourceQuota 限制一个 Namespace 内所有 Pod 的资源总和上限：

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

3.4.2 LimitRange：单个 Pod 约束

LimitRange 确保单个 Pod 或容器不会过度申请资源：

apiVersion: v1
kind: LimitRange
metadata:
  name: tenant-limit-range
  namespace: ns-tenant-a-prod
spec:
  limits:
  - max:
      cpu: "2"
      memory: "4Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
    default:
      cpu: "500m"
      memory: "1Gi"
    defaultRequest:
      cpu: "200m"
      memory: "512Mi"
    type: Container

3.5 多租户隔离策略总结

将 Namespace 隔离、RBAC 策略与资源配额管理三者结合，可以构建一个完整的多租户隔离体系。下表总结了各维度的关键配置项：

隔离维度	Kubernetes 对象	配置要点	检查命令
Namespace 隔离	Namespace	命名规范、标签标注、NetworkPolicy	`kubectl get ns`
权限隔离	Role / RoleBinding	最小权限、按角色分组、定期轮换	`kubectl describe rolebinding`
资源隔离	ResourceQuota / LimitRange	设置硬限制、默认值、突发上限	`kubectl describe quota`
网络隔离	NetworkPolicy	默认拒绝、白名单模式、标签选择器	`kubectl describe netpol`

自动化集成：在 CAPI 多租户平台中，建议将上述隔离策略封装为 Helm Chart 或 OPA/Gatekeeper 策略模板。当 CAPI 创建新租户集群时，自动执行策略部署脚本，确保每个新集群从创建之初就具备完整的隔离能力，避免人工配置遗漏。