В чем разница между основными проектами OS Kube-Prometheus и оператором Prometheus?

Question

Github-репо проекта Prometheus Operator https://github.com/coreos/prometheus-operator/ сообщает, что

Оператор Prometheus делает конфигурацию Prometheus родной для Kubernetes, а также управляет и управляет кластерами Prometheus и Alertmanager. Это часть головоломки о полном сквозном мониторинге.

kube-prometheus сочетает в себе Prometheus Operator с набором манифестов, которые помогают начать мониторинг самого Kubernetes и приложений, работающих поверх него.

Может кто-нибудь уточнить это?

Answer 1

У меня всегда был один и тот же вопрос / я неоднократно сталкивался с обоими, но чтение приведенного выше ответа не прояснило его для меня / мне нужно было короткое объяснение. Я обнаружил эту проблему с github, которая просто прояснила мне ситуацию.https://github.com/coreos/prometheus-operator/issues/2619

Цитата nicgirault из GitHub:

Наконец я понял, что диаграмма прометея-оператора упаковывает стек кубе-прометей, но мне потребовалось около 10 часов, чтобы понять это.

Вот мое краткое объяснение:
"kube-prometheus" и "Prometheus Operator Helm Chart" оба делают одно и то же:
1. В основном концепция Ingress/Ingress Controller применяется к Metrics / Prometheus Operator.
2. Оба являются средством простой настройки, установки и управления огромным распределенным приложением (Kubernetes Prometheus Stack) в Kubernetes:

