Why can adding a label through commonLabels make kubectl apply fail for an existing Deployment?

Select your answer:

A.It removes every label the Deployment already had before the build
B.It renames the Deployment, which forces Kubernetes to create a whole new one
C.It also adds the label to selectors, which can't change on a Deployment
D.It labels the Pods only, so the Deployment's selector stops matching

Show answer and explanation

Answer: It also adds the label to selectors, which can't change on a Deployment

Explanation

commonLabels adds its labels to resources, selectors and pod templates. A new label changes spec.selector, which Kubernetes rejects on an existing Deployment. commonLabels is deprecated in favor of the labels field, which leaves selectors alone unless you ask for them.

Take the Advanced Kustomize quiz All Kustomize levels

How do you add a label to every resource without changing any selectors?
What does an images entry with name: nginx and a digest: sha256:... value do?
A strategic merge patch lists one container with a new image. What happens to the base's other containers?
How do you remove a container from a base Deployment with a strategic merge patch?
When is a JSON 6902 patch a better choice than a strategic merge patch?
A patch target sets kind: Deployment and labelSelector: tier=backend. Which resources does the patch change?

Why can adding a label through commonLabels make kubectl apply fail for an existing Deployment?

Select your answer:

Explanation

More medium Kustomize questions