23. Upgrade Robin CNP Platform

You can upgrade Robin CNP using GoRobin utility using a single command or multistage upgrade.

23.1. Upgrade Using GoRobin Single command

You can upgrade Robin CNP 5.4.3 using the GoRobin utility. The GoRobin utility tool helps you install and upgrade related procedures.

Note

Contact the Robin Support team or Robin Account manager for upgrade files.

The GoRobin utility tool initiates an SSH session to access the nodes in the cluster and runs upgrade commands on all nodes of your cluster.

Note

When you upgrade using GoRobin, it automatically upgrades the Kubernetes versions if required.

23.1.1. Upgrade Paths for Robin CNP v5.4.3

Robin CNP Upgrade Paths

The following table displays the supported upgrade paths for Robin CNP and Kubernetes:

Robin CNP Upgrade

Kubernetes Upgrade

5.3.13 (GA) to 5.4.3 (GA)

1.21.5-> 1.22.5-> 1.23.8-> 1.24.8-> 1.25.4-> 1.26.0

5.4.1 (GA) to 5.4.3 (GA)

1.23.8-> 1.24.8-> 1.25.4-> 1.26.0

Note

If you are upgrading from any previous versions, you must first upgrade to Robin CNP Robin CNP v5.3.13 and then upgrade to Robin v5.4.3. For upgrade instructions, see the corresponding version documentation.

23.1.2. Prerequisites

Your Robin CNP cluster must meet the following prerequisites before upgrading to the latest version of Robin CNP:

  • Cluster must have an active Robin license.

  • Do not change the GoRobin tar file name.

  • All nodes in the Robin cluster must be accessible before starting the upgrade process.

  • Use Robin CNP super admin credentials for all upgrade steps.

  • All nodes in the cluster must be in sync with the NTP Server.

  • If a Kubernetes upgrade is required as part of the upgrade flow, any pods with a Pod Disruption Budget (PDB) configured must either be deleted beforehand or the associated PDB(s) must be configured such that the respective pods can be evicted cleanly while draining the node via kubeadm during the Kubernetes upgrade.

  • Robin CNP users must not perform any control plane operations during upgrade, including those associated with applications and volumes.

  • Remove any custom taints on master and worker nodes.

  • The root user needs to be present in the sudoers file located at /etc/sudoers

  • If you have hosts with different login credentials, prepare your host login credentials JSON file.

23.1.3. Host Login JSON File

You can use the GoRobin utility to perform upgrades on hosts with different login credentials using the host login JSON file.

Note

If you are using the host.json file for installation, you must use the --hosts-json command option as part of the installation in palace of --hosts.

The following is the sample host login JSON file.

{
      "hypervvm-65-6.robinsystems.com": {
            "password": "robin123",
            "role": "master",
            "user": "root",
            "port": "22"
      },
      "hypervvm-65-7.robinsystems.com": {
            "password": "robin123",
            "role": "master",
            "user": "root",
            "port": "22"
      },
      "hypervvm-65-8.robinsystems.com": {
            "password": "robin123",
            "role": "master",
            "user": "root",
            "port": "22"
      },
      "hypervvm-65-9.robinsystems.com": {
            "password": "robin123",
            "user": "root",
            "port": "22"
      }
}

23.1.4. Upgrade Steps

Below is a step-by-step example of how the GoRobin utility tool can be used to update a cluster to the latest version using a single command.

Note

When you upgrade using the single command option, the GoRobin utility tool automatically upgrades the Kubernetes versions if required.

23.1.4.1. Step 1 - Prepare for Upgrade

Complete the following steps to prepare for upgrading to Robin CNP v5.4.3:

  1. Verify all prerequisites and supported upgrade paths.

  2. Access your cluster using your login credentials.

  3. After you receive upgrade files from Robin.io, copy the upgrade files to your host system and untar the GoRobin binary and GoRobin tarfiles.

Note

Contact the Robin Support team or Robin Account manager for upgrade files.

