升级 Anthos clusters on VMware

10

本页面介绍如何升级 Anthos clusters on VMware (GKE On-Prem)。

升级流程概述

您可以直接升级到同一或下一次要发布版本中的任何版本。例如，您可以从 1.8.0 升级到 1.8.3，或从 1.8.1 升级到 1.9.0。

如果您要升级到非下一个次要版本，则必须在当前版本和所需版本之间升级每个次要版本的一个版本。例如，如果您要从 1.8.2 版升级到 1.10.0 版，则无法直接升级。您必须先从 1.8.2 版升级到 1.9.x 版，然后再升级到 1.10.0 版。

先升级管理员工作站，然后升级用户集群，最后升级管理员集群。如果您希望管理员集群保持当前版本，在升级用户集群后无需立即升级管理员集群。

  1. 下载 gkeadm 工具。gkeadm 的版本必须与升级的目标版本相同。
  2. 升级管理员工作站。
  3. 在管理员工作站上，升级用户集群。
  4. 在管理员工作站上，升级管理员集群。

假设您的管理员工作站、管理员集群和用户集群当前使用 1.9.x 版，并且您希望将管理员集群和用户集群升级到 1.10.x 版。如果您遵循以下升级路径，并在继续操作之前使用 Canary 版集群进行测试，则可以最大限度地降低中断的风险。

下面简要介绍了建议的升级流程。在开始之前，请创建一个使用 1.9.x 版的 Canary 用户集群（如果您尚未这样做）。

  1. 在 Canary 版集群中测试 1.10.x 版。
    • 将管理员工作站升级到版本 1.10.x。
    • 运行 gkectl prepare 命令（如下所述）来设置升级。
    • 将 Canary 版用户集群升级到版本 1.10.x。
  2. 如果您确信版本为 1.10.x，请将所有生产用户集群升级到版本 1.10.x。
  3. 将管理员集群升级到 1.10.x 版。

找到您的配置和信息文件以为升级做好准备

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

此外，您的工作站还具有信息文件。此文件的默认名称与您当前管理员工作站的名称相同。

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

如果输出信息文件缺失，您可以重新创建。

如果信息文件缺失则重新创建

如果管理员工作站的输出信息文件缺失，则必须重新创建此文件，以便继续升级。此文件是在您最初创建工作站时创建的；如果您在之后进行了升级，则系统会使用新信息对此文件进行更新。

输出信息文件采用以下格式：

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。

升级管理员工作站

请确保您的 gkectl 和集群处于适合进行升级的版本级别，并且您已下载合适的软件包。

运行此命令：

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 部分中所述。

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 地址的数量应至少比管理员集群中的节点数量多一个。

针对 1.7 版及更高版本，如需将 IP 地址添加到管理员集群，请执行以下操作：

首先修改 IP 地址块文件，如以下示例所示。

blocks:
- netmask: "255.255.252.0"
  ips:
  - ip: 172.16.20.10
    hostname: admin-host1
  - ip: 172.16.20.11
    hostname: admin-host2
  # Newly-added IPs.
  - ip: 172.16.20.12
    hostname: admin-host3

接下来，运行以下命令来更新配置。

gkectl update admin --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [ADMIN_CONFIG_FILE]

  • [ADMIN_CLUSTER_KUBECONFIG] 是 kubeconfig 文件的路径。

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

您无法移除 IP 地址，只能添加。

对于 1.7 之前的版本，您可以通过直接修改 Cluster 对象来添加其他地址。

打开集群对象进行修改：

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

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

重要提示：从 1.5.0 开始，此步骤不适用于用户集群，并且您必须为每个集群使用 gkectl update cluster。

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

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 地址块文件中，请基于 netmask 和 gateway 将地址添加到相应的块中。

  • 将所需数量的额外静态 IP 地址添加到相应的块中，然后运行 gkectl update cluster。

安装软件包以进行升级

要使某个版本可用于集群创建或升级，您必须安装相应的软件包。按照以下步骤安装 TARGET_VERSION （即要升级到的版本号）的软件包。

如需查看当前的 gkectl 和集群版本，请运行以下命令。如需查看详细信息，请使用 --details/-d 标志。

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

以下是输出示例：

