升级 Anthos clusters on VMware

本页面介绍如何升级 VMware 上的 Anthos 集群 (GKE On-Prem)。

目标版本

从 VMware 上的 Anthos 集群 1.3.2 版开始，您可以直接升级到同一或下一次要发布版本中的任何版本。例如，您可以从 1.3.2 升级到 1.3.5，或从 1.5.2 升级到 1.6.1。

如果当前版本低于 1.3.2，则必须先依序升级到 1.3.2 版。例如，如需从 1.3.0 升级到 1.3.2，您必须先从 1.3.0 升级到 1.3.1，然后再从 1.3.1 升级到 1.3.2。

如果您要从 1.3.2 版或更高版本升级到非下一个次要版本，则必须在当前版本和所需版本之间升级每个次要版本的一个版本。例如，如果您要从 1.3.2 版升级到 1.6.1 版，则无法直接升级。您必须先从 1.3.2 版升级到 1.4.x 版，其中 x 表示该次要版本下的任何补丁程序版本。然后，您可以升级到 1.5.x 版，最后升级到 1.6.1 版。

注意：如果您将 Anthos clusters on VMware 与 Anthos Service Mesh 1.7 或更高版本搭配使用，并且要升级到 1.6.0-1.6.3 或 1.7.0-1.7.2，请参阅此已知问题。

升级流程概述

1. 下载 gkeadm 工具。gkeadm 的版本必须与升级的目标版本相同。

2. 使用 gkeadm 升级管理员工作站。

3. 在管理员工作站上，升级管理员集群。

4. 在管理员工作站上，升级用户集群。

升级政策

升级管理员集群后，请执行以下操作：

• 您创建的任何新用户集群的版本必须与管理员集群的版本相同。

• 如果要升级现有用户集群，您必须升级到与管理员集群相同的版本。

• 在再次升级管理员集群之前，必须将所有用户集群升级到与当前管理员集群相同的版本。

找到您的配置文件和信息文件

创建当前管理员工作站时，请填写由 gkeadm create config 生成的管理员工作站配置文件。此文件的默认名称为 admin-ws-config.yaml。

创建当前管理员工作站时，gkeadm 会为您创建一个信息文件。此文件的默认名称与您当前管理员工作站的名称相同。

找到您的管理员工作站配置文件和信息文件。您需要它们来完成本指南中的步骤。如果这些文件在当前目录中并且具有默认名称，则运行 gkeadm upgrade admin-workstation 时无需指定它们。如果这些文件位于其他目录中，或者您更改了文件名，则可以使用 --config 和 --info-file 标志进行指定。

升级管理员工作站

如需升级管理员工作站，请先下载新版 gkeadm 工具，然后使用该工具升级管理员工作站的配置。gkeadm 的版本必须与升级的目标版本相匹配。

下载 gkeadm

如需下载适当的 gkeadm 版本，请按照下载页面上的说明操作。

升级管理员工作站

gkeadm upgrade admin-workstation --config [AW_CONFIG_FILE] --info-file [INFO_FILE]

其中：

• [AW_CONFIG_FILE] 是管理员工作站配置文件的路径。如果文件位于当前目录中且名称为 admin-ws-config.yaml，则可以省略此标志。

• [INFO_FILE] 是信息文件的路径。如果文件位于当前目录中，则可以省略此标志。此文件的默认名称与管理员工作站的名称相同。

上述命令会执行以下任务：

• 备份当前管理员工作站的主目录中的所有文件。其中包括：

  • Anthos clusters on VMware 配置文件。此文件的默认名称为 config.yaml。

  • 管理员集群和用户集群的 kubeconfig 文件。

  • vCenter 服务器的根证书。请注意，此文件必须具有所有者读写权限。

  • 组件访问服务帐号的 JSON 密钥文件。请注意，此文件必须具有所有者读写权限。

  • 用于连接和注册、连接和代理以及日志记录监控服务帐号的 JSON 密钥文件。

• 创建新的管理员工作站，并将所有备份文件复制到新的管理员工作站。

• 删除旧的管理员工作站。

更新节点操作系统映像和 Docker 映像

在新的管理员工作站上，运行以下命令：

gkectl prepare --config [ADMIN_CONFIG] [FLAGS]

其中：

• [ADMIN_CONFIG] 是管理员集群配置文件的路径。

• [FLAGS] 是一组可选的标志。例如，您可以添加 --skip-validation-infra 标志以跳过检查 vSphere 基础架构这一步。

上述命令会执行以下任务：

• 如有必要，请将新的节点操作系统映像复制到 vSphere 环境，并将操作系统映像标记为模板。

• 如果您已配置了私有 Docker 注册表，请将更新后的 Docker 映像推送到私有 Docker 注册表。

