<p>I have the following problem.
We have a website deployed on <strong>GKE</strong> with 10 pods and on new deployments we use <code>MAXsurge=1</code> <code>MAXunavailable=0</code>.</p>

<p>Sometimes when I try to load the website during deployment of new version I see in the browser only the header and I got some errors for loading the static chunks... I assume that the load balancer is sending me to old pod or trying to load old cached static files.... Is there a way to configure GKE to send traffic to the new pods only when all of them are available or something like this...
I got a final step in the cloudbuild to clear CF cache 2 mins after the deployment but this is not 100% helping.....</p>

<p>I believe that it can be configured to send the traffic only to the new version pods or something like this, but I'm new to GKE and not sure</p>

<p>Or maybe we have something wrong in the timestamps for css or browser cache control..... it is looking for files that are not there .....
<a href="https://i.stack.imgur.com/rvKKB.png" rel="nofollow noreferrer">browser errors</a></p>

Milen Tsvetkov
<p>The load balancer will send traffic to any pod that is deemed healthy (passes the readiness probe). This distribution is handled by the k8s service. With your current rollout plan, a new pod with the new version will be created before any of the old pods are removed. No old pod is removed until the new one is ready (passes readinessProbe). If requests are sent to your application during this window, there is a good chance traffic goes to your old application.</p>

<p>If you have multiple pods, this process will take longer since new pods are rolling out 1 at a time while the old ones are being removed at the same pace. As long as there is a single pod running the old version in ready state, there is a chance that traffic is directed to that pod.</p>

<p>The only real way to ensure that all traffic goes to your new application would be to perform a full rollout immediately (if there are 3 pods, set maxUnavailable to 3). This will cause a short downtime (that lasts as long as it takes for your pods to become ready) but will ensure that no traffic goes to your old version.</p>

<p>Alternatively, you can do a blue/green rollout by creating a second deployment with the new version using a different label (such as <code>version=1.1</code>). Once all the pods are ready, update your service definition to point to the new label. All traffic will switch over immediately with no downtime.</p>
