Велкам!)

Кароч на сертификат прометеус может в двух местах ругаться - во время процесса дискавери, и в момент похода на задискаверенные эндпоинты за метриками.

Кароч на сертификат прометеус может в двух местах ругаться - во время процесса дискавери, и в момент похода на задискаверенные эндпоинты за метриками.

Куда копать или с чем это связанно?

tls_config есть и в секции kubernetes_sd_configs, там попробуй указать свой ca_file. Судя по тому, что он не может ничего листить - проблема ещё и с RBAC, добавь туда же bearer_token аккаунта с правами на листинг нужных ресурсов.

А, я думал, вопрос про поход снаружи.

Я его переношу из кластера, наружу. Сейчас вот думаю как сделать. scrape_configs: - job_name: 'kubernetes-apiservers' kubernetes_sd_configs: - role: endpoints api_server: https://10.10.54.88:6443 scheme: https tls_config: ca_file: /etc/prometheus/ca.crt bearer_token_file: /etc/prometheus/token relabel_configs: - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name] action: keep regex: default;kubernetes;https Так не работает. x509: certificate signed by unknown authority выдает

Я его переношу из кластера, наружу. Сейчас вот думаю как сделать. scrape_configs: - job_name: 'kubernetes-apiservers' kubernetes_sd_configs: - role: endpoints api_server: https://10.10.54.88:6443 scheme: https tls_config: ca_file: /etc/prometheus/ca.crt bearer_token_file: /etc/prometheus/token relabel_configs: - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name] action: keep regex: default;kubernetes;https Так не работает. x509: certificate signed by unknown authority выдает

scrape_configs: - job_name: 'kubernetes-apiservers' kubernetes_sd_configs: - role: endpoints api_server: https://10.10.54.88:6443 tls_config: ca_file: /etc/prometheus/ca.crt bearer_token_file: /etc/prometheus/token scheme: https tls_config: ca_file: /etc/prometheus/ca.crt

scrape_configs: - job_name: 'kubernetes-apiservers' kubernetes_sd_configs: - role: endpoints api_server: https://10.10.54.88:6443 tls_config: ca_file: /etc/prometheus/ca.crt bearer_token_file: /etc/prometheus/token scheme: https tls_config: ca_file: /etc/prometheus/ca.crt

у тебя даже таргеты не находятся из кубе-апи?

Да, я пробовал так, и после этого ошибка ушла. Но прометей так и не пошел собирать в кластер метрики. Все пусто в логах его

В смысле, в веб-интерфейсе.

В интерфейсе нет метрик. Все дефолтные. Как будто он ничего не делает.

Там есть отдельный пункт "Service Discovery", в меню в выпадающем списке.

Не совсем понял замечание. Вот всю базу по настройке брал от сюда. https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml

с прометеем вообще работал?

Ага, если ендпоинты задискаверились, то секция kubernetes_sd_configs правильная) Дальше надо смотреть, почему метрики не приезжают.

Доброго вечера, коллеги. Есть инсталляция k8s, 8 нод под workload, nginx ingress, сервис за ним. Перед k8s внешний балансер. Идем в сервис за данными - тот отдает их за 2мс вне зависимости от количества реквестов (по сути, если идешь с однотипным запросом, он один раз берет данные из базы, а остальное время отдает из кэша). Идем в k8s - держит 550 rps, дальше начинает терять пакеты, чем дальше, тем больше. На балансере нагрузка около 40% по CPU при этом (разворачиваем https), на сервисе нагрузка минимальна, на ингрессе, судя по всему, теряем запросы, но нагрузка на нем тоже невысокая. Стандартная инсталляция прометеуса несильно помогает понять, в чем дело. Есть предположения, куда и как копать, если есть желание получить на сервисе, скажем, 10k rps?

а ингресс нодпортом торчит к балансеру?

Да, каждой нодой просто

В твоём конфиге есть - role: endpoints, значит, он будет собирать только эндпоинты.

Норм идея, пасиб

Доброго вечера, коллеги. Есть инсталляция k8s, 8 нод под workload, nginx ingress, сервис за ним. Перед k8s внешний балансер. Идем в сервис за данными - тот отдает их за 2мс вне зависимости от количества реквестов (по сути, если идешь с однотипным запросом, он один раз берет данные из базы, а остальное время отдает из кэша). Идем в k8s - держит 550 rps, дальше начинает терять пакеты, чем дальше, тем больше. На балансере нагрузка около 40% по CPU при этом (разворачиваем https), на сервисе нагрузка минимальна, на ингрессе, судя по всему, теряем запросы, но нагрузка на нем тоже невысокая. Стандартная инсталляция прометеуса несильно помогает понять, в чем дело. Есть предположения, куда и как копать, если есть желание получить на сервисе, скажем, 10k rps?

Доброго вечера, коллеги. Есть инсталляция k8s, 8 нод под workload, nginx ingress, сервис за ним. Перед k8s внешний балансер. Идем в сервис за данными - тот отдает их за 2мс вне зависимости от количества реквестов (по сути, если идешь с однотипным запросом, он один раз берет данные из базы, а остальное время отдает из кэша). Идем в k8s - держит 550 rps, дальше начинает терять пакеты, чем дальше, тем больше. На балансере нагрузка около 40% по CPU при этом (разворачиваем https), на сервисе нагрузка минимальна, на ингрессе, судя по всему, теряем запросы, но нагрузка на нем тоже невысокая. Стандартная инсталляция прометеуса несильно помогает понять, в чем дело. Есть предположения, куда и как копать, если есть желание получить на сервисе, скажем, 10k rps?

а стрим уже начался

Может сегодня повезет, ребзя подскажите, как при rolling update в deployments сделать так чтобы перед обновлением пода он дождался когда все службы внутри пода заерщаться?

поставь таймаут большой для выключения поды что-то типа 3600. он его выведет из лоад балансинга но будет ждать пока он сам выйдет.

Может сегодня повезет, ребзя подскажите, как при rolling update в deployments сделать так чтобы перед обновлением пода он дождался когда все службы внутри пода заерщаться?

А как можно продебажить это? Я правильно понимаю что прометей ломится в kube-api, потом чекает все сервисы, эндпойнты, и поды. Когда находит экспортеры, то забирает с них метрики?

Пром из API получает внутренние IP и аннотации куда стучаться за метриками (если нестандартные порты и URL), а потом пытается в них сходить. Отсюда метод проверки - с хоста прома ты можешь получить метрики с подов (в первую очередь маршрутизация внутренних ip)

Сделай копию текущих и дай полные

Вы сначала разберитесь где пакеты теряются - в ингрессе или в оверлей сети

Я бы послушал, как фланель теряет пакеты, да

вы потом расскажите чем мир дышит

Интересный доклад по istio, показали тулзу birdwatch для автоматизации canary deployments