Instead, it is kept around with a replicas count of 0. When you upgrade your Pods from version 1 to version 2, the Deployment creates a new ReplicaSet and increases the count of replicas while the previous count goes to zero.Īfter the rolling update, the previous ReplicaSet is not deleted - not immediately at least. There's something else worth noting about the ReplicaSets and Deployments. Deployments delegate counting Pods to another component: the ReplicaSetĮvery time you create a Deployment, the deployment creates a ReplicaSet and delegates creating (and deleting) the Pods. Since the replicas is a field in the Deployment, you might be tempted to conclude that is the Deployment's job to count the number of Pods and create or delete them. If you asked for 4 Pods, but you have 5, Kubernetes deletes one of the running Pods. If you asked for 5 Pods but have only 4, Kubernetes creates one more.
You are also familiar with the fact that Kubernetes watches over the number of replicas in your deployment. You learned how Deployments are responsible for gradually rolling out new versions of your Pods without causing any downtime.
Kubernetes and kubectl offer a simple mechanism to roll back changes to resources such as Deployments, StatefulSets and DaemonSets.īut before talking about rollbacks, you should learn an important detail about Deployments. When you introduce a change that breaks production, you should have a plan to roll back that change However, even if you use techniques such as Rolling updates, there's still risk that your application doesn't work the way you expect it at the end of the deployment. You can deploy as many time as you want and your user won't be able to notice the difference. Zero-downtime deployment is convenient when you wish not to interrupt your live traffic.
0 kommentar(er)