23.1.4.2. Step 2 - Copy GoRobin Files to Nodes (Optional)

To copy the Gorobin upgrade tarfile to a particular set of nodes, the following command can be used. It is particuraly useful for large clusters as it copies the files parallely in order to save time.

# ./gorobin onprem copy-gorobin-tar --hosts <robin-primary-master-IP>
--gorobintar <path-to-gorobin-tarball> --robin-admin-user <robin-admin-user>
--robin-admin-passwd <robin-admin-passwd>

23.1.4.3. Step 3 - Upgrade Robin CNP

Run the following command to upgrade Robin CNP in a single step:

# ./gorobin onprem upgrade-cluster --hosts <robin-primary-master-IP>
--gorobintar <path-to-gorobin-tarball> --tar-url
<url-to-gorobin-tarball> --robin-admin-user
<robin-admin-user> --robin-admin-passwd <robin-admin-passwd>

Note

In the command, use the complete name of the GoRobin tar utility for --gorobintar name. For example, gorobintar-5.4.1-43.tar.

Important Command options for Upgrade

  • If you have already copied the GoROBIN tar to all nodes within the cluster, use the --skip-gorobintar-push parameter to avoid repeating the process and use the –dir option to specify the destination tar folder.

  • If all hosts in the Robin cluster are configured to allow passwordless SSH access, you can utilize the --sshnopwd.

  • If the GoRobin tar file is on an external server or artifactory, use the --tar-url option to download the tar files of installation.

Example

# ./gorobin_5.4.1-24 onprem upgrade-cluster --gorobintar /tmp/gorobintar-5.4.1-24.tar
--robin-admin-user robin --robin-admin-passwd Robin123
--hosts-json hosts.json  --ignore-warnings

Robin Upgrade will be performed on hosts -> ['qct-26.robinsystems.com',
'qct-27.robinsystems.com', 'qct-28.robinsystems.com']

- Checking network connectivity to primary Robin master manager node ->   qct-26.robinsystems.com ... DONE (0 secs)

- Checking network connectivity to host qct-26.robinsystems.com ... DONE   (0 secs)

- Checking network connectivity to host qct-27.robinsystems.com ... DONE
(0 secs)

- Checking network connectivity to host qct-28.robinsystems.com ... DONE
(0 secs)

- Running GoRobin Precheck on host qct-26.robinsystems.com ... DONE (0
secs)

- Running GoRobin Precheck on host qct-27.robinsystems.com ... DONE (0
secs)

- Running GoRobin Precheck on host qct-28.robinsystems.com ... DONE (0
secs)

K8S Upgrade to v1.23.8 will be executed on the cluster

This step will remove any existing Robin tars and re-copy new Robin tars
from /tmp/ folder on all nodes. Are you sure you want to proceed (y/n) ?
n

- Executing host specific pre-upgrade actions on all nodes in the
cluster ... DONE (44 secs)

- Executing K8S specific pre-upgrade actions on the cluster ... DONE (15
secs)

- Executing Robin Networking specific pre-upgrade actions on the cluster
... DONE (1 secs)

- Executing Robin specific pre-upgrade actions on primary master node in
the cluster ... DONE (97 secs)

- Executing Host specific upgrade actions on all nodes in the cluster
... DONE (1222 secs)

- Executing K8S configmaps/secrets upgrade on the primary K8S master
node in the cluster ... DONE (52 secs)

- Executing K8S configmaps/secrets upgrade on all K8S nodes in the
cluster ... DONE (35 secs)

Executing K8S upgrade on hosts -> qct-26.robinsystems.com,
qct-27.robinsystems.com, qct-28.robinsystems.com to K8S version 1.21.5

- Executing K8S specific upgrade actions on primary Robin master node in
the cluster -> qct-26.robinsystems.com ... DONE (14 secs)

- Executing K8S specific upgrade actions on secondary master nodes in
the cluster -> qct-27.robinsystems.com ... DONE (11 secs)

