<p>In my cluster there are 30 VMs which are located in 3 different physical servers. I want to deploy different replicas of each workload on different physical server.
I know I can use podAntiAffinity to deploy replicas on different VMs but I cant find any way to guarantee spread replication on different physical server.</p>
<p>I want to know is there any way to solve this challenge?</p>

hossein bazrafkan
<p>I believe you gave the answer ;)</p>
<p>I went to the Kubernetes Patterns book (PDF available for free in <a href="https://k8spatterns.io/" rel="nofollow noreferrer">here</a>) to see if there was something related to that over there, and found exactly that:</p>
<blockquote>
<p>To express how Pods should be spread to achieve high availability, or be packed and co-located together to improve latency, Pod affinity and antiaffinity can be used.</p>
</blockquote>
<blockquote>
<p>Node affinity works at node granularity, but Pod affinity is not limited to nodes and
can express rules at multiple topology levels. Using the topologyKey field, and the
matching labels, it is possible to enforce more fine-grained rules, which combine
rules on domains like node, rack, cloud provider zone, and region [...]</p>
</blockquote>
<p>I really like the k8s docs as well, they are super complete and full of examples, so maybe you can get some ideas from <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity" rel="nofollow noreferrer">here</a>. I think the main idea will be to create your own affinity/antiaffinity rule.</p>
<p>----------------------------------- <strong>EDIT</strong> -----------------------------------</p>
<p>There is a new feature within k8s version 1.18 that may be a better solution.</p>
<p>It's called: <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/" rel="nofollow noreferrer">Pod Topology Spread Constraints</a>:</p>
<blockquote>
<p>You can use topology spread constraints to control how Pods are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.</p>
</blockquote>
