1.0 版。如 Anthos 版本支持政策中所述,此版本已不再受支持。如需获取影响 VMware 上的 Anthos 集群 (GKE On-Prem) 的安全漏洞、威胁和问题的最新补丁程序和更新,请升级到支持的版本。您可以在此处找到最新版本。

升级集群

本页面介绍如何将管理员集群和用户集群从一个 GKE On-Prem 补丁程序版本升级到下一个更高版本。如需了解可用的版本,请参阅版本

另请参阅:

概览

GKE On-Prem 支持依序升级。例如,假设以下版本是唯一存在的版本:

  • 1.0.10
  • 1.0.X,其中 X 在 .10 后
  • 1.0.Y,其中 Y 在 X 后

在本例中,1.0.Y 是最新版本。要将版本 1.0.10 集群升级到 1.0.Y,请按以下步骤操作:

  1. 将集群从 1.0.10 升级到 1.0.X。
  2. 然后,将集群从 1.0.X 升级到 1.0.Y。

准备工作

  1. 通过 SSH 连接到管理员工作站:

    ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
    
  2. 授权 gcloud 访问 Google Cloud:

    gcloud auth login
  3. 激活您的访问服务帐号:

    gcloud auth activate-service-account --project [PROJECT_ID] \
    --key-file [ACCESS_KEY_FILE]
    

    其中:

    • [PROJECT_ID] 是项目 ID。
    • [ACCESS_KEY_FILE] 是访问服务帐号的 JSON 密钥文件的路径,如 /home/ubuntu/access.json

升级到版本 1.0.2

1.0.2-gke.3 版中添加了以下必需的 OIDC 字段 (usercluster.oidc)。这些字段可让您通过 Cloud Console 登录集群:

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

如果您不想通过 Cloud Console 登录集群,但想要使用 OIDC,则可以为这些字段传入占位值:

oidc:
  kubectlredirecturl: "redirect.invalid"
  clientsecret: "secret"
  usehttpproxy: "false"

确定集群升级方案

在升级集群之前,请先确定以下哪种情况与您要升级到的版本相关:

情况 需要执行的操作 备注
版本没有安全更新。
  1. 下载最新的 gkectl
  2. 下载最新的软件包
  3. 按照本页面上的说明操作。
版本有安全更新。
  1. 下载最新的管理员工作站 OVA
  2. 升级您的管理员工作站
  3. 按照本页面上的说明操作。
只有在新版本包含安全更新时,您才需要升级管理员工作站。当您升级管理员工作站时,它会包含最新的 gkectl 和软件包。

确定平台版本

要升级集群,您需要确定集群的平台版本:

来自文档

请参阅版本

来自软件包

运行以下命令,将软件包提取到临时目录:

tar -xvzf /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION].tgz -C [TEMP_DIR]

浏览提取的 YAML 文件,大致了解软件包中的内容。

具体而言,请打开 gke-onprem-vsphere-[VERSION]-images.yaml。查看 osimages 字段。您可以在操作系统映像文件的名称中查看 GKE 平台版本。例如,在以下操作系统映像中,您可以看到 GKE 平台版本为 1.12.7-gke.19

osImages:
  admin: "gs://gke-on-prem-os-ubuntu-release/gke-on-prem-osimage-1.12.7-gke.19-20190516-905ef43658.ova"

修改配置文件

在管理员工作站虚拟机上,修改您的配置文件。设置 gkeplatformversionbundlepath 的值。例如:

gkeplatformversion: 1.12.7-gke.19
bundlepath: /var/lib/gke/bundles/gke-onprem-vsphere-1.0.10.tgz

运行 gkectl prepare

运行以下命令:

gkectl prepare --config [CONFIG_FILE]

gkectl prepare 命令可执行以下任务:

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

  • 将新软件包中指定的已更新 Docker 映像推送到您的私有 Docker 注册表(如果您已配置)。

升级集群

