多租户隔离集群蓝图与Kubernetes架构优化工程落地 - 第1节
1.1 多租户定义与核心诉求
多租户（Multi-Tenancy）是指单个软件实例或基础设施集群同时为多个独立用户群体（租户）提供服务，且每个租户在逻辑上彼此隔离。在 Kubernetes 语境下，租户可以是一个团队、一个项目、一个业务线或一个外部客户。多租户架构的核心目标是实现 资源复用 与 安全隔离 的平衡。
核心诉求：
- 安全隔离： 租户 A 无法访问或影响租户 B 的数据、网络与计算资源。
- 资源公平： 防止“吵闹邻居”现象，确保每个租户获得承诺的资源配额。
- 运维自治： 租户在自身命名空间内拥有一定管理权限，无需全局集群管理员介入。
- 成本分摊： 能够清晰统计每个租户的资源消耗，用于内部计费或展示。
1.2 Kubernetes 原生隔离模型全景
Kubernetes 本身提供了五个核心的隔离维度，它们共同构成了多租户隔离的基础层。这些机制均为“软隔离”（逻辑隔离），而非 Hypervisor 级别的“硬隔离”。
| 隔离维度 | API 对象 | 隔离范围 | 主要作用 |
|---|---|---|---|
| 身份与边界 | Namespace | 集群级 | 将集群划分为虚拟子集群，作为资源归属和权限绑定的基本单位 |
| 权限控制 | RBAC (Role / RoleBinding / ClusterRole / ClusterRoleBinding) | 命名空间 / 集群 | 精细控制用户或 ServiceAccount 对资源的读、写、执行权限 |
| 网络隔离 | NetworkPolicy | 命名空间 / Pod | 定义 Pod 之间、Pod 与外部服务之间的流量访问规则 |
| 资源配额 | ResourceQuota | 命名空间 | 限制命名空间内所有 Pod 的 CPU、内存、存储及对象数量总和 |
| 资源限制 | LimitRange | 命名空间 | 为命名空间内未显式设置资源请求/限制的 Pod 或容器设置默认值及边界 |
1.2.1 隔离模型关系图
下图展示了五个原生隔离维度在集群中的协作关系：Namespace 作为边界容器，RBAC 控制“谁能做什么”，NetworkPolicy 控制“谁能访问谁”，ResourceQuota 和 LimitRange 控制“能用多少”。
1.3 各隔离机制深度解析
1.3.1 Namespace：隔离的第一道门
Namespace 是 Kubernetes 实现多租户的基础单元。它将集群内的资源（如 Pod、Service、ConfigMap）划分为互不干扰的组。关键特性包括：
- 资源归属： 所有 Kubernetes 对象都必须属于一个 Namespace（集群范围对象除外）。
- DNS 隔离： 服务可以通过
<service>.<namespace>.svc.cluster.local跨命名空间访问，但默认不提供网络隔离。 - 删除级联： 删除 Namespace 会级联删除其下所有资源，需谨慎操作。
最佳实践： 使用
kubectl create namespace team-alpha 创建租户命名空间，并立即应用标签如 tenant: alpha 以便后续策略匹配。
1.3.2 RBAC：谁可以做什么
RBAC（基于角色的访问控制）是 Kubernetes 的权限管理标准。它通过四个核心对象实现细粒度授权：
| 对象 | 作用域 | 示例 |
|---|---|---|
| Role | 命名空间 | 允许对 Pod 执行 get、list、watch |
| ClusterRole | 集群 | 允许查看所有 Namespace 的 Node 状态 |
| RoleBinding | 命名空间 | 将 Role 绑定到用户 user-a@example.com |
| ClusterRoleBinding | 集群 | 将 ClusterRole 绑定到集群管理员组 |
# 创建一个只允许在 team-alpha 命名空间操作 Deployment 的 Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: team-alpha
name: deployment-manager
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
# 将上述 Role 绑定到用户
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: team-alpha
name: deployment-manager-binding
subjects:
- kind: User
name: "dev-user@company.com"
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: deployment-manager
apiGroup: rbac.authorization.k8s.io1.3.3 NetworkPolicy：流量隔离的守门员
NetworkPolicy 是 Kubernetes 原生的网络隔离机制，它通过标签选择器和端口规则控制 Pod 级别的流量。默认情况下，Pod 接受所有流量；一旦应用 NetworkPolicy，未显式允许的流量将被拒绝。
注意： NetworkPolicy 需要 CNI 插件支持（如 Calico、Cilium、Weave Net）。Flannel 默认不支持 NetworkPolicy。
# 拒绝所有非租户 A 的 Pod 访问租户 A 的数据库 Pod
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-db-access
namespace: tenant-a
spec:
podSelector:
matchLabels:
app: database
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
tenant: tenant-a
ports:
- protocol: TCP
port: 54321.3.4 ResourceQuota 与 LimitRange：资源使用的边界
这两个对象共同防止租户过度消耗集群资源：
- ResourceQuota： 设置命名空间级别的资源总量上限，包括 CPU、内存、存储以及对象数量（如 Pod 数量、Service 数量）。
- LimitRange： 设置 Pod 或容器级别的资源默认值和边界值，确保未设置资源请求的 Pod 不会无限占用。
# ResourceQuota 示例：限制 team-alpha 命名空间
apiVersion: v1
kind: ResourceQuota
metadata:
name: team-alpha-quota
namespace: team-alpha
spec:
hard:
requests.cpu: "4"
requests.memory: "16Gi"
limits.cpu: "8"
limits.memory: "32Gi"
pods: "20"
services: "10"
---
# LimitRange 示例：为 team-alpha 设置默认资源限制
apiVersion: v1
kind: LimitRange
metadata:
name: team-alpha-limits
namespace: team-alpha
spec:
limits:
- default:
cpu: "500m"
memory: "512Mi"
defaultRequest:
cpu: "100m"
memory: "128Mi"
type: Container1.4 多租户面临的挑战
尽管 Kubernetes 提供了上述原生隔离机制，但在实际生产环境中实现严格的多租户隔离仍面临诸多挑战：
| 挑战领域 | 具体问题 | 影响 |
|---|---|---|
| 安全漏洞 | 容器逃逸、内核漏洞、共享宿主机资源 | 恶意租户可能突破容器边界，影响其他租户 |
| 网络隔离不彻底 | NetworkPolicy 无法控制 DNS、Service Mesh 流量；默认允许所有出站流量 | 租户可能通过 DNS 或 NodePort 服务进行数据泄露 |
| 资源竞争 | CPU 可压缩资源争抢、磁盘 IO 和网络带宽未隔离 | “吵闹邻居”导致性能抖动，影响关键业务 |
| 管理复杂度 | 每个租户需要独立配置 RBAC、NetworkPolicy、Quota；策略数量随租户线性增长 | 运维成本高，容易配置错误导致隔离失效 |
| 审计与合规 | 原生审计日志缺乏租户维度聚合；无法追溯跨命名空间操作 | 难以满足 SOC2、PCI-DSS 等合规要求 |
| 共享控制面 | API Server、etcd 为所有租户共享；单个租户的异常请求可能拖垮 API Server | 影响集群全局稳定性 |
1.4.1 挑战关系图
下图展示了多租户隔离中主要挑战之间的关联关系：安全漏洞是根本风险，资源竞争和网络隔离不彻底是常见表现，管理复杂度和审计合规是运维层面的障碍，而共享控制面是架构层面的固有风险。