- Executing K8S specific upgrade actions on secondary master nodes in
the cluster -> qct-28.robinsystems.com ... DONE (10 secs)

Successfully executed K8S upgrade on hosts -> qct-26.robinsystems.com,
qct-27.robinsystems.com, qct-28.robinsystems.com to K8S version 1.21.5

Executing K8S upgrade on hosts -> qct-26.robinsystems.com,
qct-27.robinsystems.com, qct-28.robinsystems.com to K8S version 1.22.5

- Executing K8S specific upgrade actions on primary Robin master node in
the cluster -> qct-26.robinsystems.com ... DONE (323 secs)

- Executing K8S specific upgrade actions on secondary master nodes in
the cluster -> qct-27.robinsystems.com ... DONE (218 secs)

- Executing K8S specific upgrade actions on secondary master nodes in
the cluster -> qct-28.robinsystems.com ... DONE (225 secs)

Successfully executed K8S upgrade on hosts -> qct-26.robinsystems.com,
qct-27.robinsystems.com, qct-28.robinsystems.com to K8S version 1.22.5

Executing K8S upgrade on hosts -> qct-26.robinsystems.com,
qct-27.robinsystems.com, qct-28.robinsystems.com to K8S version 1.23.8

- Executing K8S specific upgrade actions on primary Robin master node in
the cluster -> qct-26.robinsystems.com ... DONE (268 secs)

- Executing K8S specific upgrade actions on secondary master nodes in
the cluster -> qct-27.robinsystems.com ... DONE (230 secs)

- Executing K8S specific upgrade actions on secondary master nodes in
the cluster -> qct-28.robinsystems.com ... DONE (201 secs)

Successfully executed K8S upgrade on hosts -> qct-26.robinsystems.com,
qct-27.robinsystems.com, qct-28.robinsystems.com to K8S version 1.23.8

- Executing Robin networking specific upgrade actions on primary master
node in the cluster ... DONE (41 secs)

- Executing Robin upgrade actions on primary master node in the cluster
... DONE (661 secs)

- Executing Robin Host post upgrade actions on primary master node in
the cluster ... DONE (147 secs)

- Executing K8S post upgrade actions on all K8S secondary master nodes
in the cluster ... DONE (796 secs)

- Checking Robin Server availability post cgroup update from primary
master node in the cluster ... DONE (10 secs)

- Executing K8S post upgrade actions on all K8S secondary master nodes
in the cluster ... DONE (1055 secs)

- Checking Robin Server availability post cgroup update from primary
master node in the cluster ... DONE (10 secs)

- Executing K8S post upgrade actions on primary K8S node in the cluster
... DONE (858 secs)

- Checking Robin Server availability post cgroup update from primary
master node in the cluster ... DONE (10 secs)

- Executing Robin networking post upgrade actions on primary master node
in the cluster ... DONE (1 secs)

- Executing Robin specific post-upgrade actions on primary master node
in the cluster ... DONE (25 secs)

- Removing ROBIN tarball from '3' node(s) at /tmp/ in the cluster ...
DONE (0 secs)

- Pulling ROBIN Install logs from '3' node(s) at /tmp/ ... DONE (1 secs)

Successfully upgraded Robin Cluster with hosts: qct-26.robinsystems.com,
qct-27.robinsystems.com, qct-28.robinsystems.com to Robin Version
5.4.1-24

23.1.4.4. Step 4 - Post- Upgrade Cluster Audit

Run the following command to verify the upgrade.

# ./gorobin onprem audit-cluster --username=<robin admin username> --password=<robin admin password>

Example

