Prometheus очищает конечные точки входа K8s

Мой экземпляр Prometheus в настоящее время развернут вне кластера K8s. Я просмотрел следующую статью: https://www.linkedin.com/pulse/monitoring-kubernetes-prometheus-outside-cluster-steven-acreman.

и это дает очень хорошее представление о доступе к службам K8s через сервер api. Я все еще пытаюсь заставить его работать (проблема с сертификатами).

Однако у меня вопрос: нельзя ли использовать Prometheus для очистки имени хоста входящего контроллера для очистки конечной точки метрик. Или это вообще стандартный подход?

Я не мог найти ни одного документа или реализации примерно одинакового. Пожалуйста, подскажите, реализовал ли кто-нибудь описанный выше сценарий или есть ли по нему какие-либо документы.


kubernetes nginx-ingress prometheus
person swetad90    schedule 17.06.2019    source источник
comment
Не могли бы вы дать более подробное объяснение того, что вы ищете? Какие метрики?   -  person Crou    schedule 18.06.2019
comment
Метрики из моего REST API. У нас есть несколько микросервисов, развернутых в кластере, и мы получаем к ним доступ через другой контекст пути при входе. Я хотел знать, должны ли мы использовать Prometheus kubernetes_sd_config и пройти через Kube-Proxy, чтобы получить доступ к службам, или напрямую использовать входящие конечные точки, то есть myvip.com/app1/metrics или myvip.com/app2/metrics для сбора метрик.   -  person swetad90    schedule 18.06.2019

Ответы (1)


arrow_upward
1
arrow_downward

Я бы использовал конфигурации SD Kubernetes и взял на себя роль обнаруживать цели.

Конфигурации Kubernetes SD позволяют получать цели очистки из Kubernetes ' REST API и всегда оставаться синхронизированными с состоянием кластера.

Вы можете использовать тип роли endpoints:

Роль endpoints обнаруживает цели из перечисленных конечных точек службы. Для каждого адреса конечной точки обнаруживается одна цель на порт. Если конечная точка поддерживается модулем, все дополнительные порты контейнера модуля, не привязанные к порту конечной точки, также обнаруживаются как цели.

Доступные мета-метки:

  • __meta_kubernetes_namespace: пространство имен объекта конечных точек.
  • __meta_kubernetes_endpoints_name: Имена объекта конечных точек.
  • For all targets discovered directly from the endpoints list (those not additionally inferred from underlying pods), the following labels are attached:
    • __meta_kubernetes_endpoint_hostname: Hostname of the endpoint.
    • __meta_kubernetes_endpoint_node_name: имя узла, на котором размещена конечная точка.
    • __meta_kubernetes_endpoint_ready: Установите значение true или false для состояния готовности конечной точки.
    • __meta_kubernetes_endpoint_port_name: Имя порта конечной точки.
    • __meta_kubernetes_endpoint_port_protocol: Протокол порта конечной точки.
    • __meta_kubernetes_endpoint_address_target_kind: Тип адресата конечной точки.
    • __meta_kubernetes_endpoint_address_target_name: Имя целевого адреса конечной точки.
  • Если конечные точки принадлежат службе, прикрепляются все метки обнаружения role: service.
  • Для всех целей, поддерживаемых модулем, прикрепляются все ярлыки обнаружения role: pod.

Или тип роли ingress:

Роль ingress обнаруживает цель для каждого пути каждого входа. Обычно это полезно для черного ящика для мониторинга входящего трафика. Адрес будет установлен на хост, указанный во входной спецификации.

Доступные мета-метки:

  • __meta_kubernetes_namespace: пространство имен входящего объекта.
  • __meta_kubernetes_ingress_name: имя входящего объекта.
  • __meta_kubernetes_ingress_label_<labelname>: Каждая метка входящего объекта.
  • __meta_kubernetes_ingress_labelpresent_<labelname>: true для каждой метки входящего объекта.
  • __meta_kubernetes_ingress_annotation_<annotationname>: каждая аннотация входящего объекта.
  • __meta_kubernetes_ingress_annotationpresent_<annotationname>: true для каждой аннотации входящего объекта.
  • __meta_kubernetes_ingress_scheme: Схема протокола входящего трафика, https, если задана конфигурация TLS. По умолчанию http.
  • __meta_kubernetes_ingress_path: Путь от входящей спецификации. По умолчанию /.

Если вы хотите проверить подробный пример настройки Prometheus для Kubernetes, см. этот файл.

Также вас может заинтересовать сторонний оператор Prometheus, который автоматизирует установку Peometheus поверх Kubernetes.

person Crou    schedule 08.08.2019