Filter on label selector AND create-by annotation should be safe

This comes up a lot. Seems like we want some machinery to make this easier. @Kargakis

Per discussion with @erictune, we should fix this in 1.6, presumably with Controller Reference instead

This is the good old overlapping selectors bug right? (fixable with the good old overlapping selectors solution as Janet mentioned). We basically punted on this for a bunch of releases for RC/RS etc, then put in controlleref, and now everything that doesn't use controllereff still suffers from it.

Do not filter on the label selector to find the pods associated with a PetSet.

This is not the solution we adopted everywhere else, though I don't deny that it might work for this specific case.

An easy short term fix would be to filter the pets returned by the selector list: https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/petset/pet_set.go#L223 by an additional petste-name filter, because we can. IIRC the selector list is used to figure out who to delete, not who to create, we know who to create based on the expected identities of the set.

Then there's the approach implemented in Jobs, where we have auto-generated selectors, which can still be combined with user created ones. That with controller ref, should make the pods distinguishable enough.

Then there's the approach implemented in Jobs, where we have auto-generated selectors, which can still be combined with user created ones. That with controller ref, should make the pods distinguishable enough.

@bgrant0607 argued somewhere that the autogenerated selector is more appropriate for Jobs than for long-running controllers (users will care more about labels on the latter vs the former) and I agree with that statement.

That make sense, thx for bringing that up.

The original discussion started in #2210.

We should document this (hint hint).

This is a tradeoff between ease of creation (1st operation) and ease of management (subsequent operations).

Labels are like names in most respects.

It is desirable for a collection of labels to be unique for a given set so that there is a way to unambiguously refer to that set, in management operations (e.g., kubectl delete all --selector=app=ss, monitoring/logging queries). Indeed, the most common reason to want to change labels and selectors (#26202) is lack of planning ahead about what labels one would need: controller, release/version, canary, service, environment, etc. etc.

We encourage use of a unique collection of labels rather than a single unique label value since the additional attributes are generally needed, anyway (e.g., due to rolling update), and otherwise the user would need to combine multiple attributes in a single label value or generate the unique label by some means that would likely result in an unpredictable and/or not-human-friendly value.

It is desirable that the collection of labels be predictable and human-friendly in order to facilitate references from other resources (e.g., services, pod affinity/anti-affinity policies, disruption budget, pod modification policies), and from controllers in adoption cases, even for StatefulSet, where a user might want to delete their previous PetSet or StatefulSet and create a new one to adopt the pre-existing pods.

Unlike many other REST APIs, we don't expect clients to need to query most resources first in order to figure out how to refer to them in subsequent operations. Jobs are different than most other resources because we do typically expect them to be managed by higher-level APIs and/or other orchestrators, and to exist concurrently with subsequently created Jobs. In those respects, they are similar to Pods and the ReplicaSets generated by Deployment, so generated names and labels make sense.

Controller references are intended to prevent bad behavior due to overlapping selectors, especially across different types of controllers, but are not intended as a replacement for label uniqueness. See also:
#14961 (comment)

StatefulSets are different than every other workload controller in that the instances have predictable names derived from the set resource name. Could we eliminate the use of labels for identifying the set's pods? In addition to making management of the pods harder, as discussed above, my main concern about that is that it would be inconsistent with all other workload controllers. Therefore, I'd like to think about a strategy that would work for other workload controllers, as well.

The main problem with Job's approach is that it creates a uid label, which is unpredictable an not human-friendly. The current approach of defaulting the label selector from all labels in the template has problems, as well (#34292, #17902). Defaulting the template labels and selector from just the resource name (and not the uid), would address the problem with Job's approach and would be neither better nor worse with respect to the other problems. We'd probably use name as the label key, which would enable users to not think as much about what --selector=name=ss1 means, which, again, mostly defers confusion to later.

It appears that we can't expect new users to understand what labels they need ahead of time, though our tooling (e.g., kubectl run) and documentation don't help them. We probably need to expect operations like expose and rolling-update to add new labels for their own use (#36897).

cc @erictune @pwittrock @Kargakis

Also note that the /scale subresource requires a selector.

I'd be on board with preventing changes that would break the StatefulSet. For instance, for now we could prevent the user from setting the selector and from removing the name label.

I'd be on board with preventing changes that would break the StatefulSet. For instance, for now we could prevent the user from setting the selector and from removing the name label.

Same thing should apply for the podtemplate-hash label in ReplicaSets owned by Deployments.

I'm pursuing a fix for this via controllerRef (#24946).