Thank you for reading this post, don't forget to subscribe!

задача – поднять Prometheus и все необходимые експортёры в AWS Elastic Kubernetes Cluster, и с него через /federation передавать метрики на наш “центровой” Prometheus, где уже есть Alertmanager и Grafana.

Смутил целый набор чартов – есть просто Prometheus, есть kube-prometheus, есть prometheus-operator, причём от разных разработчиков:

Bitnami Prometheus Operator – https://github.com/bitnami/charts/tree/master/bitnami/prometheus-operator/
CoreOS Prometheus Operator – https://github.com/coreos/prometheus-operator
Helm Community Prometheus Operator – https://github.com/prometheus-community/helm-charts
CoreOS kube-prometheus – https://github.com/coreos/kube-prometheus
И “просто Prometheus” – https://github.com/helm/charts/tree/master/stable/prometheus

Хотя в репозитории находится только один prometheus-operator:

helm search repo stable/prometheus-operator -o yaml
- app_version: 0.38.1
description: Provides easy monitoring definitions for Kubernetes services, and deployment
and management of Prometheus instances.
name: stable/prometheus-operator
version: 8.14.0

helm search repo stable/prometheus-operator -o yaml

- app_version: 0.38.1

description: Provides easy monitoring definitions for Kubernetes services, and deployment

and management of Prometheus instances.

version: 8.14.0

Разница между stable/prometheus и stable/prometheus-operator в том, что в Operator включена Grafana с набором готовых дашборд и набор ServiceMonitors для сбора метрик с сервисов кластера, таких как CoreDNS, API Server, Scheduler, etc.

Собственно – используем stable/prometheus-operator.

Prometheus Operator deployment

Деплоим:

helm install --namespace monitoring --create-namespace prometheus stable/prometheus-operator
manifest_sorter.go:192: info: skipping unknown hook: "crd-install"
manifest_sorter.go:192: info: skipping unknown hook: "crd-install"
manifest_sorter.go:192: info: skipping unknown hook: "crd-install"
manifest_sorter.go:192: info: skipping unknown hook: "crd-install"
manifest_sorter.go:192: info: skipping unknown hook: "crd-install"
manifest_sorter.go:192: info: skipping unknown hook: "crd-install"
NAME: prometheus
LAST DEPLOYED: Mon Jun 15 17:54:27 2020
NAMESPACE: monitoring
STATUS: deployed
REVISION: 1
NOTES:
The Prometheus Operator has been installed. Check its status by running:
kubectl --namespace monitoring get pods -l "release=prometheus"
Visit https://github.com/coreos/prometheus-operator for instructions on how
to create & configure Alertmanager and Prometheus instances using the Operator.

helm install --namespace monitoring --create-namespace prometheus stable/prometheus-operator

manifest_sorter.go:192: info: skipping unknown hook: "crd-install"

NAME: prometheus

LAST DEPLOYED: Mon Jun 15 17:54:27 2020

NAMESPACE: monitoring

STATUS: deployed

REVISION: 1

NOTES:

The Prometheus Operator has been installed. Check its status by running:

kubectl --namespace monitoring get pods -l "release=prometheus"

Visit https://github.com/coreos/prometheus-operator for instructions on how

to create & configure Alertmanager and Prometheus instances using the Operator.

Проверяем поды:

kk -n monitoring get pod
NAME                                                     READY   STATUS    RESTARTS   AGE
alertmanager-prometheus-prometheus-oper-alertmanager-0   2/2     Running   0          41s
prometheus-grafana-85c9fbc85c-ll58c                      2/2     Running   0          46s
prometheus-kube-state-metrics-66d969ff69-6b7t8           1/1     Running   0          46s
prometheus-prometheus-node-exporter-89mf4                1/1     Running   0          46s
prometheus-prometheus-node-exporter-bpn67                1/1     Running   0          46s
prometheus-prometheus-node-exporter-l9wjm                1/1     Running   0          46s
prometheus-prometheus-node-exporter-zk4cm                1/1     Running   0          46s
prometheus-prometheus-oper-operator-7d5f8ff449-fl6x4     2/2     Running   0          46s
prometheus-prometheus-prometheus-oper-prometheus-0       3/3     Running   1          31

kk -n monitoring get pod

