title: OpenShift service with sessionAffinity forwards traffic to two pods
body: <p>OpenShift Container Platform 3.11</p>
  <p>Assume a setup with one client pod and three equal server pods in the same namespace. The server pods are available via a service:</p>
  <pre><code>  apiVersion: v1
    kind: Service
    metadata:
      name: server
    spec:
      ports:
      - name: &quot;8200&quot;
        port: 8200
        targetPort: 8200
      selector:
        test.service: server
      sessionAffinity: ClientIP
      sessionAffinityConfig:
        clientIP:
          timeoutSeconds: 10800 # default
  </code></pre>
  <p><a href="https://i.stack.imgur.com/1wi7C.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/1wi7C.png" alt="Setup of client and server pods" /></a></p>
  <p>The <code>sessionAffinity: ClientIP</code> states that as long as the client has the same IP its requests are forwarded to the same server pod (except when the timeoutSeconds are reached). This setup worked as expected for months, until suddenly the requests were distributed between two server pods. Restarting the client pod temporarily solved the problem and the requests were forwarded to one server pod only for some time. However, after a few days, the same problem occurred again.</p>
  <p><strong>My question: Is there anything regarding OpenShift services and <code>sessionAffinity: ClientIP</code> that explaines why  requests from the same client with an unchanged IP might be &quot;suddenly&quot; distributed between two server pods?</strong></p>
  <hr />
  <p>Some additional context:</p>
  <p>The client pod receives a session token (not a cookie) when it connects to a server pod. The session token is cached inside the server pod, but is not shared between server pods. Therefore, when the client connects to a different server, it would receive a permission denied for the session token. The client then requests a new session token. If the client's requests are forwarded to the same server pod and only sometimes the server changes (e.g. because the first server crashed) the above setup works fine. However, if the client's requests are distributed between two or more servers, the session token will be invalid with every second or third request.</p>