本页面介绍如何升级 Anthos clusters on VMware (GKE On-Prem)。
升级流程概述
您可以直接升级到同一或下一次要发布版本中的任何版本。例如，您可以从 1.11.0 升级到 1.11.1，或从 1.10.1 升级到 1.11.0。
如果您要升级到非下一个次要版本，则必须在当前版本和所需版本之间升级每个次要版本的一个版本。例如，如果您要从 1.9.2 版升级到 1.11.0 版，则无法直接升级。您必须先从 1.9.2 版升级到 1.10.x 版，然后再升级到 1.11.0 版。
本主题介绍如何从 1.10.x 或 1.11.x 版升级到 1.11.y 版。
以下是升级的一般工作流。
升级管理员工作站。
从管理员工作站安装将用于升级集群的软件包。
在管理员工作站上，升级用户集群。
所有用户集群都升级后，您便可以从管理员工作站升级管理员集群。此步骤不是必须执行的步骤，除非您需要使用该项升级提供的功能。
准备升级
创建管理员工作站之前，您填写了由 gkeadm create config 生成的管理员工作站配置文件。此文件的默认名称为 admin-ws-config.yaml。
此外，您的工作站还具有信息文件。此文件的默认名称与您当前管理员工作站的名称相同。
找到您的管理员工作站配置文件和信息文件。您需要它们来完成升级步骤。如果这些文件在当前目录中并且具有默认名称，则运行升级命令时无需指定它们。如果这些文件位于其他目录中，或者您更改了文件名，则可以使用 --config 和 --info-file 标志进行指定。
如果输出信息文件缺失，您可以重新创建。 请参阅如果信息文件缺失则重新创建。
在规划升级策略时，您还应考虑升级会导致的任何停机时间。请参阅升级停机时间。
升级管理员工作站
运行以下命令来下载指定的 gkeadm 版本：
gkeadm upgrade gkeadm --target-version TARGET_VERSION
将 TARGET_VERSION 替换为您要下载的版本。
运行以下命令来完成升级：
gkeadm upgrade admin-workstation --config AW_CONFIG_FILE --info-file INFO_FILE
替换以下内容：
AW_CONFIG_FILE：管理员工作站配置文件的路径。如果文件位于当前目录中且名称为
admin-ws-config.yaml，则可以省略此标志。INFO_FILE：信息文件的路径。如果文件位于当前目录中，则可以省略此标志。此文件的默认名称与管理员工作站的名称相同。
上述命令会执行以下任务：
备份当前管理员工作站的主目录中的所有文件。其中包括：
- 您的管理员集群配置文件。默认名称是
admin-cluster.yaml。 - 您的用户集群配置文件。默认名称是
user-cluster.yaml。 - 管理员集群和用户集群的 kubeconfig 文件。
- vCenter 服务器的根证书。请注意，此文件必须具有所有者读写权限。
- 组件访问服务帐号的 JSON 密钥文件。请注意，此文件必须具有所有者读写权限。
- 用于连接和注册及日志记录监控服务帐号的 JSON 密钥文件。
- 您的管理员集群配置文件。默认名称是
创建新的管理员工作站，并将所有备份文件复制到新的管理员工作站。
删除旧的管理员工作站。
验证是否有足够的可用 IP 地址
在升级集群之前，请确保您已分配足够多的 IP 地址。您可以根据需要预留更多 IP，如 DHCP 和静态 IP 部分中所述。 如果您有多个节点池，则还应为每个节点池提供额外的 IP 地址，以方便升级过程。
请参阅管理节点 IP 地址以计算您需要的 IP 地址数量。
检查软件包以进行升级
如果您已升级管理员工作站，则用于升级集群的相应软件包版本已存在于该工作站上。
如果要使用与管理员工作站不同的版本，则必须手动安装相应的软件包。请参阅安装软件包以进行升级。
升级用户集群
命令行
在继续升级之前，请注意以下事项：
gkectl upgrade命令运行预检检查。如果预检检查失败，该命令会被屏蔽。您必须修复失败，或在命令中使用--skip-preflight-check-blocking标志来取消屏蔽命令。只有在确信没有任何问题时，才应跳过预检检查。注意：从 1.10 版开始，Anthos clusters on VMware 包含手动负载均衡器的
konnectivityServerNodePort。请确保您为此节点端口指定适当的值、使用此节点端口配置负载均衡器，以及在升级之前在配置文件中添加此新节点端口。请参阅手动负载均衡。
在管理员工作站上继续执行以下步骤：
确保管理员集群配置文件中的
bundlepath字段与您要升级到的软件包的路径相匹配。确保用户集群配置文件中的
gkeOnPremVersion字段与您要升级到的版本相匹配。如果您对管理员集群配置文件或用户集群配置文件中的字段进行了其他任何更改，则升级期间会忽略这些更改。要使这些更改生效，您必须先升级集群，然后运行包含配置文件更改的 update 命令，以对集群进行其他更改。
将软件包从指定目录安装到集群。
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
替换以下内容：
- ADMIN_CLUSTER_KUBECONFIG：管理员集群的 kubeconfig 文件。
使用以下命令进行升级。
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE \ FLAGS
替换以下内容：
USER_CLUSTER_CONFIG_FILE：新管理员工作站上的 Anthos clusters on VMware 用户集群配置文件。
FLAGS：一组可选的标志。例如，您可以添加
--skip-validation-infra标志以跳过检查 vSphere 基础架构这一步。
控制台
在管理员工作站上，运行以下命令：
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --upgrade-platform替换以下内容：
- ADMIN_CLUSTER_KUBECONFIG 是管理员集群的 kubeconfig 文件的路径。
此命令会升级用户集群控制器和基于角色的访问权限控制 (RBAC) 政策，以便 Google Cloud 控制台能够管理用户集群。
在 Google Cloud 控制台中，前往 Anthos 集群页面。
选择用户集群所在的 Google Cloud 项目。
在集群列表中，点击要升级的集群。
在详细信息面板中，如果类型为 vm Anthos (VMware)，请执行以下步骤，使用 Google Cloud 控制台升级集群：
在详细信息面板中，点击更多详细信息。
在集群基本信息部分，点击 升级。
在 Anthos clusters on VMware 版本列表中，选择您要升级到的版本。
点击升级。
如果类型为外部，则表示集群是使用
gkectl创建的。在这种情况下，请按照命令行标签页中的步骤升级集群。
恢复升级
如果用户集群升级中断，您可以通过运行带 --skip-validation-all 标志的同一升级命令来恢复用户集群升级：
gkectl upgrade cluster \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE \
--skip-validation-all
升级管理员集群
请在新的管理员工作站上执行本部分中的步骤。 请确保您的 gkectl 和集群是适合进行升级的版本，并且您已下载合适的软件包。
确保管理员集群配置文件中的
bundlepath字段与您要升级到的软件包的路径相匹配。如果您对管理员集群配置文件中的字段进行了其他任何更改，则升级期间会忽略这些更改。要使这些更改生效，您必须先升级集群，然后运行包含配置文件更改的 update 命令，以对集群进行其他更改。
运行以下命令：
gkectl upgrade admin \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config ADMIN_CLUSTER_CONFIG_FILE \ FLAGS替换以下内容：
ADMIN_CLUSTER_KUBECONFIG：管理员集群的 kubeconfig 文件。
ADMIN_CLUSTER_CONFIG_FILE：新管理员工作站上的 Anthos clusters on VMware 管理员集群配置文件。
FLAGS：一组可选的标志。例如，您可以添加
--skip-validation-infra标志以跳过检查 vSphere 基础架构这一步。
管理员集群升级完成后，运行以下命令以确定
admin-cluster-credsSecret 中的component-access-sa-key字段是否已擦除：kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds | grep 'component-access-sa-key'
如果输出为空，请运行下一个命令以重新添加
component-access-sa-key：kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -
如果您下载了整个软件包，而且已成功运行 gkectl prepare 和 gkectl upgrade admin 命令，您现在应删除整个软件包以节省管理员工作站上的磁盘空间。使用以下命令：
rm /var/lib/gke/bundles/gke-onprem-vsphere-${TARGET_VERSION}-full.tgz
恢复管理员集群升级
管理员集群升级中断或失败时，如果管理员集群检查点包含恢复中断之前状态所需的状态，则可以继续升级。
请按照以下步骤操作：
在开始初始升级尝试之前，检查管理员控制层面的运行状况是否良好。 请参阅诊断集群问题。如该主题中所述，为管理员集群运行
gkectl diagnose cluster命令。如果管理员控制层面在初始升级尝试之前运行状况不佳，请使用
gkectl repair admin-master命令修复管理员控制层面。在升级中断或失败后重新运行升级命令时，请使用与之前的升级尝试相同的软件包和目标版本。
重新运行升级命令时，恢复的升级会从检查点重新创建种类集群中的状态，并重新运行整个升级。如果管理员控制层面运行状况不佳，则必须先恢复该实例，然后再继续升级。
从管理员集群故障可用或退出的位置恢复升级。如果该检查点不可用，则升级将回退到依赖于管理员控制层面，因此管理员控制层面必须运行状况良好才能继续升级。成功升级后，系统会重新生成检查点。
如果 gkectl 在管理员集群升级期间意外退出，则系统不会清理种类集群。在重新运行升级命令以恢复升级之前，请删除种类集群：
docker stop gkectl-control-plane && docker rm gkectl-control-plane
删除种类集群后，再次运行升级命令。
升级后回滚管理员工作站
您可以将管理员工作站回滚到升级前使用的版本。
升级期间，gkeadm 会在输出信息文件中记录升级之前的版本。在回滚期间，gkeadm 会使用列出的版本下载较旧的文件。
如需将管理员工作站回滚到之前的版本，请执行以下操作：
gkeadm rollback admin-workstation --config=AW_CONFIG_FILE
如果您的管理员工作站配置文件是默认的 admin-ws-config.yaml，则可以省略 --config=AW_CONFIG_FILE。否则，请将 AW_CONFIG_FILE 替换为管理员工作站配置文件的路径。
回滚命令会执行以下步骤：
- 下载
gkeadm的回滚版本。 - 备份当前管理员工作站的主目录。
- 使用
gkeadm的回滚版本创建新的管理员工作站。 - 删除原始管理员工作站。
安装其他版本的软件包以进行升级
如果您要升级工作站，则系统会安装具有相应版本的软件包以升级集群。如果您要使用其他版本，请按照以下步骤安装 TARGET_VERSION（即您要升级到的版本）的软件包。
如需查看当前的
gkectl和集群版本，请运行以下命令。如需查看详细信息，请使用--details/-d标志。gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
输出会提供集群版本的相关信息。
根据获得的输出结果查找以下问题，并视需要修复问题。
如果当前管理员集群版本比 TARGET_VERSION 低多个次要版本，请将所有集群升级到比 TARGET_VERSION 低一个次要版本。
如果
gkectl版本低于 1.10，并且您想要升级到 1.11.x，则必须执行多次升级。一次升级一个次要版本，直到升级到 1.10.x，然后按照本主题中的说明操作。如果
gkectl版本低于 TARGET_VERSION，请将管理员工作站升级到 TARGET_VERSION。
当您确定
gkectl和集群版本适合升级时，请下载软件包。检查管理员工作站上是否已存在软件包 tar 压缩包。
stat /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz
如果软件包不在管理员工作站上，请下载它。
gsutil cp gs://gke-on-prem-release/gke-onprem-bundle/TARGET_VERSION/gke-onprem-vsphere-TARGET_VERSION.tgz /var/lib/gke/bundles/
安装软件包。
gkectl prepare --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz --kubeconfig ADMIN_CLUSTER_KUBECONFIG
将 ADMIN_CLUSTER_KUBECONFIG 替换为您的 kubeconfig 文件的路径。 如果文件位于当前目录中且名称为
kubeconfig，则可以省略此标志。列出可用的集群版本，并确保目标版本包含在可用的用户集群版本中。
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
现在，您可以创建目标版本的用户集群，也可以将用户集群升级到目标版本。
升级流程问题排查
如果您在使用推荐的升级流程时遇到问题，请按照以下建议解决问题。这些建议假设您是从 1.10.x 设置开始，并且执行了推荐的升级流程。
另请参阅排查集群创建和升级问题。
排查用户集群升级问题
假设您在升级用户集群时发现升级版本存在问题。您从 Google 支持获知，该问题会在即将发布的补丁程序版本中得到解决。您可以按以下步骤操作：
- 继续在生产环境中使用当前版本。
- 在补丁程序版本发布后，在非生产集群中测试该补丁程序版本。
- 当您确信补丁程序版本可靠后，将所有生产用户集群升级到该补丁程序版本。
- 将管理员集群升级到该补丁程序版本。
排查管理员集群升级问题
如果您在升级管理员集群时遇到问题，则必须与 Google 支持团队联系以解决管理员集群相关问题。
同时，借助新的升级流程，您仍然可以利用新用户集群功能，而不受管理员集群升级的影响。这使您可以根据需要降低管理员集群的升级频率。您的升级流程可以按如下所示进行：
- 将生产用户集群升级到 1.11.x。
- 将管理员集群保持为早期版本，并继续接收安全补丁程序。
- 在测试环境中测试管理员集群从 1.10.x 到 1.11.x 的升级，如果出现问题则报告问题；
- 如果您的问题在 1.11.x 补丁程序版本中得到解决，则可以选择将生产管理员集群升级到该补丁程序版本（如果需要）。
当前版本的已知问题
以下已知问题可能会影响升级。
另请参阅已知问题。
如果数据磁盘几乎已满，则升级管理员工作站可能会失败
如果您使用 gkectl upgrade admin-workstation 命令升级管理员工作站，则当数据磁盘几乎已满时，升级可能会失败，因为系统会在升级到新的管理员工作站时尝试在本地备份当前的管理员工作站。如果无法清除数据磁盘上的足够空间，请使用带有附加标志 --backup-to-local=false 的 gkectl upgrade admin-workstation 命令来防止对当前管理工作站进行本地备份。
使用 PodDisruptionBudget 的工作负载中断
目前，升级集群可能会导致使用 PodDisruptionBudget (PDB) 的工作负载中断或停机。
节点无法完成升级过程
如果您配置的 PodDisruptionBudget 对象无法允许任何额外的中断，则节点升级可能会在反复尝试后仍无法升级到控制平面版本。为防止此故障，我们建议您扩容 Deployment 或 HorizontalPodAutoscaler，以允许节点排空，同时仍遵循 PodDisruptionBudget 配置。
如需查看不允许出现任何中断的所有 PodDisruptionBudget 对象，请运行以下命令：
kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'
附录
关于在 1.1.0-gke.6 版本中启用的 VMware DRS 规则
从 1.1.0-gke.6 版开始，Anthos clusters on VMware 会自动为您的用户集群节点创建 VMware 分布式资源调度器 (DRS) 反亲和性规则，使其分布到数据中心内的至少三个物理主机上。从 1.1.0-gke.6 版开始，此功能会自动为新集群和现有集群启用。
在升级之前，请确保您的 vSphere 环境满足以下条件：
VMware DRS 已启用。VMware DRS 需要 vSphere Enterprise Plus 许可版本。如需了解如何启用 DRS，请参阅在集群中启用 VMware DRS
凭据配置文件中提供的 vSphere 用户名具有
Host.Inventory.EditCluster权限。至少有三个物理主机可用。
如果 vSphere 环境不满足上述条件，您仍然可以升级，但如果要将用户集群从 1.3.x 升级到 1.4.x，则需要停用反亲和性群组。如需了解详情，请参阅 Anthos clusters on VMware 版本说明中的这个已知问题。
关于升级过程中的停机时间
| 资源 | 说明 |
|---|---|
| 管理员集群 | 当管理员集群关停时，用户集群上的用户集群控制层面和工作负载会继续运行，除非它们受到导致停机的故障的影响 |
| 用户集群控制层面 | 通常情况下，用户集群控制层面应该不会出现较长的停机时间。但是，与 Kubernetes API 服务器的长时间运行的连接可能会中断，需要重新建立连接。在这些情况下，API 调用方应该重试，直到建立连接。在最糟糕的情况下，升级期间的停机时间可能长达一分钟。 |
| 用户集群节点 | 如果升级需要更改用户集群节点，Anthos clusters on VMware 会以滚动方式重新创建节点，并重新安排在这些节点上运行的 Pod。您可以通过配置适当的 PodDisruptionBudget 和反亲和性规则来防止对工作负载产生影响。 |
如果信息文件缺失则重新创建
如果管理员工作站的输出信息文件缺失，则必须重新创建此文件，以便继续升级。此文件是在您最初创建工作站时创建的；如果您在之后进行了升级，则系统会使用新信息对此文件进行更新。
输出信息文件采用以下格式：
Admin workstation version: GKEADM_VERSION Created using gkeadm version: GKEADM_VERSION VM name: ADMIN_WS_NAME IP: ADMIN_WS_IP SSH key used: FULL_PATH_TO_ADMIN_WS_SSH_KEY To access your admin workstation: ssh -i FULL-PATH-TO-ADMIN-WS-SSH-KEY ubuntu@ADMIN-WS-IP
下面是一个输出信息文件示例：
Admin workstation version: v1.10.3-gke.49 Created using gkeadm version: v1.10.3-gke.49 VM name: admin-ws-janedoe IP: 172.16.91.21 SSH key used: /usr/local/google/home/janedoe/.ssh/gke-admin-workstation Upgraded from (rollback version): v1.10.0-gke.194 To access your admin workstation: ssh -i /usr/local/google/home/janedoe/.ssh/gke-admin-workstation ubuntu@172.16.91.21
在编辑器中创建文件，并替换相应的参数。使用与 gkeadm 运行所在目录中的虚拟机名称相同的文件名保存该文件。例如，如果虚拟机名称为 admin-ws-janedoe，请将文件保存为 admin-ws-janedoe。