本文档介绍了升级 GKE on Bare Metal 的最佳实践和注意事项。您将了解如何准备集群升级，以及升级之前应遵循的最佳实践。这些最佳实践有助于降低与集群升级相关的风险。
如果您有多个环境（例如测试环境、开发环境和生产环境），我们建议您从最不重要的环境（例如测试环境）开始，并验证升级功能。验证升级成功后，进入下一个环境。重复此过程，直到升级生产环境。这种方法可让您从一个关键点转到下一个关键点，并验证升级和工作负载是否正常运行。
升级核对清单
我们建议您遵循本文档中的所有最佳实践。您可以借助以下核对清单来跟踪自己的进度。列表中的每一项都链接到本文档的各个部分，其中提供了更多详细信息：
这些检查完成后，您可以开始升级过程。监控进度，直到所有集群都成功升级。
规划升级
更新可能会造成干扰。在开始升级之前，请仔细规划，确保您的环境和应用已准备就绪。
估算时间承诺并规划维护窗口
升级集群所需的时间因节点数量和节点上运行的工作负载密度而异。如需成功完成集群升级，请使用具有足够时间的维护窗口。
要得出升级的粗略估算值，可针对单个并发节点升级使用 10 minutes * the number of
nodes 进行计算。
例如，如果集群中有 50 个节点，则总升级时间大约为 500 分钟：10 minutes * 50 nodes = 500 minutes。
检查其他 Anthos 组件的兼容性
如果您的集群运行 Anthos Service Mesh 或 Config Management 等 Anthos 组件，请查看 Anthos 兼容性矩阵，并验证升级前后 GKE on Bare Metal 支持的版本。
兼容性检查基于将 Anthos Service Mesh 或 Config Management 部署到的管理员集群或用户集群。
检查集群资源利用率
为确保当节点排空时 Pod 可以被排空，并且正在升级的集群中有足够的资源来管理升级，请检查集群的当前资源使用情况。如需检查集群的资源用量，请使用 Google Cloud 的运维套件中的自定义信息中心。
您可以使用命令（如 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.14 的排空过程不会遵循 Pod 中断预算 (PDB)。工作负载可能处于降级状态，且处理量最低的副本是 total
replica number - concurrent upgrade number。
API 兼容性
对于 API 兼容性，请在进行次要版本升级时检查工作负载 API 与 Kubernetes 较新的次要版本的兼容性。如有需要，请将工作负载升级到兼容的版本。在可能的情况下，Anthos 工程团队将提供使用不兼容的 API（例如已弃用的 Kubernetes 1.22 API）识别工作负载的说明。
如果您使用 Anthos Service Mesh、Config Management 或其他 GKE Enterprise 组件，请检查已安装的版本是否与新版 GKE on Bare Metal 兼容。如需了解 GKE Enterprise 组件版本兼容性信息，请参阅 Anthos 版本和升级支持。
审核 webhook 的使用情况
检查您的集群是否有任何网络钩子，尤其是用于审核目的的 Pod 资源，例如政策控制器。集群升级期间的排空过程可能会中断政策控制器 webhook 服务，导致升级卡住或需要很长时间。我们建议您暂时停用这些 webhook，或使用高可用性 (HA) 部署。
查看预览版功能的使用情况
预览版功能随时可能更改，并且仅用于测试和评估目的。请勿在生产集群上使用预览版功能。我们不能保证使用预览版功能的集群可以升级。在某些情况下，我们会明确阻止对使用预览版功能的集群进行升级。
如需了解与升级相关的破坏性更改，请参阅版本说明。
检查 SELinux 状态
如果要启用 SELinux 来保护容器，则必须确保在所有宿主机上以 Enforced 模式启用 SELinux。从 GKE on Bare Metal 1.9.0 版或更高版本开始，您可以在创建集群或升级集群之前或之后启用或停用 SELinux。Red Hat Enterprise Linux (RHEL) 和 CentOS 上默认启用 SELinux。如果宿主机上停用了 SELinux，或者不确定，请参阅使用 SELinux 保护容器，了解如何启用 SELinux。
GKE on Bare Metal 仅支持 RHEL 和 CentOS 系统中的 SELinux。
不更改 Pod 密度配置
GKE on Bare Metal 通过 nodeConfig.PodDensity.MaxPodsPerNode 支持每个节点最多 250 个 pod 的配置。您只能在创建集群期间配置 pod 密度。您无法更新现有集群的 pod 密度设置。 请勿在升级过程中尝试更改 pod 密度配置。
确保控制平面和负载均衡器节点未处于维护模式
在开始升级之前，请确保控制平面和负载均衡器节点未进行维护。如果任何节点处于维护模式，则升级会暂停，以确保控制平面和负载均衡器节点池足够可用。