add labels to diff command

[sethpollack]

What type of PR is this?
/kind feature

What this PR does / why we need it:
Would like to run be able to filter out things like secrets from kubectl diff

kubectl diff -f release.yaml -l app.kubernetes.io/component!=secrets

Does this PR introduce a user-facing change?:

add selectors to kubectl diff

[sethpollack]

/sig cli

[sethpollack]

/test pull-kubernetes-e2e-kind-ipv6

[sethpollack]

/test pull-kubernetes-kubemark-e2e-gce-big

[sethpollack]

/assign @pwittrock

[apelisse]

We've discussed about this problem in #87840. I think this idea is fresh and I sort of like it.

If we look at labels and annotations, my read is that it should be an annotation (please feel free to disagree). We could also possibly NOT make it a selector and just enforce the name directly: "hide-from-diff" (we should do much better than that and look at typical formats).

Thanks, thoughts?

[sethpollack]

We already have the concept of selectors in other kubectl commands like apply. This just ports over the selector flag from apply. This gives you the flexibility to exclude it from the diff or not, rather that enforcing it based on a convention.

[apelisse]

OK I think there are two things here:

1. People may only want to see resources based on labels, the same way you can do get, apply etc by label. That's a valid use-case.
2. People want to hide secrets from diff. I think that deserves special logic, and people shouldn't use labels for that.

But we shouldn't block 1 because of 2.

/lgtm
/approve

Now, I would understand if you use that mechanism to hide secrets in the mean time, but I think we should have a better mechanism.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: apelisse, sethpollack

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• staging/src/k8s.io/kubectl/OWNERS [apelisse]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[apelisse]

/retest

[sethpollack]

Makes sense. I would still make 2 optional.

[apelisse]

/retest

[fejta-bot]

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

[fejta-bot]

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

[sethpollack]

Thanks @apelisse