Распределенная трассировка Linkerd с OpenCensus

Контекст

Я пытаюсь использовать OpenCensus и Linkerd. Хотя Linkerd имеет возможность автоматически инициализировать OpenCensus и jaeger в своем пространстве имен, я не хочу их использовать. Вместо этого я самостоятельно развернул их в пространстве имен «ops».

Вопросы

  1. Должен ли Linkerd внедряться сборщик OpenCensus.

В конце (ровно 4-я строка от последней) официальной документации, он говорит,

Убедитесь, что в сборщик OpenCensus вставлен прокси Linkerd.

Что это означает?
Следует ли мне вставлять сопроводительный файл компоновщика в модуль сборщика OpenCensus?
Если да, то почему?

  1. Должен ли я суффикс имени serviceaccount по пространству имен?

Например, предположим, что я настроил пространство имен по умолчанию следующим образом.

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 находится в пространстве имен ops, поэтому я поставил .ops в конце имени службы, получив my-opencensus-collector.ops:12345. И специальная учетная запись службы для сборщика OpenCensus также существует в пространстве имен ops. В этом случае следует ли мне поместить имя пространства имен в конец имени учетной записи службы?

Какой из них будет правильным?

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

Спасибо!


person jjangga    schedule 20.12.2020    source источник


Ответы (1)


  1. Должен ли Linkerd внедряться сборщик OpenCensus.

Да, сборщик OpenCensus должен быть внедрен с прокси Linkerd, потому что сами прокси отправляют информацию диапазона, используя mTLS. При использовании mTLS отправляющая (клиентская) и принимающая (серверная) стороны запроса должны предоставить сертификаты друг другу, чтобы проверить эти идентификаторы друг для друга таким образом, чтобы подтвердить, что идентификатор был выдан тот же надежный источник.

Сервисная сетка Linkerd состоит из плоскости управления и плоскости данных. Плоскость управления - это набор сервисов, которые выполняются в кластере для реализации функций сервисной сети. Взаимный TLS (mTLS) является одной из таких функций и реализуется linkerd-identity компонентом плоскости управления.

Плоскость данных состоит из любого количества прокси Linkerd, которые вводятся в службы в приложении, например, сборщик OpenCensus. Каждый раз, когда прокси-сервер запускается в модуле, он отправляет запрос на подпись сертификата компоненту linkerd-identity и получает взамен сертификат.

Итак, когда прокси Linkerd в плоскости управления отправляют интервалы сборщику, они аутентифицируют себя с помощью этих сертификатов, которые должны быть проверены прокси-сервером, введенным в модуль сборщика OpenCensus. Это гарантирует, что весь трафик, даже распределенные трассировки, безопасно пересылается внутри кластера.

  1. Должен ли я суффикс имени serviceaccount по пространству имен?

В вашем случае вы должны добавить к учетной записи службы суффикс пространства имен. По умолчанию Linkerd будет использовать пространство имен Pod, поэтому, если учетная запись службы не существует в пространстве имен Pod, конфигурация будет недействительной. В логике есть функция, которая проверяет пространство имен в имени аннотации и добавляет его, если оно существует:

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)
}

Итак, это правильно:

config.alpha.linkerd.io/trace-collector-service-account: my-opencensus-collector-service-account.ops
person cpretzer    schedule 28.12.2020