NAME READY STATUS RESTARTS AGE

alertmanager-prometheus-prometheus-oper-alertmanager-0 2/2 Running 0 41s

prometheus-grafana-85c9fbc85c-ll58c 2/2 Running 0 46s

prometheus-kube-state-metrics-66d969ff69-6b7t8 1/1 Running 0 46s

prometheus-prometheus-node-exporter-89mf4 1/1 Running 0 46s

prometheus-prometheus-node-exporter-bpn67 1/1 Running 0 46s

prometheus-prometheus-node-exporter-l9wjm 1/1 Running 0 46s

prometheus-prometheus-node-exporter-zk4cm 1/1 Running 0 46s

prometheus-prometheus-oper-operator-7d5f8ff449-fl6x4 2/2 Running 0 46s

prometheus-prometheus-prometheus-oper-prometheus-0 3/3 Running 1 31

Note: alias kk="kubectl" >> ~/.bashrc

Итак, Prometheus Operator деплоит нам целый набор сервисов – и сам Prometheus, и Alertmanager, и Grafana, плюс набор ServiceMonitors:

kk -n monitoring get servicemonitor
NAME                                                 AGE
prometheus-prometheus-oper-alertmanager              3m53s
prometheus-prometheus-oper-apiserver                 3m53s
prometheus-prometheus-oper-coredns                   3m53s
prometheus-prometheus-oper-grafana                   3m53s
prometheus-prometheus-oper-kube-controller-manager   3m53s
prometheus-prometheus-oper-kube-etcd                 3m53s
prometheus-prometheus-oper-kube-proxy                3m53s
prometheus-prometheus-oper-kube-scheduler            3m53s
prometheus-prometheus-oper-kube-state-metrics        3m53s
prometheus-prometheus-oper-kubelet                   3m53s
prometheus-prometheus-oper-node-exporter             3m53s
prometheus-prometheus-oper-operator                  3m53s
prometheus-prometheus-oper-prometheus                3m53s

kk -n monitoring get servicemonitor

NAME AGE

prometheus-prometheus-oper-alertmanager 3m53s

prometheus-prometheus-oper-apiserver 3m53s

prometheus-prometheus-oper-coredns 3m53s

prometheus-prometheus-oper-grafana 3m53s

prometheus-prometheus-oper-kube-controller-manager 3m53s

prometheus-prometheus-oper-kube-etcd 3m53s

prometheus-prometheus-oper-kube-proxy 3m53s

prometheus-prometheus-oper-kube-scheduler 3m53s

prometheus-prometheus-oper-kube-state-metrics 3m53s

prometheus-prometheus-oper-kubelet 3m53s

prometheus-prometheus-oper-node-exporter 3m53s

prometheus-prometheus-oper-operator 3m53s

prometheus-prometheus-oper-prometheus 3m53s

Роль ServiceMonitors рассмотрим ниже, когда будем добавлять свой ServiceMonitor в Добавление сервиса в мониторинг.

Grafana access

Пока всё это тестируем – пробросим порт на Grafana, что бы посмотреть какие дашборды там есть.

Находим под с Grafana:

kk -n monitoring get pod
NAME                                                     READY   STATUS    RESTARTS   AGE
alertmanager-prometheus-prometheus-oper-alertmanager-0   2/2     Running   0          103s
prometheus-grafana-85c9fbc85c-wl856                      2/2     Running   0          107s
...

kk -n monitoring get pod

NAME READY STATUS RESTARTS AGE

alertmanager-prometheus-prometheus-oper-alertmanager-0 2/2 Running 0 103s

prometheus-grafana-85c9fbc85c-wl856 2/2 Running 0 107s

...

И вызываем port-forward:

kk -n monitoring port-forward prometheus-grafana-85c9fbc85c-wl856 3000:3000
Forwarding from 127.0.0.1:3000 -> 3000
Forwarding from [::1]:3000 -> 3000

kk -n monitoring port-forward prometheus-grafana-85c9fbc85c-wl856 3000:3000

Forwarding from 127.0.0.1:3000 -> 3000

Forwarding from [::1]:3000 -> 3000

Открываем в браузере localhost:3000, логинимся с admin и паролем prom-operator, и получаем целый набор готовых графиков, например:

