<p>Kubernetes <code>vertical pod autoscaler</code> (autoscale memory, cpu resources of pods) necessitates a restart of the pod to be able to use the newly assigned resources which might add small window of unavailability.</p>
<p>My question is that if the deployment of the pod is running a <code>rolling update</code> would that ensure zero down time, and zero window of unavailability when the VPA recommendation is applied.</p>
<p>Thank you.</p>

Mazen Ezzeddine
<p>From the <a href="https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/" rel="nofollow noreferrer">official documentation</a>:</p>
<blockquote>
<p><strong>Rolling updates</strong> allow Deployments' update to take place with zero downtime by incrementally updating Pods instances with new ones. The new Pods will be scheduled on Nodes with available resources.</p>
</blockquote>
<p>In this documentation, you will find a very good rolling update overview:</p>
<blockquote>
<p>Rolling updates allow the following actions:</p>
<ul>
<li>Promote an application from one environment to another (via container image updates)</li>
<li>Rollback to previous versions</li>
<li>Continuous Integration and Continuous Delivery of applications with zero downtime</li>
</ul>
</blockquote>
<p>Here you can find information about <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>Additionally, you can add another 2 fields: <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-unavailable" rel="nofollow noreferrer">Max Unavailable</a> and <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-surge" rel="nofollow noreferrer">Max Surge</a>.</p>
<blockquote>
<p><code>.spec.strategy.rollingUpdate.maxUnavailable</code> is an optional field that specifies the maximum number of Pods that can be unavailable during the update process.</p>
</blockquote>
<blockquote>
<p><code>.spec.strategy.rollingUpdate.maxSurge</code> is an optional field that specifies the maximum number of Pods that can be created over the desired number of Pods.</p>
</blockquote>
<p>Now it's up to you how you set these values. Here are some options:</p>
<ul>
<li><strong>Deploy by adding a Pod, then remove an old one:</strong> <code>maxSurge</code> = 1, <code>maxUnavailable</code> = 0. With this configuration, Kubernetes will spin up an additional Pod, then stop an “old” one down.</li>
<li><strong>Deploy by removing a Pod, then add a new one:</strong> <code>maxSurge</code> = 0, <code>maxUnavailable</code> = 1. In that case, Kubernetes will first stop a Pod before starting up a new one.</li>
<li><strong>Deploy by updating pods as fast as possible:</strong> <code>maxSurge</code> = 1, <code>maxUnavailable</code> = 1. This configuration drastically reduce the time needed to switch between application versions, but combines the cons from both the previous ones.</li>
</ul>
<p>See also:</p>
<ul>
<li><a href="https://www.exoscale.com/syslog/kubernetes-zero-downtime-deployment/" rel="nofollow noreferrer">good article about zero downtime</a></li>
<li><a href="https://medium.com/platformer-blog/enable-rolling-updates-in-kubernetes-with-zero-downtime-31d7ec388c81" rel="nofollow noreferrer">guide with examples</a></li>
</ul>