要升级用户集群,管理员集群的版本不得低于用户集群升级的目标版本。如果管理员集群版本低于用户集群升级的目标版本,请在升级用户集群之前先升级管理员集群。

管理员集群

运行以下命令:

gkectl upgrade admin \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE]

其中,[ADMIN_CLUSTER_KUBECONFIG] 是管理员集群的 kubeconfig 文件,[CONFIG_FILE] 是您用于执行升级的 GKE On-Prem 配置文件。

用户集群

运行以下命令:

gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE] \
--cluster-name [CLUSTER_NAME]

其中,[ADMIN_CLUSTER_KUBECONFIG] 是管理员集群的 kubeconfig 文件,[CLUSTER_NAME] 是您要升级的用户集群的名称,[CONFIG_FILE] 是您用于执行升级的 GKE On-Prem 配置文件。

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

资源 说明
管理员集群

当管理员集群关闭时,用户集群上的用户集群控制层面和工作负载会继续运行,除非它们受到导致停机的故障的影响

用户集群控制层面

通常情况下,用户集群控制层面应该不会出现较长的停机时间。但是,与 Kubernetes API 服务器的长时间运行的连接可能会中断,需要重新建立连接。在这些情况下,API 调用方应该重试,直到建立连接。在最糟糕的情况下,升级期间的停机时间可能长达一分钟。

用户集群节点

如果升级需要更改用户集群节点,GKE On-Prem 会以滚动方式重新创建节点,并重新安排在这些节点上运行的 pod。您可以通过配置适当的 PodDisruptionBudget反亲和性规则来防止对工作负载产生影响。

已知问题

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

问题排查

如需了解详情,请参阅问题排查

已创建新节点,但运行状况不佳

表现

在使用手动负载平衡模式时,新节点不会自行向用户集群控制层面注册。

可能的原因

可能启用了节点内 Ingress 验证,导致节点的启动流程被阻止。

解决方法

如需停用验证,请运行以下命令:

kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p '{"spec":{"template":{"spec":{"providerSpec":{"value":{"machineVariables":{"net_validation_ports": null}}}}}}}' --type=merge

使用 gkectl 诊断集群问题

使用 gkectl diagnose 命令识别集群问题并与 Google 共享集群信息。请参阅诊断集群问题

默认日志记录行为

对于 gkectlgkeadm,使用默认日志记录设置便已足够:

  • 默认情况下,日志条目的保存方式如下:

    • 对于 gkectl,默认日志文件为 /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log,该文件与运行 gkectl 的本地目录中的 logs/gkectl-$(date).log 文件进行符号链接。
    • 对于 gkeadm,默认日志文件是运行 gkeadm 的本地目录中的 logs/gkeadm-$(date).log
  • 所有日志条目都会保存在日志文件中,即使它们不输出到终端(当 --alsologtostderrfalse 时)也是如此。
  • -v5 详细程度(默认)涵盖支持团队所需的所有日志条目。
  • 日志文件还包含已执行的命令和失败消息。

我们建议您在需要帮助时将日志文件发送给支持团队。

为日志文件指定非默认位置

要为 gkectl 日志文件指定非默认位置,请使用 --log_file 标志。您指定的日志文件不会与本地目录进行符号链接。

要为 gkeadm 日志文件指定非默认位置,请使用 --log_file 标志。

在管理员集群中查找 Cluster API 日志

如果虚拟机在管理员控制层面启动后无法启动,您可以通过在管理员集群中检查 Cluster API 控制器的日志来尝试进行调试:

  1. kube-system 命名空间中找到 Cluster API 控制器 pod 的名称,其中 [ADMIN_CLUSTER_KUBECONFIG] 是管理员集群的 kubeconfig 文件的路径:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
  2. 打开 pod 的日志,其中 [POD_NAME] 是 pod 的名称。您可以选择使用 grep 或类似工具来搜索错误:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager