2. 集群生命周期管理
在多集群生产环境中，集群不是一次性交付物，而是一个从创建、运行、变更到退出的完整生命周期对象。OpenShift 提供了两条互补的自动化路径：OpenShift Hive 以声明式 ClusterDeployment 资源为核心，适合“从零拉起集群”的安装与规模化复制；Red Hat Advanced Cluster Management（ACM） 在 Hive 之上提供多集群可观测性、策略治理与生命周期编排，适合“跨集群统一管控”。生产实践中常见的组合是：用 Hive 完成安装与初始配置，用 ACM 的 ManagedCluster、Policy、ClusterCurator 完成升级、证书轮换与退役编排。
一、安装：以 ClusterDeployment 为唯一事实来源
Hive 安装集群的本质是“声明期望状态，由控制器驱动实际状态收敛”。一个最小可用的 ClusterDeployment 需要明确：集群名与基域、目标平台（AWS/Azure/vSphere/裸金属）、安装镜像版本、拉取密钥、SSH 公钥、控制面与计算节点规格。以下为教学示例（参数为合理假设，非实测结果）：
apiVersion: hive.openshift.io/v1
kind: ClusterDeployment
metadata:
name: prod-shanghai-01
namespace: prod-shanghai-01
spec:
baseDomain: example.corp
clusterName: prod-shanghai-01
platform:
aws:
region: cn-north-1
credentialsSecretRef:
name: aws-creds
provisioning:
installConfigSecretRef:
name: prod-shanghai-01-install-config
sshPrivateKeySecretRef:
name: prod-shanghai-01-ssh
imageSetRef:
name: ocp-4.14.12-x86-64
pullSecretRef:
name: pull-secret
controlPlaneConfig:
replicas: 3
compute:
- name: worker
replicas: 6
安装阶段的关键判断依据是 ClusterDeployment.status.conditions：Provisioned 为 True 表示安装完成，InstallImagesResolved 表示镜像已解析，DNSReady 表示 DNS 已就绪。若长时间停留在 Provisioning，应优先检查 hive-controllers 日志与云平台配额，而不是反复重建资源。安装完成后，ACM 通过 ManagedCluster 纳管该集群，klusterlet 注册成功后 ManagedClusterJoined 与 ManagedClusterAvailable 条件转为 True，集群才真正进入可治理状态。
二、升级：用 ClusterCurator 编排，用 ClusterVersion 观察
升级不应手工逐台执行，而应通过 ClusterCurator 定义升级前、升级中、升级后的钩子。典型流程是：先升级 ACM/Hive 自身，再升级受管集群。受管集群的升级由 ClusterCurator 触发，实际版本推进由集群内的 ClusterVersion 对象驱动。升级前必须确认：ClusterOperators 全部 Available、etcd 健康、剩余 etcd 空间充足、PDB 不会阻塞节点排空。
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
name: prod-shanghai-01-upgrade
namespace: prod-shanghai-01
spec:
desiredCuration: upgrade
upgrade:
desiredUpdate: 4.14.14
channel: stable-4.14
monitorTimeout: 120
升级过程中最值得观察的三个信号：ClusterVersion.status.history 中是否出现新的 Partial 或 Completed 条目；ClusterOperator 的 Progressing 是否在合理时间内回落；节点 MachineConfigPool 的 UPDATED 与 UPDATING 计数是否收敛。若 ClusterVersion 报 Upgradeable=False，应先处理阻塞原因（如不兼容的 Operator、证书即将过期），再重试升级。
三、证书轮换：区分“自动轮换”与“需人工介入”
OpenShift 中大部分证书由 service-ca 与各 Operator 自动轮换，但 kubelet 客户端证书、API Server 服务证书、etcd 证书、Ingress 证书 需要重点关注。轮换前应先用 oc get csr 与 oc adm certificate approve 确认 CSR 审批链路正常；对 etcd 证书，需确认 etcdctl endpoint health 全部健康后再触发轮换。轮换后必须验证：oc get nodes 全部 Ready、oc get clusteroperators 无 Degraded、关键 Ingress 域名 TLS 握手正常。证书轮换不是“点一下按钮”，而是一次有前置检查、有过程观察、有结果验证的受控变更。
四、退役：先摘流量，再删资源，最后清理注册
退役的标准化顺序是：先解除 ACM 纳管（删除 ManagedCluster 并确认 klusterlet 卸载），再摘除业务流量（从全局负载均衡、DNS、GitOps 目标列表中移除），然后删除 Hive 的 ClusterDeployment，最后清理云上残留资源（VPC、负载均衡、存储卷）。顺序颠倒会导致“集群已删但 DNS 仍指向”或“ACM 仍尝试下发策略”的脏状态。退役完成后，应核对云账单与资源清单，确认无孤儿资源。
五、标准化流程的落地要点
把上述四阶段固化为可重复流程，需要三个支撑：版本基线（明确当前允许的 OCP 版本与升级窗口）、审批门禁（升级前检查 ClusterOperator 与 etcd 健康，证书轮换前检查 CSR 链路）、回滚预案（升级失败时保留旧版本 MachineConfig，退役前保留最终备份）。建议用 GitOps 管理 ClusterDeployment、ClusterCurator 与 Policy，使每一次安装、升级、轮换、退役都有可审计的提交记录。这样，集群生命周期管理就从“个人经验”变成“组织能力”。