Skip to content

Deployment "Label selector updates": orphan behavior assumes --cascade=orphan, but the section doesn't say so #56075

@kfess

Description

@kfess

This is a Bug Report

Problem:

The Label selector updates section in the Deployment page tells the reader to "delete the Deployment and recreate it" and then describes the old ReplicaSet being orphaned or not orphaned.

If you must change the selector, you have to delete the Deployment and recreate it. Exercise great caution and ensure you grasp the following implications:
Additions: When you create a new Deployment with a narrower selector,...
Value Updates: Changing the existing value in a selector key (e.g., from...
Removals: Removing an existing key from the Deployment selector does...

I thought these two parts are internally inconsistent. A normal kubectl delete deployment deletes the Pods too, so there is nothing to orphan (but has downtime). The orphan behavior described in this section happens only with kubectl delete deployment <name> --cascade=orphan.

At first glance, the simple deletion case and the --cascade=orphan case are presented as one continuous explanation, so the reader cannot tell what Additions/Value Updates/Removals part assumes.

Proposed Solution:

State that the orphan-behavior here assumes kubectl delete <name> --cascade=orphan (which keeps the Pods). Split the two paths:

  1. Plain delete + recreate: no orphans, but downtime.
  2. --cascade=orphan + recreate: as described here.

Page to Update:

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#label-selector-updates

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/bugCategorizes issue or PR as related to a bug.needs-triageIndicates an issue or PR lacks a `triage/foo` label and requires one.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions