<p>Problem: Pods with serving http requests are instantly terminated during a deployment, leading to timeout errors for user requests.</p>
<p>I want to terminate the pod only when the new pod is stable and receiving traffic.
I want the old pod to be in &quot;terminated&quot; state and in its grace period and still serve traffic while the new pod is booting up.</p>
<p>Question 1: Is this even possible?</p>
<p>I read that the traffic is stopped when the pod goes into &quot;terminated&quot; state. But I still see traffic in the pod when it is in &quot;terminated&quot; state.</p>
<p>Question 2: Why does terminationGracePeriodSeconds even matter if the pod stops serving requests when it goes to &quot;terminated&quot; state?</p>
<p>My current main settings are:</p>
<pre><code>terminationGracePeriodSeconds: 240

strategy:
     type: RollingUpdate
     surge: 0
     unavailable: 30%

autoscale:
  enabled: true
  replicas:
    min: 5
    max: 5

container:
  port: 8080
    readiness:
      enabled: true
      delay: 240
      period: 240
</code></pre>

P H
<p>The normal flow of a Kubernetes Deployment is the opposite of what you describe.  On update, new Pods are created <em>first</em>, and only once the Pods are successfully handling traffic are the old Pods deleted.</p>
<p>The mechanics of a <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment" rel="nofollow noreferrer">Rolling Update Deployment</a> are described in the Kubernetes documentation.  The important setting you have is <code>surge: 0</code>; this prevents any new Pods from being started above the <code>replicas:</code>.  The default value is <code>surge: 25%</code> and this might be a more reasonable value.</p>
<p>The documentation also describes <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination" rel="nofollow noreferrer">Termination of Pods</a>, which answers your more specific questions:</p>
<ol>
<li><p>The cluster simultaneously sends the container process SIGTERM, sets the Pod state to Terminating, and removes the Pod from the Service's Endpoints; it should not handle new requests, but mechanisms like persistent HTTP connections could still send new requests over an existing network connection.  This is core Kubernetes behavior and you cannot change it; you cannot force a Terminating Pod to keep receiving requests.</p>
</li>
<li><p>If the container process handles SIGTERM, it may not terminate immediately.  If it doesn't terminate on its own within <code>terminationGracePeriodSeconds</code> then the cluster sends the process SIGKILL, which forces it to exit.  This keeps the Pod from staying in a Terminating state indefinitely.</p>
</li>
</ol>
<p>The two halves of this question interact in one more important way.  A Deployment (more correctly a ReplicaSet) will not create more new Pods until some existing Pods have terminated.  If the container process doesn't exit promptly, the grace-period/SIGKILL mechanism allows the cluster to force old Pods to exits so that new ones can start up.</p>
