The node affinity rules from the last section define pod and node assignment relationships. They describe a set of restrictions for pods to run on a set of nodes. With the same approach, inter-pod affinity, and anti-affinity rules, define constraints based on other pods. For instance, with the pod affinity rules, pods can be scheduled together for a limited set of nodes. Likewise, with the pod anti-affinity rules, pods can repel each other for a specific topology key, for instance, a node. For pod affinities, hard and soft limits can be defined with requiredDuringSchedulingIgnoredDuringExecution and preferredDuringSchedulingIgnoredDuringExecution.

With the following pod definition, pod affinity ensures that pods will only run on the nodes in the same availability zone, that is, pods with the service=backend label. In other words, affinity rules will try and ensure that our pod will be scheduled into the same availability zone, with the backend services, considering they are interacting with each other. With the pod anti-affinity, the scheduler will try not to run on the nodes that already have pods running in the service=backend label. In other words, if possible, they will not be scheduled to the same nodes with the backend to avoid creating a single point of failure:

apiVersion: v1
...
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
...
spec:
  affinity:
         - key: service
           operator: In
           values:
          - backend
        topologyKey: failure-domain.beta.kubernetes.io/zone podAntiAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
          - key: service
            operator: In
            values:
           - backend
          topologyKey: kubernetes.io/hostname