Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] Should commonLabels be patchable? I ran into kind of a show stopper #4831

Closed
nickjj opened this issue Oct 14, 2022 · 2 comments
Closed
Labels
needs-kind Indicates a PR lacks a `kind/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.

Comments

@nickjj
Copy link

nickjj commented Oct 14, 2022

Imagine a typical set up by having this in 1 overlay directory with a kustomization.yaml file that inherits from a base:

  • Deployment for a web app
  • Service for the web app
  • Ingress for the web app
  • Config map for the web app

If you wanted to add a common app.kubernetes.io/name: "hello-app" label to all of these this is no problem, you can use commonLabels and you're good to go.

Then you can patch things as needed to do whatever else you need to do in your overlays.

But now let's say you want to introduce a "Background worker deployment". It would be essentially a duplicate of the web app deployment except with a different name. You'd also likely add a patch to override the image's command and a replace patch for the health checks. It would use the same config map and secrets as the web app deployment.

If you're using something like the AWS load balancer controller, it'll try to attach a load balancer readiness gate to the background worker because one criteria it uses is to attach it to pods whose name label matches a service. That will cause the background worker to fail and never become healthy because it's not a web service.

A solution for this would be to ensure the background worker has a different name label but how can we do that if commonLabels can't be removed or patched?

@k8s-ci-robot k8s-ci-robot added needs-kind Indicates a PR lacks a `kind/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Oct 14, 2022
@k8s-ci-robot
Copy link
Contributor

@nickjj: This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@nickjj nickjj changed the title [Question] Should commonLabels be patchable or is it not needed? [Question] Should commonLabels be patchable? I ran into kind of a show stopper Oct 17, 2022
@nickjj
Copy link
Author

nickjj commented Oct 18, 2022

Technically you can solve this with #1009 (comment), thanks a lot for that @zhouhaibing089!

I tested that for both remove and replace and it works. You can modify both labels and selectors. For anyone reading this in the future, selectors are immutable which will fail to apply if you try to rename them in an existing deployment.

If you delete your old deployment and then apply this type of patch it will work. Future deploys will also work as long as you're not renaming the selector again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-kind Indicates a PR lacks a `kind/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Projects
None yet
Development

No branches or pull requests

2 participants