On the 27th of January Portworx 2.9.1 was released, bringing with it a number of new features, improvements and fixes which are detailed in the release notes. To take advantage of all the changes within my lab, let’s see how to upgrade to it.
Identify Cluster Name
Start by identifying the Portworx cluster name, namespace and version, using kubectl get StorageCluster or the short name stc.
[root@master-1 ~]# kubectl get StorageCluster -A NAMESPACE NAME CLUSTER UUID STATUS VERSION AGE portworx px-deploy-1 5598b98f-f585-4fa9-a281-0b458557f225 Online 2.8.1.2 85d
Upgrade Portworx
Now use kubectl edit StrorageCluster providing name and namespace, updating spec.image value to required version, for example
[root@master-1 ~]# kubectl edit StorageCluster/px-deploy-1 -n portworx
image: portworx/oci-monitor:2.8.1.2
to
image: portworx/oci-monitor:2.9.1
The Portworx Operator keeps everything simple, performing a rolling-upgrade and handling the upgrade of all the Portworx components.
Note: the direct upgrade of individual components is not generally recommended
Use kubectl get StorageCluster to confirm upgrade
[root@master-1 ~]# kubectl get StorageCluster -A NAMESPACE NAME CLUSTER UUID STATUS VERSION AGE portworx px-deploy-1 5598b98f-f585-4fa9-a281-0b458557f225 Online 2.9.1 85d
Wait a few minutes, then check the version of all nodes with pxctl cluster list, for example.
[root@master-1 ~]# pxctl cluster list Defaulted container "portworx" out of: portworx, csi-node-driver-registrar Cluster ID: px-deploy-1 Cluster UUID: 5598b98f-f585-4fa9-a281-0b458557f225 Status: OK Nodes in the cluster: ID SCHEDULER_NODE_NAME DATA IP CPU MEM TOTAL MEM FREE CONTAINERS VERSION Kernel OS STATUS 639a8f40-5f39-4c82-a6be-715b44145783 node-1-3 10.225.115.155 67.012987 8.2 GB 6.4 GB N/A 2.9.1.0-739824e 3.10.0-1160.45.1.el7.x86_64 CentOS Linux 7 (Core) Online bb658f53-92ab-46bc-a817-b7088e25989b node-1-6 10.225.115.152 12.765957 8.2 GB 6.5 GB N/A 2.9.1.0-739824e 3.10.0-1160.45.1.el7.x86_64 CentOS Linux 7 (Core) Online c453a2fe-ba4a-4e3b-960d-c03e6341de62 node-1-4 10.225.115.158 10.741688 8.2 GB 6.5 GB N/A 2.9.1.0-739824e 3.10.0-1160.45.1.el7.x86_64 CentOS Linux 7 (Core) Online cfa4bf3a-af39-48c5-b421-0c85e142caa6 node-1-5 10.225.115.157 12.628866 8.2 GB 6.5 GB N/A 2.9.1.0-739824e 3.10.0-1160.45.1.el7.x86_64 CentOS Linux 7 (Core) Online e2fa8f7d-2be0-4436-9306-8b6094dcbc82 node-1-2 10.225.115.154 16.120907 8.2 GB 6.4 GB N/A 2.9.1.0-739824e 3.10.0-1160.45.1.el7.x86_64 CentOS Linux 7 (Core) Online 2f48a8ad-3190-4038-abe5-54aa279b4a00 node-1-1 10.225.115.151 12.886598 8.2 GB 6.1 GB N/A 2.9.1.0-739824e 3.10.0-1160.45.1.el7.x86_64 CentOS Linux 7 (Core) Online 3f633a0e-3b60-46a5-a4a3-c2a0aa79eec0 node-1-7 10.225.115.153 10.769231 8.2 GB 6.4 GB N/A 2.9.1.0-739824e 3.10.0-1160.45.1.el7.x86_64 CentOS Linux 7 (Core) Online
Summary
In this short post I have demonstrated how we can use the Portworx Kubernetes Operator to perform a rolling upgrade of a Portworx cluster.
Now it’s time to take 2.9.1 out for a test ride.
[twitter-follow screen_name=’RonEkins’ show_count=’yes’]