что такое весь стек Kube Prometheus, спросите вы?
Prometheus, Grafana, AlertManager, CRD (пользовательские определения ресурсов), Prometheus Operator(программное приложение-бот), правила предупреждений IaC, панели мониторинга IaC Grafana, CRD IaC ServiceMonitor (которые автоматически генерируют конфигурацию сбора метрик Prometheus и автоматически импортируют ее в Prometheus Server)
(Также, когда я говорю о простой настройке, я имею в виду от 1000 до 10000++ строк простой для понимания людьми конфигурации, которая генерирует и автоматически управляет 10000-100000 строк конфигурации машины + материал с разумными настройками по умолчанию + мониторинг конфигурации, самообслуживание, распределенное сегментирование конфигурации с оператор / контроллер для объединения конфигурации + генерации подробной шаблонной машиночитаемой конфигурации из удобной, удобочитаемой человеком конфигурации.

Если они достигают одной и той же конечной цели, вы можете спросить, в чем разница между ними?
https://github.com/coreos/kube-prometheus
https://github.com/helm/charts/tree/master/stable/prometheus-operator
По сути, kube-prometheus CoreOS развертывает стек Prometheus с помощью Ksonnet, что, кстати, является теперь встроен в kubectl.
Таблица Шлем Оператора Прометея оборачивает kube-prometheus / достигает того же конечного результата, но с Хелмом.

Итак, какой из них использовать?
Не имеет значения + они достигают того же конечного результата + не должно быть безумно сложно начать с одного и переключиться на другое.

Хелм, как правило, быстрее осваивает / развивает базовое мастерство.

Ksonnet сложнее изучить / развить базовое мастерство, но:
- он более идемпотентный (лучше для автоматизации CICD) (но это всего лишь разница в 99% идемпотента против 99,99% идемпотента).
- имеет встроенный шаблон, что означает, что если у вас есть несколько кластеров, вам нужно управлять / которые вы хотите всегда согласовывать друг с другом. Затем вы можете использовать шаблоны ksonnet для управления несколькими экземплярами Kube Prometheus Stack (для нескольких envs), используя базу кода DRY с большим количеством повторного использования кода. (Если у вас есть только несколько env, и Prometheus не нужно часто менять, то не совсем разумно вручную синхронизировать 4 файла значений Helm. Я также видел шаблон Jinja2, используемый для шаблонов файлов значений Helm, но если вы собираетесь возиться с этим, вы можете просто рассмотреть ksonnet.)

Answer 2

Kubernetes operator являются конкретными приложениями (модулями) kubernetes, которые автоматически конфигурируют, управляют и оптимизируют другие развертывания Kubernetes. Они реализованы как пользовательский контроллер.

Согласно официальному сайту coreOS:

Операторы были представлены CoreOS как класс программного обеспечения, которое управляет другим программным обеспечением, внедряя в программное обеспечение знания, полученные людьми.

Оператор Prometheus предоставляет простой способ развертывания, настройки и мониторинга ваших экземпляров Prometheus в кластере kubernetes. Для этого оператор прометея вводит три типа определения пользовательских ресурсов (CRD) в kubernetes.

1. Прометей
2. Alertmanager
3. ServiceMonitor

Теперь, с помощью вышеупомянутых CRD, вы можете напрямую создать экземпляр Prometheus, предоставив kind: Prometheus и экземпляр Прометея готов служить, также вы можете сделать для AlertManager, Без этого вам придется настроить развертывание для Prometheus с его образом, конфигурацией и многими другими вещами.

Оператор Prometheus позволяет максимально упростить запуск Prometheus в верхней части Kubernetes, сохраняя при этом собственные параметры конфигурации Kubernetes.

Теперь, Kube-Prometheus реализовал оператор Prometheus и предоставляет вам минимальные файлы yaml для создания ваших основных настроек prometheus, alertmanager а также grafana запустив одну команду.

git clone https://github.com/coreos/prometheus-operator.git
kubectl apply -f prometheus-operator/contrib/kube-prometheus/manifests/

Запустив указанную выше команду в каталоге kube-prometheus, вы получите monitoring пространство имен, которое будет иметь экземпляр alertmanager, prometheus а также grafana для пользовательского интерфейса. Этого достаточно для настройки большинства основных реализаций, и если вам нужно больше подробностей в соответствии с вашим приложением, вы можете добавить больше yamls нужного вам экспортера.

Kube-prometheus - это еще один вклад в проект "Прометей-оператор", который очень хорошо реализует функциональность оператора "Прометей" и предоставляет вам полную настройку мониторинга для вашего кластера kubernetes. Вы можете начать с kube-prometheus и оттуда расширить функциональные возможности вашей настройки мониторинга в соответствии с вашим приложением.

Подробнее о Прометее-операторе можно узнать здесь

Answer 3

На сегодняшний день, 28.09.2020, это способ установить Prometheus в кластере Kubernetes https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack#kube-prometheus-stack

Answer 4

Согласно официальной документации, kube-prometheus-stack — это переименование prometheus-operator. Как я понял, в kube-prometheus-stack также есть предустановленные дашборды grafana и правила prometheus.

Примечание. Эта диаграмма ранее называлась диаграммой prometheus-operator, а теперь переименована, чтобы более четко отразить, что она устанавливает стек проекта kube-prometheus, в котором Prometheus Operator является лишь одним компонентом.

Взято с https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack

Answer 5

Архитектурно контейнер запускает docker. Журналы контейнера по умолчанию управляются Docker, а драйвер журнала по умолчанию использует JSON-файл. log-driver": "json-file

https://docs.docker.com/config/containers/logging/configure/Если для управления логами контейнера используется jSON-файл по умолчанию, ротация логов по умолчанию не выполняется. Таким образом, драйвер журнала JSON-файла по умолчанию, хранящийся драйвером журнала, может привести к большому объему дискового пространства для контейнеров, которые генерируют большой объем выходных данных, что может привести к нехватке места на диске.

В этом случае сохраняйте лог в ES, храните его отдельно, а индекс периодически удаляйте с помощью куратора kubernetes И запускайте запланированное задание в K8S для периодического удаления индекса

Другим решением для дискового пространства является периодическое удаление старых логов из jSON-файлов. Обычно мы задаем размер и количество логов

При этом будет создано не более 10 файлов журналов, каждый из которых имеет максимальный размер 20 МБ. Поэтому в контейнере максимум 200 Мб логов. "log-driver": "json-file", "log-opts": { "max-size": "20m", "max-file": "10" },

Примечание. Как правило, журнал Docker по умолчанию помещается /var/lib/docker/containers/Но в том же случае kubernetes также сохраняет журналы и создает структуру каталогов, чтобы помочь вам найти журналы на основе модулей, поэтому вы можете найти журналы контейнеров для каждого модуля, работающего на узле. /var/log/pods/<namespace>_<pod_name>_<pod_id>/<container_name>/

При удалении пода /var/lib/container в docker/containers/log и k8s, созданные в /var/log/pods/pod log, будут удалены.

Например, если POD перезапускается во время производства, журнал модуля будет удален, независимо от того, находится ли он на исходном узле или перешел на другой узел. Поэтому этот журнал необходимо сохранить в ES для централизованного управления. Многие проекты НИОКР в большинстве случаев проверяют журнал для устранения неполадок.