I’ve been playing around with Kubernetes for a few days now and I don’t know if I missed this part somewhere along the way but I really need to understand this.
I hope someone with a better understanding could spare a few minutes to explain. Here we go!
-
I understand that pods are copies of your containerized app and all network traffic will be balanced throughout all the available pods. I also see that I can shell into each pod and do whatever I want inside the pod.
So does it mean that each pod is copy / paste of all the files in the image and are built using all the process described in YAML files and if app total size would be 1gb than each pod size would be 1gb? Also, if you access the shell of a particular pod and make some changes inside then those changes will be active only on that pod as long as it will stay alive?
-
Let’s say I have 2 pods (pod A and pod B). I go to the website and I get assigned to pod A, pod B is unused. The website itself is a SPA (Single Page Application), meaning that I don’t need to reload the page to keep using it as I only load data through API endpoints.
While still being on the website I would release an update and set Kubernetes to use a new image that would include new Javascript files (responsible for front-end functionalities) and also some back-end changes.
Since pod B is unused, I understand that it would update without a problem and new visitors would be assigned to this pod.
But what would happen with pod A? Would I still see the old version without changes until I refresh the website and only then would the pod A be updated or replaced with new pod? Or rather pod A would be updated at the same time as pod B and the website would basically crash for me unless I have some sort of code-change detection inside my website that would reload the page?
Thanks.
For Q1 yes what you have described is accurate.
For Q2 when you are saying you have Pod A and Pod B I am assuming you mean 2 x replicas of the same pod created through a Deployment. If you have a Service in front of them the traffic will be balanced. When a page loads in a browser it doesn’t maintain a single HTTP request so even after it’s loaded any requests it makes will be going to both instances of the application. It’s not “assigned to a pod”.
If you modify the Deployment with a new container image new pods will be created with the new container image and once they are up and serving traffic the old pods will be deleted.
If the old and new backends are compatible then the old version of the app in the browser may not necessarily crash but will probably need some reload logic to get the new code. I’ve achieved this before by having a “version” in my API and periodically polling it ever 5 minutes and then force a reload if it changes. But my apps had fairly minimal changes between updates.
stephendotcarter
March 31
For Q1 yes what you have described is accurate.
For Q2 when you are saying you have Pod A and Pod B I am assuming you mean 2 x replicas of the same pod created through a Deployment. If you have a Service in front of them the traffic will be balanced. When a page loads in a browser it doesn’t maintain a single HTTP request so even after it’s loaded any requests it makes will be going to both instances of the application. It’s not “assigned to a pod”.
To clarify - if the SPA is using a persistent connection (eg websocket or just reusing a connection) you will go back to whichever pod was servicing your connection. If that pod goes away, you should get disconnected and reconnected to a new backend on your next connection.
If you need pod A (in this example) to survive until the connection “finishes”, you need to set a terminationGracePeriod long enough to cover however long you want to allow. That could be minutes or hours or even days, if you really need. That will rate-limit how fast the new deployment can be rolled out.