2. Kubernetes 多租户模型基础:命名空间隔离、RBAC、NetworkPolicy 基础概念
在 Argo CD 结合多租户资源配额的实践中,Kubernetes 多租户模型是底层支撑。多租户的核心目标是在共享集群资源的前提下,为不同团队、项目或用户提供逻辑或物理上的隔离,确保安全性与资源公平性。本章将深入剖析实现多租户的三大基础组件:命名空间(Namespace)、RBAC(基于角色的访问控制)和NetworkPolicy(网络策略)。
2.1 命名空间隔离:逻辑边界
命名空间是 Kubernetes 实现多租户隔离的第一道防线。它将集群内的资源划分为逻辑组,每个命名空间内的资源(如 Pod、Service、ConfigMap)默认相互隔离,且资源名称在命名空间内唯一。
以下表格对比了命名空间隔离与集群级资源的区别:
| 特性 | 命名空间级资源 | 集群级资源 |
|---|---|---|
| 典型资源 | Pod、Service、Deployment、ConfigMap | Node、PersistentVolume、ClusterRole、Namespace |
| 隔离范围 | 仅限同一命名空间内可见 | 全局可见,跨命名空间 |
| 名称唯一性 | 命名空间内唯一 | 集群内唯一 |
| 多租户用途 | 划分租户工作负载 | 定义全局策略与基础设施 |
在多租户场景中,通常为每个租户(团队/项目)分配一个独立的命名空间,例如 team-alpha、team-beta。Argo CD 在部署应用时,可以通过 destination.namespace 字段将应用资源定向到指定命名空间,实现租户工作负载的物理分离。
2.2 RBAC:细粒度访问控制
RBAC 是 Kubernetes 授权机制的核心,它通过定义“角色”和“绑定”来控制用户或服务账户对资源的操作权限。在多租户模型中,RBAC 确保租户只能访问其所属命名空间内的资源,无法越权操作其他租户的数据。
2.2.1 核心组件
- Role / ClusterRole:定义一组权限规则。Role 作用于特定命名空间,ClusterRole 作用于整个集群。
- RoleBinding / ClusterRoleBinding:将 Role 或 ClusterRole 绑定到用户、组或服务账户(ServiceAccount)。
- Subject:被授权的实体,可以是 User、Group 或 ServiceAccount。
以下是一个典型的租户 RBAC 配置示例,为 team-alpha 命名空间内的服务账户授予只读权限:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: team-alpha
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: team-alpha
name: read-pods
subjects:
- kind: ServiceAccount
name: team-alpha-sa
namespace: team-alpha
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
2.2.2 多租户 RBAC 设计模式
| 模式 | 描述 | 适用场景 |
|---|---|---|
| 命名空间级 Role | 每个租户命名空间内定义独立的 Role 和 RoleBinding | 租户权限需求差异大,完全隔离 |
| 共享 ClusterRole + 命名空间 RoleBinding | 定义通用的 ClusterRole(如只读、编辑),通过 RoleBinding 绑定到不同命名空间 | 租户角色模板化,减少重复定义 |
| 聚合 ClusterRole | 使用标签选择器将多个 ClusterRole 聚合为一个 | 需要组合多个基础权限的场景 |
2.3 NetworkPolicy:网络隔离
默认情况下,Kubernetes 集群内的所有 Pod 可以互相通信。NetworkPolicy 是一种资源对象,用于控制 Pod 组之间的网络流量,实现租户间的网络隔离。它基于标签选择器定义入站(Ingress)和出站(Egress)规则。
2.4 核心规则示例
以下策略拒绝所有来自其他命名空间的流量,仅允许同一命名空间内的 Pod 通信:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-cross-ns
namespace: team-alpha
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: team-alpha
该策略通过 namespaceSelector 限制入站流量仅来自 team-alpha 命名空间,有效阻止了 team-beta 的 Pod 访问 team-alpha 的服务。
2.5 三组件协同工作流
在实际多租户部署中,命名空间、RBAC 和 NetworkPolicy 需要协同工作,形成完整的隔离体系:
- 命名空间划分:为每个租户创建独立命名空间,作为资源隔离的基本单元。
- RBAC 权限绑定:在命名空间内创建 Role 和 RoleBinding,限制租户的操作范围。
- NetworkPolicy 网络隔离:在命名空间上应用网络策略,阻止跨命名空间的非授权流量。
- 资源配额(ResourceQuota):为命名空间设置 CPU、内存等资源上限,防止租户资源抢占(将在后续章节详细展开)。
spec.destination.namespace 指定目标命名空间,并结合 Argo CD 的 RBAC 配置(argocd-rbac-cm ConfigMap)实现 GitOps 流程中的多租户权限控制。
通过以上三个基础组件的组合,Kubernetes 能够为多租户场景提供坚实的隔离基础,为后续 Argo CD 的资源配额管理铺平道路。