Kubernetes RBAC 架构：核心组件与资源映射
RBAC（基于角色的访问控制）是 Kubernetes 默认且最推荐的鉴权机制。理解其架构是进行调度策略调优的前提。本章将拆解 RBAC 的四大核心组件，并建立 API 资源与操作动词之间的映射关系。
2.1 RBAC 核心组件
Kubernetes RBAC 由四个关键 API 对象构成，它们协同工作以定义“谁”能对“什么资源”执行“什么操作”。
| 组件 | 作用域 | 核心作用 | 典型场景 |
|---|---|---|---|
| Role | 命名空间 | 定义一组权限规则，如对 Pod 的 get、list、watch 权限 | 限制某命名空间内应用只能读取自身日志 |
| ClusterRole | 集群 | 定义集群级别或跨命名空间的权限规则 | 允许管理员查看所有命名空间的节点状态 |
| RoleBinding | 命名空间 | 将 Role 或 ClusterRole 绑定到用户、组或 ServiceAccount | 将“只读角色”绑定给开发人员 |
| ClusterRoleBinding | 集群 | 将 ClusterRole 绑定到集群范围内的主体 | 将“集群管理员”角色绑定给运维团队 |
关键区别： Role 和 RoleBinding 是命名空间级别的，只能控制本命名空间内的资源；ClusterRole 和 ClusterRoleBinding 是集群级别的，可以控制节点、持久卷、命名空间等集群资源，也可以跨命名空间授权。
2.2 RBAC 授权流程
当用户或 Pod 发起 API 请求时，RBAC Authorizer 会按以下步骤判断是否放行：
- 提取请求属性： 解析出请求的用户名、组、请求动作（动词）、资源类型、资源名称、命名空间。
- 查找绑定： 根据用户/组/ServiceAccount，查找所有匹配的 RoleBinding 和 ClusterRoleBinding。
- 聚合角色规则： 从绑定的 Role 或 ClusterRole 中提取所有权限规则（rules）。
- 规则匹配： 遍历规则，检查请求的动词、资源、资源名是否被允许。
- 决策： 如果有一条规则明确允许，则放行；如果所有规则都不匹配或明确拒绝，则拒绝。
调度调优启示： 调度器（kube-scheduler）本身通过 ServiceAccount 与 API Server 交互。如果调度器的 RBAC 权限不足（例如无法 list/watch 节点资源），会导致调度失败。调优时需确保调度器绑定的 ClusterRole 包含对 Node、Pod、PersistentVolume 等资源的完整访问权限。
2.3 API 资源与动词映射
RBAC 规则的核心是 resources 和 verbs 的组合。理解 Kubernetes API 的资源层级和可用动词是编写精确策略的基础。
2.3.1 核心资源类型
| 资源类别 | API 资源名称 | 作用域 | 调度相关 |
|---|---|---|---|
| 工作负载 | pods, deployments, statefulsets, daemonsets | 命名空间 | Pod 调度、驱逐、拓扑分布 |
| 调度资源 | nodes, persistentvolumes, storageclasses | 集群 | 节点选择、卷调度、资源配额 |
| 网络 | services, ingresses, networkpolicies | 命名空间 | 网络策略影响 Pod 间通信 |
| 配置 | configmaps, secrets | 命名空间 | 调度器配置、卷挂载 |
| 权限 | roles, rolebindings, clusterroles, clusterrolebindings | 混合 | 调度器自身权限 |
2.3.2 动词映射
Kubernetes 将 HTTP 方法映射为 RBAC 动词。以下是常用映射关系：
| HTTP 方法 | RBAC 动词 | 典型操作 | 调度场景示例 |
|---|---|---|---|
| GET / HEAD | get, list, watch | 读取资源详情、列表、监听变化 | 调度器 watch 未调度的 Pod |
| POST | create | 创建新资源 | 调度器创建绑定（binding） |
| PUT | update | 全量更新资源 | 更新 Pod 状态 |
| PATCH | patch | 部分更新资源 | 更新 Pod 注解（调度提示） |
| DELETE | delete, deletecollection | 删除单个或批量资源 | 驱逐 Pod（节点维护） |
常见陷阱： 动词
list 和 watch 是独立的。如果只授予 get 而没有 list，调度器将无法通过标签选择器查询 Pod 列表，导致调度循环异常。调优时务必同时授予 get、list、watch 三个动词。
2.4 资源子资源与自定义资源
除了标准资源，Kubernetes 还支持子资源和自定义资源（CRD），它们同样受 RBAC 控制。
- 子资源： 如
pods/log、pods/exec、pods/status、nodes/proxy。在 RBAC 规则中需写成resources: ["pods/log"]。 - 自定义资源： 如
schedules.koordinator.sh、podgroups.scheduling.x-k8s.io。资源名通常为 CRD 的spec.names.plural字段。
2.5 实战：调度器 RBAC 配置示例
以下是一个为自定义调度器（kube-scheduler 的替代或扩展）配置的最小权限 ClusterRole 示例：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: custom-scheduler-role
rules:
- apiGroups: [""]
resources: ["pods", "nodes", "persistentvolumes", "persistentvolumeclaims"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["pods/status", "nodes/status"]
verbs: ["patch", "update"]
- apiGroups: [""]
resources: ["bindings", "pods/binding"]
verbs: ["create"]
- apiGroups: ["scheduling.k8s.io"]
resources: ["priorityclasses"]
verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses", "csinodes"]
verbs: ["get", "list", "watch"]
调优要点： 上述配置遵循最小权限原则。调度器只需要读取 Pod/Node 信息、更新状态、创建绑定。不需要 delete 或 create Pod 的权限。如果使用调度框架扩展点（如 ScorePlugin），可能需要额外授权访问自定义资源。
2.6 本章小结
- RBAC 四大组件：Role（命名空间）、ClusterRole（集群）、RoleBinding（命名空间绑定）、ClusterRoleBinding（集群绑定）。
- 授权流程：请求属性提取 → 绑定查找 → 规则聚合 → 匹配决策。
- 动词映射：get/list/watch 对应读取，create 对应创建，update/patch 对应更新，delete 对应删除。
- 子资源和 CRD 需要单独在 rules 中声明。
- 调度器调优时，务必确保其 ServiceAccount 绑定的 ClusterRole 包含对调度相关资源的完整读取和绑定创建权限。