Skip to content

Improve multicluster service mirror controllers to be more flexible and GitOps-friendly #13768

Open
@alpeb

Description

@alpeb

Currently, in order to link to a target cluster, we rely on the linkerd mc link command which generates manifests for:

  • Link CR
  • Cluster credentials secrets
  • Probing service
  • Service mirror controller deployement
  • Service mirror controller RBAC

We would like to introduce a new model, moving the last three items to become part of the linkerd-multicluster chart.

To add a new link, users would have to:

  1. Persist the Link CR and cluster credentials. This can be assisted by the new flag linkerd mc link --service-mirror=false which would output just that, without the manifests for the service mirror controllers.
  2. Add a reference to the Link under a new controllers array in the chart's values.yaml. Optionally, controller-related config (like number of replicas, log level, resource constraints, etc) could be specified as well.

This way the user is only responsible for providing the config for their Links in a declarative way, without having to produce the manifests for the service mirror controllers, and no longer having to depend on the linkerd mc link command.

Also, until now people were advised to regenerate all their links whenever the multicluster extension was upgraded, so that the controllers would get upgraded as well. Now these controllers lifecycle and config make part of the extension itself, so re-linking would no longer be required (unless explicitly advised for cases where for example the Link CRD got an upgrade).

These are the pending tasks to achieve this:

Metadata

Metadata

Assignees

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions