企业官网建设流程全解析

前几年我们团队做混合云改造的时候，面对的第一件事不是选哪个云厂商，而是先回答一个看似简单的问题：多个云平台、多套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、预期用途列在一张表里，提前和供应商确认清楚，避免安装到一半发现授权不足。

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的健康检查路径是/readyz，Ingress 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 --enable=rhel-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-level=info

安装器会读取配置文件，自动在云平台上创建资源，整个过程大概在30到45分钟。安装完成后，确认一下集群状态：看所有节点是否Ready，集群算子是否都可用，OpenShift控制台是否正常响应。这里给大家一个我常用的验证清单：

• oc get nodes显示全部节点为Ready状态
• oc get co所有可用（Available）状态都为True
• oc 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 多集群统一管理：不可跳过的 ACM

OpenShift单集群部署完成只是第一步，真正体现多云架构优势的是多集群统一管理。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用顺手的团队，会发现它在多云架构里扮演的角色不只是容器平台，更是整个基础设施的统一管理入口。