На момент написания – Prometheus Operator запускал Grafana 7.0.3 (на нашем “центровом” сервере мониторинга всё ещё 6.5).

Собственно, из всего этого в будущем просто можно будет надёргать примеров всяких запросов.

На сейчас нам тут не нужны ни сама Grafana, ни Alertmanager, так что попозже мы их выпилим.

Prometheus Operator configuration

Prometheus Operator использует Custom Resource Definitions, которые описывают ресурсы:

kk -n monitoring get crd
NAME                                    CREATED AT
alertmanagers.monitoring.coreos.com     2020-06-15T14:47:44Z
eniconfigs.crd.k8s.amazonaws.com        2020-04-10T07:21:20Z
podmonitors.monitoring.coreos.com       2020-06-15T14:47:45Z
prometheuses.monitoring.coreos.com      2020-06-15T14:47:46Z
prometheusrules.monitoring.coreos.com   2020-06-15T14:47:47Z
servicemonitors.monitoring.coreos.com   2020-06-15T14:47:47Z
thanosrulers.monitoring.coreos.com      2020-06-15T14:47:48Z

kk -n monitoring get crd

NAME CREATED AT

alertmanagers.monitoring.coreos.com 2020-06-15T14:47:44Z

eniconfigs.crd.k8s.amazonaws.com 2020-04-10T07:21:20Z

podmonitors.monitoring.coreos.com 2020-06-15T14:47:45Z

prometheuses.monitoring.coreos.com 2020-06-15T14:47:46Z

prometheusrules.monitoring.coreos.com 2020-06-15T14:47:47Z

servicemonitors.monitoring.coreos.com 2020-06-15T14:47:47Z

thanosrulers.monitoring.coreos.com 2020-06-15T14:47:48Z

Например, в prometheuses.monitoring.coreos.com описывается Custom Resource с именем Prometheus:

kk -n monitoring get crd prometheuses.monitoring.coreos.com -o yaml
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
...
spec:
...
names:
kind: Prometheus
listKind: PrometheusList
plural: prometheuses
singular: prometheus
...

kk -n monitoring get crd prometheuses.monitoring.coreos.com -o yaml

apiVersion: apiextensions.k8s.io/v1beta1

kind: CustomResourceDefinition

...

spec:

...

names:

kind: Prometheus

listKind: PrometheusList

plural: prometheuses

singular: prometheus

...

И далее к нему можно обращаться, как к обычному ресурсу Kubernetes, используя имя из names:

kk -n monitoring get prometheus -o yaml
apiVersion: v1
items:
- apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
annotations:
meta.helm.sh/release-name: prometheus
meta.helm.sh/release-namespace: monitoring
...
spec:
alerting:
alertmanagers:
- apiVersion: v2
name: prometheus-prometheus-oper-alertmanager
namespace: monitoring
pathPrefix: /
port: web
baseImage: quay.io/prometheus/prometheus
enableAdminAPI: false
externalUrl: http://prometheus-prometheus-oper-prometheus.monitoring:9090
listenLocal: false
logFormat: logfmt
logLevel: info
paused: false
podMonitorNamespaceSelector: {}
podMonitorSelector:
matchLabels:
release: prometheus
portName: web
replicas: 1
retention: 10d
routePrefix: /
ruleNamespaceSelector: {}
ruleSelector:
matchLabels:
app: prometheus-operator
release: prometheus
securityContext:
fsGroup: 2000
runAsGroup: 2000
runAsNonRoot: true
runAsUser: 1000
serviceAccountName: prometheus-prometheus-oper-prometheus
serviceMonitorNamespaceSelector: {}
serviceMonitorSelector:
matchLabels:
release: prometheus
version: v2.18.1
...

kk -n monitoring get prometheus -o yaml

apiVersion: v1

items:

- apiVersion: monitoring.coreos.com/v1

kind: Prometheus

metadata:

annotations:

meta.helm.sh/release-name: prometheus

meta.helm.sh/release-namespace: monitoring

...

spec:

alerting:

alertmanagers:

- apiVersion: v2

namespace: monitoring

pathPrefix: /

port: web

baseImage: quay.io/prometheus/prometheus

enableAdminAPI: false

externalUrl: http://prometheus-prometheus-oper-prometheus.monitoring:9090

listenLocal: false

