Rolling Updates Occasionally Serve Mixed Application Versions on My Kubernetes-Hosted Morse Code Website

I recently containerized my Morse Code website and deployed it to a Kubernetes cluster to improve scalability and simplify deployments. The website is a JavaScript-based application that translates text into Morse code and decodes Morse messages in real time. Most of the application runs in the browser, while a lightweight backend provides APIs for optional features such as saving user progress. Overall the deployment has been stable, but I am encountering one issue during rolling updates.

Whenever I deploy a new application version using a standard RollingUpdate strategy, a small percentage of users occasionally receive HTML from the new deployment while their browser still loads JavaScript files from the previous version. Because the frontend and backend evolve together, this version mismatch causes parts of the translator interface to stop working correctly. Refreshing the page usually resolves the issue, but it creates an inconsistent experience immediately after deployment.

I have verified that the rollout completes successfully and that all Pods eventually become healthy. Readiness probes pass, Services update correctly, and there are no obvious errors in the cluster events or application logs. The issue only appears while old and new Pods are briefly running at the same time during the deployment process. Once the rollout finishes completely, new visitors no longer experience the problem.

To troubleshoot, I reviewed my Deployment configuration, readiness probes, and Service configuration to ensure traffic is only routed to healthy Pods. I also confirmed that container images are being pulled correctly and that the expected application version is running inside each Pod. Despite these checks, the temporary mixing of frontend assets still occurs during deployments, making me wonder whether I need a different deployment strategy or asset versioning approach.

Because the Morse Code translator is a single-page application, the JavaScript bundle must always match the HTML that references it. Even a short period where different application versions are served can result in missing functions or interface errors for users who happen to access the site during a rollout. My goal is to eliminate these inconsistencies without introducing unnecessary downtime or abandoning rolling deployments.

Has anyone experienced similar frontend version mismatch issues when deploying JavaScript-heavy applications on Kubernetes? I would appreciate recommendations on deployment strategies, readiness configuration, asset management, or rollout practices that ensure users always receive a consistent application version throughout the deployment process. Any guidance on best practices for Kubernetes-hosted single-page applications would be greatly appreciated. Sorry for the long post!

Is there anyone who can guide?

Hi!

You may want to use a blue-green style deployment strategy instead of a rolling update strategy.

Check out the Flagger utility for a declarative, Kubernetes-native way of doing this:

https://docs.flagger.app/tutorials/kubernetes-blue-green

Best,
-jay