Skip to main content
Version: 3.1

Upgrade Portworx on Kubernetes using the Operator

caution

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

note
  • 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 MCP maxUnavailable.
  • If you override the default PodDisruptionBudget in GKE environments, ensure that the maxUnavailable is less than the storage-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
  1. Enter the kubectl get command to identify your storage cluster name:

    kubectl get storagecluster -n kube-system
    NAME                                              CLUSTER UUID                           STATUS   VERSION   AGE
    px-cluster-2dc24b8d-dcf5-46d7-b4ea-0477837b54c7 9443277e-ea51-40da-b9b1-7b4739f27cf3 Online 2.10.3 43d
    note

    If your cluster is not installed in kube-system, specify your own namespace with the -n flag.

  2. Enter the kubectl edit command to modify your storage cluster:

    kubectl edit storagecluster -n kube-system <storagecluster-name>

    Change the spec.image value to the version you want to update Portworx to:

    apiVersion: core.libopenstorage.org/v1
    kind: StorageCluster
    metadata:
    name: portworx
    namespace: kube-system
    spec:
    image: portworx/oci-monitor:<your-desired-version>
    storagecluster.core.libopenstorage.org/px-cluster-2dc24b8d-dcf5-46d7-b4ea-0477837b54c7 edited
    note

    To look up recent versions, refer to the Portworx release notes

  3. Verify your upgrade using kubectl get command and make note of the version displayed under VERSION.

    kubectl get storagenodes -n kube-system -l name=portworx
    "NAME       ID                                     STATUS   VERSION          AGE",
    "node-1-1 2326f09a-73fb-440a-b059-06c81b607226 Online 2.11.3-8a0b7a8 10d",
    "node-1-2 5a21ad81-4db9-4d44-ba30-cf8908228900 Online 2.11.3-8a0b7a8 10d",
    "node-1-3 4b5e3f46-fc14-442e-adc8-c3239f8428d6 Online 2.11.3-8a0b7a8 10d"
    note

    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.

Was this page helpful?