<p>As part of rolling updates version 1 pod is rolled up with version 2 pod.</p>
<p>We need to review the logs of shutdown process of service in the pod (version one).</p>
<hr />
<ol>
<li><p>Does rolling update delete the version one pod?</p>
</li>
<li><p>If yes, can we review the logs of deleted pod (version one)? To verify the shutdown process of service in version one pod...</p>
</li>
</ol>

<blockquote>
<ol>
<li>Does rolling update delete the version one pod?</li>
</ol>
</blockquote>
<p>The short answer is: Yes.</p>
<p><a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment" rel="nofollow noreferrer">Rolling Update Deployment</a>:</p>
<blockquote>
<p>The Deployment updates Pods in a rolling update fashion when
<code>.spec.strategy.type==RollingUpdate</code>. You can specify <code>maxUnavailable</code>
and <code>maxSurge</code> to control the rolling update process.</p>
</blockquote>
<p>See the examples below:</p>
<pre><code>spec:
  replicas: 2
  strategy:
   type: RollingUpdate
   rollingUpdate:
     maxSurge: 1
     maxUnavailable: 0
</code></pre>
<p>In this example there would be one additional Pod (<code>maxSurge: 1</code>) above the desired number of 2, and the number of available Pods cannot go lower than that number (<code>maxUnavailable: 0</code>).</p>
<p>Choosing this config, the Kubernetes will spin up an additional Pod, then stop an “old” one. If there’s another Node available to deploy this Pod, the system will be able to handle the same workload during deployment. If not, the Pod will be deployed on an already used Node at the cost of resources from other Pods hosted on the same Node.</p>
<p>You can also try something like this:</p>
<pre><code>spec:
  replicas: 2
  strategy:
   type: RollingUpdate
   rollingUpdate:
     maxSurge: 0
     maxUnavailable: 1
</code></pre>
<p>With the example above there would be no additional Pods (<code>maxSurge: 0</code>) and only a single Pod at a time will be unavailable (<code>maxUnavailable: 1</code>).</p>
<p>In this case, Kubernetes will first stop a Pod before starting up a new one. The advantage of that is that the infrastructure doesn’t need to scale up but the maximum workload will be lower.</p>
<hr />
<blockquote>
<ol start="2">
<li>if yes, can we review the logs of deleted pod(version one)? To verify the shutdown process of service in version one pod...</li>
</ol>
</blockquote>
<p>See the <a href="https://kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/" rel="nofollow noreferrer">Debug Running Pods</a> docs. You can find several useful ways of checking logs/events such as:</p>
<ul>
<li><p><a href="https://kubernetes.io/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#debugging-pods" rel="nofollow noreferrer">Debugging Pods</a> by executing <code>kubectl describe pods ${POD_NAME}</code> and checking the reason behind it's failure.</p>
</li>
<li><p><a href="https://kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/#examine-pod-logs" rel="nofollow noreferrer">Examining pod logs</a>: with <code>kubectl logs ${POD_NAME} ${CONTAINER_NAME}</code> or <code>kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}</code></p>
</li>
<li><p><a href="https://kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/#container-exec" rel="nofollow noreferrer">Debugging with container exec</a>: by running commands inside a specific container with <code>kubectl exec</code></p>
</li>
<li><p><a href="https://kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container" rel="nofollow noreferrer">Debugging with an ephemeral debug container</a>: Ephemeral containers are useful for interactive troubleshooting when <code>kubectl exec</code> is insufficient because a container has crashed or a container image doesn't include debugging utilities, such as with <a href="https://github.com/GoogleContainerTools/distroless" rel="nofollow noreferrer">distroless images</a>.</p>
</li>
<li><p><a href="https://kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/#node-shell-session" rel="nofollow noreferrer">Debugging via a shell on the node</a>: If none of these approaches work, you can find the host machine that the pod is running on and SSH into that host.</p>
</li>
</ul>
<hr />
<p>However, <code>--previous</code> flag works only if the previous container instance still exists in a Pod. Check out <a href="https://stackoverflow.com/a/57009702/11560878">this answer</a> for further options.</p>
<p>Also, see this topic: <a href="https://stackoverflow.com/questions/40636021/how-to-list-kubernetes-recently-deleted-pods">How to list Kubernetes recently deleted pods?</a></p>
