CODEWITHSUNDEEP
kubernetes
Mohit Gupta
Mohit Gupta

Reputation: 649

Kubernetes | What's the difference between rollout undo vs deploy to an older version?

I see there are two ways to move back to the older deployment version. One is using rollout undo command and another option is to deploy again to the older version. Is there any difference between the two or they both are interchangeable?

Upvotes: 1

Views: 932

Answers (3)

Dashrath Mundkar
Dashrath Mundkar

Reputation: 9202

Well first of all there is no direct way of option is to deploy again in kubernetes. Yes the undo way is to going back the previous version of your deployment. and command to go back is

kubectl undo deployment ABC

Upvotes: 0

Vüsal
Vüsal

Reputation: 2706

As I understood, you're asking for a difference between doing undo and manually changing pod definitions to the exact previous state. If that's the case - read below.

When you do a new deployment and if in that deployment your pod definitions' hash has been modified - the Deployment Controller will create a new ReplicaSet (let's call it A) in order to roll out new version, but at the same time it will decrease replica count in the existing ReplicaSet (let's call it B) - so you have 2 ReplicaSets (A, B). How it does this - depends on rollout strategy you choose (for example: rolling updates, blue-green deployment and so on).

When you do kubectl rollout undo deploy <your deployment> - the Deployment Controller will basically decrease the number of replicas in your newly created ReplicaSet (A) and increase the number of replicas in the old ReplicaSet (B).

But, when you do, as you said: deploy again to the older version - you basically do a new deployment, so new ReplicaSet (C) will be created in order to roll out your new version (even if it's not a new version), and your existing ReplicaSets(A) replica count will be decreased.

So, basically the difference is the ReplicaSets which gets created.

Read: Deployments for more info

The whole flow is as following:

  • Deployment Controller manages ReplicaSets
  • ReplicaSet changes desired pod count in etcd
  • Scheduler schedules the pod
  • Kubelet creates/terminates actual pods

And all of them talk to API Server and watch for changes in resource definitions via watch mechanism, again via API Server

Upvotes: 2

GManika
GManika

Reputation: 575

when you undo the roll out, you are updating in a way that is not reflected in source control. The preferred way is to revert your YAML and apply previous versions- then your revisions match with the tracked configuration.

kubectl rollout history deployment xyz

REVISION --> these do not reflect correctly, get a new number with undo roll-out

Upvotes: 0

Related Questions