Can I update an existing cluster to include storageless nodes?

Portworx on Kubernetes
1

K8s: v1.25.10
PX: 2.13.10-ebd8383
Home lab consists of: 3 workers with storage and portworx currently functional and 2 control-plane nodes

In reviewing the Storage Cluster document it appears an initial deployment supports this type of configuration per the bullet point section

Portworx with node specific overrides. Use different devices or no devices on different set of nodes

I tried removing the below lines noted with >> from the operator:

placement:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
[truncated]
>>         - key: node-role.kubernetes.io/control-plane
>>           operator: DoesNotExist
[truncated]
>>         - key: node-role.kubernetes.io/control-plane
>>           operator: Exists

which resulted in crashlooping portworx-pvc-controller pods on the control-plane nodes

"command failed" err="failed to create listener: failed to listen on 0.0.0.0:10257: listen tcp 0.0.0.0:10257: bind: address already in use"

bc that is the port the kube-controller is using. I added those lines back into the storagecluster config and removed the nodes from the cluster.

Before I irreparably damage the cluster I am curious if I follow the below steps will it add the control-plane nodes to the cluster as storageless?
( I’m using info from the Storage Cluster docs (link above) and the post Installing Portworx using Operator with Node / Storage specifics .

  1. Label the control-plane nodes with kubectl label nodes node4 node5 px/storage=storageless
  2. Edit operator/storagecluster to include at the same level as my “generic” storage: key which is a under the spec:
nodes:
  - selector:
      labelSelector:
        matchLabels:
          px/storage: "storageless"
    storage:
      devices: []
  1. Contingent upon step two working, or at least appearing to work, remove the original two blocks of texts mentioned prior.

TYIA!

2

This approach did not work.
While it did have the effect of not joining the cluster with the local storage being added to the cluster, it did not actually join the control-plane nodes as storageless.

When editing the cluster resource to stop excluding the control-plane nodes, the deployment for portworx-pvc-controller remained at the original spec count of 3.

spec:
  replicas: 3

and attempted to start the portworx-pvc-controller pods on the control-plane nodes only to fail again with the port 10257 in use issue.

This brings up a different question, one I should have asked initially I guess:

Can a px-essentials cluster contain both storage and storageless nodes?

and if px-essentials does allow storageless nodes, how do I update the spec for portworx-pvc-controller to use a different port besides 10257 so it doesn’t conflict with kube-controller pods running on the control-plane nodes?

1 Like