logFormat: logfmt

logLevel: info

paused: false

podMonitorNamespaceSelector: {}

podMonitorSelector:

matchLabels:

release: prometheus

portName: web

replicas: 1

retention: 10d

routePrefix: /

ruleNamespaceSelector: {}

ruleSelector:

matchLabels:

app: prometheus-operator

release: prometheus

securityContext:

fsGroup: 2000

runAsGroup: 2000

runAsNonRoot: true

runAsUser: 1000

serviceAccountName: prometheus-prometheus-oper-prometheus

serviceMonitorNamespaceSelector: {}

serviceMonitorSelector:

matchLabels:

release: prometheus

version: v2.18.1

...

Нам тут интересно значение serviceMonitorSelector:

...
serviceMonitorSelector: 
  matchLabels:
    release: prometheus

...

serviceMonitorSelector:

matchLabels:

release: prometheus

Которое определяет какие ServiceMonitors будут включены под “наблюдение” Prometheus.

Добавление сервиса в мониторинг

Теперь попробуем добавить новый сервис в наш мониторинг:

запустим Redis server
запустип redis_exporter
добавим ServiceMonitor
настроим Prometheus Operator использование этого ServiceMonitor для сбора метрик с експортёра

Запуск Redis server

Создаём неймспейс, что бы максимально приблизить условия к “боевым”, когда мониторинг и приложения работают не в одном default namespace, а в разных:

kk create ns redis-test
namespace/redis-test created

1 2	kk create ns redis-test namespace/redis-test created

Запускаем Redis:

kk -n redis-test run redis --image=redis
deployment.apps/redis created

1 2	kk -n redis-test run redis --image=redis deployment.apps/redis created

Создаём для него сервис:

kk -n redis-test expose deploy redis --type=ClusterIP --name redis-svc --port 6379
service/redis-svc exposed

1 2	kk -n redis-test expose deploy redis --type=ClusterIP --name redis-svc --port 6379 service/redis-svc exposed

Проверяем:

kk -n redis-test get svc redis-svc
NAME        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
redis-svc   ClusterIP   172.20.237.116   <none>        6379/TCP   25s

kk -n redis-test get svc redis-svc

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

redis-svc ClusterIP 172.20.237.116 <none> 6379/TCP 25s

Окей – сам Redis работает, добавляем его експортер.

Запуск `redis_exporter`

Запускаем из Helm:

helm install -n monitoring redis-exporter --set "redisAddress=redis://redis-svc.redis-test.svc.cluster.local:6379" stable/prometheus-redis-exporter

Проверяем его сервис:

kk -n monitoring get svc
NAME                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
alertmanager-operated                      ClusterIP   None             <none>        9093/TCP,9094/TCP,9094/UDP   89m
...
redis-exporter-prometheus-redis-exporter   ClusterIP   172.20.239.67    <none>        9121/TCP                     84s

kk -n monitoring get svc

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

alertmanager-operated ClusterIP None <none> 9093/TCP,9094/TCP,9094/UDP 89m

...

redis-exporter-prometheus-redis-exporter ClusterIP 172.20.239.67 <none> 9121/TCP 84s

Его ендпоинт:

kk -n monitoring get endpoints redis-exporter-prometheus-redis-exporter -o yaml
apiVersion: v1
kind: Endpoints
metadata:
...
labels:
app: prometheus-redis-exporter
app.kubernetes.io/managed-by: Helm
chart: prometheus-redis-exporter-3.4.1
heritage: Helm
release: redis-exporter
name: redis-exporter-prometheus-redis-exporter
namespace: monitoring
...
ports:
- name: redis-exporter
port: 9121
protocol: TCP

kk -n monitoring get endpoints redis-exporter-prometheus-redis-exporter -o yaml

apiVersion: v1

kind: Endpoints

metadata:

...

labels:

app: prometheus-redis-exporter

app.kubernetes.io/managed-by: Helm

chart: prometheus-redis-exporter-3.4.1

heritage: Helm

release: redis-exporter

namespace: monitoring

...

ports:

- name: redis-exporter

port: 9121

protocol: TCP

Поверим доступ к метрикам – запустим дебаг-под с Debian, устанавливаем в нём curl:

