I have a kubernetes environment set up on GKE with 6 replicated pods and an ingress attached to a GCP load balancer with Google Cloud CDN enabled.
How do rolling deployments work in regards to asset fingerprinting? In the situation where a rolling deployment is in progress and a request for a new asset fingerprint is routed to a pod which doesn't yet have the new asset fingerprint? How can this be mitigated? or does Google Cloud CDN take care of this?
This article describes the situation I am thinking of: https://buildingvts.com/serving-assets-while-rolling-your-deploys-c656ce6a2123
Here the reply will be based on the shared link which is related to fingerprint hashing. Please do clarify what you mean by asset fingerprinting and run-time (python, ruby, nodejs) which would help to answer the question better.
Based on the way this question is asked I suspect an anti-pattern with the way containers and Kubernetes is used. As you have asked about assets and not paths to dynamic content I suspect that you are starting your pod and compiling all assets at start time. Typically you would do all of this work at image creation time. So there should be no interruption in service as all of their assets are pre-generated before start time (as I assume the white screen on the shared link is meant to service interruption).
For the question at hand, Kubernetes does not do anything fancy that a normal load balancer doesn’t do. Kubernetes 5 tuple hash connections through the load balancer to the node and then the pod. Once a connection is created from the web browser it will (probably) continue to be served by they pod until the connection is terminated.
There is no mechanism in Google Cloud CDN to ensure there is no interruption. If there is no asset in the cache it will have to go to a pod and the pod may or may not have the asset in question. If the asset is in the cache then it will serve it out without connecting to a pod.