Upgrade

This document provides a high-level overview of processes that are involved during the Platform9 Self Managed Cloud Platform (SMCP) on-premises upgrade process. This upgrade process is very similar to the PMK Installation process and follows similar steps except for a few other airgap specific processes.

Upgrade Process

The upgrade process is broken down into four main steps.

  1. Download & Install — The SMCP stack upgrade entails running the install.sh script, which upgrades the binaries and the associated components.

  2. Management Server upgrade — The Management Server upgrade is accomplished via the newly upgraded airctl using the upgrade-du command..

  3. HostAgent upgrade — This is actually a two-part process

    1. The first part is to clean up the (docker and rpm) caches of all existing hosts via the configure-hosts command.
    2. The second part upgrades the host agent software on all hosts listed in the config file. (see details below)

  4. Cluster upgrade — This update is executed via an API upgrade on each cluster.

Download and Install

This is similar to the Installation, you can download a newer version and run install exactly the way you would do that during install.

Bash
Copy

Upgrade Management Cluster

This does not typically happen, but if there is an upgrade to the underlying management cluster, you may upgrade your existing cluster with the following steps. In your cluster spec file, update the nodelet package path to point to the latest version.

Bash
Copy

Once set, run the following command to upgrade the cluster:

Bash
Copy

Preload Images

If the previous step has NOT been run, you need to ensure that containerd has access to the latest nodelet and kubedu image bundles.

Copy the latest nodelet and kubedu images from /opt/pf9/airctl/imgs to /var/opt/pf9/images on all nodes and then restart the pf9-nodeletd service on each node. If there are multiple master nodes, this needs to be done in a staggered manner so as to not disrupt the API server availability.

Make sure to copy the nodelet and kubedu bundles that have the same version tag as airctl version.

Once the images are copied over, restart the pf9-nodeletd service and wait until all the phases report running. This needs to be done on all nodes of the management cluster.

Bash
Copy
Bash
Copy

Upgrade Management Plane

Run the configure-localhost command first to make sure that IPv4/IPv6 settings are configured, and the HAProxy configuration is initialized.

Bash
Copy

The next task after the installation is to upgrade the Management Server.

Configure Host and HostAgent Upgrade

Platform9 uses a two-step upgrade process. The first step is to run a configure-hosts command to update any yum/apt repos or add docker images (this is being deprecated and moving to a centralized registry for images and a centralized yum-repo). This step is also needed if you want to change the Management Server Name to IP mapping.

Before running host upgrade, ensure the airct-config.yaml file has the correct file names set in the hostAgentRepo and dockerRepo parameters.

To upgrade the nodes, run the configure-hosts command followed by the upgrade-hosts command. This will only upgrade nodes listed in the airctl-config.yaml.

This will only upgrade nodes listed in the airctl-config.yaml. This allows you to upgrade only a subset of the nodes at a time.
Bash
Copy
Bash
Copy

Host Status

You can obtain the status of each host's kubernetes version and hostagent version before you proceed to the next step using the following command.

Bash
Copy

Now you are ready to upgrade your cluster whenever you would like.

Upgrade Cluster

You can also upgrade the cluster upgrade via the Qbert API There may be other specific considerations for upgrading the cluster, which can be found on the upgrade your cluster page.

API For Host Data

In the Management Server shell, users can obtain relevant data by querying the hostagent on the node by running REST API GET at http://localhost:8082/v1/hosts/<host uuid> and noting the host_agent section in the output. The version field represents the hostagent version that is currently running, while the status field has one of two values, either running_or _updating. The default status is _running_,while the updating state indicates that it has received the command and is updating and processing it. If the host reports offline, the hostagent is down or connectivity to the host is broken.

Bash
Copy

Additionally, users can upgrade the hostagent on the host using the REST API to invoke a PUT via http://localhost:8082/v1/hosts/<host uuid>/hostagent using a request body containing the name, version, and URL of the node for the hostagent package.

Bash
Copy

Rollback

Considerations

  • Any cluster created on the Management Server after the Management Server upgrade will cease to communicate with the Management Server after the Management Server is rolled back. Such clusters will have to be destroyed. Nodes will have to be cleaned up and then connected to the rolled back Management Server before bootstrapping a fresh cluster.
  • Rollback was designed to be used shortly after a failed upgrade and is not intended as a general purpose backup/restore feature.

How to

  • Use these steps to stop and unconfigure the Management Server.

These commands may or may not fail, depending on the actual state of the failed upgraded Management Server.
Bash
Copy
  • To roll back to the previous Management Server, use this command.
Bash
Copy
  • To start the Management Server, use this command.
Bash
Copy
  • Run validations
  • The Kubernetes nodes and clusters should show as connected.
Type to search, ESC to discard
Type to search, ESC to discard
Type to search, ESC to discard
Next to read:
Upgrade Guide: SMCP 5.11 to SMCP 5.12

© 2023 Platform9. All Rights Reserved

On This Page
UpgradeUpgrade ProcessDownload and InstallUpgrade Management ClusterPreload ImagesUpgrade Management PlaneConfigure Host and HostAgent UpgradeHost StatusUpgrade ClusterAPI For Host DataRollbackConsiderationsHow to