Linkerd 2.12.0 injects proxies into control plane pods

[ngc4579]

We've just upgraded vom Linkerd 2.11.4 to 2.12.0 and notice Linkerd (now?) injects data plane proxies into the control plane. I actually can't quite remember if this was the case before the upgrade - the control plane has been installed into the exact same namespace set up as follows:

labels:
    config.linkerd.io/admission-webhooks: disabled
    field.cattle.io/projectId: p-fr8ck
    kubernetes.io/metadata.name: linkerd
    linkerd.io/control-plane-ns: linkerd
    linkerd.io/is-control-plane: "true"
  annotations:
    ...
    linkerd.io/inject: disabled

Is this somewhat intended behaviour? Especially as the namespace is annotated as linkerd.io/inject: disabled I'd rather assume the control plane pods don't get injected with data plane proxies.

As a side note...: I've only noticed the above because of a success rate below 100% for both linkerd and linkerd-viz namespaces - some yet unidentified component of our Rancher 2 environment keeps unsuccessfully requesting control plane pods.

[124341.307486s]   INFO ThreadId(01)  inbound:server{port=9996}:rescue{client.addr=10.10.0.114:37276}:  linkerd_app_core::errors::respond: Request failed error=connection  closed before message completed
[124341.307490s] WARN ThreadId(01) inbound:server{port=9996}:rescue{client.addr=10.10.0.114:37276}: linkerd_app_inbound::http::server: Unexpected error error=connection closed before message completed

The origin IP is one of some DaemonSet pods on the same node...

canal (rancher/mirrored-calico-node:v3.19.2)
cattle-node-agent (rancher/rancher-agent:2.6.3)
csi-cinder-nodeplugin (k8s.gcr.io/sig-storage/csi-node-driver-registrar:v1.3.0)
pushprox-kube-proxy-client (rancher/pushprox-client:v0.1.0-rancher2-client)
rancher-monitoring-prometheus-node-exporter (rancher/mirrored-prometheus-node-exporter:v1.2.2)

... But - as mentioned above - that was only the root cause that had me look into the control plane noticing it suddenly (?) has data plane proxies injected.

[olix0r]

The control plane has always run with proxies. The specific error you've seen is likely due to a timeout that was added to the controllers' admin servers. We think we've fixed this issue by changing the timeout (in #9272). This change will be included in this week's edge release and, assuming that goes well, we'll do a stable-2.12.1 release in the coming weeks.

[ngc4579]

Thank you so much for clarification. As mentioned above - I just couldn't remember the proxies... :) - Anyway. I think I'll install the edge release once it's available into our staging environment and see how things go.