#Configure scheduling

The high-level Valkey API exposes standard Kubernetes scheduling controls.

#Affinity policies

The high-level schema accepts these spec.affinityPolicy values, but the inspected Cluster builder does not implement every schema description:

Required anti-affinity can leave Pods Pending when the cluster has too few eligible nodes. For example, two members in one shard require two eligible nodes for either required policy. Different shards can still share those nodes.

For an existing Cluster instance, the reconcile path preserves each StatefulSet's current Pod affinity during updates. A changed affinityPolicy or customAffinity therefore applies only to StatefulSets created afterward, such as the workloads of newly added shards. Set the intended policy at creation time.

#Node selector and tolerations

kubectl -n default patch valkey valkey-cluster --type=merge -p '
{
  "spec": {
    "nodeSelector": {
      "workload.alauda.io/type": "memory-optimized"
    },
    "tolerations": [
      {
        "key": "middleware",
        "operator": "Equal",
        "value": "valkey",
        "effect": "NoSchedule"
      }
    ]
  }
}'

The Operator propagates these settings to data workloads. For an Operator-created Sentinel deployment, unspecified Sentinel node selectors and tolerations inherit the high-level instance values.

#Failover and Replica affinity

Failover and Replica do not use the high-level affinityPolicy switch. When spec.customAffinity is absent, their data StatefulSet receives required anti-affinity across the data group. When spec.customAffinity is present, the builder copies that Kubernetes Affinity object directly. For example:

spec:
  customAffinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            topologyKey: topology.kubernetes.io/zone
            labelSelector:
              matchLabels:
                buf.red/name: valkey-failover

Replace the label value with the owning instance name. Apply this field only after validating it against the Failover or Replica workload in a test namespace and inspecting the generated StatefulSet. An Operator-created Sentinel inherits the high-level node selector and tolerations, but not this custom affinity.

#Verify scheduling

kubectl -n default get pods -l buf.red/name=valkey-cluster -o wide
kubectl -n default get events --sort-by=.lastTimestamp
kubectl -n default describe pod <pending-pod>

Wait for the Valkey resource to return to Ready. If Pods remain Pending, check node labels, taints, allocatable resources, volume topology, and required anti-affinity before relaxing the policy.