kk -n monitoring run --rm -ti debug --image=debian --restart=Never bash
If you don't see a command prompt, try pressing enter.
root@debug:/# apt update && apt -y install curl

kk -n monitoring run --rm -ti debug --image=debian --restart=Never bash

If you don't see a command prompt, try pressing enter.

root@debug:/# apt update && apt -y install curl

И обращаемся к ендпоинту сервиса redis_exporter:

root@debug:/# curl redis-exporter-prometheus-redis-exporter:9121/metrics
...
HELP redis_up Information about the Redis instance
TYPE redis_up gauge
redis_up 1
HELP redis_uptime_in_seconds uptime_in_seconds metric
TYPE redis_uptime_in_seconds gauge
redis_uptime_in_seconds 2793

root@debug:/# curl redis-exporter-prometheus-redis-exporter:9121/metrics

...

HELP redis_up Information about the Redis instance

TYPE redis_up gauge

redis_up 1

HELP redis_uptime_in_seconds uptime_in_seconds metric

TYPE redis_uptime_in_seconds gauge

redis_uptime_in_seconds 2793

Либо без дополнительного пода – делаем port-forward на redis-svc:

kk -n monitoring port-forward svc/redis-exporter-prometheus-redis-exporter 9121:9121
Forwarding from 127.0.0.1:9121 -> 9121
Forwarding from [::1]:9121 -> 9121

kk -n monitoring port-forward svc/redis-exporter-prometheus-redis-exporter 9121:9121

Forwarding from 127.0.0.1:9121 -> 9121

Forwarding from [::1]:9121 -> 9121

И проверяем с локальной машины:

curl localhost:9121/metrics
...
redis_up 1
HELP redis_uptime_in_seconds uptime_in_seconds metric
TYPE redis_uptime_in_seconds gauge
redis_uptime_in_seconds 8818

curl localhost:9121/metrics

...

redis_up 1

HELP redis_uptime_in_seconds uptime_in_seconds metric

TYPE redis_uptime_in_seconds gauge

redis_uptime_in_seconds 8818

Хорошо – у нас есть приложение – Редис, есть его експортёр, который отдаёт нам метрики на порту 9121 по URI /metrics – теперь надо настроить Prometheus Operator на сбор метрик с него.

Создание Kubernetes ServiceMonitor

Проверим лейблы нашего redis_exporter:

kk -n monitoring get deploy redis-exporter-prometheus-redis-exporter -o yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
...
generation: 1
labels:
app: prometheus-redis-exporter
app.kubernetes.io/managed-by: Helm
chart: prometheus-redis-exporter-3.4.1
heritage: Helm
release: redis-exporter
...

kk -n monitoring get deploy redis-exporter-prometheus-redis-exporter -o yaml

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

...

generation: 1

labels:

app: prometheus-redis-exporter

app.kubernetes.io/managed-by: Helm

chart: prometheus-redis-exporter-3.4.1

heritage: Helm

release: redis-exporter

...

И ещё раз глянем селектор serviceMonitorSelector ресурса prometheus:

kk -n monitoring get prometheus -o yaml

В конце манифеста находим:

...
serviceMonitorSelector: 
  matchLabels:
    release: prometheus

...

serviceMonitorSelector:

matchLabels:

release: prometheus

Т.е. Prometheus ищет ServiceMonitor-ы с тегом release, у которых значение prometheus.

Далее – создаём ServiceMonitor:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    serviceapp: redis-servicemonitor
    release: prometheus
  name: redis-servicemonitor
  namespace: monitoring
spec:
  endpoints:
  - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
    interval: 15s
    port: redis-exporter
  namespaceSelector:
    matchNames:
    - monitoring
  selector:
    matchLabels:
      release: redis-exporter

apiVersion: monitoring.coreos.com/v1

kind: ServiceMonitor

metadata:

labels:

serviceapp: redis-servicemonitor

release: prometheus

namespace: monitoring

spec:

endpoints:

- bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token

interval: 15s

port: redis-exporter

namespaceSelector:

matchNames:

- monitoring

selector:

matchLabels:

release: redis-exporter

В его labels задаём release: prometheus, что бы Prometheus его обнаружил, а в selector.matchLabels – указываем поиск сервисов с тегом release: redis-exporter.

Применяем:

kk -n monitoring apply -f redis-service-monitor.yaml

