Configuring Pod Affinity

In XDM we highly recommend using a cloud storage solution that supports the ReadWriteMany access mode. This gives you the best performance and lets you fully benefit from Kubernetes features such as flexible scheduling, scalability and higher availability.

If you do not have the option to use cloud storage with ReadWriteMany, you must ensure that the core and dataflow pods run on the same node. This significantly reduces both performance and the advantages of Kubernetes and should therefore only be used as a temporary workaround to make XDM runnable until a suitable storage solution is available.

As a transitional solution, you can use podAffinity. One pod is selected by a label, and the other pod is configured to run on the same node as that labeled pod. In the following example, the core pod is placed on the same node as the dataflow pod by using the app.kubernetes.io/name: xdm-dataflow label:

core:
  service:
    port: 8000
    type: ClusterIP
  image:
    name: xdm3-core
    version: '{{ .Values.xdm.version }}'
    repository: '{{ .Values.repository }}'
    pullPolicy: IfNotPresent
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
              app.kubernetes.io/name: xdm-dataflow
          topologyKey: "kubernetes.io/hostname"

Notes:

  • Changing the accessMode of existing PVCs may not be accepted by Kubernetes.

  • In this case, it may be necessary to:

    • stop the affected Deployments/StatefulSets,

    • explicitly delete the corresponding PVCs (and, if required, PVs),

    • run the Helm upgrade again so that the PVCs are recreated with the correct parameters.

  • Before doing this, make sure that a valid backup exists if important data is stored on the volume.