Upgrade Portworx on Kubernetes using the Operator in AKS

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.

Smart upgrade

The Smart upgrade feature introduces a streamlined, resilient upgrade process for Portworx nodes, allowing them to be upgraded in parallel while maintaining volume quorum and without application disruption.

By default, smart upgrade is disabled and maxUnavailable value is set to 1. This means one Portworx node is upgraded at a time.

You can enable the smart upgrade by setting the spec.updateStrategy.rollingUpdate.disruption.allow parameter to false and set the maximum number of nodes that can be upgraded at a time using the spec.updateStrategy.rollingUpdate.maxUnavailable parameter in the StorageCluster.

The following are the key benefits of using smart upgrades:

• Parallel upgrades: Based on volume distribution, the Portworx Operator tries the best to select multiple nodes for concurrent upgrades, accelerating the upgrade process while eliminating downtime and application disruption.
• Volume quorum maintenance: Ensures volume quorum is maintained throughout the upgrade process.
• Managed node upgrades: You can use the spec.updateStrategy.rollingUpdate.maxUnavailable parameter in the StorageCluster CRD to manage the number of nodes upgraded in parallel.
• Automatic reconciliation: The Portworx operator actively monitors and reconciles the storage nodes during upgrades, ensuring smooth progression while preserving quorum integrity.

important

• There will be a downtime for applications using volumes with a replication factor of 1.
• Smart upgrade is not supported for synchronous DR setup.

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.
• For smart upgrades, ensure the following prerequisites are met:
  • Required Portworx and Operator versions:
    • Portworx version 3.1.2 or later
    • Operator version 24.2.0 or later
  • The cluster must be ready and available for upgrade. You can use the pxctl status and kubectl get storagenodes -n portworx commands to check the cluster status.
    • No nodes or pools should be under maintenance.
    • No decommissioned nodes should appear in the output of the kubectl get storagenodes command.
    • No nodes should have the px/service=stop or px/service=disabled label. If nodes have these labels, remove them and restart the Portworx service or decommission the node before the upgrade.

Upgrade Portworx

note

If using configmap, update the version manifest for Portworx Operator. Otherwise, you might not see the expected image versions.

1. Enter the kubectl get command to identify your StorageCluster name:

   kubectl get storagecluster -n <px-namespace>

   NAME                                              CLUSTER UUID                           STATUS   VERSION   AGE
   px-cluster-xxxxxxxx-xxxx-xxxx-xxxx-0477837b54c7   xxxxxxxx-xxxx-xxxx-xxxx-7b4739f27cf3   Online   2.10.3    43d

2. Enter the kubectl edit command to modify your StorageCluster:

   kubectl edit storagecluster -n <px-namespace> <storagecluster-name>

   In the editor, make the following changes in the StorageCluster:

   • Update the spec.image field to your desired Portworx version.
   • (optional) For smart upgrade, ensure that the spec.updateStrategy.rollingUpdate.disruption.allow parameter is set to false and the maximum number of nodes that can be upgraded at a time is set using the spec.updateStrategy.rollingUpdate.maxUnavailable parameter.

   apiVersion: core.libopenstorage.org/v1
   kind: StorageCluster
   metadata:
       name: portworx
       namespace: <px-namespace>
   spec:
       image: portworx/oci-monitor:<desired-version>
       # For smart upgrades, ensure that the below lines are uncommented and `disruption.allow` is set to false. You can use the `maxUnavailable` field to control the maximum number of Portworx nodes that can be upgraded at a time.
       #updateStrategy:
       #   type: RollingUpdate
       #   rollingUpdate:
       #      maxUnavailable: 5
       #      minReadySeconds: 0
       #      disruption:
       #         allow: false

   storagecluster.core.libopenstorage.org/px-cluster-xxxxxxxx-xxxx-xxxx-xxxx-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 <px-namespace> -l name=portworx

   "NAME       ID                                     STATUS   VERSION          AGE",
   "node-1-1   xxxxxxxx-xxxx-xxxx-xxxx-06c81b607226   Online   2.11.3-8a0b7a8   10d",
   "node-1-2   xxxxxxxx-xxxx-xxxx-xxxx-cf8908228900   Online   2.11.3-8a0b7a8   10d",
   "node-1-3   xxxxxxxx-xxxx-xxxx-xxxx-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.