<p>I have a testing scenario to check if the API requests are being handled by another pod if one goes down. I know this is the default behaviour, but I want to stimulate the following scenario.</p>
<p>Pod replicas - 2 (pod A and B)</p>
<p>During my API requests, I want to kill/stop only pod A.
During downtime of A, requests should be handled by B.</p>
<p>I am aware that we can restart the deployment and also scale replicas to 0 and again to 2, but this won't work for me.</p>
<p>Is there any way to kill/stop/crash only pod A?
Any help will be appreciated.</p>

<p>If you want to simulate what happens if one of the pods just gets lost, you can scale down the deployment</p>
<pre class="lang-sh prettyprint-override"><code>kubectl scale deployment the-deployment-name --replicas=1
</code></pre>
<p>and Kubernetes will terminate all but one of the pods; you should almost immediately see all of the traffic going to the surviving pod.</p>
<p>But if instead you want to simulate what happens if one of the pods crashes and restarts, you can delete the pod</p>
<pre class="lang-sh prettyprint-override"><code># kubectl scale deployment the-deployment-name --replicas=2
kubectl get pods
kubectl delete pod the-deployment-name-12345-f7h9j
</code></pre>
<p>Once the pod starts getting deleted, the Kubernetes Service should route all of the traffic to the surviving pod(s) (those with <code>Running</code> status).  However, the pod is managed by a ReplicaSet that wants there to be 2 replicas, so if one of the pods is deleted, the ReplicaSet will immediately create a new one.  This is similar to what would happen if the pod crashes and restarts (in this scenario you'd get the same pod and the same node, if you delete the pod it might come back in a different place).</p>