servicemonitor.monitoring.coreos.com/redis-servicemonitor created

И проверяем таргеты Prometheus: и Метрики Редиса:

Что надо дальше?

А дальше надо выпилить из Operator запуск Alertmanager и Grafana.

Prometheus Operator Helm deployment и конфигурация сервисов

Хотя – а зачем выпиливать Графану? Там уже есть пачка готовых дашборд – пусть остаётся.

Давайте сделаем иначе:

на каждый EKS кластер выкатываем Operator с Grafana, но без Alertmanager
на локальных кластеру Prometheus retention period для хранения метрик используем дефолтный – 2 недели, и локальные Grafana будут выводить графики за две недели
Alertmanager выпиливаем – будем использовать его с центрального сервера мониторинга – там уже настроены роуты, каналы, и прочее – надо будет только добавить алерты
центральный сервер мониторинга хранит метрики год, и там нарисуем свою дашборду(ы) Grafana

Значит надо будет создать два LoadBalancer – один с типом internet-facing для Grafana, и один для Prometheus – internal, т.к. к Prometheus в кластере будет ходить “центральный” Prometheus через AWS VPC Peering, и с /federation забирать у него метрики.

И всё это надо заинтегрировать с нашей автоматизацией – Ansible,

Но сначала сделаем вручную, конечно.

Итак, что нам надо изменить в дефолтном деплое Prometheus Operator?

убрать деплой Alertmanager
добавить настройки для:
- Prometheus и Grafana – должны деплоится за LoadBalancer
- логин-пароль для Grafana

Дальше смотрим доступные параметры в документации – https://github.com/helm/charts/tree/master/stable/prometheus-operator.

Пока начнём с того, что передеплоим стек без Алертменеджера, для этого надо передать alertmanager.enabled.

Проверяем под сейчас:

kk -n monitoring get pod
NAME                                                        READY   STATUS             RESTARTS   AGE
alertmanager-prometheus-prometheus-oper-alertmanager-0      2/2     Running            0          24h
...

kk -n monitoring get pod

NAME READY STATUS RESTARTS AGE

alertmanager-prometheus-prometheus-oper-alertmanager-0 2/2 Running 0 24h

...

Редеплоим, через --set задаём alertmanager.enabled=false:

helm upgrade --install --namespace monitoring --create-namespace prometheus stable/prometheus-operator --set "alertmanager.enabled=false"

Проверяем поды ещё раз – Алертменеджера нет, отлично.

Настройка LoadBalancer

Итак, мы хотим открыть доступ из мира к Grafana – значит нужен будет ресурс Ingress для неё, и отдельный Ingress для Prometheus.

Что есть в доке:

`grafana.ingress.enabled`	Enables Ingress for Grafana	`false`
`grafana.ingress.hosts`	Ingress accepted hostnames for Grafana	`[]`

Добавляем Ingress для Графаны:

helm upgrade --install --namespace monitoring --create-namespace prometheus stable/prometheus-operator --set "alertmanager.enabled=false" --set grafana.ingress.enabled=true
...
Error: UPGRADE FAILED: failed to create resource: Ingress.extensions "prometheus-grafana" is invalid: spec: Invalid value: []networking.IngressRule(nil): either `backend` or `rules` must be specified

helm upgrade --install --namespace monitoring --create-namespace prometheus stable/prometheus-operator --set "alertmanager.enabled=false" --set grafana.ingress.enabled=true

...

Error: UPGRADE FAILED: failed to create resource: Ingress.extensions "prometheus-grafana" is invalid: spec: Invalid value: []networking.IngressRule(nil): either `backend` or `rules` must be specified

Какую-то подсказку удалось нагуглить тут: https://zero-to-jupyterhub.readthedocs.io/en/latest/administrator/advanced.html#ingress

Пробуем – теперь уже через values.yaml, что бы не городить кучу --set, добавляем hosts:

grafana:
  ingress:
    enabled: true
    annotations:
      kubernetes.io/ingress.class: "alb"
      alb.ingress.kubernetes.io/scheme: "internet-facing"
    hosts:
      - "dev-0.eks.monitor.example.com"

grafana:

ingress:

enabled: true

annotations:

kubernetes.io/ingress.class: "alb"

alb.ingress.kubernetes.io/scheme: "internet-facing"

