📚 课程目录第3章 OpenShift安装部署实战

3. OpenShift安装部署实战

OpenShift的安装部署不是“装完即用”的一次性动作，而是一次围绕基础设施、网络、引导流程和验证闭环的系统工程。实际项目中最常见的返工，往往不是命令敲错，而是安装方式选错、配置清单与真实环境不匹配、引导阶段异常未被及时识别。本节围绕IPI与UPI的选择、install-config配置清单编写、集群引导与验证、以及常见故障排查四条主线展开，帮助你把安装过程从“照文档执行”提升为“可判断、可定位、可复现”。

一、IPI与UPI：先选对路径，再谈安装

OpenShift安装方式的核心差异在于“谁负责基础设施”。IPI（Installer-Provisioned Infrastructure）由安装程序自动创建和销毁计算、网络、存储等底层资源，适合云平台或已支持自动化的虚拟化环境；UPI（User-Provisioned Infrastructure）则由用户自行准备主机、负载均衡、DNS、网络和存储，安装程序只负责引导集群。选择时不要只看“哪个更省事”，而要看环境是否允许安装程序调用云API、是否已有固定网络与安全策略、以及后续是否需要与既有CMDB或审批流程对接。

一个实用的判断顺序是：若目标平台在OpenShift官方支持列表中，且允许安装程序创建VPC、子网、安全组、负载均衡和DNS记录，优先选IPI；若主机由既有运维体系交付、网络地址和负载均衡已固定、或需要复用已有DNS域和证书体系，则选UPI。混合场景下，也可以采用“UPI准备基础设施 + 手动引导”的方式，但必须接受更高的配置核对成本。

二、安装配置清单编写：把环境事实写进YAML

无论IPI还是UPI，install-config.yaml都是安装程序的唯一输入契约。它一旦被安装程序消费，就会被移动到备份目录，后续修改必须重新生成。因此编写清单时，重点不是“字段填满”，而是让每个字段都能对应到真实环境中的可验证事实。

以一套典型的UPI实验环境为例：三台控制平面节点（10.0.10.11~13）、两台计算节点（10.0.10.21~22）、一台引导节点（10.0.10.10），集群域名ocp.lab.example.com，Pod网段10.128.0.0/14，Service网段172.30.0.0/16。对应的关键片段如下：

apiVersion: v1
baseDomain: lab.example.com
metadata:
  name: ocp
platform:
  none: {}
networking:
  networkType: OVNKubernetes
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  serviceNetwork:
  - 172.30.0.0/16
controlPlane:
  name: master
  replicas: 3
compute:
- name: worker
  replicas: 2
pullSecret: '{"auths":{...}}'
sshKey: 'ssh-rsa AAAAB3...'

这里有几个容易出错的点：platform: none表示UPI模式，安装程序不会创建任何基础设施；hostPrefix: 23决定每个节点可分配的Pod数量，需与节点规模和业务密度匹配；pullSecret必须来自Red Hat账号且包含正确的registry认证；sshKey用于故障时登录节点排查，不能省略。IPI模式下则要把platform替换为具体云平台字段，并补充region、子网、实例类型等参数。

编写清单前，先确认三件事：DNS正向与反向解析是否已配置、负载均衡是否已放行6443/22623/80/443、所有节点时间是否同步。这三项在引导阶段最容易引发连锁失败。

三、集群引导与安装验证

引导阶段是安装过程中最“黑盒”的一段。以UPI为例，典型顺序是：先生成manifest和ignition配置，再启动bootstrap节点，随后控制平面节点从bootstrap拉取ignition并完成自身配置，最后bootstrap将控制权交给稳定的控制平面并退出。整个过程可以通过以下命令观察：

openshift-install create manifests --dir=ocp
openshift-install create ignition-configs --dir=ocp
openshift-install wait-for bootstrap-complete --dir=ocp --log-level=info
openshift-install wait-for install-complete --dir=ocp --log-level=info

验证不能只看“安装命令返回成功”。建议按四层检查：第一层，oc get nodes确认所有节点Ready；第二层，oc get clusteroperators确认所有Operator的AVAILABLE为True、DEGRADED为False；第三层，oc get co -w持续观察是否有反复抖动；第四层，实际创建一个测试项目并暴露路由，验证镜像拉取、DNS解析和Ingress链路。只有四层都通过，才能认为集群具备交付条件。

四、常见安装故障排查

安装故障大多集中在引导阶段，排查时不要盲目重装，而应按“节点是否启动—ignition是否拉取—服务是否就绪—Operator是否收敛”的顺序定位。常见现象与处理方向如下：

节点无法获取ignition：检查bootstrap节点上的/var/lib/ignition与HTTP服务是否可达，确认节点能解析api-int.ocp.lab.example.com。
控制平面节点卡在NotReady：登录节点执行journalctl -u kubelet -f，重点看证书、时间同步和容器运行时错误。
clusteroperator持续DEGRADED：用oc describe co <name>查看具体条件，常见原因是镜像拉取失败或DNS解析异常。
bootstrap无法退出：检查oc get csr是否有待批准证书，以及控制平面节点是否全部加入。
路由访问502：确认Ingress Controller Pod运行正常，并检查负载均衡后端是否包含所有计算节点。

安装失败后，先收集openshift-install gather bootstrap --dir=ocp日志，再决定是否重建。直接删除节点重装，往往会掩盖DNS、证书或负载均衡配置问题，导致同样故障重复出现。

把安装过程当作一次可验证的交付：选对IPI或UPI路径，把环境事实准确写入install-config.yaml，用分层验证确认集群真正收敛，再以日志和条件为依据排查故障。这样得到的不仅是一个可用的OpenShift集群，更是一套可复用的安装与排障方法。