Блог

Я развернул helm chart для prometheus-operator, и в настоящее время все службы запущены.

У меня уже есть контроллер входа, и он отлично маршрутизирует наши внутренние службы.

Но сейчас я создаю ingress для Prometheus, Grafana и AlertManager, и он работает не так, как ожидалось.

Мой Prometheus Ingress YAML —

 apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: prom
  namespace: monitoring
spec:
  rules:
  - host: abc.xyz.com
    http:
      paths:
      - backend:
          serviceName: my-prom-check-prometheus-o-prometheus
          servicePort: 9090
        path: /prometheus
  

Вывод — 404 не найден

Но для Grafana это не выдает 404, а скорее выдает ошибку недействительного ключа —

Пожалуйста, дайте совет по этому поводу. Я не изменял значения.yaml и непосредственно установил его.

Prometheus не знает, чего вы пытаетесь достичь, и именно поэтому перенаправляет в неизвестное место назначения, вы получаете сообщение об ошибке 404 страница не найдена, потому что http-запрос, который попадает на целевой веб-сервер, запрашивает содержимое /prometheus каталога вместо / того, из которого он фактически обслуживается.

Насколько я знаю, вы должны сказать prometheus, чтобы он принимал трафик по новому пути. Я предполагаю, что если вы измените path с /prometheus на / , это должно сработать.

Если вы хотите включить его в / prometheus, вам либо придется правильно настроить значения диаграммы оператора prometheus, я предполагаю, что они являются ExternalURL и RoutePrefix.

prometheus.prometheusSpec.ExternalURL -> Внешний URL, по которому будут доступны экземпляры Prometheus. Это необходимо для генерации правильных URL-адресов. Это необходимо, если Prometheus не обслуживается из корня DNS-имени.

prometheus.prometheusSpec.RoutePrefix -> Префикс маршрута, для которого Prometheus регистрирует обработчики HTTP. Это полезно, если при использовании ExternalURL и прокси-сервера переписываются HTTP-маршруты запроса, и фактический ExternalURL по-прежнему соответствует действительности, но сервер обслуживает запросы с другим префиксом маршрута. Например, для использования с прокси-сервером kubectl. Значение по умолчанию равно /

По этому поводу есть связанная с github проблема

или

Настройте свой nginx для перезаписи с /prometheus на / .

Следующее определение входа должно решить вашу проблему

 apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: prometheus-ingress
  namespace: monitoring
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - http:
      paths:
      - backend:
          serviceName: my-prom-check-prometheus-o-prometheus
          servicePort: 9090
        path: /prometheus(/|$)(.*)
  

Перезапись, которая была использована выше, гарантирует, что исходный путь доступа / prometheus будет перезаписан в / до достижения целевого модуля.

Об этом есть учебное пособие.

Если контроллер входа уже установлен, к prometheus можно получить доступ в пользовательском домене, используя следующие значения в вашем values.yaml.

Есть ли конкретная причина, по которой вы пытаетесь вручную настроить и развернуть prometheus ingress самостоятельно?

Используя следующие значения в ваших значениях.yaml создаст prometheus ingress для вас.

 ingress:
  enabled: true
  annotations: {kubernetes.io/ingress.class: "nginx"}
  labels: {}
  ## Hostnames.
  ## Must be provided if Ingress is enabled.
  ##
  # hosts:
  #   - prometheus.domain.com
  hosts: []
  ## Paths to use for ingress rules - one path should match the prometheusSpec.routePr
  ##
  paths:
    - /
  

Теперь вы сможете получить доступ к своему пользовательскому интерфейсу prometheus на localhost через браузер.