2. 多云Kubernetes集群生命周期治理

在多云环境中，Kubernetes 集群不是“一次性资源”，而是一个有明确生命周期的受管对象。生命周期治理的目标，是让每一个集群从申请、创建、注册、纳管，到升级、变更、下线，都处于可追踪、可审计、可回滚的状态。与单集群运维不同，多云场景下集群数量多、分布广、版本差异大、归属关系复杂，因此必须把“集群”本身当作一等公民来建模和管理。

一、生命周期阶段与状态机

一个受治理的集群通常经历以下阶段：规划（Planned）→ 创建中（Provisioning）→ 已注册（Registered）→ 已纳管（Managed）→ 升级中（Upgrading）→ 已下线（Decommissioned）。每个阶段都应有明确的状态字段、责任人和准入条件。例如，只有处于“已纳管”状态的集群才允许被业务工作负载调度；处于“升级中”的集群应暂停新的变更操作，避免并发冲突。

状态机不是装饰，而是控制面逻辑的基础。平台侧应维护一个集群状态表，记录 cluster_id、phase、last_transition_time、reason 等字段。任何状态跃迁都必须经过校验：例如从“已注册”到“已纳管”，需要确认 kubeconfig 可用、节点就绪、核心插件（CNI、CSI、CoreDNS）健康；从“已纳管”到“升级中”，需要确认没有正在进行的发布窗口冲突。

二、集群创建与注册：两条路径

多云集群的来源通常有两类：平台自建和外部纳管。自建集群由平台通过 IaC（如 Terraform、Cluster API）在云厂商或裸金属上创建，创建完成后自动生成注册凭据；外部集群则由业务团队自行创建，再通过注册流程接入平台。

注册的核心是“信任建立”。平台不应直接保存长期高权限 kubeconfig，而应通过注册令牌 + 短期凭据的方式完成接入。典型流程是：平台生成一次性注册令牌，外部集群部署一个轻量 agent，agent 使用令牌向平台换取受限的、可轮换的访问凭据，并上报集群元数据。这样即使令牌泄露，影响范围也可控。

纳管则是在注册之后，平台对集群施加统一治理策略：安装策略引擎（如 OPA Gatekeeper、Kyverno）、可观测组件、日志采集、证书管理、备份组件等。纳管不是“接管一切”，而是明确边界：哪些命名空间由平台管理，哪些由业务自管；哪些 CRD 由平台下发，哪些允许业务自定义。

三、版本策略与升级治理

多云环境最容易失控的是版本。不同云厂商支持的 Kubernetes 版本窗口不同，业务团队又倾向于“能跑就不升”。因此平台必须制定明确的版本策略：支持版本集合、默认版本、升级窗口、强制升级截止时间。例如，平台可规定只支持最近三个 minor 版本，超出支持范围的集群进入“版本过期”状态，限制其新增工作负载，并触发升级提醒。

升级本身应分级进行：先升级控制面，再升级节点池；先升级非生产集群，再升级生产集群。升级前必须做兼容性检查，包括 API 废弃检查（如 kubectl deprecations 或 pluto）、CRD 版本检查、准入 Webhook 兼容性检查。升级过程中要观察关键指标：API Server 延迟、etcd 健康、节点 NotReady 数量、工作负载重启次数。若超过阈值，应自动暂停并回滚。

四、区域与可用区规划

区域（Region）和可用区（AZ）规划直接影响可用性和成本。基本原则是：控制面跨 AZ 高可用，工作节点按业务容灾等级分布。对于核心业务，节点池应至少跨三个 AZ；对于一般业务，可跨两个 AZ；对于开发测试，可单 AZ 以降低成本。

在多云场景下，还要考虑跨云网络连通性、数据驻留合规、云厂商锁定风险。例如，某金融业务要求数据不出境，则集群必须部署在境内 Region；某业务要求跨云容灾，则需要在两个云厂商各部署一套集群，并通过全局流量管理实现切换。这些约束都应作为集群元数据的一部分被记录和校验。

五、下线与资源回收

集群下线不是简单删除。正确顺序是：停止调度 → 迁移工作负载 → 备份关键数据 → 吊销凭据 → 删除节点 → 清理云资源 → 归档元数据。平台应提供“下线检查清单”，确认没有遗留的 PVC、LoadBalancer、DNS 记录、IAM 角色等。元数据不应立即删除，而应转入归档状态，保留审计追溯能力。

总结来看，多云 Kubernetes 集群生命周期治理的核心，是用状态机约束阶段跃迁，用元数据模型统一描述集群，用版本策略控制升级节奏，用区域规划保障可用性与合规，用下线流程确保资源干净回收。只有把集群当作有生命周期的受管对象，多云治理才具备可操作的基础。