Настройте statsd-exporter как демон на Kubernetes и отправьте ему метрики из подов

Я хочу настроить statsd-exporter как DaemonSet в моем кластере Kubernetes. Он предоставляет UDP-порт 9125, по которому приложения могут отправлять метрики с помощью клиентской библиотеки statsD. Prometheus сканеры могут сканировать этот модуль экспорта для получения показателей приложения или системы. Я хочу отправить метрики на UDP-сервер, работающий в экспортере на порту 9125. У меня есть два варианта:

  1. Предоставьте службу как ClusterIP для DaemonSet, а затем настройте клиенты statsD для использования этого IP-адреса и порта для отправки метрик.

  2. Заставьте statsd-exporter работать на hostNetwork и каким-то образом разрешите модулям отправлять метрики exporter, работающим на том же узле.

Каким-то образом вариант 2 кажется лучше, поскольку мои модули будут отправлять метрики экспортеру, работающему на том же узле, но я не могу отправлять метрики в локальный модуль statsd-exporter, поскольку у меня нет IP-адреса узла, на котором находится модуль. работает.

Не могли бы вы сравнить плюсы и минусы обоих методов и подсказать, как я могу узнать IP-адрес узла, на котором работает модуль вместе с экспортером.

ИЗМЕНИТЬ 1

Я могу получить IP-адрес узла, добавив переменную среды.

- name: NODE_IP
  valueFrom:
    fieldRef:
      fieldPath: status.hostIP

Мне все еще нужна ясность в отношении того, какой подход к настройке будет лучше. Предоставление службы с типом ClusterIP, а затем использование переменной среды HOST:PORT from в модуле или использование hostNetwork: true в спецификации модуля, а затем доступ к ней с помощью переменной среды NODE_IP. Гарантирует ли clusterIp, что пакет будет перенаправлен на тот же узел, что и модуль, отправляющий пакет?

ИЗМЕНИТЬ 2

Я изучил безголовый сервис и думаю, что это ближе всего к что я хочу. Но я не уверен, что разрешение DNS вернет IP-адрес локального узла в качестве первого результата в nslookup.


kubernetes prometheus statsd
person Abhishek    schedule 27.08.2019    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Я бы предложил один из двух нижеприведенных подходов, у обоих есть свои плюсы и минусы.

  • Быстро, возможно, не совсем безопасно.

Демон устанавливается с использованием hostPort. Это будет быстро, поскольку оба модуля будут на одном узле, но порт statsd будет открыт. (Вам нужно защитить statsd каким-либо другим способом)

  • Не так быстро, как hostPort, но надежно

Открытие службы и использование службы DNS для подключения (servicename.namespace.svc.cluster.local). Не так быстро, как hostPort, поскольку нет возможности добраться до конкретного модуля, но надежно, так как никто за пределами кластера не может попасть в statsd.

Подробнее: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#communicating-with-daemon-pods

person Tummala Dhanvi    schedule 27.08.2019
comment
Да, я тоже чувствую, что это правильный путь. Я подожду некоторое время, пока появятся другие мнения. - person Abhishek; 28.08.2019