验证是否有足够的可用 IP 地址

请在新的管理员工作站上执行本部分中的步骤。

在升级之前，请确保您有足够的 IP 地址可供集群使用。

DHCP

在您升级管理员集群时，Anthos clusters on VMware 会在管理员集群中创建一个临时节点。在您升级用户集群时，Anthos clusters on VMware 会在该用户集群中创建一个临时节点。临时节点的目的是确保不间断的可用性。在升级集群之前，请确保您的 DHCP 服务器可以为临时节点提供足够的 IP 地址。如需了解详情，请参阅管理员集群和用户集群所需的 IP 地址。

静态 IP

在您升级管理员集群时，Anthos clusters on VMware 会在管理员集群中创建一个临时节点。在您升级用户集群时，Anthos clusters on VMware 会在该用户集群中创建一个临时节点。临时节点的目的是确保不间断的可用性。在升级集群之前，请验证您是否预留了足够的 IP 地址。对于每个集群，您预留的 IP 地址数必须至少比集群节点数多一个。如需了解详情，请参阅配置静态 IP 地址。

确定管理员集群中的节点数量：

kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes

其中，[ADMIN_CLUSTER_KUBECONFIG] 是管理员集群的 kubeconfig 文件的路径。

接下来，查看为管理员集群预留的地址：

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -o yaml

在输出中，您可以在 reservedAddresses 字段中查看为管理员集群节点预留的 IP 地址数。例如，以下输出显示为管理员集群节点预留了五个 IP 地址：

...
reservedAddresses:
- gateway: 21.0.135.254
  hostname: admin-node-1
  ip: 21.0.133.41
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-2
  ip: 21.0.133.50
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-3
  ip: 21.0.133.56
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-4
  ip: 21.0.133.47
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-5
  ip: 21.0.133.44
  netmask: 21

预留 IP 地址的数量应至少比管理员集群中的节点数量多一个。否则，您可以通过修改集群对象来预留一个额外的地址。

打开集群对象进行修改：

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

在 reservedAddresses 下，添加一个包含 gateway、hostname、ip 和 netmask 的块。

要确定用户集群中的节点数量，请运行以下命令：

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes

其中，[USER_CLUSTER_KUBECONFIG] 是用户集群的 kubeconfig 文件的路径。

要查看为用户集群预留的地址，请运行以下命令：

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml

其中：

• [ADMIN_CLUSTER_KUBECONFIG] 是管理员集群的 kubeconfig 文件的路径。

• [USER_CLUSTER_NAME] 是用户集群的名称。

预留的 IP 地址的数量应大于用户集群中的节点数。否则，请执行以下步骤：

• 打开用户集群的 IP 地址块文件进行修改。

• 将其他 IP 地址添加到地址块，然后关闭该文件。

• 更新用户集群：

  gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONIFG] \
    --config [USER_CLUSTER_CONFIG]
  

（可选）停用新的 vSphere 功能

新的 Anthos clusters on VMware 版本可能会包含新功能或对特定 VMware vSphere 功能的支持。有时，升级到某个 Anthos clusters on VMware 版本会自动启用此类功能。如需了解新功能，请参阅 Anthos clusters on VMware 的版本说明。新功能有时会在 Anthos clusters on VMware 配置文件中呈现。

如需停用在新的 Anthos clusters on VMware 版本中自动启用和由配置文件驱动的新功能，请在升级集群之前执行以下步骤：

1. 从升级后的管理员工作站中创建一个新的配置文件，并使用与当前配置文件不同的名称：

   gkectl create-config --config [CONFIG_NAME]

2. 打开新配置文件并记下该功能的字段。关闭文件。

3. 打开当前配置文件并添加新功能的字段。将字段的值设置为 false 或等效值。

4. 保存配置文件。

升级集群之前，请查看版本说明。升级后，您将无法以声明方式更改现有集群的配置。

升级管理员集群

注意：在开始此升级之前，请确定您的证书是否是最新的，并根据需要续订。

请在新的管理员工作站上执行本部分中的步骤。

回想一下，升级的目标版本必须与 gkeadm 版本相同。

运行以下命令：

gkectl upgrade admin \
    --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    --config [ADMIN_CLUSTER_CONFIG_FILE] \
    [FLAGS]

其中：

• [ADMIN_CLUSTER_KUBECONFIG] 是管理员集群的 kubeconfig 文件的路径。

• 其中 [ADMIN_CLUSTER_CONFIG_FILE] 是管理员集群配置文件的路径。

• [FLAGS] 是一组可选的标志。例如，您可以添加 --skip-validation-infra 标志以跳过检查 vSphere 基础架构这一步。

注意：这不会升级管理员集群中的所有节点，因为管理员集群中的部分节点是用户集群的控制层面节点。升级用户集群时，这些管理员集群也会升级。