# ./gorobin_5.4.1-43 onprem audit-cluster --robin-admin-user admin --robin-admin-passwd Robin123 --hosts-json /root/hosts.json --gorobintar gorobintar-5.4.1-43.tar
- Checking network connectivity to primary Robin master manager node -> poch02.robinsystems.com ... DONE (0 secs)
- Checking network connectivity to host poch02.robinsystems.com ... DONE (0 secs)
- Checking network connectivity to host poch01.robinsystems.com ... DONE (0 secs)
- Checking network connectivity to host poch03.robinsystems.com ... DONE (0 secs)
- Executing cluster audit. You may check /var/log/robin-install.log on host -> poch02.robinsystems.com for details of the cluster audit ... DONE (34 secs)

23.1.5. Multistage Upgrade Using GoRobin

Using GoROBIN, users are able to split their upgrade process into four main parts: pre-upgrade , upgrade, kubernetes-upgrade and post-upgrade. Given the flexibility this feature provides, the user inherently gains more control over the upgrade process.

Listed below are the four GoROBIN options that correspond to each of the aforementioned sections. These commands must be executed sequentially in order to result in a successful upgrade.

Note

For each of the given commands GoROBIN will copy the necessary Robin tar files to all nodes in the Robin cluster while executing the upgrade process. The user can skip this copying process (assuming the required files are already present on the respective machines) using the --skip-gorobintar-push parameter. Similarly, the --hosts-json option can be used for each of the commands in order to specify the login credentials of each host via a JSON file.

23.1.5.1. Pre-Robin Upgrade

This step will perform all the pre-upgrade steps on the Robin cluster and can be executed with the following command:

# ./gorobin onprem pre-upgrade-robin --hosts <IP address of the Robin Primary Master Node> --gorobintar <Upgrade version GoROBIN tar> --robin-admin-user <Robin Super Admin Username> --robin-admin-passwd <Robin Super Admin Password>

23.1.5.2. Robin Upgrade

This step will perform the actual upgrade on the Robin cluster and can be executed with the following command:

# ./gorobin onprem upgrade-robin --hosts <IP address of the Robin Primary Master Node> --gorobintar <Upgrade version GoROBIN tar> --robin-admin-user <Robin Super Admin Username> --robin-admin-passwd <Robin Super Admin Password> --topology-manager-policy <Topology manager policy. Valid values none,best-effort,restricted and single-numa-node. Default: best-effort> --cpu-manager-policy <CPU manager policy. Valid values none or static. Default: static>

23.1.5.3. Kubernetes Upgrade

This step performs the Kubernetes upgrade on the Robin cluster. If there are multiple Kubernetes versions involved in the Kubernetes upgrade then the command detailed below needs to be executed for each intermediate Kubernetes version.

Note

This step can be skipped for upgrade paths where a Kubernetes upgrade is not required. --reserved-cpus option will set the same value for reserved CPUs on all nodes in the cluster during upgrades. Users should also be able to specify reserved CPUs for master nodes using --reserved-cpus-masters and for worker nodes using --reserved-cpus-workers options respectively. If none of these options are used; default value of 0-3 as reserved CPUs shall be configured on all nodes in the cluster.

# ./gorobin onprem upgrade-k8s --hosts <IP address of the Robin Primary Master Node> --gorobintar <Upgrade version GoROBIN tar> --robin-admin-user <Robin Super Admin Username> --robin-admin-passwd <Robin Super Admin Password> --k8s-upgrade-version <K8S Version i.e 1.17.5> --reserved-cpus <Reserved cpus Kubelet option. Pass the cpus to be reserved by kubelet and not used for guaranteed PODs> --topology-manager-policy <Topology manager policy. Valid values none,best-effort,restricted and single-numa-node. Default: best-effort> --cpu-manager-policy <CPU manager policy. Valid values none or static. Default: static>

23.1.5.4. Post-Robin Upgrade

This step will perform all post upgrade steps on the Robin cluster and can be executed with the following command:

# ./gorobin onprem post-upgrade-robin --hosts <IP address of the Robin Primary Master Node> --gorobintar <Upgrade version GoROBIN tar>  --robin-admin-user <Robin Super Admin Username> --robin-admin-passwd <Robin Super Admin Password>