Upgrade Portworx on Kubernetes using the Operator
If you're upgrading OpenShift to 4.3, you must change Portworx before you can do so. See the Preparing Portworx to upgrade to OpenShift 4.3 page for details.
If you're using the Portworx Operator, you can upgrade or change your Portworx version at any time by modifying the StorageCluster
spec.
In addition to managing a Portworx cluster, the Operator also manages the following other components in the Portworx platform:
- Stork
- Autopilot
For simplicity, the Portworx Operator handles the component upgrades without user intervention. When Portworx upgrades, the Operator upgrades the installed components to the recommended version as well.
Prerequisites
- You must already be running Portworx through the Operator, this method will not work for other Portworx deployments.
- You must be running the latest available version of the Operator.
- For an air-gapped environment, complete the instructions in the Get the updated container images section.
Prepare Anthos environments
If you're not running Portworx on Anthos, skip this section.
If your Portworx cluster is managing the underlying storage devices in an Anthos deployment, add the following annotation to the StorageCluster
spec to ensure that during an Anthos or a Portworx upgrade, Portworx does not failover the internal KVDB to a storageless node:
portworx.io/misc-args: "-rt_opts wait-before-retry-period-in-secs=360"
Upgrade Portworx
Upgrade Portworx
- If using configmap, update the version manifest for Portworx Operator. Otherwise, you might not see the expected image versions.
- If you override the default PodDisruptionBudget in OpenShift platforms, ensure that the
storage-pdb-min-available
value is greater than or equal to OCP's MCPmaxUnavailable
. - If you override the default PodDisruptionBudget in GKE environments, ensure that the
maxUnavailable
is less than thestorage-pdb-min-available
value for a balanced speed and disruption. Portworx by Pure Storage recommends using the following configurations for surge upgrades:maxSurge=1
maxUnavailable=0
-
Identify Your StorageCluster:
Retrieve the name of your Portworx storage cluster within the appropriate namespace:
kubectl get storagecluster -n <px-namespace>
NAME STATUS VERSION AGE
px-cluster-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Online 2.10.3 43dIf your cluster is installed in a different namespace, specify it using the
-n
flag. -
Edit the StorageCluster:
Modify the StorageCluster resource to update Portworx to the desired version:
kubectl edit storagecluster -n <px-namespace> <storagecluster-name>
In the editor, change the
spec.image
field to your desired Portworx version:apiVersion: core.libopenstorage.org/v1
kind: StorageCluster
metadata:
name: portworx
namespace: <px-namespace>
spec:
image: portworx/oci-monitor:<desired-version>note- If there are any component images configured in the StorageCluster, such as the
spec.stork.image
orspec.autopilot.image
fields, you need to update the image fields to the latest version. - To look up recent versions, refer to the following release notes:
- If there are any component images configured in the StorageCluster, such as the
-
Verify the Upgrade:
Confirm the upgrade by checking the Portworx version on the nodes:
kubectl get storagenodes -n <px-namespace> -l name=portworx
NAME ID STATUS VERSION AGE
node-1-1 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Online <desired-version> 10d
For air-gapped clusters, if you do not see the expected image versions that you have configured in the configmap, you should edit the StorageCluster to include the autoUpdateComponents: Once
parameter. This will force Portworx Operator to reconcile all the components and retrieve the correct images.