Ownership: follow object UIDs through dependent lifecycles

An owner reference identifies an API object using fields including its kind, name, and UID. A controller must verify the referenced incarnation rather than matching only a name or selector. Labels and selectors help discover candidates but can be edited and are not a replacement for ownership checks. A dependent may have multiple owner references, while the controlling-owner relationship has its own uniqueness constraints. Adoption of an existing object therefore needs an explicit rule; finding a matching label is not sufficient permission to claim it.

The namespace rules constrain the ownership graph. A namespaced dependent can reference a namespaced owner in the same namespace or an allowed cluster-scoped owner. A namespaced owner in another namespace is not a valid cross-namespace ownership link. A cluster-scoped dependent cannot validly depend on a namespaced owner; the documented v1.34 behavior treats that kind of reference as unresolvable for garbage collection. Invalid references can produce warning events, and different invalid cases should not be collapsed into an assumption that every such object is immediately deleted.

Background deletion can remove the owner while garbage collection handles dependents asynchronously. Foreground deletion keeps the owner in a deletion state until the relevant blocking dependents are handled. Orphan propagation preserves dependents by removing the ownership relationship rather than deleting the dependent objects. These policies govern API object relationships; they do not directly guarantee an external cloud resource was cleaned up. A dependent’s own finalizers can also delay its disappearance after a delete request.

Foreground blocking specifically concerns dependents with the appropriate blockOwnerDeletion reference that the garbage collector knows about under its documented behavior. Do not assume every matching label, every new dependent created concurrently, or every inaccessible resource automatically blocks the owner. Garbage collection depends on discovery, watches, permissions, and its own working state. If an owner appears stuck, inspect actual reference UIDs, scopes, finalizers, blocking flags, and events before removing metadata. Correct lifecycle debugging follows the graph and its conditions, not a guessed name hierarchy.

A controller should avoid creating new dependents for an owner already marked for deletion. When it creates or adopts a dependent, set a valid owner reference for the observed UID and preserve other required metadata using concurrency-aware updates. Recreating an owner with the same name yields a new UID, so old dependents are not automatically the new object’s responsibility. Define an explicit migration or adoption workflow if retention is desired. This is especially important for resources that also control durable storage or external identifiers.

The queue lab illustrates only the service cost of many independent deletion obligations. Reset, set λ=2 and μ=3, predict the initial four abstract jobs drain at t=4, then Play or Step. It has no ownership graph, UID matching, namespaces, finalizers, or foreground blockers. The analogy cannot tell you which dependents should be deleted. Use the graph trace below for lifecycle correctness, then use a capacity model to ask whether the responsible controllers can process the eligible work promptly.