Linkerd 使用 OpenCensus 进行分布式跟踪

Question

Context

I am trying to use OpenCensus and Linkerd. Though Linkerd has an option to automatically provision OpenCensus and jaeger in its namespace, I don't want to use them. Instead, I deployed them independently by myself under the namespace named 'ops'.

Questions

1. Whether OpenCensus collector should be injected by Linkerd.

At the end (exactly 4th line from the last) of the the official docs , it says,

Ensure the OpenCensus collector is injected with the Linkerd proxy.

What does this mean?
Should I inject linkerd sidecar into OpenCensus collector pod?
If so, why?

2. Should I suffix serviceaccount name by namespace?

For example, let's say I've configured the default namespace like this.

apiVersion: v1
kind: Namespace
metadata:
  name: default
  annotations:
    linkerd.io/inject: enabled
    config.linkerd.io/trace-collector: my-opencensus-collector.ops:12345
    config.alpha.linkerd.io/trace-collector-service-account: my-opencensus-collector-service-account

my-opencensus-collector is in ops namespace, so I put .ops at the end of its service name, resulting my-opencensus-collector.ops:12345 . And the dedicated service account for the OpenCensus collector exists in ops namespace, too. In this case, should I put the namespace name at the end of service account name as well?

Which one would be right?

config.alpha.linkerd.io/trace-collector-service-account: my-opencensus-collector-service-account

or

config.alpha.linkerd.io/trace-collector-service-account: my-opencensus-collector-service-account.ops

Thanks!

Answer 1

1. Whether OpenCensus collector should be injected by Linkerd.

Yes, the OpenCensus collector should be injected with the Linkerd proxy because the proxies themselves send the span info using mTLS. With mTLS, the sending (client) and receiving (server) sides of the request must present certificates to each other in to verify that identities to each other in a way that validates that the identity was issued by the same trusted source.

The Linkerd service mesh is made up of the control plane and the data plane. The control plane is a set of services that run within the cluster to implement the features of the service mesh. Mutual TLS (mTLS) is one of those features and is implemented by the linkerd-identity component of the control plane.

The data plane is comprised of any number of the Linkerd proxies which are injected into the services in the application, like the OpenCensus collector. Whenever a proxy is started within a pod, it sends a certificate signing request to the linkerd-identity component and receives a certificate in return.

So, when the Linkerd proxies in the control plane send the spans to the collector, they authenticate themselves with those certificates, which must be verified by the proxy injected into the OpenCensus collector Pod. This ensures that all traffic, even distributed traces, are sent securely within the cluster.

2. Should I suffix serviceaccount name by namespace?

In your case, you should suffix the service account with the namespace. By default, Linkerd will use the Pod namespace, so if the service account doesn't exist in the Pod namespace, then the configuration will be invalid. The logic has a function that checks for a namespace in the annotation name and appends it, if it exists:

func ammendSvcAccount(ns string, params *Params) {
    hostAndPort := strings.Split(params.CollectorSvcAddr, ":")
    hostname := strings.Split(hostAndPort[0], ".")
    if len(hostname) > 1 {
        ns = hostname[1]
    }
    params.CollectorSvcAccount = fmt.Sprintf("%s.%s", params.CollectorSvcAccount, ns)
}

So, this one is correct:

config.alpha.linkerd.io/trace-collector-service-account: my-opencensus-collector-service-account.ops