1. OpenShift开发者平台与自助服务导论
在传统交付模式中，开发者要上线一个应用，往往需要先提交资源申请，等待运维分配服务器、开通网络策略、配置数据库、申请域名和证书，再手工搭建 CI/CD 流水线。这个链条中任何一环排队，都会让"写代码"这件本该聚焦的事情被大量环境协调工作稀释。OpenShift 要解决的核心问题，正是把这条链条从"人工审批驱动的资源交付"转变为"平台能力驱动的自助服务"：开发者通过声明式接口，在受治理的边界内自行获取构建、部署、发布、观测所需的能力，而平台团队则从"逐单响应"转向"定义规则、维护能力、保障底线"。
平台定位：以 Kubernetes 为内核的开发者平台
OpenShift 是 Red Hat 基于 Kubernetes 构建的企业级容器平台。理解它的定位，需要区分三个层次：最底层是 Kubernetes 提供的容器编排与声明式 API 能力；中间层是 OpenShift 在其上补齐的企业化能力，包括内置镜像仓库、Source-to-Image 构建、路由与入口、基于 OAuth 的身份认证、多租户项目隔离、安全上下文约束（SCC）、Operator 生命周期管理等；最上层才是面向开发者的自助服务界面，包括 Web 控制台、oc 命令行、开发者目录（Developer Catalog）与模板。换句话说，OpenShift 的价值不在于重新发明编排，而在于把"能跑容器"变成"团队可以放心、快速、合规地交付应用"。
与"自建 Kubernetes 再加一堆插件"相比，OpenShift 的关键差异在于默认集成与默认安全。例如，普通用户默认不能以 root 运行容器，镜像来自内部仓库时可通过 ImageStream 触发自动构建与滚动更新，路由与证书由平台统一管理。这些默认值决定了开发者自助服务的边界：能自助做什么、哪些必须走平台审批，都由平台策略预先定义，而不是每次临时协商。
核心价值：从"申请资源"到"声明意图"
OpenShift 对开发者的核心价值可以归纳为四点。第一是声明式交付：开发者用 YAML 或控制台表单描述"我要什么"（镜像、副本数、环境变量、健康检查、资源配额），平台负责把实际状态收敛到期望状态。第二是内建构建与发布链路：通过 BuildConfig、ImageStream、DeploymentConfig 或 Deployment，代码提交后可自动触发构建、生成镜像、滚动发布，无需自建流水线即可完成最小闭环。第三是多租户隔离与配额：Project（即 Namespace）作为隔离单元，配合 ResourceQuota、LimitRange 和 RBAC，让多个团队共享集群而不互相干扰。第四是可观测与可回滚：部署历史、Pod 日志、事件、指标与健康探针共同构成判断"这次发布是否成功"的依据，失败时可快速回退到上一个版本。
一个典型的最小自助闭环是：开发者创建 Project → 从 Git 仓库或本地目录触发构建 → 镜像推入内部 ImageStream → 创建 Deployment 并暴露 Service/Route → 通过 Route 访问应用 → 观察 Pod 状态与日志 → 需要变更时更新镜像标签触发滚动更新。
开发者自助服务能力全景
把 OpenShift 面向开发者的能力按"开发者旅程"梳理，可以形成一张能力地图。下面这张图不是流程步骤，而是能力分层与依赖关系：左侧是开发者可自助触发的动作，右侧是平台提供的支撑能力，中间通过声明式 API 连接。
这张图的关键在于中间的"声明式 API"层：开发者并不直接操作服务器，而是提交期望状态，由控制器持续调谐。右侧能力并非全部需要开发者手工配置——很多由平台团队通过 Operator 或模板预置，开发者只需在开发者目录中选择并填写少量参数即可获得一个可用的中间件实例。这正是"自助服务"与"自己动手搭"的区别：能力被封装、被治理、被复用。
课程学习路径
本课程共 30 章，建议按"认知—操作—治理—扩展"的顺序推进。前几章建立平台定位与自助服务心智模型，理解 Project、声明式 API、构建与部署的基本对象；随后进入实操层面，围绕一个示例应用完成从源码到可访问服务的完整闭环，并练习配置注入、健康检查、滚动更新与回滚；再往后进入治理与协作，包括配额、RBAC、多租户隔离、镜像与构建策略；最后扩展到 Operator、开发者目录、CI/CD 集成与平台可观测性，形成"开发者能自助、平台能管控"的完整视角。
学习建议：每章都动手执行一次。OpenShift 的很多概念（如 ImageStream 触发构建、Route 与 Service 的关系、SCC 对容器用户的影响）只有在实际创建对象、观察事件和日志时才会真正清晰。遇到 Pod 无法启动时，优先看 oc describe pod 的 Events 与 oc logs，而不是反复修改 YAML。
一个可复现的入门示例
为了把上述概念落到具体对象，下面给出一个最小示例。假设已登录集群，且当前用户有创建 Project 的权限。示例参数均为教学假设值，实际执行时请替换为你的集群地址与镜像仓库。
# 1. 创建项目（隔离单元）
oc new-project demo-selfservice
# 2. 从 Git 源码构建（S2I），假设仓库可访问
oc new-app nodejs:18~https://example.com/demo/app.git --name=demo-app
# 3. 查看构建与镜像流状态
oc get builds
oc get imagestream demo-app
# 4. 暴露服务并生成路由
oc expose svc/demo-app
oc get route demo-app
# 5. 观察运行态
oc get pods -w
oc logs deploy/demo-app
执行后应重点观察三类信号：Build 是否从 Pending 进入 Running 再到 Complete；ImageStream 的 tag 是否更新；Pod 是否 Ready 且 Route 能返回预期响应。若 Build 失败，先看 oc logs build/demo-app-1；若 Pod 处于 CrashLoopBackOff，先看容器日志与探针配置。这个闭环虽小，却覆盖了自助服务的核心：声明意图、平台执行、反馈判断、按需调整。