在 1.29 及更高版本中,Google Distributed Cloud 允许用户集群的控制平面最多比集群中的节点池高两个次要版本。例如,如果用户集群的控制平面为 1.29,则集群中的节点池可以是版本 1.16、1.28 或 1.29。此外,Google Distributed Cloud 还可让您在升级节点池时跳过一个次要版本。使用前面的示例,您可以将版本 1.16 的节点池直接升级到版本 1.29,并跳过升级到 1.28 的过程。升级节点池时跳过次要版本称为“跳过版本升级”。
本页面介绍了跳过版本升级的一些优势,并提供了相关步骤,说明如何通过进行配置文件更改并运行 gkectl upgrade cluster
来执行跳过版本升级。
本页面适用于管理底层技术基础架构生命周期的 IT 管理员和运维人员。如需详细了解我们在 Google Cloud 内容中提及的常见角色和示例任务,请参阅常见的 GKE 用户角色和任务。 本页面假定您对规划和执行 Google Distributed Cloud 升级有一定的了解,如以下页面中所述:
限制
跳过版本升级具有以下限制:
Ubuntu 和 COS 节点池支持跳过版本升级,但 Windows 节点池不支持。
1.31 版:此功能不适用于高级集群。
1.32 版及更高版本:此功能适用于高级集群。
由于 Kubernetes 限制条件,用户集群的控制平面必须一次升级一个次要版本。但请注意,与升级运行工作负载的节点池相比,仅升级控制平面所花费的时间要少得多,风险也更低。
跳过版本升级的优势
本部分介绍了使用跳过版本升级的一些优势。
更轻松地让集群使用受支持的版本
新的 Google Distributed Cloud 次要版本每四个月发布一次,每个次要版本的支持期为一年。为了让您的集群保持在支持期内,您必须大约每四个月执行一次次要版本升级,如下所示:
12 月 |
1 月 |
2 月 |
3 月 |
4 月 |
5 月 |
6 月 |
7 月 |
8 月 |
9 月 |
10 月 |
11 月 |
12 月 |
1 月 |
2 月 |
3 月 |
4 月 |
5 月 |
6 月 |
7 月 |
8 月 |
9 月 |
10 月 |
11 月 |
12 月 |
1 月 |
2 月 |
3 月 |
1.14 | 升级 | ||||||||||||||||||||||||||
1.15 | 升级 | ||||||||||||||||||||||||||
1.16 | 升级 | ||||||||||||||||||||||||||
1.28 | 升级 | ||||||||||||||||||||||||||
1.29 | 升级 |
如果您需要较长的验证窗口来验证新的次要版本,并且需要较短的维护窗口将集群升级到新的次要版本,则此要求会带来挑战。为了克服这些挑战,您可以采用跳过版本升级,这样一来,您只需每 8 个月升级一次集群,而不是每 4 个月升级一次,即可确保集群始终在支持期内。下表显示了跳过 1.15 版升级意味着您只能在 8 个月后升级,而不是 4 个月后。
12 月 |
1 月 |
2 月 |
3 月 |
4 月 |
5 月 |
6 月 |
7 月 |
8 月 |
9 月 |
10 月 |
11 月 |
12 月 |
1 月 |
2 月 |
3 月 |
4 月 |
5 月 |
6 月 |
7 月 |
8 月 |
9 月 |
10 月 |
11 月 |
12 月 |
1 月 |
2 月 |
3 月 |
1.14 | 升级 | ||||||||||||||||||||||||||
1.15 | |||||||||||||||||||||||||||
1.16 | 升级 | ||||||||||||||||||||||||||
1.28 | |||||||||||||||||||||||||||
1.29 |
升级节点池时跳过一个次要版本可减少继续使用受支持的版本所需的升级次数。此外,您不需要限定跳过的次要版本,因为它仅由控制平面临时使用。
维护窗口缩短
使用跳过版本升级时,您无需延长维护窗口。升级节点池时跳过某个次要版本所需的时间与将节点池升级到下一个次要版本所需的时间相同,因为节点池中的每个节点都会被排空并重新创建一次。因此,跳过版本升级可节省总体时间并减少工作负载中断。
摘要
总而言之,跳过版本升级具有以下优势:
让集群使用受支持的版本:Google Distributed Cloud 支持三个最新的次要版本。如果您的集群使用的是不受支持的版本,则根据集群版本,在升级节点池时跳过次要版本可让集群使用受支持的版本且升级次数较少。
节省时间:升级节点池时跳过某个次要版本所需的时间与将节点池升级到下一个次要版本所需的时间相同。因此,跳过版本升级所需的时间约为升级节点池两次所需时间的一半。同样,跳过版本升级只有一个验证窗口,而常规升级有两个。
减少中断:升级间隔时间更长,升级和验证所花费的时间更少,这意味着您的工作负载可以运行更长时间,中断次数更少。
在升级期间控制控制平面和节点池版本
在用户集群配置文件中,nodePools[i].gkeOnPremVersion 字段允许特定节点池使用与顶级 gkeOnPremVersion 字段不同的版本。通过更改 nodePools[i].gkeOnPremVersion
字段的值,您可以在运行 gkectl upgrade cluster
时控制节点池升级的时间。如果您未在配置文件中添加 nodePools[i].gkeOnPremVersion
,或者将该字段设置为空字符串,则节点池会升级到您在 gkeOnPremVersion
中指定的同一目标版本。
版本规则
升级规则取决于集群次要版本。
对于 1.30 及更低版本,用户集群次要版本必须大于或等于管理员集群次要版本。补丁版本无关紧要。例如,如果用户集群的版本为 1.30.1,则管理员集群可以升级到更高补丁版本(例如 1.30.3)。
对于 1.31 及更高版本,管理员集群版本(包括补丁版本)必须大于或等于用户集群版本。例如,如果管理员集群的版本为 1.31.1,则用户集群可升级到的最高版本为 1.31.1。
如果您想将集群升级到 1.31 版,则必须先将所有集群升级到 1.30 版。所有集群都升级到 1.30 版后,您可以将管理员集群升级到 1.31 版。之后,您可以将用户集群升级到与管理员集群相同的 1.31 补丁版本。
跳过版本升级序列
升级管理员集群和用户集群的序列取决于您要升级到的集群版本(称为目标版本):
1.32 及更高版本
如果目标版本为 1.32 或更高版本,请使用此序列。假设用户集群控制平面和所有节点池都处于次要版本 1.N
。使用跳过版本升级将集群从 1.N
升级到 1.N+2
的流程大致如下:
- 将管理员集群从版本
1.N
升级到中间版本1.N+1
。 - 将管理员集群从中间版本
1.N+1
升级到目标版本1.N+2
。 - 仅将用户集群控制平面从来源版本
1.N
升级到中间版本1.N+1
。请将节点池保留为来源版本。之所以需要中间版本,是因为控制平面必须一次升级一个次要版本。 - 将控制平面和节点池升级到目标版本
1.N+2
。
1.31
如果用户集群的版本为 1.29,请使用此特殊序列,这意味着目标版本为 1.31。如果用户集群的版本为 1.29,则管理用户集群的管理员集群的版本可以是 1.27、1.28 或 1.29。
- 如果管理员集群为 1.27 版,请将其升级到 1.28。
- 如果管理员集群为 1.28 版,请将其升级到 1.29。
- 仅将用户集群控制平面从来源版本 1.29 升级到中间版本 1.30。请将节点池保留为来源版本。之所以需要中间版本 1.30,是因为控制平面必须一次升级一个次要版本。
- 将管理员集群从 1.29 版升级到中间版本 1.30。
- 将管理员集群升级到目标版本 1.31。
- 将用户集群控制平面和节点池升级到目标版本 1.31。
1.30 及更低版本
如果目标版本为 1.30 或更低版本,请使用此序列。
假设用户集群控制平面和所有节点池都处于次要版本 1.N
。使用跳过版本升级将集群从 1.N
升级到 1.N+2
的流程大致如下:
- 仅将控制平面从来源版本
1.N
升级到中间版本1.N+1
。请将节点池保留为来源版本。之所以需要中间版本,是因为控制平面必须一次升级一个次要版本。 - 将控制平面和节点池升级到目标版本
1.N+2
。
执行跳过版本升级
本部分介绍了执行跳过版本升级的步骤。
准备工作
确保集群的当前版本(来源版本)为 1.16 版或更高版本。请务必检查控制平面 (
gkeOnPremVersion
) 和所有节点池 (nodePools[i].gkeOnPremVersion
) 的版本。在 1.29 版及更高版本中,服务器端预检检查默认处于启用状态。请务必查看防火墙规则,以便进行任何所需的更改。
如需升级到 1.28 版及更高版本,您必须启用
kubernetesmetadata.googleapis.com
并将kubernetesmetadata.publisher
IAM 角色授予日志记录监控服务账号。如需了解详情,请参阅 Google API 和 IAM 要求。
执行升级
1.31
如果用户集群的版本为 1.29(意味着目标版本为 1.31),请使用此特殊序列。之所以需要此序列,是因为版本规则在 1.31 版中发生了变化。
如果用户集群的版本为 1.29,则管理用户集群的管理员集群的版本可以是 1.27、1.28 或 1.29。
如果管理员集群的版本为 1.27,请按照相关步骤将管理员工作站升级到 1.28 版并将管理员集群升级到 1.28 版。
如果管理员集群的版本为 1.28,请按照相关步骤将管理员工作站升级到 1.29 版并将管理员集群升级到 1.29 版。
为了节省管理员工作站的空间,请移除已下载的软件包:
rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz
如果管理员集群和所有用户集群均为 1.29 版,您可以开始跳过版本升级。
在以下占位变量中定义来源版本 (1.29)、中间版本 (1.30) 和目标版本 (1.31)。所有版本都必须是采用
x.y.z-gke.N
格式的完整版本号,例如1.29.700-gke.110
。版本 获取当前用户集群的 1.29 版。这是来源版本。 SOURCE_VERSION
选择中间版本 1.30。 INTERMEDIATE_VERSION
选择目标版本 1.31。从次要版本 1.31 中选择建议的补丁。 TARGET_VERSION
将管理员工作站升级到中间版本 1.30
INTERMEDIATE_VERSION
。等待指示升级成功的消息。安装相应的软件包:
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
再次升级管理员工作站,但这次升级到目标版本 1.31
TARGET_VERSION
。等待指示升级成功的消息。安装相应的软件包:
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
仅将用户集群控制平面升级到中间版本,如下所示:
在用户集群配置文件中进行以下更改:
将
gkeOnPremVersion
字段设置为中间版本INTERMEDIATE_VERSION
。将
nodePools[i].gkeOnPremVersion
中的所有节点池版本设置为来源版本SOURCE_VERSION
。
更新配置文件后,该文件应如下所示:
gkeOnPremVersion: INTERMEDIATE_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: SOURCE_VERSION ... - name: pool-2 gkeOnPremVersion: SOURCE_VERSION ...
升级控制平面:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
将
USER_CLUSTER_CONFIG
替换为用户集群配置文件的路径。
将管理员集群配置文件中的
bundlePath
字段设置为软件包的中间版本 1.30:bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz"
将管理员集群升级到中间版本 1.30:
gkectl upgrade admin \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config ADMIN_CLUSTER_CONFIG_FILE
将管理员集群配置文件中的
bundlePath
字段设置为软件包的目标版本 1.31:bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz"
Upgrade the admin cluster to the target 1.31 version:
gkectl upgrade admin \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config ADMIN_CLUSTER_CONFIG_FILE
将控制平面和节点池升级到目标版本,具体如下:
在用户集群配置文件中进行以下更改:
将
gkeOnPremVersion
字段设置为目标版本TARGET_VERSION
。将所有
nodePools[i].gkeOnPremVersion
设置为空字符串。
更新配置文件后,该文件应如下所示:
gkeOnPremVersion: TARGET_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: "" ... - name: pool-2 gkeOnPremVersion: "" ...
升级控制平面和节点池:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
1.30 及更低版本
如果目标版本为 1.30 或更低版本,请使用此序列。
在以下占位变量中定义来源版本 (
1.N
)、中间版本 (1.N+1
) 和目标版本 (1.N+2
)。所有版本都必须是采用x.y.z-gke.N
格式的完整版本号,例如1.16.11-gke.25
。版本 获取当前的集群版本。这是来源版本 ( 1.N
)。SOURCE_VERSION
选择中间版本 ( 1.N+1
)。INTERMEDIATE_VERSION
选择目标版本 ( 1.N+2
)。从目标次要版本中选择建议的补丁。TARGET_VERSION
将管理员工作站升级到中间版本
INTERMEDIATE_VERSION
。等待指示升级成功的消息。安装相应的软件包:
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
将
ADMIN_CLUSTER_KUBECONFIG
替换为管理员集群kubeconfig
文件的路径。再次升级管理员工作站,但这次升级到目标版本
TARGET_VERSION
。等待指示升级成功的消息。安装相应的软件包:
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
仅将控制平面升级到中间版本,具体如下:
在用户集群配置文件中进行以下更改:
将
gkeOnPremVersion
字段设置为中间版本INTERMEDIATE_VERSION
。将
nodePools[i].gkeOnPremVersion
中的所有节点池版本设置为来源版本SOURCE_VERSION
。
更新配置文件后,该文件应如下所示:
gkeOnPremVersion: INTERMEDIATE_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: SOURCE_VERSION ... - name: pool-2 gkeOnPremVersion: SOURCE_VERSION ...
升级控制平面:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
将
USER_CLUSTER_CONFIG
替换为用户集群配置文件的路径。
将控制平面和节点池升级到目标版本,具体如下:
在用户集群配置文件中进行以下更改:
将
gkeOnPremVersion
字段设置为目标版本TARGET_VERSION
。将所有
nodePools[i].gkeOnPremVersion
设置为空字符串。
更新配置文件后,该文件应如下所示:
gkeOnPremVersion: TARGET_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: "" ... - name: pool-2 gkeOnPremVersion: "" ...
升级控制平面和节点池:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
如果您没有任何其他用户集群需要升级,请从管理员工作站中移除软件包以节省空间:
rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz