There are two modes available to enforce pod locality for StorageOS Volumes. The mode is defined by labeling the Pods.
||Best effort placement of the Pod along its StorageOS Volume|
||Enforce placement of the Pod alongside the Primary Volume or do not schedule|
The Pod will be placed along with its data if possible. Otherwise, it will be placed along the volume replicas. If both scenarios are not possible, the Pod will start on a different node and StorageOS will grant accessibility to the data via network.
You can explicitly guarantee that mode by setting the label
storageos.com/locality: "preferred"to the Pod.
For instance a Pod would set the labels as:
apiVersion: v1 kind: Pod metadata: name: pod labels: storageos.com/locality: "preferred" spec: containers: - name: debian image: debian:9-slim command: ["/bin/sleep"] args: [ "3600" ] volumeMounts: - mountPath: /mnt name: v1 volumes: - name: v1 persistentVolumeClaim: claimName: persistent-volume # ----> StorageOS PVC
The Pod will be enforced to be placed along its data. Hence, in the same node as the Primary Volume. In case of that not being possible, the Pod will remain in pending state until that premise is fulfilled.
You can enable this mode by setting the label
storageos.com/locality: "strict" to the Pod.
For instance an StatefulSet would set the labels as:
apiVersion: apps/v1 kind: StatefulSet metadata: name: mysql spec: selector: matchLabels: app: mysql storageos.com/locality: "strict" # Matching label to the template serviceName: mysql replicas: 1 template: metadata: labels: app: mysql storageos.com/locality: "strict" # Inherited label by the Pod spec: serviceAccountName: mysql containers: - name: mysql image: mysql:5.7 ... volumeClaimTemplates: - metadata: name: data labels: app: mysql spec: accessModes: ["ReadWriteOnce"] storageClassName: "storageos" # StorageClass for your cluster resources: requests: storage: 50Gi
It is not necessary to explicitly set the SchedulerName as the Admission Controller automatically populates the PodSpec field. Set the SchedulerName in your manifests, manually, only if you disable or can’t execute the StorageOS Admission Controller.
Kubernetes allows the use of different schedulers by setting the field
For instance the Pod manifest utilising the StorageOS scheduler would look as follows:
apiVersion: v1 kind: Pod metadata: name: d1 spec: schedulerName: storageos-scheduler # --> StorageOS Scheduler # No need if using Admission Controller # (enabled by default) containers: - name: debian image: debian:9-slim command: ["/bin/sleep"] args: [ "3600" ] volumeMounts: - mountPath: /mnt name: v1 volumes: - name: v1 persistentVolumeClaim: claimName: persistent-volume # ----> StorageOS PVC