[multicluster] Provide mechanism to disable mirrored service label/annotation copying
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 11.5k
- Forks
- 1.4k
- Avg merge
- 3d 22h
- Merged PRs (30d)
- 53
Description
### What problem are you trying to solve?
It is sometimes undesirable to copy some or all of the labels/annotations of a mirrored service. Introduced in #6626 was a feature to copy all the labels and annotations from a source service to a mirrored service. This can causes issues because labels/annotations are often used for metadata/config for other tools that might be irrelevant or cause issues if copied to another cluster. Below is a concrete example (seen in our environments) and a hypothetical one.
It would be very useful to have a way to stop these labels/annotations being copied.
Examples:
* (concrete) We use ArgoCD to manage our deployments. It adds a `argocd.argoproj.io/instance` label to all resources under it's control, including Services. If one of these Services gets mirrored to another cluster also running ArgoCD, the `argocd.argoproj.io/instance` label is copied and so the remote ArgoCD assumes it owns the mirrored Service. This causes "fighting" between ArgoCD and the LinkerD service-mirror as they both try to control the same service (ArgoCD deleting it as no manifest, service-mirror recreating it, etc.)
* (hypothetical) Labels/annotations are often used by monitoring tools to mark services that should be monitored. For example, `prometheus.io/scrape` is a common annotation to mark a Service for Prometheus to scrape metrics from. If, however, this annotation is copied to a mirrored service this could cause Prometheus in the remote cluster to scrape metrics across the multicluster link, which may be undesirable for various reasons.
### How should the problem be solved?
There is many ways this could be solved. Ideally the label/annotation copying can be configured on a per-service basis.
The simplest approach would be new labels that the service-mirror would check for and not copy labels/annotations when they are present. For example if the `mirror.linkerd.io/copy-labels: false` label is present on a source service, the service-mirror would not copy the labels but would still copy the annotations. Similarly it could check for the `mirror.linkerd.io/copy-annotations: false` label to not copy the annotations. Both could be specified together to copy neither. Default behaviour would be to assume "true" to maintain backwards compatibility.
This could be implemented by modifying `multicluster/service-mirror/cluster_watcher.go` `getMirroredServiceLabels` and `getMirroredServiceAnnotations` to check for these labels on the remote service before copying in the `for` loops.
I might be able to provide a PR for this.
### Any alternatives you've considered?
The most flexible solution would be an allowlist/blocklist of label/annotations names that can(not) be copied. This could however get very complex to implement on a per-service basis e.g. either needing complex CLI arguments or complex labels on the source services. I think most use case will fall into the "all or nothing" category so a simple copy/don't copy option is a good starting point that could be expanded on in future.
### How would users interact with this feature?
Adding labels to source services in the same way as the `mirror.linkerd.io/exported` label is added.
### Would you like to work on this feature?
maybe
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in multicluster/service-mirror/cluster_watcher.go, focusing on getMirroredServiceLabels and getMirroredServiceAnnotations and how mirrored services are assembled. Check the existing service-mirror tests or test entry points before changing behavior. Done means source-service controls can prevent label or annotation copying while the default behavior remains unchanged.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- cloud, distributed-systems
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100