hosts:

- "dev-0.eks.monitor.example.com"

Деплоим:

helm upgrade --install --namespace monitoring --create-namespace prometheus stable/prometheus-operator -f oper.yaml

И смотрим логи ALB Controller:

I0617 11:37:48.272749 1 tags.go:43] monitoring/prometheus-grafana: modifying tags { ingress.k8s.aws/cluster: “bttrm-eks-dev-0”, ingress.k8s.aws/stack: “monitoring/prometheus-grafana”, kubernetes.io/service-name: “prometheus-grafa
na”, kubernetes.io/service-port: “80”, ingress.k8s.aws/resource: “monitoring/prometheus-grafana-prometheus-grafana:80”, kubernetes.io/cluster/bttrm-eks-dev-0: “owned”, kubernetes.io/namespace: “monitoring”, kubernetes.io/ingress-name
: “prometheus-grafana”} on arn:aws:elasticloadbalancing:us-east-2:534***385:targetgroup/96759da8-e0b8253ac04c7ceacd7/35de144cca011059
E0617 11:37:48.310083 1 controller.go:217] kubebuilder/controller “msg”=”Reconciler error” “error”=”failed to reconcile targetGroups due to failed to reconcile targetGroup targets due to prometheus-grafana service is not of type NodePort or LoadBalancer and target-type is instance” “controller”=”alb-ingress-controller” “request”={“Namespace”:”monitoring”,”Name”:”prometheus-grafana”}

Хорошо – давайте добавим /target-type: "ip", что бы AWS ALB слал трафик прямо на под с Grafana, а не на WorkerNodes, заодно добавим валидные коды ответов:

grafana:
  ingress:
    enabled: true
    annotations:
      kubernetes.io/ingress.class: "alb"  
      alb.ingress.kubernetes.io/scheme: "internet-facing"
      alb.ingress.kubernetes.io/target-type: "ip"
      alb.ingress.kubernetes.io/success-codes: 200,302
    hosts:
      - "dev-0.eks.monitor.example.com"

grafana:

ingress:

enabled: true

annotations:

kubernetes.io/ingress.class: "alb"

alb.ingress.kubernetes.io/scheme: "internet-facing"

alb.ingress.kubernetes.io/target-type: "ip"

alb.ingress.kubernetes.io/success-codes: 200,302

hosts:

- "dev-0.eks.monitor.example.com"

Либо, что бы использовать Instance type – можно переопределить тип Service для Grafana, и задать его в NodePort:

grafana:
  service:
    type: NodePort
    port: 80
    annotations: {}
    labels: {}  
  ingress:
    enabled: true
    annotations:
      kubernetes.io/ingress.class: "alb"
      alb.ingress.kubernetes.io/scheme: "internet-facing"
      alb.ingress.kubernetes.io/success-codes: 200,302
    hosts:
      - "dev-0.eks.monitor.example.com"

grafana:

service:

type: NodePort

port: 80

annotations: {}

labels: {}

ingress:

enabled: true

annotations:

kubernetes.io/ingress.class: "alb"

alb.ingress.kubernetes.io/scheme: "internet-facing"

alb.ingress.kubernetes.io/success-codes: 200,302

hosts:

- "dev-0.eks.monitor.example.com"

Передеплоиваем:

helm upgrade --install --namespace monitoring --create-namespace prometheus stable/prometheus-operator -f oper.yaml

Через минуту поднялся ALB:

kk -n monitoring get ingress
NAME                 HOSTS                              ADDRESS                                                                 PORTS   AGE
prometheus-grafana   dev-0.eks.monitor.example.com   96759da8-monitoring-promet-***.us-east-2.elb.amazonaws.com   80      30m

kk -n monitoring get ingress

NAME HOSTS ADDRESS PORTS AGE

prometheus-grafana dev-0.eks.monitor.example.com 96759da8-monitoring-promet-***.us-east-2.elb.amazonaws.com 80 30m

Но теперь при открытии страницы dev-0.eks.monitor.example.com – ALB отдаёт 404:

