<p>We want to have roundrobin of request across all pods deployed in openshift.
I have configured below annotations in Route config but the sequence of calls to all pods is random:</p>

<pre><code>haproxy.router.openshift.io/balance : roundrobin
haproxy.router.openshift.io/disable_cookies: 'true'
</code></pre>

<p>We have spinup 3 pods. We want requests to have sequence 
pod1,pod2,pod3,pod1,pod2,pod3,pod1....</p>

<p>But the real behaviour after setting above annotations in random like:
pod1,pod1,pod2,pod2,pod3,pod1,pod2,pod2.... which is incorrect.</p>

<p>Do we need to configure any openshift configuration make it perfect roundroubin?</p>

<p>If you want to access through pod1, pod2, pod3 in order, the you should use <code>leastconn</code> on the same pod group.</p>

<pre><code>leastconn   The server with the lowest number of connections receives the
              connection. Round-robin is performed within groups of servers
              of the same load to ensure that all servers will be used. Use
              of this algorithm is recommended where very long sessions are
              expected, such as LDAP, SQL, TSE, etc... but is not very well
              suited for protocols using short sessions such as HTTP. This
              algorithm is dynamic, which means that server weights may be
              adjusted on the fly for slow starts for instance.
</code></pre>

<p><code>roundrobin</code> of <code>HAProxy</code> would distribute the request equally, but it might not protect the accessing server order in the group.</p>

<pre><code>roundrobin  Each server is used in turns, according to their weights.
              This is the smoothest and fairest algorithm when the server's
              processing time remains equally distributed. This algorithm
              is dynamic, which means that server weights may be adjusted
              on the fly for slow starts for instance. It is limited by
              design to 4095 active servers per backend. Note that in some
              large farms, when a server becomes up after having been down
              for a very short time, it may sometimes take a few hundreds
              requests for it to be re-integrated into the farm and start
              receiving traffic. This is normal, though very rare. It is
              indicated here in case you would have the chance to observe
              it, so that you don't worry.
</code></pre>

<p>Refer <a href="https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4.2-balance" rel="nofollow noreferrer">HAProxy balance (algorithm)</a> for details of balance algorithm options.</p>
