<p>I want to deploy a Java application that uses a vue.js frontend.
Currently, I am using multiple pods in a Deployment, a ClusterIp Service and a nginx Ingress. The Ingress is running in round-robin mode.</p>
<p>The problem is as follows:</p>
<p>Fine before deployment:</p>
<ul>
<li>The application is deployed in version <code>1.0</code>.</li>
<li>Version <code>1.0</code> provides a frontend that uses some resources with hashes in their name -- let's just say <code>1.0.js</code> and <code>1.0.css</code> (we will use versions instead of hashes to make it easier to read).</li>
<li>A user requests the site, the site tells him to request <code>1.0.js</code> and he does so. The round-robin nginx will dispatch the request to another Pod that is also in version <code>1.0</code> and he can retreive the resource.</li>
</ul>
<hr />
<p>Broken during deplyoment:</p>
<ul>
<li>Version <code>2.0</code> is deployed, providing the all-new <code>2.0</code> frontend (<code>2.0.js</code> and <code>2.0.css</code>)</li>
<li>During deployment, there are at least two Pods in the cluster that have different versions (<code>1.0</code> and <code>2.0</code>)</li>
<li>A user requests the site and finishes up on a <code>2.0</code> Pod. The site tells him to request <code>2.0.js</code> and he does so. The round-robin nginx will dispatch the request for <code>2.0.js</code> to a <code>1.0</code> Pod that does not have the resource on hand -- the request fails (404, this will fail the other way around, too).</li>
</ul>
<hr />
<p>Fine after deployment:</p>
<ul>
<li>The deployment is finished, all pods are version <code>2.0</code></li>
<li>No more requests fail.</li>
</ul>
<p>So during the development, requests will fail constantly. Having two pods, around 50% of the time the user will get a 404. This is not only be a problem with hashed resources (webpack etc.) but also with all other resources that only on version of the pod provides.</p>
<p>Is there a way to reduce these failed requests? Restrict new requests during deployment to new Pods maybe? I researched Ingress/Service LB but found nothing, am I missing the point?</p>

Thomas Pötzsch
<p>It's happening due to you having a <strong>RollingUpdate</strong> deployment strategy.</p>
<p>You can try implementing the <strong>Canary</strong> or <strong>Blue-Green</strong> deployment and I think that will resolve your issue.</p>
<p>With Nginx ingress, it's tricky to implement canary and Blue green however logic is like, once your all v2 PODs are deployed to cluster you update the <strong>Lable</strong> of service, so service will only forward the traffic to <strong>V2</strong> version pod.</p>
<p>Simple example by changing <strong>labels</strong> in service : <a href="https://www.sivalabs.in/2021/09/kubernetes-blue-green-deployments/" rel="nofollow noreferrer">https://www.sivalabs.in/2021/09/kubernetes-blue-green-deployments/</a></p>
<p>Above one is the simplest solution, you can manage the traffic and version using the service label.</p>
<p><strong>OR</strong></p>
<p>Instead of Nginx ingress, you can also use Istio service mesh or HAproxy to mange traffic routing very well</p>
<p>Example of Istio with canary deployment : <a href="https://www.digitalocean.com/community/tutorials/how-to-do-canary-deployments-with-istio-and-kubernetes" rel="nofollow noreferrer">https://www.digitalocean.com/community/tutorials/how-to-do-canary-deployments-with-istio-and-kubernetes</a></p>
<p>Example of Istio with blue/green deployment :
<a href="https://thenewstack.io/tutorial-blue-green-deployments-with-kubernetes-and-istio/" rel="nofollow noreferrer">https://thenewstack.io/tutorial-blue-green-deployments-with-kubernetes-and-istio/</a></p>
