5

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment mentions that a deployment creates a replicaSet but appends a pod-template-hash to the name of the replicaSet and also adds pod-template-hash as replicaSet's label.

my best guess is that deployment creates multiple replicaSets and this hash ensures that the replicas do not overlap. Is that correct?

Prasath
  • 595
  • 5
  • 11

1 Answers1

5

Correct, the documentation states this really well:

The pod-template-hash label is added by the Deployment controller to every ReplicaSet that a Deployment creates or adopts.

This label ensures that child ReplicaSets of a Deployment do not overlap. It is generated by hashing the PodTemplate of the ReplicaSet and using the resulting hash as the label value that is added to the ReplicaSet selector, Pod template labels, and in any existing Pods that the ReplicaSet might have.

This is necessary for a bunch of different reasons:

  • When you apply a new version of a Deployment, depending on how the deployment is configured and on probes, the previous Pod / Pods could stay up until the new one / ones is not Running and Ready and only then is gracefully terminated. So it may happens that Pods of different ReplicaSet (previous and current) run at the same time.
  • Deployment History is available to be consulted and you may also want to rollback to an older revision, should the current one stops behaving correctly (for example you changed the image that needs to be used and it jsut crash in error). Each revision has its own ReplicaSet ready to be scaled up or down as necessary as explained in the docs
AndD
  • 2,281
  • 1
  • 8
  • 22
  • still it s not clear why they say "This label ensures that child ReplicaSets of a Deployment do not overlap". they can not overlap. every rs and every pod of rs have "ownerReferences" section that states who is the owner of the pod of rs. "ownerReferences" says who is the owner of the object. in my opinion "pod-template-hash" absolutely not necessary. – Alex Jun 20 '23 at 13:39
  • Without this hash, when a Deployment specs are updated and a new ReplicaSet needs to be created, how would it be distinguished from the previous one? I think this is not a matter of overlapping ownership of objects, it is more of a matter of overlapping specs. When a Deployment is changed, the previous ReplicaSet needs to remain in the history. – AndD Jun 20 '23 at 17:56
  • when deployment creates new RS it adds some hash in the end of the NAME of rs. so two rs have different names. from this point of view we can distinguish them without any problem, also every rs have uuid. deployment can track rs names or uuid in its history. we dont need adiitional labels to distinguish one rs from another. what am i missing ? – Alex Jun 20 '23 at 18:34