Upgrade Portworx on AWS EKS and EKS-D using the Operator
Utilizing the Portworx Operator, you can easily upgrade or modify your Portworx version on Amazon Elastic Kubernetes Service (EKS) and EKS-Distro (EKS-D). The Operator not only manages the Portworx cluster but also other essential components like Stork and Autopilot.
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.
- 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
- Ensure Portworx is running through the Operator in your AWS EKS or EKS-D cluster. This method is not suitable for other Portworx deployment methods.
- You must be running the latest available version of the Operator.
- 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
andkubectl 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
orpx/service=disabled
label. If nodes have these labels, remove them and restart the Portworx service or decommission the node before the upgrade.
- Required Portworx and Operator versions:
Upgrade Portworx
-
Identify Your StorageCluster:
Retrieve the name of your Portworx StorageCluster 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, 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 tofalse
and the maximum number of nodes that can be upgraded at a time is set using thespec.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: falsenote- 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:
- Update 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