本页面介绍如何将管理员集群和用户集群从一个 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.0.10 升级到 1.0.X。
- 然后，将集群从 1.0.X 升级到 1.0.Y。
准备工作
通过 SSH 连接到管理员工作站：
ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
授权
gcloud访问 Google Cloud：gcloud auth login
激活您的访问服务帐号：
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)。这些字段可让您从 Google Cloud 控制台登录集群：
- usercluster.oidc.kubectlredirecturl
- usercluster.oidc.clientsecret
- usercluster.oidc.usehttpproxy
如果您不想通过 Google Cloud 控制台登录集群，但想要使用 OIDC，则可以为这些字段传入占位值：
oidc: kubectlredirecturl: "redirect.invalid" clientsecret: "secret" usehttpproxy: "false"
确定集群升级方案
在升级集群之前，请先确定以下哪种情况与您要升级到的版本相关：
| 情况 | 需要执行的操作 | 备注 |
|---|---|---|
| 版本没有安全更新。 |
|
|
| 版本有安全更新。 |
|
只有在新版本包含安全更新时，您才需要升级管理员工作站。当您升级管理员工作站时，它会包含最新的 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"
修改配置文件
在管理员工作站虚拟机上，修改您的配置文件。设置 gkeplatformversion 和 bundlepath 的值。例如：
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 共享集群信息。请参阅诊断集群问题。
默认日志记录行为
对于 gkectl 和 gkeadm，使用默认日志记录设置便已足够：
-
默认情况下，日志条目的保存方式如下：
- 对于
gkectl，默认日志文件为/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log，该文件与运行gkectl的本地目录中的logs/gkectl-$(date).log文件进行符号链接。 - 对于
gkeadm，默认日志文件是运行gkeadm的本地目录中的logs/gkeadm-$(date).log。
- 对于
- 所有日志条目都会保存在日志文件中，即使它们不输出到终端（当
--alsologtostderr为false时）也是如此。 -v5详细程度（默认）涵盖支持团队所需的所有日志条目。- 日志文件还包含已执行的命令和失败消息。
我们建议您在需要帮助时将日志文件发送给支持团队。
为日志文件指定非默认位置
要为 gkectl 日志文件指定非默认位置，请使用 --log_file 标志。您指定的日志文件不会与本地目录进行符号链接。
要为 gkeadm 日志文件指定非默认位置，请使用 --log_file 标志。
在管理员集群中查找 Cluster API 日志
如果虚拟机在管理员控制层面启动后无法启动，您可以通过在管理员集群中检查 Cluster API 控制器的日志来尝试进行调试：
在
kube-system命名空间中找到 Cluster API 控制器 pod 的名称，其中 [ADMIN_CLUSTER_KUBECONFIG] 是管理员集群的 kubeconfig 文件的路径：kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
打开 pod 的日志，其中 [POD_NAME] 是 pod 的名称。您可以选择使用
grep或类似工具来搜索错误：kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager