Rolling-update works on the units of the ReplicaSet in a Deployment. The effect is to create a new ReplicaSet to replace the old one. Then, the new ReplicaSet is scaling up to meet the desired numbers, while the old ReplicaSet is scaling down to terminate all the Pods in it. The Pods in the new ReplicaSet are attached to the original labels. Therefore, if any service exposes this Deployment, it will take over the newly created Pods directly.

An experienced Kubernetes user may know that the resource ReplicationController can be rolling-update as well. So, what are the differences of rolling-update between ReplicationController and deployment? The scaling processing uses the combination of ReplicationController and a client such as kubectl. A new ReplicationController will be created to replace the previous one. Clients don't feel any interruption since the service is in front of ReplicationController while doing replacement. However, it is hard for developers to roll back to previous ReplicationControllers (they have been removed), because there is no built-in mechanism that records the history of updates.

In addition, rolling-update might fail if the client connection is disconnected while rolling-update is working. Most important of all, Deployment with ReplicaSet is the most recommended deploying resource than ReplicationController or standalone ReplicaSet.

While paying close attention to the history of update in deployment, be aware that it is not always listed in sequence. The algorithm of adding revisions could be clarified as the following bullet points show:

• Take the number of last revision as N
• When a new rollout update comes, it would be N+1
• Roll back to a specific revision number X, X would be removed and it would become N+1
• Roll back to the previous version, which means N-1, then N-1 would be removed and it would become N+1

With this revision management, no stale and overlapped updates occupy the rollout history.