拿到EX280通过邮件的那一刻，我比预想中平静。为了这一封邮件，我前后练了三周，几乎把能踩的坑踩了个遍。身边经常有人问我：RHCA那么多门专项考试，为什么第二站就选EX280？我的回答一直很一致——它是目前红帽认证体系里离“生产环境真实操作”最近的一门考试。EX280对应的课程是Red Hat OpenShift Administration II，官方全称写得很直白：Configuring a Production Cluster。翻译成大白话就是：给你一个已经跑起来的OpenShift集群，你得像真正接手生产环境的运维工程师一样，把认证、权限、网络、存储、监控、审计这些事一件一件配置到位。
这门考试不考选择题，不考背诵。所有题目都是对着真实集群的实际操作，最终按集群里留下的状态打分。说白了，会就是会，不会就是不会，现场编不出来的。这篇文章我不想复述一遍官方大纲，而是打算从备考角度把几个核心考点、实验环境搭建、我踩过的坑、考前两周怎么安排，一次性讲清楚。适合两类人看：一类是正在规划RHCA选课的人，想知道EX280到底值不值得先考；另一类是已经在做OpenShift运维、想用一次考试倒逼自己把知识体系补完整的人。文章里涉及的命令我都尽量给了可直接抄的写法，但红帽考试题目每年都会微调，具体以官方考试目标为准。
1. EX280在RHCA路线里的位置：为什么它是容器运维方向的“标配”
1.1 考试代码、课程对应与官方定位
EX280对应的是DO280这门课，也就是Red Hat OpenShift Administration II。在老版RHCA体系里，这门课叫OpenShift Administration，后来红帽把课程内容重新梳理，新版考试名称加上了“Configuring a Production Cluster”，强调的就是生产集群的配置与管理，而不是最基础的容器入门。
一门考试值得不值得排在RHCA第二站，要看它对后面科目的支撑作用。RHCA虽然是五门专项考试的集合，但每门考试的侧重点差异很大。有的偏向性能调优，有的偏向安全加固，有的偏向自动化。EX280的独特之处在于，它覆盖的是OpenShift集群的日常运维主线——认证、授权、存储、网络、应用交付、监控、审计、节点维护。这些内容几乎是所有云原生岗位的基础底盘。考完这门，再看其他RHCA科目，比如故障排查、性能调优，你会发现很多底层概念已经在这个阶段打好了。这也是我把它排在RHCA路线的早期而不是后期的原因。
1.2 全实操考试形态：现场没有“标准答案”
红帽的考试基本都是performance-based，EX280尤其典型。考试现场会给你一个已经部署好的OpenShift集群环境，以及一个可以操作的bastion工作站。你在工作站上用oc命令或浏览器打开Web控制台，按题干要求完成任务。题干不会告诉你用什么命令，更不会提示你改哪个文件。“集群里有个用户jordan，要求他只能在项目dev-blue中读取Pod日志”，这就是一道题的全部信息。
这种形态决定了备考方式和背题库完全不同。背知识点只能帮你听懂题目，能不能得分取决于你在集群里是否真的把状态配对了。评分的维度包括：资源是否存在、配置是否正确、服务是否可用。所以我在练题阶段就养成了一个习惯——每完成一个任务，立刻用查询命令验证一遍，而不是“我觉得我配了”。这种习惯后来直接帮我在考场上稳住了心态。
1.3 前置基础：需要具备什么才不劝退
官方对EX280没有强制的前置考试要求，但实际操作中，没有以下几块基础会很吃力。
首先是Linux命令基本功。虽然OpenShift的管理大部分通过oc命令完成，但HTPasswd身份提供程序需要你在终端用htpasswd工具生成密码文件，处理证书需要openssl，排查节点问题时可能要登录节点查看服务状态。这些涉及RHEL基本操作，RHCSA里那一套东西，全都会用上。
其次是容器和Kubernetes的基本概念。至少你得知道Pod、Deployment、Service、Namespace这些词是干嘛的，知道容器镜像怎么运行。如果连“Pod里的两个容器怎么共享网络”都没概念，那EX280对你来说跳跃太大了，建议先去补一些容器入门知识。
最后是oc命令行工具的熟练度。考试里大部分操作在命令行完成，你不用做到oc命令后面每个字段都倒背如流，但常用对象的创建、修改、查看、删除要形成肌肉记忆。考试环境不像平时工作可以随时查文档，越熟练越占便宜。
2. 核心考点拆解：EX280在生产集群里到底考什么
2.1 认证、RBAC与SCC：整场考试的“保命三件套”
如果你时间只够重点复习一个方向，那一定是认证、授权和SCC（Security Context Constraints，安全上下文约束）。这三块在考试题目里的出现频率非常高，而且彼此关联。
认证部分最常考的是配置HTPasswd身份提供程序。流程大概是：先用htpasswd工具创建一个密码文件，再把这个文件放到openshift-config命名空间下的Secret里，最后修改OAuth配置，把HTPasswd加到身份提供程序列表中。步骤不复杂，但每一步都有细节。例如，密码文件里的密钥名称必须是htpasswd，否则OAuth配置引用会失败；创建Secret时namespace必须是openshift-config；修改OAuth后需要等认证相关组件重载完成，而不是立刻登录。
授权部分考的是RBAC操作。要分清Role和ClusterRole、RoleBinding和ClusterRoleBinding的区别。Role作用在特定命名空间，ClusterRole作用在整个集群。题目常见形式是“给某个用户在某项目中授予特定资源的访问权限”“给某个ServiceAccount在集群范围内授予查看权限”。命令本身不复杂，oc create role、oc create rolebinding、oc adm policy add-cluster-role-to-user这几条背熟基本就能覆盖。
SCC则是OpenShift里非常容易混淆的一块。SCC是用来约束Pod运行时权限的，比如允许以root运行时、允许使用特权容器、允许挂载宿主目录等。考试常见题目是“某个Deployment使用了一个需要root运行的镜像，请调整SCC配置让它能正常启动”。解题思路通常是先看Pod卡在什么状态，再用oc describe确认被哪个SCC拒绝，最后给对应的ServiceAccount授予合适的SCC。这里要特别注意，SCC授予的对象是ServiceAccount或用户/组，不是Deployment本身，用-z参数指定ServiceAccount是最快捷的写法。
2.2 应用交付链路：new-app、Service、Route与伸缩回滚
EX280对应用管理的考查，核心是一条完整的交付链路：从一个镜像创建一个应用，把它暴露为Service，再通过Route提供外部访问，最后能调整副本数、完成升级和回滚。
创建应用我习惯用oc new-app，它会根据镜像或镜像流自动生成DeploymentConfig、Service等对象。如果你只想创建不带Build的纯部署，也可以用oc create deployment，但要注意考试环境对DeploymentConfig的偏爱——OpenShift的很多自动触发机制，比如镜像变化触发滚动更新，是挂在DeploymentConfig上的。
暴露服务用oc expose service，创建Route之后要注意检查Termination策略。考试题可能要求你创建一个“edge”类型的TLS终止路由，或“reencrypt”类型，甚至“passthrough”类型。这个不难，但很容易忽略题干里“必须使用TLS”这种条件。创建完Route后，最好用oc get route确认host和service指向正确。
伸缩与回滚也很高频。手动伸缩是oc scale dc，自动伸缩用oc autoscale创建HorizontalPodAutoscaler。回滚是oc rollout undo。我在练习时反复强调自己：每次伸缩后都要用oc get pods确认副本真的起来了，而不是看到命令返回成功就完事。因为镜像拉取失败、SCC拒绝这类问题，通常在Pod创建阶段才暴露。
2.3 存储与网络策略：从“能跑”到“可靠跑”
存储部分的核心是PersistentVolumeClaim和StorageClass。考试里一般不会让你手工创建PV，而是让你从已有的多个StorageClass里选一个合适的，创建一个PVC，再把这个PVC挂载到某个应用上。这里有几个特别容易翻车的细节：一是PVC的storageClassName字段必须和集群里实际存在的StorageClass名称完全一致；二是容量单位必须写对，不能把1Gi写成1GB；三是accessModes必须匹配存储后端实际支持的模式，比如有些后端只支持ReadWriteOnce，你写了个ReadWriteMany就会一直Pending。
网络策略部分主要考NetworkPolicy。OpenShift默认的网络策略是允许所有流量，但一旦某个命名空间里存在NetworkPolicy，规则就会生效。考试常见场景是“只允许来自某个命名空间的访问”“只允许带指定标签的Pod访问”。这块前几年考得相对少，但新版考试里比重明显上升。写NetworkPolicy的时候，核心是podSelector和ingress.from的组合。要注意Namespace级别的选择器用namespaceSelector，Pod级别的用podSelector，两个都写就是“且”的关系。
2.4 监控、审计与节点维护：生产集群的“下半场”
很多人备考EX280时把注意力全放在应用和存储上，忽略了监控、审计和节点管理，这是很吃亏的。因为真正区分“懂OpenShift”和“只会配置OpenShift”的，恰恰是这些运维向的内容。
监控方面，要会用oc get clusteroperators检查核心Operator状态，会通过Web控制台的Observe页面查看告警，也可能会要求你查看某个命名空间的告警路由是否配置正确。新版考试里出现过AlertmanagerConfig相关题目，需要你会创建一个自定义告警路由到某个webhook或接收器。
审计方面，最常见的是开启API Server的审计日志。在OpenShift 4.x里，这通常通过修改API Server集群配置、设置spec.audit.profile为WriteRequestBodies这类预置策略来完成。有些地方会介绍手动挂载审计策略ConfigMap的旧做法，但新版考试建议优先掌握CR的方式，简单直接。
节点管理几乎是必定出现的：oc adm cordon停止节点调度、oc adm drain驱逐节点上的Pod、oc adm uncordon恢复调度。考试可能会给你一个虚拟机故障场景，要求你把某个节点上的Pod安全地迁移到其他节点，再让节点进入维护模式。这个流程要多练几遍，尤其drain命令的参数，--ignore-daemonsets和--delete-emptydir-data经常要带上，不带的话驱逐会卡住。
集群升级也是新版EX280的考点之一。至少要熟悉oc get clusterversion查看当前版本，用oc adm upgrade触发升级，用oc get clusteroperators观察升级过程中各组件的状态变化。不用指望在考试里真的完成一次完整的版本升级——时间不够——但你要能判断集群当前是否有待处理的升级状态，以及如何处理升级的阻断条件。
3. 实验环境怎么搭：从CRC单节点到完整三节点
3.1 为什么不能用minikube练EX280
备考EX280最容易被误解的就是用minikube或纯kubectl来练。我见过不少朋友用minikube练了一星期，觉得命令差不多，结果一上考场看到Route、DeploymentConfig、SCC这些OpenShift特有的对象直接懵了。
问题很现实：minikube是Kubernetes的最小发行版，它没有OpenShift的认证插件体系，没有内部镜像仓库，没有Route资源，没有SCC，也没有集群版本升级那一套Operator。而这些恰恰是EX280里几乎一半的考点。所以练这门考试，环境必须是真的OpenShift，不能用“差不多”的东西替代。
3.2 用OpenShift Local（CRC）快速起步
对大多数备考者来说，最现实的第一步是装OpenShift Local。它以前叫CodeReady Containers，现在官方称为Red Hat OpenShift Local，本质是一个单节点OpenShift环境，通过crc命令启动。我当时的笔记本配置是32GB内存、8核CPU，给它分配了14GB内存和6核CPU，跑起来之后还能同时开几个终端窗口敲命令，不算太卡。如果你想用来练习，官方文档建议至少16GB内存和4核CPU，实际用起来建议比这个下限再高一点，否则Web控制台和多个oc命令并行时会明显变慢。
安装流程不复杂：从红帽开发者网站下载crc二进制包，执行crc setup做前置检查，然后crc start启动。首次启动会下载一个比较大的镜像，之后启动就快很多。启动完成后，终端会给出Web控制台地址和admin用户的登录命令，把kubeadmin密码保存好。
CRC能覆盖EX280里相当大的比例：HTPasswd认证配置、RBAC、SCC、Route、DeploymentConfig、NetworkPolicy、PVC动态存储、告警配置，这些在单节点环境里都能练。但我必须提醒，它有三个明显局限。
第一，单节点没有多Worker节点，练不了节点排空、Cordon、跨节点调度这组操作。第二，升级功能很受限，虽然能看clusterversion状态，但真实的生产集群升级路径没法完整演练。第三，内置的存储后端和考试环境未必一致，你在CRC里用某个StorageClass，考试时不一定有对应的。所以CRC适合练“命令习惯”，不适合练“集群运维场景”。
3.3 完整三节点集群的搭建思路
如果你有条件把实验环境搭得更接近生产，强烈建议用虚拟机搭一个完整三节点集群。我自己的方案是：一台宿主机装了KVM，开了四台虚拟机——一台bastion节点做DNS解析和负载均衡，一台master节点，一台worker节点，还有一台临时bootstrap节点，安装完成后bootstrap就功成身退。资源方面，master和worker每台给了8GB内存和4个vCPU，bastion给了2GB内存，宿主机是64GB内存。这套配置算不上宽裕，但跑一个小型OpenShift集群足够。
安装方式上，现在主流是agent-based installer，把安装配置文件准备好之后，用一条安装命令让机器自己完成集群初始化。相比老版的引导式安装，这种方式更适合脚本化反复练习。整个安装过程顺利的话大约一个半小时，装完打个快照，练坏了直接回滚，非常划算。
3.4 三节点安装的三个硬门槛：DNS、负载均衡和证书
三节点安装最大的门槛其实不在OpenShift本身，而在它依赖的基础设施。很多人卡在bootstrap阶段起不来，大概率是DNS或证书有问题。
DNS这一关，关键是把API域名和泛域名解析都配好。比如集群名是ocp，基础域名是lab.example.com，那么api.ocp.lab.example.com要指向API负载均衡地址，*.apps.ocp.lab.example.com要指向应用负载均衡地址。解析不完全或指向错误，安装程序会一直等待某个组件就绪，最后超时失败。
负载均衡这一关，通常用HAProxy或nginx来做。OpenShift的API请求和应用的HTTP流量都要经过负载均衡，你需要定义好后端节点列表和健康检查方式。这块配置不复杂，但如果不熟，反而比OpenShift本身的安装排错更难。
证书这一关，生产环境一般用正规CA证书，实验环境可以用自建CA签发的证书。要注意，openshift-install生成的安装配置文件里，如果是pull secret关联了相关镜像仓库，证书信任关系也要正确处理。如果只是本地实验，最简单是用让安装器在初始化阶段自动生成内部证书的方式，不要人为干预太多，否则很容易出现“能启动但控制台访问的时候证书报错”的情况。
4. 我踩过的五个坑：每一条都是真实翻车记录
4.1 坑一：HTPasswd配置完，没等认证组件收敛就去登录
这是我最开始练习HTPasswd时犯的错。我把Secret建好、OAuth配置改完，立刻执行oc login -u admin -p 密码，结果提示认证失败。当时我第一反应是配置文件写错了，开始反复检查YAML，甚至把OAuth配置删了重建。折腾了十几分钟，最后发现配置本身没错，只是OAuth相关组件还在滚动更新，认证接口暂时没恢复正常。
正确的做法是配置完HTPasswd之后，先观察认证组件状态，用oc get co authentication等待AVAILABLE状态变成True，再尝试登录。如果处于Progressing或Degraded状态，哪怕多等两三分钟，也比误判配置错误强。在考场上，这种误判会消耗非常多时间。
4.2 坑二：RBAC绑定写对了，但namespace写错导致权限落空
RBAC这部分我翻过最无语的跟头：创建了一个Role，给某个用户绑定时命令看起来也没问题，但用户到了目标项目里还是没有任何权限。后来逐行检查才发现，rolebinding创建在了错误的命名空间里。
Role和RoleBinding都有namespace属性。Role本身是namespace级别的，RoleBinding也是namespace级别的，它们都必须在目标项目所在的namespace里创建。如果因为在别的namespace里执行命令，bind确实创建成功了，但绑定的Role所作用的资源范围根本不是目标项目，用户的权限自然为空。所以每条RBAC操作前，先oc project确认当前上下文，再检查要操作的namespace，这个习惯能帮你省下至少一半的排错时间。
4.3 坑三：SCC权限加给了用户，而不是ServiceAccount
SCC这块的坑更隐蔽。题目要求是“让某个Deployment能以root身份运行”，我当时的做法是给跑这个Deployment的用户加了anyuid SCC，结果Pod还是起不来。原因很简单：Deployment里的Pod运行时使用的是ServiceAccount的身份，不是某个人类用户的身份。SCC要和Pod的ServiceAccount匹配，而不是和当前操作者匹配。
正确的命令是给Pod指定的ServiceAccount授权，比如oc adm policy add-scc-to-user anyuid -z default -n myproject。这里的-z表示目标是ServiceAccount。如果你不加-z，后面跟的名字会被当成用户名，权限就加错对象了。平时练习时，每次涉及SCC，先问自己一句：我的Pod用的是哪个ServiceAccount？然后再执行命令。
4.4 坑四：PVC一直Pending，原因在StorageClass选错
有次练习时我创建了一个PVC，oc get pvc一直是Pending。反复看YAML都没发现语法问题，后来检查集群里已有的StorageClass，才发现题目场景里的默认StorageClass是另一个名字，而我在PVC里写死的storageClassName根本没有对应的后端供给者。
PVC一直Pending，通常就是三个原因：storageClassName写错、accessModes不匹配、容量请求超出后端剩余空间。考试环境里一般会预置多个StorageClass，有的可能没有动态供给能力，有的回收策略是Delete。操作之前，先oc get storageclass把所有StorageClass看清楚，再决定用哪个。不要凭记忆写名字，集群环境里名字不是你说了算的。
4.5 坑五：只验证了“配置写入”，没验证“业务可用”
这个坑贯穿整个备考过程。我给某个应用创建了Route，oc get route能查到记录，觉得很稳；给某个ServiceAccount授了SCC，oc get scc能查到，也觉得很稳。但真正的问题往往藏在最后一步：Route的后端Service是否选对了？Pod挂载PVC之后能不能正常读写？NetworkPolicy放行之后，对端是否真的能访问？
后来我给自己定了一条铁律：每个配置任务完成之后，至少做一次业务层面的验证。创建Route就去curl一下地址，网络策略改完就从一个测试Pod发起访问，PVC挂载完就看Pod日志。这条习惯在考试里非常有用，因为红帽评分很大程度上看最终状态是否满足要求，业务是否可访问，而不是看你是不是用了某个标准命令。
5. 考前两周的训练节奏与考试当天的操作习惯
5.1 两周时间怎么分阶段
如果备考时间只有两周，我会把它拆成两个阶段。第一周按官方考试目标清单逐项过，每天保证两到三小时的动手时间。不求速度快，但每个对象都要亲手创建、修改、删除、验证一遍。第二周进入综合练习模式，每天给自己出一套完整的综合任务，要求在一个小时内完成。
综合任务的设计思路要贴近考试组合。我常用的自拟题目是：创建两个新用户、分别授予不同项目的只读权限、让其中一个用户通过HTPasswd登录成功、在指定项目里用某个镜像部署一个应用、为它配置动态存储、创建Route并设置TLS终止、再给这个项目加一层NetworkPolicy只允许特定来源访问、最后开启或验证API Server审计日志。这一套流程如果能稳定在45分钟到60分钟内完成且业务可访问，考试多数题目做起来就不会慌。
5.2 二十条自测任务清单
这套清单是浓缩了考试核心操作的自测表，我备考时每次完整做一遍，做完核对状态，一个都不能少。
- 用htpasswd创建用户密码文件，并放入openshift-config命名空间的Secret
- 修改OAuth配置，添加HTPasswd身份提供程序
- 等待认证组件收敛后，用新用户登录
- 给指定用户授予cluster-admin角色
- 在指定项目创建Role，赋予Pod的get、list、watch权限
- 创建RoleBinding，绑定到指定用户
- 给指定ServiceAccount授予anyuid SCC权限
- 创建一个DeploymentConfig，副本数为2
- 创建一个Service，并验证Endpoints里有Pod的IP
- 创建一个edge类型的Route，绑定上述Service
- 执行一次水平自动伸缩配置，目标CPU使用率80%，副本范围1到5
- 对DeploymentConfig执行一次回滚操作
- 查看默认StorageClass列表，并选择一个创建PVC
- 将PVC挂载到DeploymentConfig并确认Pod能读写
- 在指定项目创建NetworkPolicy，只允许某个标签的Pod访问
- 验证被拒绝和放行的流量情况
- 给某个节点执行cordon和drain操作
- 排空后执行uncordon恢复调度
- 查看clusteroperators状态，确认关键组件正常
- 查看当前集群版本和可用更新
不要小看这张清单，它能覆盖绝大多数高频考点。每完成一项，用oc get、oc describe或实际访问验证结果，不要只看命令是否执行成功。
5.3 考试当天的现场流程
考试当天，我的建议是不要上来就做题。先花十到十五分钟把环境摸清楚。
第一，确认当前所在的工作站主机名和集群名称。答题环境可能包含多个集群，如果题干要求操作的是“集群A”，你却在“集群B”上操作，前面所有命令都白做。第二步，用oc whoami和oc project确认当前身份和上下文，避免在错误的命名空间里操作。第三步，快速执行一遍oc get nodes和oc get clusteroperators，了解集群当前健康度，也顺手验证oc命令是否正常工作。
做题顺序上，我习惯先做自己有把握的题目，不确定的先跳过。红帽考试是按最终状态评分，不会因为题目顺序扣分。把会的做扎实，回头再来啃不确定的，心理压力会小很多。
另外，考试过程中Web控制台和命令行可能同时可用，有的题目明确要求“使用Web控制台完成”，这时候别偷懒只用命令行。至少要知道如何在控制台里切换项目、查看告警和检查工作负载，这和命令行操作一样属于基础能力。
6. 备考资料与信息源：少走弯路的三个原则
6.1 官方考试目标清单是唯一锚点
红帽官方会在考试页面上公布一份考试目标清单，英文叫Exam Objectives。这份文档才是真正的考纲。网上任何培训机构的课程大纲、任何博客的考点总结，都是从这份文档延伸出来的。我的建议是备考第一天就把附件下载下来，逐条对照自己的能力，标出熟悉的、模糊的和完全不会的，后续复习唯一要做的就是把标注为模糊和不会的部分逐个消灭。
6.2 课程、文档、社区经验怎么组合
有条件的话，官方培训课程DO280是最系统的方式，但不是每个人都有预算或时间。纯自学的话，红帽在线文档是优先级最高的，尤其是OpenShift的Authentication、RBAC、Storage、Networking几个章节，基本是考试题目的直接出处。社区方面，中文技术社区和博客有很多备考经验贴，可以参考别人的踩坑记录，但要注意时效性——OpenShift 4.x的版本更新很快，两三年前的配置方式放到现在可能已经被新的API替代。看到命令时先看一眼文档里的版本号，别盲目照抄。
6.3 关于题库与“包过”信息的清醒认识
市面上流传的一些EX280题目和“包过”渠道，我的态度是：可以当练习题看看，但不能当成备考依赖。因为红帽实操考试的题目场景每次都会变化，评分基于集群最终状态，哪怕你把题目背得滚瓜烂熟，遇到环境里的实际差异时照样无从下手。我备考时也临时看过一些回忆版题目，对里面的知识点做了查漏补缺，但真正让我在考试里稳住的，是三周来一遍遍亲手操作积累出的判断力。
考完EX280之后，我再回头看生产环境里那些看起来复杂的OpenShift组件，心里踏实了不少。之前遇到集群告警只会到处截图问人，现在能顺着Operator状态、日志和事件一步步定位问题。这门考试给我最大的收获，其实不是那张RHCA证书上的一个通过记录，而是把“OpenShift是一个能自愈的黑盒”这个模糊印象，替换成了一层一层清晰可检查的结构。如果你也在备考EX280，记住一件事：这门考试不考灵感，只考手上功夫。练得越多，考场上的意外就越少。
