本页面介绍如何升级 GKE on VMware。如果用户集群由 Anthos On-Prem API 管理，并且您想要使用 Google Cloud 控制台或 Google Cloud CLI 升级集群，请参阅使用 Anthos On-Prem API 客户端升级用户集群。
升级流程概述
您可以直接升级到同一或下一次要发布版本中的任何版本。例如，您可以从 1.14.0 升级到 1.14.1，或从 1.13.1 升级到 1.14.0。
如果您要升级到非下一个次要版本，则必须在当前版本和所需版本之间升级每个次要版本的一个版本。例如，如果您要从版本 1.12.2 升级到版本 1.14.0，则无法直接升级，您必须先从 1.12.2 升级到 1.13.x，然后再升级到 1.14.0。
本主题介绍了如何从 1.13.x 版升级到 1.14.y 版。
在开始升级过程之前，请查看集群升级最佳做法。
以下是升级的一般工作流。
将管理员工作站升级到目标版本。
在管理员工作站上，升级用户集群。
所有用户集群都升级后，您便可以从管理员工作站升级管理员集群。此步骤不是必须执行的步骤，除非您需要使用该项升级提供的功能。
用户集群的异步升级
对于用户集群的升级，gkectl upgrade cluster 命令有两个变体：
- 异步（推荐）
- 同步
使用异步变体时，该命令会开始升级，然后完成。在升级的整个过程中，您无需观察该命令的输出。您可以通过运行 gkectl list clusters 和 gkectl describe clusters 来定期检查升级进度。
如需使用异步变体，请在该命令中添加 --async 标志。如需了解详情，请参阅升级用户集群。
升级期间的证书轮替
在升级期间，叶证书将会轮替，但 CA 证书不会轮替。您必须每五年至少手动轮替 CA 证书一次。如需了解详情，请参阅轮替用户集群证书授权机构和轮替管理员集群 CA 证书。
准备升级
在开始升级之前，请截取集群的快照。升级过程中出现问题时，快照将帮助您进行问题排查。
创建管理员工作站之前，您填写了由 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 地址。请参阅管理节点 IP 地址以确定您需要的 IP 地址数量。
升级用户集群
您可以在命令行中执行两种类型的用户集群升级：
- 异步
- 同步
异步升级
在管理员工作站上继续执行以下步骤：
运行
gkectl prepare，将操作系统映像导入 vSphere：gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
如果您的集群具有 Windows 节点池，请运行
gkectl prepare windows并更新该节点池的osImage字段。如需查看详细说明，请参阅升级具有 Windows 节点池的用户集群。运行升级前工具以检查集群运行状况和配置。
在用户集群配置文件中，将
gkeOnPremVersion设置为升级操作的目标版本。在管理员工作站上，启动异步升级：
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG \ --async
上述命令完成后，您便可以在升级过程中继续使用您的用户集群。
如需查看升级的状态，请运行以下命令：
gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG
输出会显示集群
STATE的值。如果集群仍在升级，则STATE的值为UPGRADING。例如：NAMESPACE NAME READY STATE AGE VERSION my-uc-gkeonprem-mgmt my-uc False UPGRADING 9h 1.14.0-gke.1
STATE的可能值包括PROVISIONING、UPGRADING、DELETING、UPDATING、RUNNING、RECONCILING、ERROR和UNKNOWN。如需获取有关升级进度和集群事件的详细信息，请运行以下命令：
gkectl describe clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --cluster USER_CLUSTER_NAME -v 5
输出会显示指定用户集群的 OnPremUserCluster 自定义资源，其中包括集群状态、条件和事件。
我们记录了每个关键升级阶段的开始和结束的事件，包括：
- ControlPlaneUpgrade
- MasterNodeUpgrade
- AddonsUpgrade
- NodePoolsUpgrade
输出示例：
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal NodePoolsUpgradeStarted 22m onprem-user-cluster-controller Creating or updating node pools: pool-2: Creating or updating node pool Normal AddonsUpgradeStarted 22m onprem-user-cluster-controller Creating or updating addon workloads Normal ControlPlaneUpgradeStarted 25m onprem-user-cluster-controller Creating or updating cluster control plane workloads: deploying user-kube-apiserver-base, ...: 14/15 pods are ready Normal ControlPlaneUpgradeFinished 23m onprem-user-cluster-controller Control plane is running
升级完成后，
gkectl list clusters会显示STATUS为RUNNING：NAMESPACE NAME READY STATE AGE VERSION my-uc-gkeonprem-mgmt my-uc True RUNNING 9h 1.14.0-gke.1
此外，升级完成后，
gkectl describe clusters会在Status下显示一个LastGKEOnPremVersion字段。例如：Status: Cluster State: RUNNING LastGKEOnOremVersion: 1.14.0-gke.1
排查异步升级问题
对于异步升级，超时时长取决于集群中的节点数。如果升级花费的时间超过超时时长，则集群状态会从 UPGRADING 更改为 ERROR，并且事件表示升级操作超时。请注意，此处的 ERROR 状态表示升级花费的时间超过预期，但尚未终止。控制器会继续进行协调，并不断重试操作。
超时通常是由 PodDisruptionBudget (PDB) 引起的死锁的结果。在这种情况下，无法从旧节点中逐出 Pod，并且无法排空旧节点。如果 Pod 逐出花费的时间超过 10 分钟，我们会向 OnPremUserCluster 对象写入一个事件。您可以通过运行 gkectl describe clusters 来捕获该事件。然后，您可以调整 PDB 以允许节点排空。之后，升级便可以继续进行并最终完成。
事件示例
Warning PodEvictionTooLong 96s (x2 over 4m7s) onprem-user-cluster-controller Waiting too long(>10m0.00000003s) for (kube-system/coredns-856d6dbfdf-dl6nz) eviction.
此外，当升级被阻止或失败时，您可以运行 gkectl diagnose 来检查是否存在常见的集群问题。根据检查结果，您可以决定是执行手动修复，还是联系 Anthos 支持团队以获取进一步帮助。
同步升级
gkectl upgrade 命令运行预检检查。如果预检检查失败，则该命令会被屏蔽。您必须修复故障，或使用 --skip-preflight-check-blocking 标志。只有在您确信没有任何严重故障时，才应跳过预检检查。
在管理员工作站上继续执行以下步骤：
运行
gkectl prepare，将操作系统映像导入 vSphere：gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
如果您的集群具有 Windows 节点池，请运行
gkectl prepare windows并更新该节点池的osImage字段。如需查看详细说明，请参阅升级具有 Windows 节点池的用户集群。运行升级前工具以检查集群运行状况和配置。
在用户集群配置文件中，将
gkeOnPremVersion设置为升级操作的目标版本。升级集群：
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
如果您要升级到 1.14.0 版或更高版本，系统会为用户集群生成新的 kubeconfig 文件，该文件会覆盖任何现有文件。如需查看此文件中的集群详情，请运行以下命令：
kubectl config view --kubeconfig USER_CLUSTER_KUBECONFIG
恢复升级
如果用户集群升级中断，您可以通过运行带 --skip-validation-all 标志的同一升级命令来恢复用户集群升级：
gkectl upgrade cluster \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE \
--skip-validation-all
升级管理员集群
须知事项：
确定您的证书是否是最新的，并根据需要进行续订。
如果您要升级到 1.13 版或更高版本，则必须先填写管理员集群配置文件中的
gkeConnect部分来注册管理员集群。根据配置文件更改运行 update cluster 命令。
请在新的管理员工作站上执行本部分中的步骤。 请确保您的 gkectl 和集群是适合进行升级的版本，并且您已下载合适的软件包。
确保管理员集群配置文件中的
bundlepath字段与您要升级到的软件包的路径相匹配。如果您对管理员集群配置文件中的字段进行了其他任何更改，则升级期间会忽略这些更改。如需使这些更改生效，您必须先升级集群，然后根据配置文件更改运行 update cluster 命令，以对集群进行其他更改。
运行升级前工具以检查集群运行状况和配置。
运行以下命令：
gkectl upgrade admin \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config ADMIN_CLUSTER_CONFIG_FILE \ FLAGS替换以下内容：
ADMIN_CLUSTER_KUBECONFIG：管理员集群的 kubeconfig 文件。
ADMIN_CLUSTER_CONFIG_FILE：新管理员工作站上的 GKE on VMware 管理员集群配置文件。
FLAGS：一组可选的标志。例如，您可以添加
--skip-validation-infra标志以跳过检查 vSphere 基础架构这一步。
如果您要升级到 1.14.0 版或更高版本，系统会为管理员集群生成新的 kubeconfig 文件，该文件会覆盖任何现有文件。如需查看此文件中的集群详情，请运行以下命令：
kubectl config view --kubeconfig ADMIN_CLUSTER_KUBECONFIG
如果您下载了整个软件包，而且已成功运行 gkectl prepare 和 gkectl upgrade admin 命令，您现在应删除整个软件包以节省管理员工作站上的磁盘空间。使用以下命令：
rm /var/lib/gke/bundles/gke-onprem-vsphere-${TARGET_VERSION}-full.tgz
恢复管理员集群升级
管理员集群升级中断或失败时，如果管理员集群检查点包含恢复中断之前状态所需的状态，则可以继续升级。
警告：升级失败后，请勿使用 gkectl repair admin-master 修复管理员主节点。这将导致管理员集群进入错误状态。
请按照以下步骤操作：
在开始初始升级尝试之前，检查管理员控制层面的运行状况是否良好。 请参阅诊断集群问题。如该主题中所述，为管理员集群运行
gkectl diagnose cluster命令。如果管理员控制层面在初始升级尝试之前运行状况不佳，请使用
gkectl repair admin-master命令修复管理员控制层面。在升级中断或失败后重新运行升级命令时，请使用与之前的升级尝试相同的软件包和目标版本。
重新运行升级命令时，恢复的升级会从检查点重新创建管理员集群状态，并重新运行整个升级。从 1.12.0 开始，如果管理员控制平面健康状况不佳，升级过程将直接升级到目标版本，而不会在继续升级之前尝试恢复源版本的管理员集群。
从管理员集群故障可用或退出的位置恢复升级。如果该检查点不可用，则升级将回退到依赖于管理员控制层面，因此管理员控制层面必须运行状况良好才能继续升级。成功升级后，系统会重新生成检查点。
如果 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.11，并且您想要升级到 1.12.x，则必须执行多次升级。一次升级一个次要版本，直到升级到 1.11.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.11.x 设置开始，并且执行了推荐的升级流程。
另请参阅排查集群创建和升级问题。
排查用户集群升级问题
假设您在升级用户集群时发现升级版本存在问题。您从 Google 支持获知，该问题会在即将发布的补丁程序版本中得到解决。您可以按以下步骤操作：
- 继续在生产环境中使用当前版本。
- 在补丁程序版本发布后，在非生产集群中测试该补丁程序版本。
- 当您确信补丁程序版本可靠后，将所有生产用户集群升级到该补丁程序版本。
- 将管理员集群升级到该补丁程序版本。
排查管理员集群升级问题
如果您在升级管理员集群时遇到问题，则必须与 Google 支持团队联系以解决管理员集群相关问题。
同时，借助新的升级流程，您仍然可以利用新用户集群功能，而不受管理员集群升级的影响。这使您可以根据需要降低管理员集群的升级频率。您的升级流程可以按如下所示进行：
- 将生产用户集群升级到 1.12.x。
- 将管理员集群保持为早期版本，并继续接收安全补丁程序。
- 在测试环境中测试管理员集群从 1.11.x 升级到 1.12.x，如果出现问题则报告问题；
- 如果您的问题在 1.12.x 补丁程序版本中得到解决，则可以选择将生产管理员集群升级到该补丁程序版本（如果需要）。
当前版本的已知问题
如果您从 1.7 版或更高版本升级，以下已知问题可能会影响升级。
另请参阅已知问题。
如果数据磁盘几乎已满，则升级管理员工作站可能会失败
如果您使用 gkectl upgrade admin-workstation 命令升级管理员工作站，则当数据磁盘几乎已满时，升级可能会失败，因为系统会在升级到新的管理员工作站时尝试在本地备份当前的管理员工作站。如果无法清除数据磁盘上的足够空间，请使用带有附加标志 --backup-to-local=false 的 gkectl upgrade admin-workstation 命令来防止对当前管理工作站进行本地备份。
使用 PodDisruptionBudget 的工作负载中断
目前，升级集群可能会导致使用 PodDisruptionBudgets (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 版本开始，GKE 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，则需要停用反亲和性群组。如需了解详情，请参阅 GKE on VMware 版本说明中的此已知问题。
关于升级过程中的停机时间
| 资源 | 说明 |
|---|---|
| 管理员集群 | 当管理员集群关停时，用户集群上的用户集群控制层面和工作负载会继续运行，除非它们受到导致停机的故障的影响 |
| 用户集群控制层面 | 通常情况下，用户集群控制层面应该不会出现较长的停机时间。但是，与 Kubernetes API 服务器的长时间运行的连接可能会中断，需要重新建立连接。在这些情况下，API 调用方应该重试，直到建立连接。在最糟糕的情况下，升级期间的停机时间可能长达一分钟。 |
| 用户集群节点 | 如果升级需要更改用户集群节点，GKE on VMware 会以滚动方式重新创建节点，并重新安排在这些节点上运行的 Pod。您可以通过配置适当的 PodDisruptionBudgets 和反亲和性规则来防止对工作负载产生影响。 |
如果信息文件缺失则重新创建
如果管理员工作站的输出信息文件缺失，则必须重新创建此文件，以便继续升级。此文件是在您最初创建工作站时创建的；如果您在之后进行了升级，则系统会使用新信息对此文件进行更新。
输出信息文件采用以下格式：
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。