<p><em>Situation</em></p>

<p>I want to have a <code>pool</code> of <code>serving</code> pods (say I have 50 <code>serving</code> pods lying around). They will be exposed via a LoadBalancer Service.</p>

<p>I want to make sure that:</p>

<ol>
<li>each pod serves only one TCP connection and keep this connection alive until the client terminates it. Until the end of this pod's life, it will not receive any other TCP connections.</li>
<li>Once the client terminates the connection, the pod cleans up and destroys it self.</li>
<li>Another pod is spinned up to match the desired replica number. Since it's not currently serving any TCP connection, it can be chosen to serve the next TCP connection that goes into the LoadBalancer service.</li>
</ol>

<p><em>Example</em></p>

<pre><code>1. Initially, a `Deployment` specifies a pool of 2 pods behind a LoadBalancer Service.

[1] [2]


------LoadBalancer-------



2. A client initiates a TCP connection to the LoadBalancer (e.g. telnet loadbalancer.domain.com 80) and the TCP connection is routed to the first vacant pod.

[1] [2]
 |
 |
------LoadBalancer-------
 |
 |
cl1



3. 24 hours after that (assuming data has been passing between client1 &amp; pod1), another client hits to the same Load Balancer public domain. Since pod1 is serving client1, I want the second client to be routed to another vacant pod, such as pod 2.

[1] [2]
 |   |
 |   |
------LoadBalancer-------
 |   |
 |   |
cl1 cl2



4. 24 hours after that, client 1 terminates the connection, I want pod1 to do clean up and destroy itself shortly afterwards. No new connections should be routed to it. That leaves pod2 the only one still running.

[2]
 |
 |
------LoadBalancer-------
 |
 |
cl2



5. `Deployment` will create additional pods to ensure the number of replicas. So pod3 is created.

[1] [3]
 |   
 |   
------LoadBalancer-------
 |   
 |   
cl1 



6. Another client hits the same endpoint and is routed to a vacant pod (pod 3 in this case).

[1] [3]
 |   |
 |   |
------LoadBalancer-------
 |   |
 |   |
cl1 cl3

And so on and so forth.
</code></pre>

<p>Anybody has any ideas how this can be solved on K8s?</p>

<p>Have you looked at k8s' <code>sessionAffinity</code>, it might help I think. <a href="https://kubernetes.io/docs/concepts/services-networking/service/#proxy-mode-userspace" rel="nofollow noreferrer">This link</a> says:</p>

<blockquote>
  <p>kube-proxy takes the <code>SessionAffinity</code> setting of the Service into account when deciding which backend Pod to use.</p>
</blockquote>

<p>and</p>

<blockquote>
  <p>If you want to make sure that connections from a particular client are passed to the same Pod each time, you can select the session affinity based on the client’s IP addresses by setting <code>service.spec.sessionAffinity</code> to “ClientIP” (the default is “None”). You can also set the maximum session sticky time by setting <code>service.spec.sessionAffinityConfig.clientIP.timeoutSeconds</code> appropriately.</p>
</blockquote>

<p>After the client terminates, make the server return a failure code at a path like <code>/clientstatus</code>, use <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/" rel="nofollow noreferrer">readinessProbe/livenessProbe</a> to check this path every second, and delete the pod if readinessProbe/livenessProbe fails.</p>
