📚 课程目录第1章 OpenShift自动化与资源治理全景

1. OpenShift自动化与资源治理全景

OpenShift 是建立在 Kubernetes 之上的企业级容器平台，它在原生 API 之上叠加了大量面向多租户、安全与运维的扩展对象。当集群从“能跑容器”走向“被多个团队长期共用”时，真正决定平台是否稳定的，往往不是某个应用能否启动，而是资源是否被合理分配、权限是否被正确约束、变更是否可被自动化地重复执行。这正是“自动化与资源治理”要解决的问题：让平台在规模扩大、团队增多的情况下，仍然保持可预测、可审计、可复现。

理解这一主题，需要先建立一张“对象地图”。OpenShift 中与治理相关的核心对象可以分成四类：边界类（Project / Namespace）、配额与约束类（ResourceQuota / LimitRange）、权限类（RBAC 的 Role、ClusterRole、RoleBinding、ClusterRoleBinding、ServiceAccount）、自动化类（Operator、CRD、Controller）。它们不是彼此孤立的，而是围绕“谁、在哪个范围、能用多少资源、能做什么操作、由谁自动维持状态”这一条主线协同工作。

先看边界层。Project 是 OpenShift 对 Namespace 的封装，它额外携带了显示名称、描述、成员与配额等元数据。创建 Project 时，OpenShift 会自动生成同名 Namespace，并默认绑定一组自管理角色。对治理而言，Project 的意义在于：它是资源配额、权限绑定、网络策略和监控标签的天然作用域。一个团队一个 Project，或一个应用一个 Project，是常见的划分方式。划分过粗会导致权限与配额互相干扰，划分过细则会带来管理负担，因此边界设计本身就是治理决策。

约束层解决“能用多少”和“默认给多少”。ResourceQuota 作用于 Namespace，限制该命名空间内所有对象可消耗的资源总量，例如 CPU 请求、内存请求、Pod 数量、Service 数量、PVC 数量等。LimitRange 则作用于单个 Pod 或容器，为未显式声明资源的容器提供默认 request/limit，并强制最大最小值。两者配合的逻辑是：Quota 管住命名空间的天花板，LimitRange 管住单个工作负载的默认值与边界。如果只设 Quota 不设 LimitRange，未声明资源的 Pod 可能因缺少 request 而无法被调度，或因缺少 limit 而挤占其他工作负载；如果只设 LimitRange 不设 Quota，多个工作负载叠加仍可能耗尽节点资源。

下面是一段可直接参考的 Quota 与 LimitRange 示例，用于演示两者的配合方式。示例参数为教学假设值，实际应按集群容量与团队约定调整。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "20"
    services: "10"
    persistentvolumeclaims: "5"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: team-a-limits
  namespace: team-a
spec:
  limits:
  - type: Container
    default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 200m
      memory: 256Mi
    max:
      cpu: "2"
      memory: 2Gi
    min:
      cpu: 50m
      memory: 64Mi

应用后，可以用 oc describe quota team-a-quota -n team-a 观察已用与硬限制的对比，用 oc describe limitrange team-a-limits -n team-a 确认默认值是否生效。判断依据很直接：若某个 Pod 未写 resources 却被自动补上 200m/256Mi，说明 LimitRange 生效；若创建第 21 个 Pod 被拒绝并提示 exceeded quota，说明 Quota 生效。

权限层回答“谁能做什么”。OpenShift 的 RBAC 由 Role/ClusterRole 定义权限集合，由 RoleBinding/ClusterRoleBinding 把权限授予用户、组或 ServiceAccount。Role 是命名空间级的，ClusterRole 是集群级的；RoleBinding 可以引用 Role 或 ClusterRole，但作用范围仍限于所在命名空间。治理实践中，应遵循最小权限原则：开发人员通常绑定 edit 或自定义 Role，只允许操作工作负载、ConfigMap、Secret，而不允许修改 ResourceQuota、LimitRange 或 RBAC 本身；平台管理员才持有 cluster-admin 或等价的高权限角色。ServiceAccount 则是工作负载访问 API 的身份，Operator 和自动化任务通常以 ServiceAccount 运行，其权限同样需要被约束。

自动化层是让治理可持续的关键。Operator 通过 CRD 扩展 API，并用 Controller 持续对比“期望状态”与“实际状态”，发现偏差就自动调谐。例如，一个数据库 Operator 可以自动创建 StatefulSet、Service、Secret 和备份任务；一个配额 Operator 可以在检测到命名空间用量接近上限时发出告警或自动扩容。自动化的价值不只是省去手工操作，更在于把治理规则固化成代码，使每次变更都可复现、可审计、可回滚。没有自动化，治理规则容易在人工操作中被绕过；有了自动化，规则才能被持续执行。

把四层串起来看，一个典型的治理闭环是：先按团队或应用划分 Project，再为每个 Project 设置 ResourceQuota 与 LimitRange，然后通过 RBAC 把不同角色的权限绑定到对应用户组和 ServiceAccount，最后用 Operator 或 GitOps 流水线自动创建和维护这些对象。这样，平台既给了团队自助使用的空间，又守住了资源与安全的边界。

治理对象之间存在依赖顺序：Project 必须先存在，Quota、LimitRange、RoleBinding 才能绑定到它；ServiceAccount 必须先创建，引用它的 RoleBinding 才能生效。排障时若发现权限或配额“没起作用”，先确认对象是否落在正确的命名空间、绑定关系是否完整。

最后需要强调，资源治理不是一次性配置，而是持续运营。集群容量会变、团队规模会变、应用形态会变，Quota 和 LimitRange 的数值需要定期复核；RBAC 权限会随人员流动而累积，需要定期审计；Operator 版本会升级，需要关注兼容性。把“对象地图”装进脑子，再配合自动化工具，才能在 OpenShift 上建立起真正可长期运行的治理体系。