安装新版 bmctl
时,您可以升级使用较早版本创建的现有集群。将集群升级到最新的 Anthos Clusters on Bare Metal 版本可为集群新增功能和修复,还可确保您的集群保持受支持状态。您可以使用 bmctl upgrade cluster
命令升级管理员集群、独立集群或用户集群。
升级注意事项
以下部分概述了升级集群之前要考虑的规则和最佳做法。
预览功能
预览版功能随时可能更改,并且仅用于测试和评估目的。请勿在生产集群上使用预览版功能。我们不能保证使用预览版功能的集群可以升级。在某些情况下,我们会明确阻止对使用预览版功能的集群进行升级。
如需了解与升级相关的破坏性更改,请参阅版本说明。
SELinux
如果要启用 SELinux 来保护容器,则必须确保在所有宿主机上以 Enforced
模式启用 SELinux。从 Anthos clusters on Bare Metal 1.9.0 版或更高版本开始,您可以在创建集群或升级集群之前或之后启用或停用 SELinux。Red Hat Enterprise Linux (RHEL) 和 CentOS 上默认启用 SELinux。如果宿主机上停用了 SELinux,或者不确定,请参阅使用 SELinux 保护容器,了解如何启用 SELinux。
Anthos clusters on Bare Metal 仅支持 RHEL 和 CentOS 系统中的 SELinux。
升级的版本规则
下载并安装新版本的 bmctl
时,您可以升级使用 bmctl
早期版本创建或升级的管理员集群、混合集群、独立集群和用户集群。集群不能降级到较低版本。
您只能将集群升级到与您正在使用的 bmctl
版本匹配的版本。也就是说,如果您使用的是 bmctl
1.13.10 版,则只能将集群升级到 1.13.10 版。
补丁版本升级
对于给定的次要版本,您可以升级到任何更高的补丁程序版本。也就是说,只要 Y
大于 X
,您就可以将 1.13.X
版本集群升级到版本 1.13.Y
。例如,您可以从 1.12.0
升级到 1.12.1
,也可以从 1.12.1
升级到 1.12.3
。我们建议您尽可能升级到最新的补丁程序版本,以确保您的集群拥有最新的安全修复程序。
次要版本升级
无论补丁程序版本如何,您都可将集群从一个次要版本升级到下一个次要版本。也就是说,您可以从 1.N.X
升级到 1.N+1.Y
;其中,1.N.X
是您的集群版本,N+1
是下一个可用的次要版本。在这种情况下,补丁程序版本 X
和 Y
不会影响升级逻辑。例如,您可以从 1.12.3
升级到 1.13.10
。
升级集群时,您无法跳过次要版本。如果您尝试升级到比集群版本高两个或更多的次要版本,次要版本 bmctl
会发出错误。例如,您无法将版本 1.11.0
的集群升级到版本 1.13.0
。
管理员集群可以管理相同或先前次要版本的用户集群。受管用户集群最多只能比管理员集群低一个次要版本,因此在将管理员集群升级到新的次要版本之前,请确保所有受管用户集群都与管理员集群处于同一次要版本中。
以下升级说明中的示例显示了从版本 1.12.2
到 Anthos clusters on Bare Metal 1.13.10
的升级过程。
自行管理的集群的就地升级
从 Anthos Clusters on Bare Metal 1.13.1 版开始,您可以在管理员集群、混合集群和独立集群上执行就地升级。就地升级不需要使用引导集群,这就简化了流程并降低了升级的资源要求。在您可以对自行管理的集群执行就地升级之前,该集群必须为 1.13.0 或更高版本。
要执行就地升级,您可以使用 bmctl
或 kubectl
:
bmctl
该升级过程与标准升级过程相同,但 bmctl upgrade cluster
命令除外。
如需开始就地升级,请在升级命令中使用
--use-bootstrap=false
标志:bmctl upgrade cluster -c CLUSTER_NAME --use-bootstrap=false \ --kubeconfig ADMIN_KUBECONFIG
请替换以下内容:
CLUSTER_NAME
:要升级的集群的名称。ADMIN_KUBECONFIG
:管理员集群 kubeconfig 文件的路径。
与标准升级过程一样,预检检查在集群升级的过程中运行,以验证集群状态和节点运行状况。如果预检检查失败,则系统会停止集群升级。如需排查任何故障问题,请检查集群和相关日志,因为未创建任何引导集群。
kubectl
如需使用 kubectl
升级自行管理的集群,请执行以下步骤:
修改集群配置文件,将
anthosBareMetalVersion
设置为升级目标版本。如需启动升级,请运行以下命令:
kubectl apply -f CLUSTER_CONFIG_PATH
将
CLUSTER_CONFIG_PATH
替换为集群配置文件的路径。
与标准升级过程一样,预检检查在集群升级的过程中运行,以验证集群状态和节点运行状况。如果预检检查失败,则系统会停止集群升级。如需排查任何故障问题,请检查集群和相关日志,因为未创建任何引导集群。
Pod 密度
Anthos clusters on Bare Metal 通过 nodeConfig.PodDensity.MaxPodsPerNode
支持每个节点最多配置 250 个 pod。您只能在创建集群期间配置 pod 密度。您无法更新现有集群的 pod 密度设置。
已知问题
如需了解与集群升级相关的潜在问题,请参阅“已知问题”页面上的升级 Anthos clusters on Bare Metal。
升级管理员集群、独立集群、混合集群或用户集群
下载并安装新版 bmctl
时,您可以升级使用较早版本创建的管理员集群、混合集群、独立集群和用户集群。对于给定的 bmctl
版本,集群只能升级到同一版本。
首先,您需要下载最新的 bmctl
,然后修改相应的集群配置文件,最后发出 bmctl upgrade cluster
命令以完成升级。
从 Cloud Storage 存储桶下载最新的
bmctl
,然后使用chmod
向所有用户授予bmctl
执行权限:gsutil cp gs://anthos-baremetal-release/bmctl/1.13.10/linux-amd64/bmctl bmctl chmod a+x bmctl
修改集群配置文件,将 Anthos clusters on Bare Metal 集群版本从
1.12.2
更改为1.13.10
。下面显示了来自管理员集群配置的示例:--- apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: cluster1 namespace: cluster-cluster1 spec: # Cluster type. This can be: # 1) admin: to create an admin cluster. This can later be used to create user clusters. # 2) user: to create a user cluster. Requires an existing admin cluster. # 3) hybrid: to create a hybrid cluster that runs admin cluster components and user workloads. # 4) standalone: to create a cluster that manages itself, runs user workloads, but does not manage other clusters. type: admin # Anthos cluster version. # Change the following line from 1.12.2 to 1.13.10, shown below anthosBareMetalVersion: 1.13.10
将集群升级到
1.13.10
时,您必须通过 Connect 将项目注册到项目舰队(如果尚未注册)。- 按照“启用 Google 服务和服务账号”页面上的配置服务账号以与 Connect 搭配使用中的说明,手动创建服务账号并检索 JSON 密钥文件。
- 在集群配置文件的关联
gkeConnectAgentServiceAccountKeyPath
和gkeConnectRegisterServiceAccountKeyPath
字段中引用下载的 JSON 密钥。
使用
bmctl upgrade cluster
命令完成升级:bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
请替换以下内容:
CLUSTER_NAME
:要升级的集群的名称。ADMIN_KUBECONFIG
:管理员集群 kubeconfig 文件的路径。
预检检查在集群升级的过程中运行,以验证集群状态和节点运行状况。如果预检检查失败,则不会继续集群升级。