gkectl version: 1.7.2-gke.2 (git-5b8ef94a3)onprem user cluster controller version: 1.6.2-gke.0
current admin cluster version: 1.6.2-gke.0
current user cluster versions (VERSION: CLUSTER_NAMES):
- 1.6.2-gke.0: user-cluster1
available admin cluster versions:
- 1.6.2-gke.0
available user cluster versions:
- 1.6.2-gke.0
- 1.7.2-gke.2
Info: The admin workstation and gkectl is NOT ready to upgrade to "1.8" yet, because there are "1.6" clusters.
Info: The admin cluster can't be upgraded to "1.7", because there are still "1.6" user clusters.

根据获得的输出结果查找以下问题，并视需要修复问题。

  • 如果 gkectl 版本低于 1.7，则无法直接使用新的升级流程。请按照原始升级流程将所有集群升级到 1.6，然后将管理员工作站升级到 1.7 以开始使用新的升级流程。

  • 如果当前管理员集群版本比 TARGET_VERSION 低一个次要版本以上，请将所有集群升级到比 TARGET_VERSION 低一个次要版本的版本。

  • 如果 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

现在，您可以创建目标版本的用户集群，也可以将用户集群升级到目标版本。

升级后回滚管理员工作站

您可以将管理员工作站回滚到升级前使用的版本。

升级期间，gkeadm 会在输出信息文件中记录升级之前的版本。在回滚期间，gkeadm 会使用列出的版本下载较旧的文件。

如需将管理员工作站回滚到之前的版本，请执行以下操作：

gkeadm rollback admin-workstation --config=AW_CONFIG_FILE

如果您的管理员工作站配置文件是默认的 admin-ws-config.yaml，则可以省略 --config=AW_CONFIG_FILE。否则，请将 AW_CONFIG_FILE 替换为管理员工作站配置文件的路径。

回滚命令会执行以下步骤：

  1. 下载 gkeadm 的回滚版本。
  2. 备份当前管理员工作站的主目录。
  3. 使用 gkeadm 的回滚版本创建新的管理员工作站。
  4. 删除原始管理员工作站。

升级用户集群

在继续升级之前，请注意以下事项：

  • 如果用户集群未注册，则您必须注册该用户集群，然后才能将其升级到 1.10 版。

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

  • 注意：从 1.10 版开始，Anthos clusters on VMware 包含手动负载均衡器的 konnectivityServerNodePort。请确保您为此节点端口指定适当的值、使用此节点端口配置负载均衡器，以及在升级之前在配置文件中添加此新节点端口。请参阅手动负载均衡。

在管理员工作站上继续执行以下步骤：

  1. 确保管理员集群配置文件中的 bundlepath 字段与您要升级到的软件包的路径相匹配。

  2. 确保用户集群配置文件中的 gkeOnPremVersion 字段与您要升级到的版本相匹配。

    如果您对管理员集群配置文件或用户集群配置文件中的字段进行了其他任何更改，则升级期间会忽略这些更改。要使这些更改生效，您必须先升级集群，然后运行包含配置文件更改的 update 命令，以对集群进行其他更改。

  3. 使用以下命令进行升级。

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

    其中：

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

    • [USER_CLUSTER_CONFIG_FILE] 是新管理员工作站上的 Anthos clusters on VMware 用户集群配置文件。

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

继续升级

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

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

升级管理员集群

请在新的管理员工作站上执行本部分中的步骤。 请确保您的 gkectl 和集群处于适合进行升级的版本级别，并且您已下载合适的软件包。

  1. 确保管理员集群配置文件中的 bundlepath 字段与您要升级到的软件包的路径相匹配。

    如果您对管理员集群配置文件中的字段进行了其他任何更改，则升级期间会忽略这些更改。要使这些更改生效，您必须先升级集群，然后运行包含配置文件更改的 update 命令，以对集群进行其他更改。

gkectl 版本必须等于或高于目标升级版本。因此，如果您的 gkectl 版本为 1.10.0，则可以将集群升级到 1.10.0 或 1.9.x。当所有用户集群都升级到某个次要版本后，管理员集群只能升级到该次要版本。

  1. 运行以下命令：

    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 基础架构这一步。

