VolumePlacementStrategy CRD reference in OCP IBM Cloud

Portworx provides a CustomResouceDefinition (CRD) called VolumePlacementStrategy. The specification for this CRD is composed of 4 main sections:

• replicaAffinity
  • Schema
  • Example use cases
• replicaAntiAffinity
  • Schema
  • Example use cases
• volumeAffinity
  • Schema
  • Example use cases
• volumeAntiAffinity
  • Schema
  • Example use cases

Additional Information:

• topologyKey
• Templates

replicaAffinity

Schema

Field	Description	Optional?	Default
enforcement	Specifies if the given rule is required (hard) or preferred (soft). Portworx will fail volume creation if it cannot provision volumes matching a rule with hard enforcement enabled.	Yes	required
matchExpressions	matchExpressions is a list of label selector requirements. The requirements are ANDed. The labels provided here are matched against the following: OpenShift node labels PVC labels Portworx storage pool labels	Yes * * required if topologyKey is empty	empty
topologyKey	Key for the node label that the system uses to denote a topology domain. The key can be for any node label that is present on the OpenShift node. NOTE: Using topologyKey requires nodes to be consistently labelled, i.e. every node in the cluster must have an appropriate label matching topologyKey. If some or all nodes are missing the specified topologyKey label, it can lead to unintended behavior.	Yes* * required if matchExpressions is empty	empty
weight	Specifies the weight of the rule. If more than one rule matches, then the rule with the highest weight is applied.	Yes	0
affected_replicas	Specifies the number of volume replicas affected by this rule.	Yes	0 (Interpreted as all volume replicas)

Example use cases of replicaAffinity

• [Use SSD pools]/samples/k8s/volume-placement-ssd-sata-pool-spread-affinity.yaml)
• [Use SSD and SATA and spread replicas evenly]/samples/k8s/volume-placement-ssd-sata-pool-spread-affinity.yaml)
• [First replica SSD, others SATA]/samples/k8s/volume-placement-one-ssd-other-sata-pool.yaml)
• [Place volume on specific nodes, example infra etc]/samples/k8s/volume-infra-node-affinity.yaml)
• [Place volume only on racks 1, 2 and 3]/samples/k8s/volume-rack-1-2-3-affinity.yaml)

By default, Portworx automatically adds the following labels to each of its storage pools. These can be used for replica affinity rules to target replicas on a specific storage pool type:

• iopriority
• medium (Media Type)

replicaAntiAffinity

Schema

Field	Description	Optional?	Default
enforcement	Specifies if the given rule is required (hard) or preferred (soft). Portworx will fail volume creation if it cannot provision volumes matching a rule with hard enforcement enabled.	Yes	required
topologyKey	Key for the node label that the system uses to denote a topology domain. The key can be for any node label that is present on the OpenShift node. Using topologyKey requires nodes to be consistently labelled, i.e. every node in the cluster must have an appropriate label matching topologyKey. If some or all nodes are missing the specified topologyKey label, it can lead to unintended behavior.	Yes* * required if matchExpressions is empty	empty

Example use cases

• [Antiaffinity to data pools and spread across racks]/samples/k8s/antiAffinityDataRacks.yaml)
• [Antiaffinity to not use SATA pools]/samples/k8s/volume-placement-sata-pool-anti-affinity.yaml)

volumeAffinity

Schema

Field	Description	Optional?	Default
enforcement	Specifies if the given rule is required (hard) or preferred (soft) Portworx will fail volume creation if it cannot provision volumes matching a rule with hard enforcement enabled.	Yes	required
topologyKey	Key for the node label that the system uses to denote a topology domain. The key can be for any node label that is present on the OpenShift node. Using topologyKey requires nodes to be consistently labelled, i.e. every node in the cluster must have an appropriate label matching topologyKey. If some or all nodes are missing the specified topologyKey label, it can lead to unintended behavior.	Yes	empty
matchExpressions	matchExpressions is a list of label selector requirements. The requirements are ANDed. The labels provided here are matched against the following: OpenShift node labels PVC labels Portworx storage pool labels	No	empty
weight	Specifies the weight of the rule. If more than one rule matches, then the rule with the highest weight is applied.	Yes	0

Example use cases

• [Collocate postgres volumes]/samples/k8s/volume-placement-postgres-volume-affinity.yaml)
• [Place volume on DB type nodes or collocate with postgres volumes]/samples/k8s/volume-db-nodes-or-postgres-affinity.yaml)

volumeAntiAffinity

Schema

Field	Description	Optional?	Default
enforcement	Specifies if the given rule is required (hard) or preferred (soft). Portworx will fail volume creation if it cannot provision volumes matching a rule with hard enforcement enabled.	Yes	required
topologyKey	Key for the node label that the system uses to denote a topology domain. The key can be for any node label that is present on the OpenShift node. Using topologyKey requires nodes to be consistently labelled, i.e. every node in the cluster must have an appropriate label matching topologyKey. If some or all nodes are missing the specified topologyKey label, it can lead to unintended behavior.	Yes	empty
matchExpressions	matchExpressions is a list of label selector requirements. The requirements are ANDed. The labels provided here are matched against the following: OpenShift node labels PVC labels Portworx storage pool labels	No	empty

Example use cases

[Do not collocate with other cassandra volumes]/samples/k8s/volume-placement-cassandra-volume-anti-affinity.yaml)

topologyKey

If topologyKey is not set, by default the rule will avoid/colocate volumes at the node level using built-in unique node identifiers.

Portworx Built-in

topologyKey can use the built-in key portworx.io/pool that is set automatically as a unique key/value on every Portworx pool. This can be used with volumeAffinity/volumeAntiAffinity to control volume placement at the pool level to work for individual pools.

Templates

Parameter values in matchExpressions may use predefined templates. The VolumePlacementStrategy will automatically resolve these templates at provision time as detailed below:

• key: namespace
  • ${pvc.namespace}
    • Replaced with namespace of the PersistentVolumeClaim that triggered provisioning
    • Example: [Do not collocate with other app volumes within the same namespace]/samples/k8s/volume-anti-affinity-namespace-template.yaml)
• key: px/statefulset-pod
  • ${pvc.statefulset-pod}
    • Replaced with the StatefulSet pod name the PersistentVolumeClaim belongs to
    • Matches corresponding label key/value applied to the volume
    • Use this with multiple volumeClaimTemplates in a StatefulSet to relate volumes for the same replica pod to each other
    • Works with Immediate binding mode
    • Example: [Collocate volumes that belong to the same StatefulSet pod]/samples/k8s/statefulset-template-volume-affinity.yaml)
• key: labelkey
  • ${pvc.labels.labelkey}
    • Portworx replaces any values in the template ${pvc.labels.labelkey} with the pvc.labels value for labelkey.
    • Example: [Label the volumes dynamically based on the PVC label field]/samples/k8s/volume-anti-affinity-dynamic-label-template.yaml)