注意：gkectl upgrade 命令会运行预检检查。如果预检检查失败，该命令会被屏蔽。您必须修复失败，或在命令中使用 --skip-preflight-check-blocking 标志来取消屏蔽命令。

升级用户集群

请在新的管理员工作站上执行本部分中的步骤。

回想一下，升级的目标版本必须与 gkeadm 版本相同。

gkectl

gkectl upgrade cluster \
    --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    --config [USER_CLUSTER_CONFIG_FILE] \
    [FLAGS]

其中：

• 其中，[ADMIN_CLUSTER_KUBECONFIG] 是管理员集群的 kubeconfig 文件的路径。

• [USER_CLUSTER_CONFIG_FILE] 是用户集群配置文件的路径。

• [FLAGS] 是一组可选的标志。例如，您可以添加 --skip-validation-infra 标志以跳过检查 vSphere 基础架构这一步。

控制台

您可以选择在用户集群安装期间或创建后向 Google Cloud 控制台注册用户集群。您可以在 Google Cloud 控制台中查看并登录到已注册的 Anthos 集群和 GKE 集群。

当用户集群有可用的升级时，Google Cloud 控制台中会显示一条通知。点击此通知会显示可用版本的列表以及可用于升级集群的 gkectl 命令：

1. 访问 Google Cloud 控制台中的 Google Kubernetes Engine 页面。

   访问 Google Kubernetes Engine 页面

2. 在用户集群的通知列下，点击现在可升级（如有）。

3. 复制 gkectl upgrade cluster 命令。

4. 在管理员工作站上，运行 gkectl upgrade cluster 命令，其中 [ADMIN_CLUSTER_KUBECONFIG] 是管理员集群的 kubeconfig 文件的路径，[CLUSTER_NAME] 是要升级的用户集群的名称，[USER_CLUSTER_CONFIG_FILE] 是用户集群配置文件的路径。

注意：gkectl upgrade 命令会运行预检检查。如果预检检查失败，该命令会被屏蔽。您必须修复失败或将 --skip-preflight-check-blocking 标志与该命令结合使用。

恢复升级

如果用户集群升级中断，您可以通过运行带 --skip-validation-all 标志的同一升级命令来恢复升级：

gkectl upgrade cluster \
    --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    --config [USER_CLUSTER_CONFIG_FILE] \
    --cluster-name [CLUSTER_NAME] \
    --skip-validation-all

恢复管理员集群升级

您不应中断管理员集群升级。管理员集群升级并非总是可以恢复。如果管理员集群升级因任何原因中断，您应该联系支持团队寻求帮助。

升级后创建新的用户集群

升级管理员工作站和管理员集群后，您创建的任何新用户集群的版本必须与升级目标版本相同。

VMware DRS 规则

Anthos clusters on VMware 会自动为您的用户集群节点创建 VMware 分布式资源调度器 (DRS) 反亲和性规则，使其分布到数据中心内的至少三个物理主机上。 此功能会自动为新集群和现有集群启用。

在升级之前，请确保您的 vSphere 环境满足以下条件：

• VMware DRS 已启用。VMware DRS 需要 vSphere Enterprise Plus 许可版本。如需了解如何启用 DRS，请参阅在集群中启用 VMware DRS
• 在 vcenter 字段中提供的 vSphere 用户帐号拥有 Host.Inventory.EditCluster 权限。
• 至少有三个物理主机可用。

如果 vSphere 环境不满足上述条件，您仍然可以升级，但如果要将用户集群从 1.3.x 升级到 1.4.x，则需要停用反亲和性群组。如需了解详情，请参阅 1.4.0 版的版本说明。

停机时间

关于升级过程中的停机时间

资源	说明
管理员集群	当管理员集群关停时，用户集群上的用户集群控制层面和工作负载会继续运行，除非它们受到导致停机的故障的影响
用户集群控制层面	通常情况下，用户集群控制层面应该不会出现较长的停机时间。但是，与 Kubernetes API 服务器的长时间运行的连接可能会中断，需要重新建立连接。在这些情况下，API 调用方应该重试，直到建立连接。在最糟糕的情况下，升级期间的停机时间可能长达一分钟。 注意：如果用户集群节点在升级过程中无法访问用户控制层面，则系统不会为集群安排新的工作负载。现有工作负载不受影响。
用户集群节点	如果升级需要更改用户集群节点，Anthos clusters on VMware 会以滚动方式重新创建节点，并重新安排在这些节点上运行的 Pod。您可以通过配置适当的 PodDisruptionBudget 和反亲和性规则来防止对工作负载产生影响。

已知问题

请参阅已知问题。

问题排查

请参阅排查集群创建和升级问题