curl -vL dev-0.eks.monitor.example.com
*   Trying 3.***.***.247:80...
* Connected to dev-0.eks.monitor.example.com (3.***.***.247) port 80 (#0)
> GET / HTTP/1.1
> Host: dev-0.eks.monitor.example.com
> User-Agent: curl/7.70.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
...
< Location: /login
...
* Connection #0 to host dev-0.eks.monitor.example.com left intact
* Issue another request to this URL: 'http://dev-0.eks.monitor.example.com/login'
...
> GET /login HTTP/1.1
...
< HTTP/1.1 404 Not Found
< Server: awselb/2.0

curl -vL dev-0.eks.monitor.example.com

* Trying 3.***.***.247:80…

* Connected to dev-0.eks.monitor.example.com (3.***.***.247) port 80 (#0)

> GET / HTTP/1.1

> Host: dev-0.eks.monitor.example.com

> User-Agent: curl/7.70.0

> Accept: */*

* Mark bundle as not supporting multiuse

< HTTP/1.1 302 Found

...

< Location: /login

...

* Connection #0 to host dev-0.eks.monitor.example.com left intact

* Issue another request to this URL: 'http://dev-0.eks.monitor.example.com/login'

...

> GET /login HTTP/1.1

...

< HTTP/1.1 404 Not Found

< Server: awselb/2.0

Что тут происходит?

ALB принимает запрос к dev-0.eks.monitor.example.com, отправляет его на TargetGroup с Grafana
Grafana возвращает 302 /login
мы возвращаемся к ALB, но теперь в URI передаём /login

Проверяем правила Listener:

Ну, да – а в правилах балансера на все запросы кроме / мы возвращаем 404. Соответсвенно, и на /login тоже возвращается 404.

Очень хотелось бы увидеть комментарии разработчика, который дефолтным рулом path задал именно такое.

Возвращаемся к нашему values.yaml, добавляем path равным /*.

А hosts, что бы избежать ошибки “Invalid value: []networking.IngressRule(nil): either `backend` or `rules` must be specified” и не привязываться к конкретному домену можно задать просто в виде "":

grafana:
  ingress:
    enabled: true
    annotations:
      kubernetes.io/ingress.class: "alb"
      alb.ingress.kubernetes.io/target-type: "ip"
      alb.ingress.kubernetes.io/scheme: "internet-facing"
      alb.ingress.kubernetes.io/success-codes: 200,302
    hosts:
      - ""
    path: /*

grafana:

ingress:

enabled: true

annotations:

kubernetes.io/ingress.class: "alb"

alb.ingress.kubernetes.io/target-type: "ip"

alb.ingress.kubernetes.io/scheme: "internet-facing"

alb.ingress.kubernetes.io/success-codes: 200,302

hosts:

- ""

path: /*

Редеплоим, проверяем:

kk -n monitoring get ingress
NAME                 HOSTS   ADDRESS                                                                  PORTS   AGE
prometheus-grafana   *       96759da8-monitoring-promet-bb6c-2076436438.us-east-2.elb.amazonaws.com   80      15m

kk -n monitoring get ingress

NAME HOSTS ADDRESS PORTS AGE

prometheus-grafana * 96759da8-monitoring-promet-bb6c-2076436438.us-east-2.elb.amazonaws.com 80 15m

И открываем в браузере:

Prometheus и Lens

И даже в Lens появились все графики вместо ошибок “Metrics are not available due to missing or invalid Prometheus configuration” и “Metrics not available at the moment“:

В целом – на этом, думаю, всё основное рассмотрели.

Можно прикручивать автоматизацию, и выкатывать в тестирование.

Centos

Kubernetes: мониторинг кластера с Prometheus Operator

Prometheus Operator deployment

Grafana access

Prometheus Operator configuration

Добавление сервиса в мониторинг

Запуск Redis server

Запуск `redis_exporter`

Создание Kubernetes ServiceMonitor

Prometheus Operator Helm deployment и конфигурация сервисов

Настройка LoadBalancer

Prometheus и Lens

https://github.com/midnight47/

Апрель 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

Prometheus Operator deployment

Grafana access

Prometheus Operator configuration

Добавление сервиса в мониторинг

Запуск Redis server

Запуск redis_exporter

Создание Kubernetes ServiceMonitor

Prometheus Operator Helm deployment и конфигурация сервисов

Настройка LoadBalancer

Prometheus и Lens

https://github.com/midnight47/

Запуск `redis_exporter`