ReplicaSet naming is inconsistent

[majanjua-amzn]

What happened?

When kubernetes is creating a ReplicaSet automatically through a deployment, the suffix added to the deployment name has an inconsistent length. Although this is not necessarily a bug, this can lead to issues in trying to identify ReplicaSets that were created through deployments using, for instance, RegEx.

This code is responsible for creating a suffix string to add to the deployment name to create the ReplicaSet name. The number created by podTemplateSpecHasher.Sum32() is any number from 0 to 4,294,967,295. This means the suffix string after the number goes through rand.SafeEncodeString (link) will have a length of 0 to 10.

What did you expect to happen?

ReplicaSet names should always have a suffix of consistent length when created automatically via a deployment.

How can we reproduce it (as minimally and precisely as possible)?

Create a number of deployments that will in turn create ReplicaSets. On average, 23% of these ReplicaSets will have suffixes of length 9 or shorter instead of the expected 10.

Anything else we need to know?

An easy solution would be to simply change the code as follows:

return rand.SafeEncodeString(fmt.Sprintf("%0*d", 10, podTemplateSpecHasher.Sum32()))

There is no risk to a solution like this as it will only go into effect when new ReplicaSet revisions are created and will only make ReplicaSet names more consistent. Any names that would be generated out of a number like 1,234,567 will instead be generated by 0,001,234,567, i.e. there is the same number of possible suffixes as before.

Kubernetes version

Doesn't really matter but:

$ kubectl version
Client Version: v1.28.0
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Unable to connect to the server: dial tcp: lookup ...: no such host

Cloud provider

Not sure what this means.

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[majanjua-amzn]

/sig cluster-lifecycle

[kannon92]

/remove-sig cluster-lifecycle
/sig apps

[sftim]

this can lead to issues in trying to identify ReplicaSets that were created through deployments using, for instance, RegEx

I'm not sure that's a bug. A better way is to match via labels or via ownerReferences.

/priority awaiting-more-evidence

Also:
/remove-sig cluster-lifecycle

[k8s-ci-robot]

@sftim: Those labels are not set on the issue: sig/cluster-lifecycle

In response to this:

this can lead to issues in trying to identify ReplicaSets that were created through deployments using, for instance, RegEx

I'm not sure that's a bug. A better way is to match via labels or via ownerReferences.

/priority awaiting-more-evidence

Also:
/remove-sig cluster-lifecycle

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.