2. OpenShift架构与开发者视角
要真正用好OpenShift，开发者需要先建立一张“集群地图”：哪些组件属于平台底座、哪些资源由开发者创建、哪些操作会被平台策略拦截。OpenShift本质上是“Kubernetes + 企业级扩展”，它保留了Kubernetes的核心对象模型，同时叠加了安全、构建、镜像、路由、监控等能力。理解这套架构，能帮助你在遇到权限拒绝、Pod无法调度、镜像拉取失败等问题时，快速判断问题出在平台层还是应用层。
一、集群组成：控制平面与工作节点
一个OpenShift集群由控制平面（Control Plane）和工作节点（Worker Node）组成。控制平面是集群的“大脑”，负责接收请求、保存期望状态、调度工作负载；工作节点是“手脚”，负责实际运行容器。开发者通常不直接登录控制平面节点，而是通过API Server或Web控制台提交资源。
控制平面中的关键组件包括：
- kube-apiserver：所有请求的统一入口，kubectl、oc、Web控制台、CI/CD系统都通过它读写资源。
- etcd：保存集群全部状态数据，是集群的“唯一事实来源”。
- kube-scheduler：决定Pod应该调度到哪个节点，依据资源请求、亲和性、污点与容忍等规则。
- kube-controller-manager：运行各种控制器，持续把实际状态拉回到期望状态。
- cloud-controller-manager：在云环境中对接负载均衡、存储、节点生命周期等云资源。
工作节点上运行的关键组件包括：
- kubelet：节点代理，负责启动、停止、监控Pod。
- CRI-O：OpenShift默认的容器运行时，负责拉取镜像并运行容器。
- kube-proxy：维护Service的网络转发规则。
- OVN-Kubernetes：OpenShift默认网络插件，提供Pod网络、Service网络和网络策略。
从开发者视角看，你提交一个Deployment后，请求先到API Server，写入etcd；Deployment控制器创建ReplicaSet，ReplicaSet控制器创建Pod；Scheduler为Pod选择节点；目标节点的kubelet通过CRI-O拉取镜像并启动容器。这条链路是理解OpenShift行为的基础。
二、项目与命名空间：开发者最常打交道的边界
在Kubernetes中，命名空间（Namespace）用于隔离资源；在OpenShift中，项目（Project）是命名空间的增强版。创建一个项目时，OpenShift会自动创建对应的Namespace，并附加默认的RBAC、配额、LimitRange、NetworkPolicy等策略。开发者通常通过oc new-project dev-team创建项目，随后所有资源都限定在该项目内。
项目带来的实际约束包括：
- 名称唯一性：项目名即命名空间名，集群内全局唯一。
- 资源配额：管理员可设置CPU、内存、Pod数量、PVC数量上限，超出后创建请求会被拒绝。
- 默认限制：LimitRange可为未声明resources的容器设置默认requests/limits，避免“裸奔”容器。
- 网络隔离：默认允许同项目内Pod互通，跨项目访问需显式NetworkPolicy或Service暴露。
- 权限隔离：开发者通常只拥有自己项目的edit或admin角色，无法查看其他项目。
一个常见的教学示例：在dev-team项目中创建Deployment，副本数3，容器镜像为quay.io/example/web:v1，资源请求cpu=100m, memory=128Mi，限制cpu=500m, memory=256Mi。如果项目配额为cpu=2, memory=2Gi, pods=10，那么3个副本合计请求300m CPU、384Mi内存，在配额内可正常创建；若把副本数改为10，请求达到1 CPU、1.28Gi内存，仍可能通过，但Pod总数达到10，接近上限。此时再创建新应用就会触发配额拒绝，API返回类似exceeded quota: compute-resources的错误。
三、开发者可操作边界：能做什么、不能做什么
OpenShift通过RBAC和SCC（Security Context Constraints）划分开发者边界。开发者通常可以：
- 在授权项目内创建、更新、删除Deployment、Service、Route、ConfigMap、Secret、PVC、BuildConfig、ImageStream等应用层资源。
- 查看自己项目的Pod日志、事件、指标，使用
oc logs、oc describe、oc get events排查问题。 - 触发构建、回滚部署、调整副本数、修改环境变量和配置。
- 使用
oc port-forward临时访问Pod端口进行调试。
开发者通常不能：
- 直接访问或修改etcd、控制平面组件、节点配置。
- 创建ClusterRole、ClusterRoleBinding、Namespace级别的全局资源。
- 使用特权容器、hostNetwork、hostPath等高风险配置，除非管理员通过SCC显式授权。
- 查看其他项目的资源，除非被授予跨项目权限。
oc auth can-i <verb> <resource> -n <project>。例如oc auth can-i create deployment -n dev-team返回yes，说明当前用户在该项目内可以创建Deployment。四、从请求到运行：一次部署的完整链路
假设开发者执行oc apply -f web-deployment.yaml，集群内部发生以下过程：
- oc客户端把YAML发送到API Server，API Server完成认证、鉴权、准入控制。
- 准入控制器检查配额、LimitRange、SCC等策略，通过后写入etcd。
- Deployment控制器发现新对象，创建ReplicaSet；ReplicaSet控制器创建3个Pod对象。
- Scheduler为每个Pod选择满足资源请求和亲和性规则的节点。
- 目标节点kubelet收到Pod绑定信息，调用CRI-O拉取镜像并启动容器。
- OVN-Kubernetes为Pod分配IP，kube-proxy维护Service转发规则。
- 若创建了Route，OpenShift Ingress Controller将外部域名映射到Service。
观察结果时，可以按顺序执行：oc get deployment查看期望副本与实际副本是否一致；oc get pods -o wide查看Pod所在节点和IP；oc describe pod <name>查看事件；oc logs <pod>查看应用日志。如果Pod一直Pending，优先检查资源配额、节点可调度资源和PVC绑定状态；如果ImagePullBackOff，检查镜像地址、Secret和网络；如果CrashLoopBackOff，检查应用启动命令、配置和依赖服务。
unable to validate against any security context constraint，需要调整容器安全上下文或联系管理员授权。五、开发者视角的架构速查
| 层级 | 对象/组件 | 开发者是否可直接操作 | 典型用途 |
|---|---|---|---|
| 控制平面 | etcd、apiserver、scheduler | 否 | 集群状态与调度 |
| 节点 | kubelet、CRI-O、OVN | 否 | 运行容器与网络 |
| 项目 | Namespace、Quota、LimitRange | 部分（查看/使用） | 资源隔离与配额 |
| 应用 | Deployment、Service、Route | 是 | 部署与暴露应用 |
| 配置 | ConfigMap、Secret、PVC | 是 | 配置与持久化 |
| 构建 | BuildConfig、ImageStream | 是 | 源码到镜像 |
掌握这张架构图后，开发者就能把“我的应用为什么没起来”拆解成几个可检查的层面：请求是否被API Server接受、是否通过配额和SCC、是否被调度到节点、镜像是否拉取成功、容器是否正常启动、Service和Route是否可达。每一层都有对应的oc命令和事件信息，定位效率会显著提升。