Feature Request

What problem are you trying to solve?

We use the gitops method for maintaining our clusters and deploying services. This involves writing kubernetes manifests (or kustomize, or helm charts) to a config repo and ArgoCD applies them to the cluster specified.

For example:

infrastructure
  \__ linkerd
         \__ azure
                \__ dev-ea
                \__ qa-scu
                \__ prod-scu

each folder under the azure folder is a specific cluster and contains the output of linkerd install --ha --proxy-auto-inject > install.yaml as well as an ingress for the web-ui, etc.

With the new upgrade mechanism (and identity), we can no longer do a linkerd install --ha --proxy-auto-inject > install.yaml (even with --ignore-cluster) and expect identity to stay happy (due to install creating new keys, etc).

If we do a linkerd upgrade > install.yaml it will take the config from whichever cluster is my current kubernetes context. Therefore if I wish to upgrade prod-scu and I'm not paying attention, it may write config values from dev-ea.

How should the problem be solved?

The addition of a --from-manifest flag for the linkerd upgrade command. Instead of reading the config from the linkerd-config configmap, it reads it from the manifest created by a prior linkerd install --flags... > install.yaml

Any alternatives you've considered?

Nothing else on the linkerd side comes to mind. We could probably write some tooling that does the upgrade in a way that mitigates the risk outlined above.

How would users interact with this feature?

linkerd upgrade --from-manifests install.yaml > install.yaml