如果您的集群运行 GKE Enterprise 组件（如 Anthos Service Mesh、Config Sync、Policy Controller 或 Config Controller），请检查 GKE Enterprise 版本和升级支持，并在升级前后验证 Google Distributed Cloud 支持的版本。

兼容性检查基于部署了 Anthos Service Mesh、Config Sync、Policy Controller 或 Config Controller 的管理员集群或用户集群。

检查集群资源利用率

为确保当节点排空时 Pod 可以被排空，并且正在升级的集群中有足够的资源来管理升级，请检查集群的当前资源使用情况。如需检查集群的资源用量，请使用 Google Cloud Observability 中的自定义信息中心。

您可以使用 kubectl top nodes 等命令来获取当前的集群资源用量，但信息中心可以提供更详细的资源用量随时间变化的视图。此资源使用情况数据有助于指示升级何时会导致最少的服务中断（例如在周末或晚上），具体取决于正在运行的工作负载和使用场景。

管理员集群升级的时间可能不如用户集群那么重要，因为管理员集群升级通常不会导致应用停机。但是，在开始管理员集群升级之前，请务必检查可用资源。此外，升级管理员集群可能会带来一些风险，因此建议在不太活跃的使用期间（对集群的管理访问不太重要时）升级管理员集群。

管理员集群控制平面资源

所有升级控制器和作业都在管理员集群控制平面节点中运行。检查这些控制平面节点的资源消耗量以了解可用的计算资源。升级过程通常需要为每组生命周期控制器提供 1000 millicore (1000 mCPU) 和 2-3 GiB RAM。请注意，CPU 单位“mCPU”代表“核心的千分之一”，因此 1000 millicore 相当于每组生命周期控制器上每个节点的一个核心。如需减少升级过程中所需消耗的其他计算资源，请尝试将用户集群保持在同一版本。

在以下示例部署中，两个用户集群的版本与管理员集群不同：

管理员集群	用户集群 1	用户集群 2
1.13.3	1.13.0	1.13.2

系统会针对正在使用的每个版本在管理员控制器中部署一组生命周期控制器。在此示例中，有三组生命周期控制器：1.13.3、1.13.0 和 1.13.2。每组生命周期控制器总共消耗 1000 mCPU 和 3 GiB RAM。这些生命周期控制器的当前总资源消耗量为 3000 mCPU 和 9 GiB RAM。

如果用户集群 2 升级到 1.13.3，则现在有两组生命周期控制器：1.13.3 和 1.13.0：

管理员集群	用户集群 1	用户集群 2
1.13.3	1.13.0	1.13.3

生命周期控制器现在总共消耗 2000 mCPU 和 6 GiB RAM。

如果用户集群 1 升级到 1.13.3，则舰队现在都运行同一版本：1.13.3：

管理员集群	用户集群 1	用户集群 2
1.13.3	1.13.3	1.13.3

现在，只有一组生命周期控制器，总共消耗 1000 mCPU 和 3 GiB RAM。

在以下示例中，所有用户集群的版本都相同。如果管理员集群升级，则仅使用两组生命周期控制器，从而减少计算资源消耗量：

管理员集群	用户集群 1	用户集群 2
1.14.0	1.13.3	1.13.3

在此示例中，生命周期控制器同样总共消耗 2000 mCPU 和 6 GiB RAM，直到所有用户集群升级到与管理员集群相同的版本。

如果控制平面节点在升级期间没有额外的计算资源，您可能会看到 Pod（例如 anthos-cluster-operator、capi-controller-manager、cap-controller-manager 或 cap-kubeadm-bootstraper）处于 Pending 状态。要解决此问题，请将一些用户集群升级到同一版本，以整合版本并减少正在使用的生命周期控制器的数量。如果升级停滞，您还可以使用 kubectl edit deployment 修改待处理的部署以降低 CPU 和 RAM 请求，使其适合管理员集群控制平面。

下表详细介绍了不同升级场景的计算资源要求：

