RHCA这条路走到EX280这一步才算真正摸到了企业级容器平台的边。EX280全称Red Hat OpenShift Administration考试编号里那个EX很直白——它是红帽实操考试没有一道选择题全程对着真实OpenShift集群干活。我写这个系列不是把官方大纲抄一遍而是想以一个考过、也带过团队的人的身份把考试背后的“为什么”和“坑在哪里”尽量讲透。在RHCA的认证版图里EX280对应的课程是DO280主要考核OpenShift集群上的项目管理、用户与权限、镜像与构建、应用部署、网络路由、存储接入、集群维护与监控。一句话评价它的价值RHCE证明你能管好一台机器EX280证明你能管好一个平台。这篇文章适合两类人一类是已经拿到RHCE准备把技能栈往云原生方向转的工程师另一类是平时在K8s里摸爬滚打、想用红帽体系的题目来检验自己系统掌握OpenShift到不到位的人。1. 先拆清楚EX280的考试盘子形式、范围和底层逻辑1.1 真实的考试环境长什么样先说大家最关心的考试环境。EX280总共3小时满分300分210分算通过。整个考试没有填空题没有选择题你在屏幕上看到的不是问卷而是一个倒计时、一串任务描述以及一两个真实的OpenShift集群环境。红帽这类实操考试的界面一般是这样左边是题目列表右边是终端和浏览器。你需要在终端里通过oc命令行完成操作或者在浏览器里打开OpenShift控制台做点配置。真正的战场是一套已经预置好的集群里面有多个项目、多个用户甚至多个集群环境让你切换。这句话值得反复读三遍EX280会给你多个上下文而不是一套环境考到底。比如第三题明确说“在clusterA上完成”你却跑到clusterB里把资源全建好了结果就是零分。很多人第一次考挂不是不会做是没看当前context。考试过程允许打开红帽官方文档但不允许访问外网。这个限制对心态的影响很大——你不需要背下所有YAML字段但要能快速在文档里找到正确示例。平时练习时我就养成了一个习惯遇到不确定的参数先查文档再动手而不是硬记。评分机制也是典型的“状态评分”。题目要求“orders项目里运行3个order-service副本并且能通过普通域名访问”判分器就去检查项目里是不是真有3个Running的Pod、Service和Route是否存在、路由能否返回200。它不看你怎么敲的命令只看最终状态。这意味着做完题目之后的验证环节比操作本身更值钱。1.2 官方考试目标拆解红帽官方给出的考试目标可以归纳成几个主题域我根据自己的考试经验和带人经历把出现频率标了一下。这个频率不是官方的但很贴近真实考卷主题域具体考点出现频率项目和资源管理创建项目、配置配额、LimitRange很高用户权限和安全RBAC角色绑定、ServiceAccount、OAuth身份提供方很高镜像与构建ImageStream、BuildConfig、S2I构建、构建触发很高应用部署Deployment、DeploymentConfig、HPA、环境变量很高网络接入Service、Route、TLS策略、NetworkPolicy高存储接入PV、PVC、StorageClass、动态供给高集群运维节点维护、Operator状态、集群升级、监控日志中另外一个特点是很多题目不是单一考点的一道题能同时串起存储、部署和网络。比如“给order应用挂一块持久化存储副本数2用Route暴露”这一条看起来是部署题实际上PVC、Deployment、Service、Route全都考了。所以备考不能按知识点孤立练要练习“一条龙”操作。1.3 为什么RHCA路上必须认真啃EX280技术层面很好理解企业内部只要用红帽生态几乎绕不开OpenShift。OpenShift不是单纯的K8s发行版它有自己的一整套抽象——Project、ImageStream、BuildConfig、Route、DeploymentConfig、SCC。这些概念在原生Kubernetes里没有对应的对象而企业里真实运维天天都在碰它们。从认证体系看RHCA是红帽整个认证体系的天花板而EX280是其中和现代化应用平台关系最直接的一门。它不像EX380那样偏自动化也不像EX342那样偏故障诊断它就是一个“管理真实容器平台”的考试。想继续学自动化你也要先搞清楚自动化操作的对象长什么样想继续学诊断你也得先知道一个健康集群应该是什么状态。所以我个人建议如果还没考RHCA把EX280放在靠前的位置来考性价比最高。还有一点常常被忽略EX280考的不是“命令行背得多熟”而是“能不能把系统调到预期状态”。这种声明式思维是云原生时代的核心技能从OpenShift迁移到其他K8s发行版一样吃得开。这也就是我说“RHCE证明你能管好一台机器EX280证明你能管好一个平台”的原因。2. 高频考点上项目权限、镜像构建的操作细节2.1 项目与配额新环境下的第一道“准入控制”OpenShift里的Project其实就是一个带额外注释和权限管理的Namespace。创建项目最简单的方式是oc new-project orders进去之后第一件事通常不是建应用而是确认资源边界。考试里经常要求你为项目设置配额然后让某用户的Pod不能超过这个额度。配额命令很有代表性oc create quota app-quota --hardcpu2,memory4Gi,pods6 -n orders等于告诉集群这个项目最多只能用2个CPU、4Gi内存、跑6个Pod。这里有个关键认知配额是项目级别的大盘子而LimitRange是单个Pod或容器的红绿灯。考试经常把这两个混在一起考。LimitRange的典型例子apiVersion: v1 kind: LimitRange metadata: name: dev-limits namespace: orders spec: limits: - max: cpu: 2 memory: 2Gi min: cpu: 100m memory: 128Mi default: cpu: 500m memory: 512Mi defaultRequest: cpu: 200m memory: 256Mi type: Container一个很容易踩的坑是如果你先创建了Quota再创建没有写resources.requests和resources.limits的Pod调度器可能直接拒绝这个Pod。LimitRange的作用就是在这种情况下自动补上默认值所以先建LimitRange再建工作负载更稳妥。验证配额是否生效不要用眼睛猜用命令oc get quota -n orders oc describe quota app-quota -n orders看Used列有没有涨。这也是考场上判分器看的东西。2.2 用户、权限和ServiceAccountRBAC不只是记角色名EX280对权限的要求远不是“记住view、edit、admin三个角色”这么简单。它要求你搞清楚“给谁授权”和“在哪里授权”。给普通用户授权oc adm policy add-role-to-user view devuser -n orders新版推荐用更标准的方式oc create rolebinding dev-view --roleview --userdevuser -n orders如果题目要求给ServiceAccount授权很多人就懵了。ServiceAccount是Pod用来访问API的对象不是人。比如构建流水线经常要用一个叫pipeline的SA来操作项目资源oc create sa pipeline -n orders oc adm policy add-role-to-user edit -z pipeline -n orders这里的-z参数表示在-n指定的项目内给这个ServiceAccount授权操作对象是“项目内的服务账户”而不是openShift里的某个用户。这是OpenShift特有的一种快捷授权方式考试中很爱考。再多说一个高频考点HTPasswd身份提供方。如果考试里要求配置本地用户认证套路基本是三步。第一步用htpasswd生成密码文件htpasswd -c -B -b /tmp/users.htpasswd devuser redhat第二步把文件放进Secretoc create secret generic htpass-secret --from-filehtpasswd/tmp/users.htpasswd -n openshift-config第三步把OAuth配置打补丁oc patch oauth cluster --typemerge -p {spec:{identityProviders:[{name:htpasswd-provider,mappingMethod:claim,type:HTPasswd,htpasswd:{fileData:{name:htpass-secret}}}]}}这段配置不复杂但很多人栽在第二步和第三步的Secret名称、namespace对不上。我给的经验是敲完oc patch之后立刻用oc get oauth cluster -o yaml看一眼identityProviders段确认配置已经写入。2.3 ImageStream与BuildConfig明白“镜像流”是有状态的元数据ImageStream是OpenShift区别于原生Kubernetes最明显的点。它可以理解成“镜像的智能指针”——它自己不存镜像只是追踪镜像仓库里某个Tag的更新。上游镜像Tag发生变化时ImageStream能感知到并触发下游的部署或构建流程。这个机制是OpenShift内置“CI/CD”能力的基础。构建动作由BuildConfig定义。考试常考的是从已有源码构建镜像并启动应用。典型的二进制构建流程如下oc new-build --nameorder-build --imageregistry.ocp4.example.com:5000/openshift/openjdk-11 --binarytrue oc start-build order-build --from-dir./src --follow--binarytrue表示我们不从外部Git仓库拉代码而是把本地目录打包上传给构建器。构建完成后镜像会被推送到OpenShift内部镜像仓库并以ImageStreamTag的形式存在。你查看对象时要区分oc get imagestream oc get build oc logs build/order-build-1构建触发器是另一个常见考点。题目经常要求“当开发更新代码后自动触发新构建并自动更新部署”。这通常靠ImageChange触发器实现也就是ImageStreamTag变化后由DeploymentConfig自动创建新版本。这也是为什么我会提醒如果题目里明确出现了“image change触发”那大概率需要用DeploymentConfig而不是普通Deployment。3. 高频考点下部署、网络、存储和集群运维的实操要点3.1 Deployment与DeploymentConfig别把单词看错题目里如果写的是“Deployment”那就建apps/v1的Deployment如果写的是“DeploymentConfig”就建apps.openshift.io/v1的DeploymentConfig。单词看错整个题目的对象类型就错了后面部署得再漂亮也偏题。两者的对比可以记这张表对比项DeploymentDeploymentConfig控制器Kubernetes原生ReplicaSetOpenShift原生ReplicationController滚动更新支持支持自动回滚有限支持更完整的自动回滚ImageChange触发器不支持支持生命周期钩子不支持支持常用于标准K8s工作负载OpenShift的S2I和CI/CD场景创建Deployment的命令oc create deployment order --imageregistry.ocp4.example.com:5000/orders/order-service:latest --replicas3 oc rollout status deployment/order基于CPU使用率做弹性伸缩oc autoscale deployment/order --min1 --max5 --cpu-percent60如果考试要求看滚动更新是否完成oc rollout status是最直接的。3.2 Service、Route与TLS从“内部可达”到“外部可访问”Service的作用是给一组Pod提供稳定的访问入口但它是集群内部的。想要外部访问OpenShift里靠Route。Route是OpenShift的Ingress实现但比原生K8s的Ingress更顺手。创建Service和Routeoc create service clusterip order-svc --tcp8080:8080 -n orders oc create route edge order-route --serviceorder-svc --port8080 -n ordersTLS策略是路由题里的常客三种模式本质区别要看清楚模式客户端到路由路由到后端Pod证书位置edgeHTTPSHTTP明文路由侧reencryptHTTPSHTTPS再次加密路由侧和后端侧passthroughHTTPSHTTPS透明透传后端Pod自己持有考试里经常要求把HTTP请求自动跳转到HTTPS创建Route时加一个参数oc create route edge order-route --serviceorder-svc --port8080 --insecure-policyRedirect -n orders验证路由是否通的命令可以一步到位curl -kI https://$(oc get route order-route -n orders -o jsonpath{.spec.host})一个容易忽略的坑是Service和Pod之间的selector不匹配。Service选不中Pod路由自然503或502你查半天Route配置却忘了查oc get endpoints这是新手翻车的第一名。3.3 网络策略从“全互通”到“最小权限”OpenShift默认的SDN策略下项目之间是可以互通的至少很多考试场景里不会主动拦截。但考试经常要求你“只允许某个项目或某类标签的Pod访问”。NetworkPolicy这时就派上用场。例如只允许appfrontend的Pod访问appweb的PodapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend-to-web spec: podSelector: matchLabels: app: web policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: frontend这里有两个易错点。第一podSelector默认选择的是当前命名空间内的Pod如果你要跨项目放行需要改用namespaceSelector。第二policyTypes字段如果写了Ingress和Egress那么没有列出的规则都会被禁止。写策略之前想清楚默认行为是什么再决定要不要显式声明Egress。跨项目精确放行时考场上最稳妥的做法是先看目标项目有什么标签oc get ns openshift-ingress --show-labels然后把namespaceSelector的matchLabels按实际标签填进去。3.4 集群运维节点维护、Operator状态与升级节点维护几乎是必考内容。核心流程是先把节点标记为不可调度再排空存量Podoc adm cordon node01 oc adm drain node01 --ignore-daemonsets --delete-emptydir-data oc adm uncordon node01--ignore-daemonsets是必须的因为DaemonSet的Pod不会被驱离--delete-emptydir-data用来处理使用emptyDir的Pod不加这个参数drain会在那里卡住不动。恢复节点时重新uncordon让调度器重新允许Pod调度过来。集群健康检查主要看ClusterOperatoroc get clusteroperator重点是AVAILABLE和PROGRESSING两列。如果某些Operator一直是AvailableFalse大概率考试题目会要求你查看那个Operator对应命名空间的Pod日志并修复问题。集群升级相关的检查分两步。先确认当前版本和可用版本oc adm upgrade新版本OpenShift里也可以直接指定目标版本升级oc adm upgrade --to4.14.x升级前建议看一眼MachineConfigPool是否处于Updated状态因为升级过程中节点会逐个重启oc get machineconfigpools这些命令不需要背到滚瓜烂熟但看到题目里“升级集群到指定版本”“维护节点”“查看Operator异常”这些字眼时要第一时间反应出对应的命令长什么样。4. 模拟一条完整任务链从建项目到暴露应用的实操实录4.1 场景设计与环境准备把知识点串起来才是最有效的备考方式。我设计了一个典型场景基本是把EX280的常见考点揉进一条任务链里给开发团队准备一个订单服务环境。要求创建orders项目该项目最多使用2个CPU、4Gi内存应用使用内部镜像仓库的镜像部署副本2个挂一块1Gi的持久化存储通过order.apps.ocp4.example.com域名安全暴露只允许来自openshift-ingress项目的流量访问业务Pod。考试开始后先做环境检查这是老手和菜鸟的分水岭oc whoami --show-context oc project oc get nodes oc get storageclass确认当前在哪个集群、哪个项目、仓库地址和存储类分别是什么。很多时候题目已经建好了项目你直接复用就行没必要重复创建。4.2 任务链拆解配额 - 存储 - 部署 - 网络 - 路由第一步创建项目和配额。如果项目已存在只创建配额oc create quota app-quota --hardcpu2,memory4Gi,pods6 -n orders第二步创建PVC申请1Gi存储。这里必须根据环境里的StorageClass填写storageClassName名字可以通过上一步的oc get storageclass确认apiVersion: v1 kind: PersistentVolumeClaim metadata: name: order-data namespace: orders spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi storageClassName: nfs-storage创建后立刻检查状态oc get pvc order-data -n ordersBound说明绑定成功Pending说明存储类或容量有问题。第三步创建Deployment。由于要挂PVC直接写YAML比拼命令更清晰apiVersion: apps/v1 kind: Deployment metadata: name: order-service namespace: orders spec: replicas: 2 selector: matchLabels: app: order template: metadata: labels: app: order spec: containers: - name: order image: default-route-openshift-image-registry.apps.ocp4.example.com/orders/order-service:latest ports: - containerPort: 8080 volumeMounts: - name: data mountPath: /var/lib/order volumes: - name: data persistentVolumeClaim: claimName: order-dataoc apply -f deployment.yaml之后使用oc rollout status deployment/order-service等待Pod进入Running。这里我不建议用oc create deployment因为后续挂PVC还要改YAML一步到位更省事。第四步创建Service和Routeoc create service clusterip order-svc --tcp8080:8080 -n orders oc create route edge order-route --serviceorder-svc --port8080 --insecure-policyRedirect -n orders第五步创建NetworkPolicy。目标只放行openshift-ingress项目oc get ns openshift-ingress --show-labels查完实际标签后写成apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-ingress-router namespace: orders spec: podSelector: matchLabels: app: order policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-ingress这种动态用oc get ns --show-labels查标签再写策略的方式是我在真实考试里比较推荐的做法——不用背标签跟着环境走。4.3 做完之后的自我验证任务完成后不要只盯着屏幕发呆按顺序执行一遍验证oc get deploy,pods,pvc,svc,route -n orders curl -kI https://order.apps.ocp4.example.com oc describe quota app-quota -n orders如果curl返回200或301说明Deployment、Service、Route和NetworkPolicy全都正常。如果返回503优先看Service的Endpointsoc get endpoints order-svc -n orders只有Endpoints里有Pod IP流量才会被代理这个细节帮我省过好几次返工。5. 考场实战中的常见翻车点与排查方法5.1 常见问题速查表考试现场容易出现的状况其实很有限绝大多数都可以用一张表覆盖。现象常见原因排查命令 / 解决Pod一直PendingPVC未绑定、配额不够、节点资源不足oc describe podoc get pvcoc apply报错YAML缩进错误、apiVersion不对oc explain deployment.spec路由访问502Service的selector没匹配上Podoc get endpoints绑定了角色还没权限授权给了用户而不是SAoc get rolebinding -n 项目构建日志报错镜像地址写错、源目录不存在oc logs build/构建名drain卡住有本地存储Pod或DaemonSet加--delete-emptydir-data和--ignore-daemonsets提示未登录切换到了错误集群上下文oc whoami --show-context看到一个现象别急着删资源重建先读Events。oc describe输出里的Events才是真正的线索来源删了重建往往会把原有的绑定关系也拆掉。5.2 时间管理和做题顺序3个小时看起来很长但EX280的题目量不小每道题还要留出验证时间。我的习惯是开考后前10分钟不做题把所有题目扫一遍在草稿纸上给每道题打个难度标记限时15分钟超过就先放下做下一题最后再回头补。做题顺序上先做熟悉度最高、操作步骤最短的题比如创建项目加配额这种能在前半小时攒起分数和心态。最后留30分钟做全面验证——把每个项目里的重点资源都过一遍。红帽考试不讲究“快速提交”提前交卷不会加分但少验证一道题可能丢十分。5.3 备考工具箱少走弯路的资源和练习方法教材首选官方DO280课程和红帽在线文档。视频教程可以看但不能只看不练。个人实验环境用OpenShift Local也就是CRC就够了电脑至少8核CPU和16GB内存。虽然启动起来比较吃资源但练EX280这套东西绰绰有余。备考的最后阶段我建议把考试目标当成每日清单每天挑一个主题域先在文档里找到对应章节然后在本地环境把每个操作完整做一遍。练习时不要开着官方示例直接复制最好是自己先写错了再对照文档。这里的区别在于考场上没有现成答案肌肉记忆和纠错能力才是真正能带进考场的。结尾再说一点个人体会。我第一次考EX280没过不是知识点不会而是太紧张把一道题里的项目名看成了namespace名结果资源建到了别的地方。从那之后我养成一个很机械的习惯动手前先oc project确认当前项目任何一道题都说一句“我现在在哪”。这个方法听起来很笨但考场上真的救命。如果你也准备走RHCA我的建议是先放下“到底考多少分”的焦虑把每个考点练到闭着眼能输出正确状态。EX280这道关过了你对OpenShift的理解会有一个明显提升后面学自动化、学诊断都会顺很多。祝你一次通过。