Постоянное понимание хранения Prometheus при установке из [stable / prometheus] на кубернец / экс с Grafana - PullRequest
Новая
       26

Постоянное понимание хранения Prometheus при установке из [stable / prometheus] на кубернец / экс с Grafana

0 голосов
/ 14 апреля 2020

Проблема: результаты запросов к серверу Prometheus на стороне Grafana не согласованы, как это должно быть, когда у нас есть HA сервера Prometheus. Поэтому я хочу добиться согласованного доступа к хранилищу с высокой доступностью.

Сценарий-1 RelicaCount = 1 statefulSet = false Создано PersitantVolume Count = 1 Приложение работает, как и ожидалось, но не HA.

Scenerio-2 ReplicaCount = 3 statefulSet = false Создано PersistantVolume Count = 1 В этом сценарии работает только один модуль, а другие генерируют ошибку блокировки с сервера Prometheus.

Сценарий-2.1

ReplicaCount = 3 statefulSet = false Создано PersistantVolume Count = 1 с "--storage.tsdb.no-lockfile"

это создает 3 модуля, но за исключением 1, все остальные выдают ошибку golang из приложения сервера Prometheus.

Сценарий-3 ReplicaCount = 3 statefulSet = true Создано PersistantVolume Count = 3

Так что в этом сценарии у нас есть 3 реплики модули с 3 отдельными постоянными хранилищами через набор с сохранением состояния, который является рекомендуемой конфигурацией от сообщества. Но эта конфигурация не дает непротиворечивых метрик на Grafana, так как сеанс является липким.

Информация об инфраструктуре: диаграмма управления: версия "stable / prometheus": 10.0.1 appVersion: 2.15.2 Aws EKS с Kubernetes 1.14

Вопрос: Итак, как я могу достичь HA сервера Prometheus с планом HPA или VPA с постоянным хранилищем в Kubernetes.

Разрешение : Я подумываю решить эту проблему с помощью приведенного ниже решения:

  1. использовать реплику развертывания для модулей с одним постоянным хранилищем, но это не работает, или, возможно, моя конфигурация неверна для этого.
  2. предоставьте серверу Prometheus балансировщик нагрузки приложения с помощью липкого сеанса и используйте ALB URL в Grafana для получения постоянных результатов запроса. но, тем не менее, я считаю, что он будет вести себя по-разному для разных запросов pods.

Кто-нибудь сталкивался с этой проблемой раньше, если да, как вы справляетесь с HA и постоянным хранилищем в Kubernetes? Если моя конфигурация неверна, чтобы удовлетворить это требование, можете ли вы предоставить рекомендуемый подход и конфигурацию для этого?

Пожалуйста, спросите, если что-то не хватает, чтобы объяснить в моей текущей реализации, Спасибо заранее.

...