如果您下载了整个软件包，而且已成功运行 gkectl prepare 和 gkectl upgrade admin 命令，您现在应删除整个软件包以节省管理员工作站上的磁盘空间。使用以下命令：

rm /var/lib/gke/bundles/gke-onprem-vsphere-${TARGET_VERSION}-full.tgz

恢复管理员集群升级

管理员集群升级中断或失败时，如果管理员集群检查点包含恢复中断之前状态所需的状态，则可以继续升级。

请按照以下步骤操作：

  1. 在开始初始升级尝试之前，检查管理员控制层面的运行状况是否良好。
  2. 如果管理员控制层面在初始升级尝试之前运行状况不佳，请使用 gkectl repair admin-master 命令修复管理员控制层面。
  3. 在升级中断或失败后重新运行升级命令时，请使用与之前的升级尝试相同的软件包和目标版本。

重新运行升级命令时，恢复的升级会从检查点重新创建种类集群中的状态，并重新运行整个升级。如果管理员控制层面运行状况不佳，则必须先恢复该实例，然后再继续升级。

从管理员集群故障可用或退出的位置恢复升级。如果该检查点不可用，则升级将回退到依赖于管理员控制层面，因此管理员控制层面必须运行状况良好才能继续升级。成功升级后，系统会重新生成检查点。

如果 gkectl 在管理员集群升级期间意外退出，则系统不会清理种类集群。在重新运行升级命令以恢复升级之前，请删除种类集群：

docker stop gkectl-control-plane && docker rm gkectl-control-plane

删除种类集群后，再次运行升级命令。

升级流程问题排查

如果您在使用推荐的升级流程时遇到问题，请按照以下建议解决问题。这些建议假设您是从 1.6.2 设置开始，并且执行了推荐的升级流程。

排查用户集群升级问题

假设您在测试 Canary 版集群或升级用户集群时遇到 1.7 版相关问题。您从 Google 支持获知，该问题会在即将发布的补丁程序版本 1.7.x 中得到解决。您可以按以下步骤操作：

  1. 继续在生产环境中使用 1.6.2；
  2. 1.7.x 补丁程序版本发布后，在 Canary 版集群中对其进行测试。
  3. 当您确信 1.7.x 可靠后，将所有生产用户集群升级到 1.7.x。
  4. 将管理员集群升级到 1.7.x。

在测试 1.7 时管理 1.6.x 补丁程序版本

假设您正在测试或迁移到 1.7，但尚未确信它是可靠的，并且管理员集群仍使用 1.6.2。您发现重大 1.6.x 补丁程序版本已发布。您仍可以使用此 1.6.x 补丁程序版本，同时继续测试 1.7。请遵循以下升级流程：

  1. 安装 1.6.x-gke.0 软件包。
  2. 将所有 1.6.2 生产用户集群升级到 1.6.x。
  3. 将管理员集群升级到 1.6.x。

排查管理员集群升级问题

如果您在升级管理员集群时遇到问题，则必须与 Google 支持团队联系以解决管理员集群相关问题。

同时，借助新的升级流程，您仍然可以利用新用户集群功能，而不受管理员集群升级的影响。这使您可以根据需要降低管理员集群的升级频率。例如，您可能想要使用 1.7 版中发布的 Container-Optimized OS 节点池。您的升级流程可以按如下所示进行：

  1. 将生产用户集群升级到 1.7。
  2. 将管理员集群保持为 1.6 并继续接收安全补丁程序；
  3. 在测试环境中测试管理员集群从 1.6 到 1.7 的升级，如果出现问题则报告问题；
  4. 如果您的问题在 1.7 补丁程序版本中得到解决，则可以选择将生产管理员集群从 1.6 升级到此 1.7 补丁程序版本（如果需要）。

已知问题

以下已知问题会影响集群升级。

如果数据磁盘几乎已满，则升级管理员工作站可能会失败

如果您使用 gkectl upgrade admin-workstation 命令升级管理员工作站，则当数据磁盘几乎已满时，升级可能会失败，因为系统会在升级到新的管理员工作站时尝试在本地备份当前的管理员工作站。如果无法清除数据磁盘上的足够空间，请使用带有附加标志 --backup-to-local=false 的 gkectl upgrade admin-workstation 命令来防止对当前管理工作站进行本地备份。

