4. 集群生命周期管理

在多集群运维中，集群不是“装好就完事”的静态资产，而是一个有明确生命周期的对象：从创建、纳管、日常升级、证书维护，到配置漂移治理，最终退役下线。OpenShift 的集群生命周期管理，核心是把这些阶段变成可重复、可审计、可回滚的工程流程，而不是依赖个人经验临时处理。本节围绕五个关键阶段展开，重点说明每个阶段实际要做什么、看什么指标、如何判断结果。

一、集群创建：从安装到纳管

创建阶段的目标不是“装完一个集群”，而是“交付一个可被统一纳管、可被策略约束、可被监控的集群”。以 OpenShift 为例，常见创建方式包括 IPI（安装程序自动置备基础设施）、UPI（用户自备基础设施）以及托管控制平面模式。无论哪种方式，创建完成后必须完成三件事：安装 kubeconfig 与集群访问凭据、注册到多集群管理面（如 Red Hat Advanced Cluster Management，RHACM）、打上正确的标签与集群集（ClusterSet）。

实际交付时，建议在创建流程中固定以下输入：集群名称、基域、平台类型（AWS/Azure/vSphere/裸金属）、OpenShift 版本、网络 CIDR、基础设施账号、以及所属 ClusterSet。创建完成后，用以下命令确认集群已就绪并纳管：

oc get clusterversion
oc get nodes
oc get managedcluster <cluster-name> -o yaml

判断标准是：clusterversion 显示 Available=True、Progressing=False；节点全部 Ready；managedcluster 的 JOINED 与 AVAILABLE 均为 True。若 managedcluster 长时间处于 NotReady，优先检查 klusterlet 的注册端点、证书与网络连通性，而不是反复重装。

二、升级：版本节奏与批次控制

OpenShift 升级通过 ClusterVersionOperator 驱动，遵循“小版本通道（channel）”机制，例如 stable-4.14。升级不是一次性把所有集群推到最新版，而是按批次推进：先升级非生产集群验证，再升级生产集群；同一 ClusterSet 内保留至少一个可回退的旧版本集群作为对照。

升级前必须确认：当前版本与目标版本在同一通道内、Operator 全部健康、etcd 备份已完成、PDB 与节点排空策略已评估。升级过程中重点观察：

• oc get clusterversion 的 Progressing 状态与当前阶段；
• oc get co 中是否有 Degraded 的 ClusterOperator；
• 节点滚动重启期间业务 Pod 的可用副本数是否满足 PDB。

若升级卡在某个 Operator，先查看该 Operator 的 oc describe co <name> 与相关 Pod 日志，判断是镜像拉取、权限还是 API 兼容问题。升级完成后，用 oc adm upgrade 确认无待处理更新，并记录升级前后版本与耗时，作为后续批次参考。

三、证书轮换：时间驱动的维护动作

OpenShift 集群内部存在大量证书：API Server、etcd、kubelet、Ingress、Service CA、以及各 Operator 的客户端证书。它们有各自的签发者与有效期，默认多数为 1 年或 2 年。证书过期会导致 API 不可用、节点 NotReady、Operator 崩溃等连锁故障，因此证书轮换必须作为周期性维护任务，而不是等到告警才处理。

日常巡检可用以下方式查看证书剩余时间：

oc get secret -A -o json | jq -r '.items[] | select(.type=="kubernetes.io/tls") | "\(.metadata.namespace)/\(.metadata.name) \(.data["tls.crt"] | @base64d | openssl x509 -noout -enddate)"'

对于集群内建证书，OpenShift 会在到期前自动轮换大部分证书，但 kubelet 服务证书、部分 Operator 证书仍需人工确认。建议在证书到期前 30 天触发轮换窗口，轮换后重启相关组件并验证 API、Ingress 与监控链路恢复正常。

四、配置漂移检测：让集群回到期望状态

配置漂移是指集群实际配置偏离了基线，例如有人手动改了 LimitRange、删除了 NetworkPolicy、调整了节点标签，或 Operator 被意外降级。漂移检测的核心是“基线 + 对比 + 修复”。在 RHACM 中，可用 Policy 定义期望状态，并通过 PolicyReport 查看合规情况。

一个典型的漂移检测流程是：先定义 Policy（如要求所有集群必须存在某个 Namespace 与 ResourceQuota），再让策略控制器周期性扫描，最后对不合规项生成修复任务。判断漂移是否严重，可看三个维度：影响范围（单集群还是整个 ClusterSet）、是否涉及安全策略、是否影响业务可用性。安全类漂移应优先修复，配置类漂移可纳入变更窗口。

五、退役下线：有序移除而非直接删除

退役下线是最容易被忽视、却最容易留下隐患的阶段。直接删除集群会遗留 DNS 记录、负载均衡器、存储卷、云资源与监控目标，造成成本浪费与安全暴露。正确流程是：先标记集群为 decommissioning，停止新业务调度；再迁移或备份工作负载；然后从 ClusterSet 与 GitOps 仓库中移除；最后清理云资源与 DNS，并保留审计记录。

下线前必须确认：无业务流量、无持久化数据依赖、无其他集群引用其 Service/Endpoint、备份已完成。下线后检查云账单与监控目标是否仍有残留，确保资源真正释放。

六、把五个阶段串成可执行流程

把上述阶段串起来，实际运维中建议形成一份“集群生命周期台账”，每个集群记录：当前版本、所属通道、证书最近轮换时间、最近一次漂移扫描结果、以及退役计划。台账不需要复杂系统，用 Git 仓库中的 YAML 或表格即可维护，关键是让每个阶段都有明确的责任人与检查点。

例如，一个生产集群的典型节奏是：创建后 7 天内完成纳管与策略绑定；每季度评估一次升级窗口；证书到期前 30 天进入轮换窗口；每月执行一次漂移扫描；退役前 14 天冻结变更并启动迁移。这样做的价值在于，把“救火式运维”变成“计划式维护”，让多集群环境在规模增长后仍然可控、可审计、可回退。