A wrinkle: updating a selector in Deployment #14894

Some use cases for orphaning and/or adoption of pods:

• Stop the controller and restart it later. For instance, that's the way we pause Deployment at the moment.
• Update some attributes of the controller that can't be updated by deleting and re-creating it. For instance, renaming the controller, which we do in "simple rolling update".
• Adoption by an non-backward-compatible API resource.
• Update labels on existing pods that would be incompatible with the controller. Delete controller, change pod labels, create new controller with new selector.
• Bootstrapping. Create pods to start the control plane, then create their controllers.
• System exploration/learning. Create a pod, then a controller to manage it.
• Debugging. Change a pod's labels to orphan it so that it can be replaced and debugged out of the critical path.
• Replacement. Replace a pod generated from the template with a special one, perhaps with special support for profiling, tracing, audit, monitoring, etc.

If we had an imperative API, a controllerRef backpointer could be manipulated to transfer ownership: transfer pods from controller X to controller Y. Orphaning would be somewhat weird in that a dangling controllerRef pointer would need to be left. Otherwise, there would be no attribute to select on for re-adoption. Or one could require transferring ownership before deleting the previous controller.

With our declarative API, we can't get rid of the labels and selector since those identify which pods should be adopted -- there needs to be some known unique set of attributes to select on.

Will also include nominal services #260, splitting out the template #170, and nominal jobs #14188 in the proposal. See also #12450.

Ref #8190, since this is a "next-gen" API proposal.

Demo of Kelsey removing a label in order to orphan a pod for debugging: https://www.youtube.com/watch?feature=player_detailpage&v=-8aUxpVrD40#t=2193
https://github.com/kelseyhightower/yapc-asia-2015/blob/master/demo/README.md#troubleshooting

@kubernetes/rh-cluster-infra

If we had an imperative API, a controllerRef backpointer could be manipulated to transfer ownership: transfer pods from controller X to controller Y. Orphaning would be somewhat weird in that a dangling controllerRef pointer would need to be left. Otherwise, there would be no attribute to select on for re-adoption. Or one could require transferring ownership before deleting the previous controller.

With our declarative API, we can't get rid of the labels and selector since those identify which pods should be adopted -- there needs to be some known unique set of attributes to select on.

Maybe it's a semantic quibble, but I don't think the issue is imperative vs. declarative -- it's implicit vs. explicit encoding of which controller owns a pod. I see the as both being declarative.

Do we have any examples/uses cases of adoption yet?

I think it would be great if we could allow people to write controllers that only support the explicit model, i.e. don't have a Selector. (The controller would fill in controllerRef for the pods it creates.)

By imperative, I meant operations like "transfer pods from controller X to controller Y".

Adoption requests: #11209
Other scenarios are described above.

/sub

cc @smarterclayton

/sub

Having a backpointer from pod to controller will greatly simplify scheduler code, consider for example the hoops we jump through to determine if a pod is controlled by a particular RC in CalculateSpreadPriority() and CalculateAntiAffinityPriority() (both in selector_spreading.go). A backpointer to the service would also be nice (would simplify CalculateSpreadPriority(), which spreads on both RC and service).

Back pointer to service has other undesirable characteristics - like
services have to mutate pods to reference them, which means services
controller is another thing which has effective root access to the
cluster. Is the benefit high enough?

On Dec 1, 2015, at 5:28 AM, David Oppenheimer notifications@github.com
wrote:

Having a backpointer from pod to controller will greatly simplify scheduler
code, consider for example the hoops we jump through to determine if a pod
is controlled by a particular RC in CalculateSpreadPriority() and
CalculateAntiAffinityPriority() (both in selector_spreading.go). A
backpointer to the service would also be nice (would simplify
CalculateSpreadPriority(), which spreads on both RC and service).

—
Reply to this email directly or view it on GitHub
#14961 (comment)
.

Template proposal: #18215

PetSet proposal: #18016

For 1.3, we're working on:

• controllerRef
• cascading deletion
• finalizers
• generation/observedGeneration
• PetSet
• Templates

Note that unique label/selector generation similar to what we do for Job will require changes to kubectl expose, if will want users to be able to do a rolling update to an RC/RS with auto-generated labels.

#17902
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/kubernetes-dev/WbqQVNkDZUE/1f5WZK2zCAAJ

Make controllers aware of namespace termination: #38612

v1 plan: #42752

cc @kow3ns

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

/remove-lifecycle stale
/lifecycle frozen