前几年我们团队做混合云改造的时候面对的第一件事不是选哪个云厂商而是先回答一个看似简单的问题多个云平台、多套Kubernetes集群到底由谁来统一管当时手上有自建机房、有公有云资源开发团队交付应用的环境五花八门To B客户对部署环境的要求又各有差异。折腾一圈下来最终选定的底座就是今天的主题在 RHEL 8 上部署 Red Hat OpenShift用它作为混合云部署的统一控制面。这篇文章就把整个落地过程、选型逻辑和实际运维中踩过的坑写出来希望能给正在做多云架构管理方案的同学一些直接可用的参考。1. 为什么选择 RHEL 8 OpenShift 作为混合云的统一控制面1.1 混合云的真实痛点不是资源不够是管理成本失控先说说我看到的普遍情况。很多企业做多云第一动机是避免被单一云厂商绑定顺便利用不同云的差异化优惠。但真正跑起来之后发现多云的复杂度远超预期。资源层面还好说最头疼的是管理层面每个云平台一套账号体系每套Kubernetes集群一套监控告警每套环境的应用发布流程都不一样。开发团队要在三四个平台之间来回切换配置运维团队要在半夜爬起来处理不同集群的告警安全团队根本没法对分散的资源做统一合规审计。这种情况下多云架构听起来很美实际执行却变成了一场管理灾难。我当时调研过几种路线一种是直接在多个云上分别部署社区版Kubernetes然后自建一套管理平台去纳管另一种是采用企业级发行版把底层平台能力统一起来。仔细对比之后我们更倾向后者因为自建管理平台的开发和维护成本其实非常高昂而且稳定性很难保证。OpenShift正好落在这个位置上。1.2 为什么是 RHEL 8 作为操作系统底座OpenShift本身可以跑在多种操作系统上但我们最终选择 RHEL 8一个主要原因是认证和兼容性。Red Hat对OpenShift在RHEL 8上的支持是非常明确的从操作系统内核参数、容器运行时依赖到cgroups v2的适配都有一套经过验证的组合。相比让OpenShift跑在通用Linux发行版上RHEL 8作为底座能把很多底层的玄学问题提前消解掉。RHEL 8本身的生命周期也很重要。我们的生产环境不希望每两三年就做一次大的操作系统升级RHEL 8提供的是长达十年的维护周期这对企业IT来说是相当关键的决策因素。再加上RHEL 8内置的SELinux策略和OpenShift之间有深度集成安全层面开箱即用不用我们在每台机器上手动调一堆安全配置。在混合云场景下各个节点的操作系统行为一致性会直接影响上层调度和故障排查RHEL 8在这里承担的就是一个标准底座的角色。1.3 控制面设计思路以OpenShift为中心向上屏蔽云差异我们最终确定的核心架构思路是在每个物理位置自建机房、云厂商A、云厂商B分别部署一套OpenShift集群然后在所有集群之上再构建一个统一管理平面。这个管理平面不是重新发明一套调度系统而是利用OpenShift自身的管理API、策略引擎和交付链路把各个集群的差异屏蔽在平台层之下。对开发团队他们面对的是统一的OpenShift控制台、统一的项目Namespace申请流程、统一的应用发布管道。对运维团队看到的是统一的多集群列表统一的告警聚合入口统一的日志检索方式。对安全团队策略可以一次性下发到所有集群合规基线集中配置。这种设计的核心价值在于OpenShift不只是一个容器平台它本身就是一个非常完整的多集群管理框架。真正把OpenShift用到位之后上层应用不需要关心自己跑在哪个云的哪台机器上底层资源的差异由平台层消化。这个理念贯穿了我们整个部署和后续运维的全程。2. 部署前最容易忽略的环境设计细节2.1 版本选型与订阅先定版本再谈安装OpenShift的版本节奏大概每四个月一个大版本每个版本都有对应的支持周期。我们在规划RHEL 8部署方案时建议优先选择当时处于活跃支持期的版本不要追太新的版本更不要用已经接近维护尾期的版本。比如说当时的主流选择是OpenShift 4.12和4.14我们就以4.14为目标版本因为它对应的RHEL 8版本组合、功能特性和已知问题列表都比较清晰。另一个容易踩的坑是订阅和授权问题。Red Hat的订阅模型分为基础节点订阅和额外组件订阅OpenShift集群的节点订阅必须覆盖所有控制平面节点和工作节点。有些团队喜欢把管理组件也塞进集群节点里跑这本身没问题但要注意这些节点的订阅类型必须匹配。我们在实际规划中会把每个节点的角色、订阅SKU、预期用途列在一张表里提前和供应商确认清楚避免安装到一半发现授权不足。节点角色建议配置订阅需求主要用途Bootstrap临时4C/16G临时订阅即可完成集群初始化后销毁Control Plane8C/16G起OpenShift节点订阅运行API Server、etcd、调度器等Worker通用8C/32G起OpenShift节点订阅运行业务应用Worker基础设施4C/16G起OpenShift节点订阅运行监控、日志、Ingress等平台组件2.2 网络规划DNS和负载均衡是集群的隐形命脉OpenShift集群对网络的要求非常细尤其是DNS和负载均衡。很多第一次部署失败的案例最终排查下来都集中在网络规划不严谨上。DNS方面OpenShift集群依赖几个核心域名解析项API Server的域名、.apps的泛解析、etcd节点的域名。我们在自建机房和公有云上都采用的是内部DNS加公网DNS分离的策略。内部节点之间的通信全部走内网DNS外部用户访问应用走.apps的解析。这里有一个非常容易被忽视的细节OpenShift节点的主机名必须能通过DNS互相解析否则etcd集群在初始化阶段就会出现成员发现失败的问题。我们当时在公有云的一个VPC里部署时遇到过节点主机名解析到公网IP的情况导致集群内部流量绕了一大圈延迟飙升还偶发超时。负载均衡方面每个OpenShift集群至少需要两组负载均衡一组对应API Server的6443端口一组对应Ingress Controller的80/443端口。如果是单集群部署前端的负载均衡器可以复用如果是多集群建议每个集群的API负载均衡独立避免不同集群之间互相影响。在公有云上我们用的是云厂商的负载均衡服务在自建机房则用硬件负载均衡。无论哪种都需要提前把健康检查路径配好OpenShift API Server的健康检查路径是/readyzIngress Controller则检查/healthz。2.3 存储设计不同云的不同存储类如何统一抽象混合云场景下存储往往是最让人头疼的一环。每个云厂商都有自己的一套块存储、对象存储和文件存储服务API和性能模型完全不同。OpenShift本身通过StorageClass屏蔽了一部分差异但在部署之前就要想清楚每个集群默认的StorageClass是什么性能档次如何划分。以我们当时的做法为例在公有云集群里我们分别定义了标准SSD、高性能SSD和低频对象存储三类StorageClass在自建机房则对接了已有的分布式存储。OpenShift允许管理员为每个StorageClass设置默认标识应用发布时如果不显式指定存储类就会使用默认的那个。这个设计让应用层无感使用底层存储但如果默认StorageClass没有提前建好很多需要持久化存储的应用会在部署时报错。强烈建议在安装集群之后就立即创建好StorageClass并标记默认而不是等第一个应用报错才去补。3. RHEL 8 上 OpenShift 的安装方式选择与实操记录3.1 三种安装方式什么场景选什么OpenShift在RHEL 8上安装的官方方式有几种交互式安装Installer Provisioned Infrastructure简称IPI、用户提供基础设施User Provisioned Infrastructure简称UPI和Agent-based安装。业界还有一种很常见的做法是使用Red Hat提供的辅助安装工具Assisted Installer。我们实际对比之后的选择逻辑很简单IPI适用于公有云环境比如AWS、Azure、GCP安装器会直接调用云厂商API创建虚拟机、负载均衡器、安全组自动化程度最高。UPI适用于自建机房、VMware vSphere或者裸金属服务器需要我们自己把虚拟机和网络环境准备好安装器只负责把OpenShift集群组件部署上去。辅助安装方式则适合边缘节点、受限网络环境可以在没有完整云API的环境下用一种更简化的方式拉起集群。我们最终采用了混合策略公有云环境用IPI自建机房用UPI边缘站点用辅助安装工具。原因很简单每种环境的基础设施自动化程度不同没必要用一种方式强行套全部场景。3.2 IPI方式在RHEL 8上的实际操作步骤以我们在AWS上的一套OpenShift 4.14集群为例配置流程大致如下。先准备一台跳板机这台机器使用RHEL 8系统安装必要的工具# 在RHEL 8跳板机上安装OpenShift安装工具和命令行工具 subscription-manager repos --enablerhel-8-for-x86_64-appstream-rpms dnf install -y wget git python3 wget https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-install-linux.tar.gz wget https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-client-linux.tar.gz tar xzf openshift-install-linux.tar.gz tar xzf openshift-client-linux.tar.gz mv oc kubectl openshift-install /usr/local/bin/然后创建安装配置文件install-config.yaml这是整个安装过程的核心输入里面要指定云平台凭证、集群名称、基础域名、节点数量和网络类型。这里有一个关键点OpenShift的安装器支持通过SSH公钥注入节点后续排查节点问题的时候可以免密登录所以一定要配置一个有效的公钥否则出了问题只能通过云厂商控制台的VNC去操作效率很低。安装配置文件准备好之后需要将文件放在一个独立的目录中然后执行安装命令mkdir ~/cluster-config cp install-config.yaml ~/cluster-config/ cd ~/cluster-config openshift-install create cluster --dir. --log-levelinfo安装器会读取配置文件自动在云平台上创建资源整个过程大概在30到45分钟。安装完成后确认一下集群状态看所有节点是否Ready集群算子是否都可用OpenShift控制台是否正常响应。这里给大家一个我常用的验证清单oc get nodes显示全部节点为Ready状态oc get co所有可用Available状态都为Trueoc get clusterversion显示版本为预期版本且没有Failing状态通过oc login能正常登录集群token认证正常3.3 UPI方式在自建机房RHEL 8上的准备重点自建机房的UPI安装比公有云要麻烦一些核心在于所有基础设施都需要提前准备好。我们需要准备三台控制平面节点和若干工作节点全部安装RHEL 8系统并确保这些节点满足OpenShift的硬件和内核参数要求。RHEL 8节点准备的核心操作是配置好存储和防火墙。OpenShift要求节点使用支持overlayfs的文件系统我们在安装RHEL 8时直接把根分区设置为xfs预留足够空间给容器镜像和持久化数据。防火墙方面需要放通集群内部通信的端口范围分别是kubernetes API Server的6443端口、etcd的2379-2380端口、节点间的VXLAN端口4789以及Ingress的80/443端口。如果内网还有额外的安全策略提前把所有节点的端口放行规则统一对齐。网络配置上UPI方式会用到Ignition文件进行节点引导。先在跳板机上生成Ignition文件然后通过HTTP服务器把Ignition文件分发到各节点。RHEL 8节点的网络启动阶段需要能够访问到这个HTTP服务器否则节点无法获取到初始化配置。我们当时在隔离网络环境里部署还在HTTP服务器上做了IP白名单限制确保只有规划内的节点能访问。整个UPI安装过程中有一个非常容易出错的地方是OpenShift节点的Hostname必须与证书中的名称一致。我们在初始化RHEL 8节点时就通过hostnamectl命令把主机名设置成规划好的名称并且确保该名称能通过内网DNS正确解析。如果主机名和证书不匹配安装过程中会出现TLS握手失败排查起来非常浪费时间。4. 多云架构下管理效率提升的配套组件落地4.1 多集群统一管理不可跳过的 ACMOpenShift单集群部署完成只是第一步真正体现多云架构优势的是多集群统一管理。Red Hat对应的组件是Advanced Cluster Management简称ACM。ACM可以做这样几件事多集群的可见性列表、统一的策略下发、集群的批量创建与生命周期管理和跨集群的应用部署。我们使用ACM之后最大的感受是一个页面看所有集群带来的效率提升。以前要登录五六套平台才能看到的集群状态、节点资源水位、告警数量现在全部汇总到一个控制台里。更重要的是策略下发安全团队可以定义一套合规基线比如所有集群必须启用审计日志所有NameSpace必须设置资源配额然后一键推送到所有集群。任何集群偏离基线ACM会在统一控制台里标记出来。ACM安装本身很简单通过OpenShift OperatorHub就可以安装但要注意版本兼容性。ACM和集群版本之间偏移不要太大否则策略下发可能因为API差异失效。我们运维中遇到过一次ACM版本与集群版本不匹配的问题结果所有集群都显示为脱管状态实际上集群本身正常运行只是管理通道断了。后来我们定下一个规矩任何集群升级之前先确认ACM版本对目标集群版本的兼容范围。4.2 应用交付标准化GitOps管住所有环境多云环境还有一个很实际的难题同一个应用如何在不同集群里保持一致。我们最终选择的解法是OpenShift GitOps底层技术是Argo CD。具体来说每个集群里部署一个Argo CD实例所有的应用配置都存放在Git仓库中通过一套Application模板渲染出不同环境的具体差异。这套机制的好处非常明显。开发团队只需要管理Git仓库中的一套Kubernetes清单然后通过Git分支或目录来区分不同环境。我们当时是把每个集群对应一个目录目录里维护该集群特有的配置覆盖公共部分统一放在base目录中。任何变更都走Git提交、代码评审、自动同步的流程发布过程全程可审计。实际使用中我强烈建议把Argo CD的自动同步功能先关闭更稳妥的做法是Git提交合并后触发一个Pipeline执行argocd app sync的显式操作。因为完全自动同步在配置写错的时候会立刻影响线上环境出现了问题连回滚的时间都很紧张。先手动同步跑几周确认配置和流程都稳定了再对非核心应用开放自动同步。4.3 可观测性日志、指标、追踪的统一侧写多云架构下的监控通常也是割裂的每个云厂商的监控服务有自己的告警规则和指标口径出了问题根本没法横向对比。OpenShift自带了一套监控栈Prometheus Alertmanager Grafana但我们多集群之后选择了统一侧写方案。指标方面使用OpenShift内置的Cluster Monitoring加上Prometheus的远程写功能把所有集群的监控指标汇聚到一个中心化Prometheus。日志方面采用Loki做集中日志存储每个集群通过Vector采集日志并推送到中心Loki。这样在排查跨集群问题时只需要在中心Loki里按集群标签过滤查询不需要逐个登录集群看日志。链路追踪方面通过OpenShift分布式追踪平台底层是Jaeger把分布在不同集群的微服务调用链串起来。我们落地可观测性最大的体会是别贪多求全。一开始就把所有指标、日志、追踪全部集中会带来非常大的存储和网络开销。更合理的做法是先在中心侧配置好基础设施然后按业务重要性逐步接入。我们最开始只接入了核心交易链路的追踪和日志稳定运行一个季度之后才逐步覆盖到所有业务应用。这样既控制了资源成本也不会一上来就陷入配置泥潭。5. 实际运维中最值得记录的坑与经验5.1 证书过期问题计划内恐慌OpenShift集群内置大量证书最让人头疼的是集群自身的API Server证书和Ingress证书默认不像传统系统那样需要手动更换而是由OpenShift自动轮换的。听起来很方便但自动轮换在某些情况下会失败。我们遇到过一次API Server证书轮换失败现象是集群控制台突然无法访问oc get nodes报证书过期错误。排查过程让人记忆深刻。先确认证书的有效期发现只剩不到24小时。然后看证书轮换的日志发现轮换失败的根因是其中一个控制平面节点在轮换窗口期内重启过导致证书签发服务的记录不同步。最终解决办法是强制重新生成证书并重启kubelet服务。这个坑告诉我们虽然证书是自动轮换的但运维人员还是要定期检查证书有效期尤其是在集群做过节点维护之后一定要确认轮换正常。5.2 集群升级不能只看大版本OpenShift的升级机制是分层的先是控制平面再是节点最后是Operator。每次升级前我会先去Red Hat官方查看目标版本和当前版本之间的更新建议注意有没有已知的运维注意事项。比如某些版本对特定的云平台API有依赖升级前需要先在云平台上调整配额或网络策略。我们踩过的一个具体问题是在某个z-stream版本升级后集群节点上的某个内核模块与容器运行时发生冲突导致部分节点上的Pod无法正常启动。虽然Red Hat后来发布了修复版本但那次事故让我们意识到生产集群升级并不一定要追最新版本更稳妥的做法是等官方发布说明中确认的稳定版本并且先在测试集群上完整跑一遍升级流程再逐步推进到生产集群。5.3 默认存储类缺失痛过才记住这个问题在前面提到过但值得单独再说一次。我们第一批测试微服务上线的时候有二三十个Pod一直处于Pending状态查下来都是因为没有可用的持久化存储。当时OpenShift集群装完之后只做了基础验证没有创建默认StorageClass结果所有PVC都卡在创建中。这个排查过程其实很快oc get pvc一看状态就能定位问题但修复起来需要管理员权限创建StorageClass普通开发账号根本做不了只能等运维介入。这个看似小的问题实际上拖慢了整个应用上线进度。我个人的习惯是集群装好之后第一件事就是创建默认StorageClass然后在测试环境部署一个有状态应用验证存储链路这样就把后续的坑提前排掉了。5.4 多集群应用部署的网络延迟与流量拓扑多云架构还有一个被忽视的细节跨集群的服务调用。虽然ACM和GitOps能把集群管理统一起来但网络层面不同云之间的专线或公网质量才是决定链路延迟的关键。如果应用拓扑中频繁出现跨集群调用性能会非常难看。更合理的设计是尽量让一个应用的所有组件部署在同一个集群内或者通过服务网格做流量治理让跨集群调用走质量更好的专线。我们当时给每个集群划分了明确的业务域例如核心交易域数据分析域开发测试域域内应用优先本地调用只有少数跨域调用才走服务网格路由。这个设计让整个混合云架构在管理层面统一但数据面仍然保持可控的物理拓扑性能和稳定性都有保障。5.5 资源配额与成本控制多集群最大的隐性成本是资源碎片化。每个集群都预留了一定比例的请求和限制但真正用起来会发现有些集群CPU水位长期偏低另一个集群又经常资源紧张。通过ACM的集中视图我们能够快速识别出空转集群把一些非关键工作负载迁移过去再对资源紧张的集群做扩容。成本层面OpenShift本身提供了比较细粒度的计量能力可以按Namespace、按Deployment查看资源使用情况。我们每月会出一份资源成本报告直接映射到各个业务团队让大家的资源使用意识和成本意识都建立起来。这一步看起来和部署无关但对于多云架构的长期健康运行重要性不亚于技术本身。最后分享一点我个人的实际操作体会回顾整个RHEL 8 OpenShift混合云部署的过程技术层面的内容官方文档都有真正有价值的是那些散落在实战中的决策逻辑和避坑经验。如果让我给准备做同样事情的同学一个建议不要急着把所有集群、所有组件一次性全部铺开先在一个云环境里把管理链路跑通再逐步扩展到其他环境。管理链路指的是统一的身份认证、统一的多集群列表、统一的应用交付、统一的日志和监控。这些链路打通了后续每扩展一个新集群成本都只是增加一套基础设施而不是重新设计一套管理方案。另外一定要用好RHEL 8和OpenShift自带的安全能力。SELinux在RHEL 8上是默认强制的很多从别的平台迁过来的团队会试图把它关掉这是非常不建议的做法。OpenShift在SELinux之上做了大量安全上下文适配保留这些默认安全策略才能让集群在混合云、多租户场景下保持可靠的隔离边界。真正把OpenShift用顺手的团队会发现它在多云架构里扮演的角色不只是容器平台更是整个基础设施的统一管理入口。