Upgrading Google Distributed Cloud
When you install a new version of bmctl
, you can upgrade your existing
clusters that were created with an earlier version. Upgrading a cluster to the
latest Google Distributed Cloud version brings added features and fixes to your
cluster. It also ensures that your cluster remains
supported.
You can upgrade admin, hybrid, standalone, or user
clusters with the bmctl upgrade cluster
command.
Preflight checks are run before a cluster upgrade to validate cluster status and node health.
The following examples show the upgrade process from version 1.6.2 to Google Distributed Cloud 1.7.7.
You can upgrade any given version to the next available version (for example, 1.6.1 to 1.6.2) in the same fashion. Skip upgrades, such as 1.6.1 to 1.7.7, are also supported.
Google Distributed Cloud 1.7.0 and later versions support the configuration of up to 250 maximum pods per node. This configuration can only be done during cluster creation and cannot be updated for existing clusters, including clusters upgraded to 1.7.0 from a lower version and new 1.7.7 clusters.
Upgrading admin, standalone, hybrid, or user clusters Google Distributed Cloud
When you download and install a new version of bmctl
, you can upgrade your
admin, hybrid, standalone, and user clusters created with an earlier version.
For a given version of bmctl
, clusters can be upgraded to the same version
only.
First, you download the latest bmctl
, then modify the appropriate cluster
config files, and then you issue the bmctl upgrade cluster
command to complete
the upgrade.
Download the latest
bmctl
from the Cloud Storage bucket and usechmod
to givebmctl
execute permissions to all users:gcloud storage cp gs://anthos-baremetal-release/bmctl/1.7.7/linux-amd64/bmctl bmctl chmod a+x bmctl
Modify the cluster config file to change the Google Distributed Cloud cluster version from
1.6.2
to1.7.7
. The following shows an example from an admin cluster config:--- 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.6.2 to 1.7.7, shown below anthosBareMetalVersion: 1.7.7
When upgrading clusters to 1.7.7, you must register the clusters with Connect to your project fleet, if they have not been already.
- Manually create service accounts and retrieve the JSON key files as described in Configuring service accounts for use with Connect on the Enabling Google services and service accounts page.
- Reference the downloaded JSON keys in the associated
gkeConnectAgentServiceAccountKeyPath
andgkeConnectRegisterServiceAccountKeyPath
fields of the cluster config file.
Use the
bmctl upgrade cluster
command to complete the upgrade:bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
Replace the following:
- CLUSTER_NAME: the name of the cluster to upgrade.
- ADMIN_KUBECONFIG: the path to the admin cluster kubeconfig file.