Upgrading Google Distributed Cloud

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.

1. Download the latest bmctl from the Cloud Storage bucket and use chmod to give bmctl execute permissions to all users:

    gcloud  
   storage  
   cp  
   gs://anthos-baremetal-release/bmctl/1.7.7/linux-amd64/bmctl  
   bmctl
   chmod  
   a+x  
   bmctl 
   

2. Modify the cluster config file to change the Google Distributed Cloud cluster version from 1.6.2 to 1.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 
    
   

3. When upgrading clusters to 1.7.7, you must register the clusters with Connect to your project fleet, if they have not been already.

   1. 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.
   2. Reference the downloaded JSON keys in the associated gkeConnectAgentServiceAccountKeyPath and gkeConnectRegisterServiceAccountKeyPath fields of the cluster config file.

4. 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.