Install Portworx on Openshift on AWS ROSA

Portworx Install
1

Hi, we have been running a POC to evaluate portworx as a possible container storage solution for Openshift on AWS ROSA (managed Openshift service). This flavour of openshift allows no access to kube-system namespace. Hence we installed and configured Portworx on our custom namespace. We are facing issues with regards to application trying to mount volumes. I have attached screenshots of the config and the error. Also as an observation, I can see 3 portworx-proxy-* pods running in kube-system - we are not allowed to run these :frowning: . Is there a doucumented procedure to follow for installation of portworx on custom namespaces?

portworx-all
portworx-all1918×975 253 KB

2

For ROSA, add these annotations to your StorageCluster spec:

annotations:
  portworx.io/portworx-proxy: "false"
  portworx.io/is-openshift: "true"

That will stop the proxy pods from trying to start in kube-system. The other messages seem to point to not having available unused EBS volumes attached to the nodes for Portworx to consume and create a StorageCluster.
Can you confirm that you have attached additional volumes for use by Portworx?

Best Regards

3

Hi Chris,

I have a similar problem with OCP, and I added the annotation for portworx-proxy as false, and installed Portworx 2.12.1 fine and create a test storage class too. But when I tried to create a PVC using the test storage class, it shows the following error:

...services "portworx-service" not found

that’s the PVC provisioning stuck at Pending.
So questions:

  1. Are those “portworx-proxy” pods needed so the portworx service can be found? With those pods running in kube-system, the PVC provisioning works fine though.
  2. If we use the annotation not to run those pods, how is portworx service to be found?
    Thanks.
    bxu@us.ibm.com
4

Never mind. I used the wrong native-tree provisioner. As I installed with the CSI driver, using the CSI provisioner works fine. Thanks.

5

This annotation is for an older release of Portworx. It is not necessary any longer, and with the recent changes in the K8s API newer versions, this can cause issues based on the cluster config.

Thanks,
Chris

6

Hi Chris,

Thanks a lot for the reply. Yes, without that annotation, “protworx-proxy” pods are created in “kube-system” namespace on OCP while all the other Portworx pods are in the “portworx” namespace where we installed Portworx. In this case, both the in-tree provisioner and CSI provisioner work fine.

Without the creation of those “portworx-proxy” pods in the “kube-system” namespace (using this annotation), the in-tree provisioner does NOT work. So a further question: for the in-tree provisioner to work, either “portworx-proxy” pods need to be in “kube-system” or the entire porrtowrx is installed in the “kube-system” namespace, is that correct assumption?
OR is there a way to install Portworx in the “portworx” namespace without those “portworx-proxy” pods, but still we can use both types of provisioners?

Thanks for your advice!

7

So, for clarity… the Portworx-proxy pods are only needed for the in-tree provisioner. Our CSI provisioner, pxd.portworx.com, does not need the proxy pods. The go forward plan is to use the CSI provisioning endpoint, but because of the maturity of the product, there is still support available for the older method.

At the end of the day, all in-tree provisioning is being slowly deprecated. My recommendation would be to ensure all storageClasses in use are using the csi provisioner. If you are using any “built-in” storageClasses, I would recommend migrating to a standard set of SCs and annotate the cluster with “Portworx.io/disable-storage-class: true” to remove the example storageClasses we create by default.
This way you can be sure your end-users are using the long-term supported CSI provisioner and still have all the Portworx benefits.

Best regards,
Chris

8

Fully understood, and we’re moving with CSI based provisioner forward. Thank you for the advice.

On the other hand, as you recommend not to use this annotation to suppress those “portworx-proxy” pods in “kube-system”, so what’s the latest method not to create them when installing Portworx? Thanks.

9

Apologies if there is any confusion.

For ROSA, I suggest using the annotation to prevent the Proxy Pods in ‘kube-system’ as well as the second one I posted that disables the “sample” storageClasses.
From there, create the SCs that meet your app needs using the pxd.portworx.com provisioner. This will keep you in compliance with ROSA support guidance, and declutter the list of available storageClasses, only presenting what you create.

Best Regards and happy to answer questions.
Chris