Introduction
this is part 38 from the journey it's a long journey(360 day) so go please check previous parts , and if you need to walk in the journey with me please make sure to follow because I may post more than once in 1 Day but surely I will post daily at least one 😍.
And I will cover lot of tools as we move on.
Deployment
let's say we have in the registry (dockerhub) a container , we need to deploy it , In real world a big project contain many containers.
Now we have a replicaset with 2 nodes and 5 pods , so we have high availability and load balancing , and every thing work fine.
Let's say we need to upgrade our containers to a newer version , the first solution that will came to mind is to delete the replicaset and create new one with the editing of the yml file. But this is risky move , why it is risky because in the time between deletion and creating the app will go offline and no one can access the app. You will say heeey hold on it's just minutes , maybe it's true for small apps , but what about big ones? it is a big problem. So there is tones of Algorithms to do roll-update to the app , what roll-update mean ? it mean update 1 at a time.
update 1 at a time , it's mean he will take v1 and replace it with v2 , one by one in this time the other pods of v1 will still serving the app , so the app will be available at all the times , and he loop threw all the other pods to replace them with v2.
Let's say we find an error in v2 , or the app is not stable or the customer didn't like it or ... what we should do?
hide(best solution) or so I need a roll-back to the old version so he does the same thing , he loop on every pod replace it and go on.
In the next tutorials we will do the lab and explain how to do it using Kubernetes.
Top comments (0)