1.7.0 版：Anthos Config Management 更新发生变化

在 1.7.0 之前的版本中，Anthos clusters on VMware 包含安装和升级 Anthos Config Management 所需的映像。从 1.7.0 开始，Anthos clusters on VMware 软件包中不再包含 Anthos Config Management 软件，您需要单独添加。如果您之前在集群上使用了 Anthos Config Management，则该软件在您执行相应操作之前不会进行升级。

如需详细了解如何安装 Anthos Config Management，请参阅安装 Anthos Config Management。

1.1.0-gke.6、1.2.0-gke.6 版本：stackdriver.proxyconfigsecretname 字段被移除

1.1.0-gke.6 版本中移除了 stackdriver.proxyconfigsecretname 字段。如果配置文件中有该字段，Anthos clusters on VMware 的预检检查将返回错误。

要解决此问题，请在升级到 1.2.0-gke.6 之前，从配置文件中删除 proxyconfigsecretname 字段。

Stackdriver 引用旧版本

对于 1.2.0-gke.6 之前的版本，一个已知问题阻止了 Stackdriver 在集群升级后更新其配置。Stackdriver 仍引用旧版本，这会阻止 Stackdriver 接收其遥测流水线的最新功能。此问题可能会导致 Google 支持人员难以排查集群问题。

将集群升级到 1.2.0-gke.6 后，请对管理员集群和用户集群运行以下命令：

kubectl --kubeconfig=[KUBECONFIG] \
-n kube-system --type=json patch stackdrivers stackdriver \
-p '[{"op":"remove","path":"/spec/version"}]'

其中，[KUBECONFIG] 是集群的 kubeconfig 文件的路径。

使用 PodDisruptionBudgets 的工作负载中断

目前，升级集群可能会导致使用 PodDisruptionBudget (PDB) 的工作负载中断或停机。

1.2.0-gke.6 版本：升级后 Prometheus 和 Grafana 被停用

在用户集群中，升级时会自动停用 Prometheus 和 Grafana。不过，配置和指标数据不会丢失。在管理员集群中，Prometheus 和 Grafana 保持启用状态。

如需相关说明，请参阅 Anthos clusters on VMware 版本说明。

1.1.2-gke.0 版本：已删除的用户集群节点未从 vSAN 数据存储区中移除

如需相关说明，请参阅 Anthos clusters on VMware 版本说明。

1.1.1-gke.2 版本：vSAN 数据存储区文件夹中的数据磁盘可以被删除

如果您使用的是 vSAN 数据存储区，则需要创建一个文件夹来保存 VMDK。已知问题要求您向 vcenter.datadisk 提供文件夹的通用唯一标识符 (UUID) 路径，而不是文件路径。这种不匹配可能会导致升级失败。

如需相关说明，请参阅 Anthos clusters on VMware 版本说明。

从 1.0.2-gke.3 版本升级到 1.1.0-gke.6 版本：OIDC 问题

配置了 OpenID Connect (OIDC) 的 1.0.11、1.0.1-gke.5、1.0.2-gke.3 版本集群无法升级到版本 1.1.0-gke.6。此问题在 1.1.1-gke.2 版本中已得到解决。

如果您在安装过程中配置了使用 OIDC 的 1.0.11、1.0.1-gke.5 或 1.0.2-gke.3 版本集群，则无法对其进行升级。您应改为创建新集群。

从 1.0.11 版本升级到 1.0.2-gke.3 版本

1.0.2-gke.3 版本引入了以下 OIDC 字段 (usercluster.oidc)。这些字段允许从 Google Cloud 控制台登录集群：

  • usercluster.oidc.kubectlredirecturl
  • usercluster.oidc.clientsecret
  • usercluster.oidc.usehttpproxy

如果要使用 OIDC，即使您不想从 Google Cloud 控制台登录集群，也必须填写 clientsecret 字段。为了使用 OIDC，您可能需要为 clientsecret 提供一个占位值：

oidc:
  clientsecret: "secret"

节点无法完成升级过程

如果您配置的 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 和反亲和性规则来防止对工作负载产生影响。

已知问题

请参阅已知问题。

问题排查

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