<p>I have deploy my application in kubernetes using deployment.</p>
<ol>
<li>Whenever user gets login to application pod will generate session for that user.</li>
<li>To maintain session stickiness I have set session cookie using Nginx ingress annotations.</li>
<li>When hpa scale down pods application user is phasing a logout problem when pod is get terminated. If ingress has generated a session using this pod. It needs to log in again.</li>
<li>What I want is some sort of graceful termination of the connection. when pod is in a terminating state it should serve existing sessions until grace period.</li>
</ol>

<p>The answer <a href="https://stackoverflow.com/users/5525824/harsh-manvar">Harsh Manvar</a> is great, However, I want to expand it a bit :)</p>
<p>You can of course use <strong>terminationGracePeriodSeconds</strong> in the POD spec. Look at the example yaml:</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
  terminationGracePeriodSeconds: 60
</code></pre>
<blockquote>
<p>At this point, Kubernetes waits for a specified time called the termination grace period. By default, this is 30 seconds. It’s important to note that this happens in parallel to the preStop hook and the SIGTERM signal. Kubernetes does not wait for the preStop hook to finish.</p>
<p>If your app finishes shutting down and exits before the terminationGracePeriod is done, Kubernetes moves to the next step immediately.</p>
<p>If your pod usually takes longer than 30 seconds to shut down, make sure you increase the grace period. You can do that by setting the terminationGracePeriodSeconds option in the Pod YAML. For example, to change it to 60 seconds.</p>
</blockquote>
<p>For more look <a href="https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-terminating-with-grace" rel="nofollow noreferrer">here</a>.</p>
<p>If you want to know how exactly looks like <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/" rel="nofollow noreferrer">pod lifecycle</a> see this link to the official documentation. The part about the <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination" rel="nofollow noreferrer">termination of pods</a> should be most interesting. You will also have it described how exactly the termination takes place.</p>
<p>It is recommended that applications deployed on Kubernetes have a design that complies with the recommended standards.
One set of standards for modern, cloud-based applications is known as the <a href="https://12factor.net/" rel="nofollow noreferrer">Twelve-Factor App</a>:</p>
<blockquote>
<p>Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database.
Some web systems rely on “sticky sessions” – that is, caching user session data in memory of the app’s process and expecting future requests from the same visitor to be routed to the same process. Sticky sessions are a violation of twelve-factor and should never be used or relied upon. Session state data is a good candidate for a datastore that offers time-expiration, such as Memcached or Redis.</p>
</blockquote>
