title: Kubernetes pod in terminating state receiving traffic for long time
body: <p>I have an application service running with 2 pods that are receiving traffic from another service in the Kubernetes cluster.</p>
  <p>I am facing an issue where my pods are getting terminated and not fulfilling the inflight requests.</p>
  <p>So to fix this I have added a pod lifecycle  <strong>preStop</strong>  hook to wait for 250 seconds to complete all pending requests and set the  <strong>terminationGracePeriodSeconds</strong>  to 300 seconds.</p>
  <pre class="lang-yaml prettyprint-override"><code>lifecycle:
    preStop:
      exec:
        command:
        - /bin/sleep
        - &quot;250&quot;
  </code></pre>
  <p>Now what I was expecting is the moment the pod transitioned to Terminating state, it should stop receiving the new requests and only fulfill the requests that it already has, but this did not happen.</p>
  <p>Pod continued to receive the traffic until the last second and eventually got killed once the  <strong>preStop</strong>  completed and eventually the calling application received 502 error code.</p>
  <p>So to debug this I moved further and doubted it could be the endpoints that are not getting updated properly in the service but I was wrong. The moment the pod transitioned to the Terminating state the endpoint is removed from the service, but the pod continued getting the traffic.</p>
  <p>Then I log in to the node and check the IPtables to get the IP table forwarding rules to verify if the pod IP is still there, but the IPtable forwarding rules got updated immediately when the pod transition to Terminating.</p>
  <pre class="lang-yaml prettyprint-override"><code>&gt;sudo iptables -t nat -L  KUBE-SVC-MYVS2X43QAGQT6BT -n | column -t
  Chain                      KUBE-SVC-MYVS2X43QAGQT6BT  (1   references)
  target                     prot                       opt  source       destination
  KUBE-SEP-HDK3MJ4L3R3PLTOQ  all                        --   &lt;IP&gt;    &lt;IP&gt;    /*  default/test-cart-service:http  */  statistic  mode  random  probability  0.50000000000
  KUBE-SEP-237VYZFMFXN2THCB  all                        --   &lt;IP&gt;    &lt;IP&gt;    /*  default/test-cart-service:http  */
  
  &gt;sudo iptables -t nat -L KUBE-SEP-HDK3MJ4L3R3PLTOQ -n | column -t
  Chain           KUBE-SEP-HDK3MJ4L3R3PLTOQ  (1   references)
  target          prot                       opt  source          destination
  KUBE-MARK-MASQ  all                        --   &lt;IP&gt;  &lt;IP&gt;    /*  default/test-cart-service:http  */
  DNAT            tcp                        --   &lt;IP&gt;  &lt;IP&gt;  /*  default/test-cart-service:http  */  tcp  to:&lt;IP&gt;:&lt;PORT&gt;
  
  &gt;sudo iptables -t nat -L KUBE-SEP-HDK3MJ4L3R3PLTOQ -n | column -t
  iptables: No chain/target/match by that name.
  
  </code></pre>
  <p>So the tables got updated immediately by the kube-proxy but still, the pod is receiving the traffic.</p>
  <p>I tried port forwarding the service directly as well as hitting it with the network flow (ELB-&gt;Ingress-&gt;Service-&gt;pod) thinking it might be the Loadbalancer issue but the results are the same.</p>
  <p>K8s is managed by Amazon  <strong>EKS(1.20)</strong>  and the Ingress service is mapped to Amazon classic Load Balancer(ELB).</p>
  <p>I am not sure what I am missing. If this is an EKS bug or something related to k8s behavior.</p>
  <p><strong>Update:</strong></p>
  <p>Tested the same scenario on GKE and it worked as expected. Then moment the pod entered into the Terminating state, it stopped receiving the traffic and completed the pending requested only.</p>