集群	需要的管理员集群资源
用户集群升级	升级到其他集群的相同版本：不适用升级到其他管理员或用户集群的不同版本：1000 mCPU 和 3 GiB RAM 混合集群中的用户集群具有相同的资源要求。
管理员集群升级（有用户集群）	1000 mCPU 和 3 GiB RAM
混合集群升级（无用户集群）	1000 mCPU 和 3 GiB RAM 超额配置。资源在使用后归还。
独立脚本	200 mCPU 和 1 GiB RAM 超额配置。资源在使用后归还。

备份集群

在开始升级之前，请先使用 bmctl backup cluster 命令备份集群。

由于备份文件包含敏感信息，因此请安全存储备份文件。

核实集群是否配置正确且正常运行

如需在升级前检查集群的运行状况，请针对集群运行 bmctl check cluster。该命令会运行高级检查，例如识别未正确配置的节点或者处于卡滞状态的 Pod。

当您运行 bmctl upgrade cluster 命令以升级集群时，系统会运行一些预检检查。如果这些检查不成功，则升级过程将停止。最好使用 bmctl check cluster 命令主动识别并修复这些问题，而不是依靠预检检查来保护集群免遭任何可能的损坏。

查看用户工作负载部署

用户工作负载需要考虑以下两个方面：排空和 API 兼容性。

工作负载排空

节点上的用户工作负载在升级期间会被排空。如果工作负载具有单个副本或所有副本位于同一节点上，则工作负载排空可能会导致集群中运行的服务中断。使用多个副本运行工作负载。副本数应大于并发节点数。

为了避免升级卡住，升级到 1.29 的排空过程不会遵循 Pod 中断预算 (PDB)。工作负载可能处于降级状态，且处理量最低的副本是 total replica number - concurrent upgrade number。

API 兼容性

对于 API 兼容性，请在进行次要版本升级时检查工作负载 API 与 Kubernetes 较新的次要版本的兼容性。如有需要，请将工作负载升级到兼容的版本。GKE Enterprise 工程团队会尽可能提供说明，以使用不兼容的 API（例如已移除的 Kubernetes API）识别工作负载。

如果您使用 Anthos Service Mesh、Config Sync、Policy Controller、Config Controller 或其他 GKE Enterprise 组件，请检查安装的版本是否与新版 Google Distributed Cloud 兼容。如需了解 GKE Enterprise 组件版本兼容性信息，请参阅 GKE Enterprise 版本和升级支持。

审核 webhook 的使用情况

检查您的集群是否有任何网络钩子，尤其是用于审核目的的 Pod 资源，例如政策控制器。集群升级期间的排空过程可能会中断政策控制器 webhook 服务，导致升级卡住或需要很长时间。我们建议您暂时停用这些 webhook，或使用高可用性 (HA) 部署。

查看预览版功能的使用情况

预览版功能随时可能会更改，并且仅用于测试和评估目的。请勿在生产集群上使用预览版功能。我们无法保证使用预览版功能的集群可以升级。在某些情况下，我们会明确阻止对使用预览版功能的集群进行升级。

如需了解与升级相关的破坏性更改，请参阅版本说明。

检查 SELinux 状态

如果要启用 SELinux 来保护容器，则必须确保在所有宿主机上以 Enforced 模式启用 SELinux。从 Google Distributed Cloud 1.9.0 版或更高版本开始，您可以在创建集群或升级之前或之后启用或停用 SELinux。在 Red Hat Enterprise Linux (RHEL) 上，SELinux 默认处于启用状态。如果宿主机上停用了 SELinux，或者不确定，请参阅使用 SELinux 保护容器，了解如何启用 SELinux。

Google Distributed Cloud 仅在 RHEL 系统中支持 SELinux。

不更改 Pod 密度配置

Google Distributed Cloud 支持使用 nodeConfig.PodDensity.MaxPodsPerNode 配置每个节点最多 250 个 Pod。您只能在创建集群期间配置 pod 密度。您无法更新现有集群的 pod 密度设置。请勿在升级过程中尝试更改 pod 密度配置。

确保控制平面和负载均衡器节点未处于维护模式

在开始升级之前，请确保控制平面和负载均衡器节点未进行维护。如果任何节点处于维护模式，则升级会暂停，以确保控制平面和负载均衡器节点池足够可用。

Google Distributed Cloud 集群升级的最佳做法

升级核对清单

规划升级

估算时间承诺并规划维护窗口

检查其他 GKE Enterprise 组件的兼容性