<p>I have created deployment which has a service. I set it to run it in 5 replicas. When I call the service it always uses the same replica (pod). Is there a way how to use round robin instead, so all pods will be used?
<a href="https://i.stack.imgur.com/KKxyp.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/KKxyp.png" alt="enter image description here" /></a></p>

JurajRabcan
<p>By default, Kubernetes distributes the traffic to all the service endpoints in a <code>round-robin</code> fashion. <strong>Although</strong>, this behavior can be changed if you use <code>kube-proxy</code> in <code>IPVS</code> mode. With <code>IPVS</code> mode, you can change the traffic distribution algorithms to something else.</p>
<p>To check the mode of the <code>kube-proxy</code>:(it should be either <code>iptables</code> or <code>ipvs</code> or <code>blank</code>)</p>
<pre><code>kubectl get cm -n kube-system  kube-proxy -o jsonpath='{.data.config\.conf}{&quot;\n&quot;}' |grep mode
</code></pre>
<p>If the mode is blank or iptables, the traffic is distributed round-robin. <strong>However</strong>, if the mode is set to <code>ipvs</code>, <em>things will get interesting</em>. You will have to check the <code>scheduler</code> field under the ipvs. E.g.:</p>
<pre><code>kubectl get cm -n kube-system  kube-proxy -o jsonpath='{.data.config\.conf}{&quot;\n&quot;}' |grep -ozP '(?s)ipvs:.*?(?=kind:)'
ipvs:
  excludeCIDRs: []
  minSyncPeriod: 0s
  scheduler: rr                              #&lt;----rr here means round-robin
  strictARP: false
  syncPeriod: 30s
  tcpFinTimeout: 0s
  tcpTimeout: 0s
  udpTimeout: 0s
</code></pre>
<p>The <code>IPVS</code> supports other traffic distribution algorithms, like:</p>
<blockquote>
<p>rr: round-robin  Robin Robin: distributes jobs equally amongst the
available real servers.</p>
<p>lc: least connection (smallest number of open connections)
Least-Connection: assigns more jobs to real servers with fewer active
jobs.</p>
<p>dh: destination hashing Destination Hashing: assigns jobs to servers
by looking up a statically assigned hash table by their destination IP
addresses.</p>
<p>sh: source hashing Source Hashing: assigns jobs to servers by looking
up a statically assigned hash table by their source IP addresses.</p>
<p>sed: shortest expected delay Shortest Expected Delay: assigns an
incoming job to the server with the shortest expected delay. The
expected delay that the job will experience is (Ci + 1) / Ui if sent
to the ith server, in which Ci is the number of jobs on the ith server
and Ui is the fixed service rate (weight) of the ith server.</p>
<p>nq: never queue Never Queue: assigns an incoming job to an idle server
if there is, instead of waiting for a fast one; if all the servers are
busy, it adopts the Shortest Expected Delay policy to assign the job.</p>
</blockquote>
<p>If you decide to play around with the different values, then you would have to edit the configmap:</p>
<pre><code>kubectl edit cm -n kube-system  kube-proxy 
</code></pre>
<p>And restart the <code>daemonset</code> for kube-proxy:</p>
<pre><code>kubectl rollout restart ds kube-proxy -n kube-system
</code></pre>
<p>You may find some exciting read about load balancing for services <a href="https://kubernetes.io/blog/2018/07/09/ipvs-based-in-cluster-load-balancing-deep-dive/" rel="nofollow noreferrer">here</a> and <a href="https://technekey.com/changing-the-traffic-distribution-of-a-kubernetes-service/" rel="nofollow noreferrer">here</a>.<br />
<strong>Note</strong>, if you have service mesh(like <code>istio</code>) installed in your cluster and virtual services in play, then it's beyond the scope of this answer.</p>
