Почему Istio Mixer использует два развертывания для раздельного сбора и проверки политик телеметрии? - PullRequest
Новая
       4

Почему Istio Mixer использует два развертывания для раздельного сбора и проверки политик телеметрии?

0 голосов
/ 28 октября 2018

После развертывания istio мы видим два развертывания на основе Mixer: istio-policy и istio-telemetry.У них одинаковая спецификация контейнера на контейнере mixer: 

containers:
- args:
  - --address
  - unix:///sock/mixer.socket
  - --configStoreURL=k8s://
  - --configDefaultNamespace=istio-system
  - --trace_zipkin_url=http://zipkin:9411/api/v1/spans
  image: anjia0532/istio-release.mixer:master-latest-daily
  imagePullPolicy: IfNotPresent
  livenessProbe:
    failureThreshold: 3
    httpGet:
      path: /version
      port: 9093
      scheme: HTTP
    initialDelaySeconds: 5
    periodSeconds: 5
    successThreshold: 1
    timeoutSeconds: 1
  name: mixer
  ports:
  - containerPort: 9093
    protocol: TCP
  - containerPort: 42422
    protocol: TCP
  resources:
    requests:
      cpu: 10m

У меня два вопроса:

  1. Как контейнер миксера может знать, что он должен отвечать за телеметриюсбор или политика контроля?Я предполагаю, что они различаются по различным аргументам контейнера istio-proxy?

  2. Почему бы не использовать одно и то же развертывание для обеих функций?

1 Ответ

0 голосов
/ 30 октября 2018

Я поделюсь своим пониманием этой функции.Мы видим, что это разделение было сделано в версии 0.6, как написано в заметках о выпуске .

Отдельные кластеры проверки и отчета.При настройке Envoy теперь можно использовать разные кластеры для экземпляров микшера, которые используются для функции проверки микшера, и те, которые используются для функции отчета микшера.Это может быть полезно в больших развертываниях для лучшего масштабирования экземпляров Mixer.

Почему это важно?Проверки политики выполняются перед каждым запросом, поэтому отсюда и может возникнуть задержка, поэтому у нас может возникнуть необходимость масштабировать компонент политики микшера.Принимая во внимание, что отчет телеметрии происходит после запроса, более того, коляска буферизует исходящую телеметрию, поэтому вызов на микшер-телеметрию происходит не так часто.Кроме того, задержка данных телеметрии не так критична, поскольку она не повлияет на UX вашего приложения.

Короче говоря, основной причиной этого являются проблемы масштабируемости, особенно для многокластерной среды.

...