Warning: file_get_contents(/data/phpspider/zhask/data//catemap/1/ssh/2.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Cookies 跨所有POD的Openshift循环请求_Cookies_Kubernetes_Openshift_Sticky Session - Fatal编程技术网

Cookies 跨所有POD的Openshift循环请求

Cookies 跨所有POD的Openshift循环请求,cookies,kubernetes,openshift,sticky-session,Cookies,Kubernetes,Openshift,Sticky Session,我们希望在openshift中部署的所有POD中进行请求循环。 我在Route config中配置了以下注释,但对所有POD的调用顺序是随机的: haproxy.router.openshift.io/balance : roundrobin haproxy.router.openshift.io/disable_cookies: 'true' 我们有3个吊舱。我们希望请求具有顺序 pod1,pod2,pod3,pod1,pod2,pod3,pod1 但在随机设置上述注释后的真实行为如下: p

我们希望在openshift中部署的所有POD中进行请求循环。 我在Route config中配置了以下注释,但对所有POD的调用顺序是随机的:

haproxy.router.openshift.io/balance : roundrobin
haproxy.router.openshift.io/disable_cookies: 'true'
我们有3个吊舱。我们希望请求具有顺序 pod1,pod2,pod3,pod1,pod2,pod3,pod1

但在随机设置上述注释后的真实行为如下: pod1,pod1,pod2,pod2,pod3,pod1,pod2,pod2。。。。这是不正确的


我们是否需要配置任何openshift配置,使其成为完美的roundroubin?

如果您希望依次通过pod1、pod2、pod3访问,您应该在同一pod组上使用leastconn

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.
HAProxy的roundrobin将平均分配请求,但可能无法保护组中的访问服务器顺序

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.
有关平衡算法选项的详细信息,请参阅