<p>I have a Java-based server managed by the kubernetes cluster. It's a distributed environment where the number of the instance is set to 4 to handle millions of request per minute.</p>

<p><em>The issue</em> that I am facing is kubernetes tries to balance the cluster and in the process kills the pod and take it to another node, but there are <strong>pending HTTP request</strong> GET and POST that gets lost.</p>

<p>What is the solution by kubernetes or architectural solution that would let me retry if the request is stuck/ failed?</p>

<p>UPDATE:</p>

<p>I have two configurations for kubernetes service:</p>

<ol>
<li>LoadBalancer (is with AWS ELB): <em>for external facing</em></li>
<li>ClusterIP: <em>for internal microservice based architecture</em></li>
</ol>

<p>Kubernetes gives you the means to gracefully handle pod terminations via SIGTERM and preStop hooks. There are several articles on this, e.g. <a href="https://pracucci.com/graceful-shutdown-of-kubernetes-pods.html" rel="nofollow noreferrer">Graceful shutdown of pods with Kubernetes</a>. In your Java app, you should listen for SIGTERM and gracefully shutdown the server (most http frameworks have this "shutdown" functionality built in them).</p>

<blockquote>
  <p>The issue that I am facing is kubernetes tries to balance the cluster and in the process kills the pod and take it to another node</p>
</blockquote>

<p>Now this sounds a little suspicious - in general K8s only evicts and reschedules pods on different nodes under specific circumstances, for example when a node is running out of resources to serve the pod. If your pods are frequently getting rescheduled, this is generally a sign that something else is happening, so you should probably determine the root cause (if you have resource limits set in your deployment spec make sure your service container isn't exceeding those - this is a common problem with JVM containers).</p>

<p>Finally, HTTP retries are inherently unsafe for non-idempotent requests (POST/PUT), so you can't just retry on any failed request without knowing the logical implications. In any case, retries generally happen on the client side, not server, so it's not a flag you can set in K8s to enable them. </p>
