Nginx ingress
Last updated
Was this helpful?
Last updated
Was this helpful?
Команда перевела пошаговую инструкцию о том, как установить и сконфигурировать ingress-nginx, Prometheus и Grafana, а также настроить оповещения для ключевых метрик Ingress. Для работы понадобится кластер Kubernetes и Helm v3.
Первым делом установим Prometheus для сбора метрик и Grafana для визуализации и создания оповещений на их основе.
Давайте убедимся, что установленные компоненты работают:
Переходим к следующему этапу.
На этом этапе устанавливаем и настраиваем контроллер Nginx ingress и включаем метрику, которую собирает Prometheus.
С помощью следующей команды устанавливаем ingress Nginx в кластер:
Чтобы Prometheus мог обнаружить монитор служб и автоматически подтягивать из него метрики, в качестве release: kube-prometheus-stack указываем serviceMonitor.additionalLabels.
Теперь создаем ingress для выполненного деплоймента podinfo:
Давайте немного углубимся в эту конфигурацию ingress:
В качестве ingress-контроллера мы используем ingress-nginx, поэтому класс ingress определяется как nginx.
В этой конфигурации я использовал podinfo.localdev.me как адрес хоста для Ingress.
DNS *.localdev.me трансформируется в 127.0.0.1, так что этот DNS можно использовать для любого локального тестирования, не добавляя запись в файл /etc/hosts.
Приложение Podinfo обслуживает HTTP API через порт 9898, и поэтому мы указываем его для backend-порта. То есть трафик, поступающий в домен http://podinfo.localdev.me, направляется на порт 9898 службы podinfo.
Далее с терминала трафик необходимо перенаправить на порт службы ingress-nginx, чтобы можно было направлять трафик с локального терминала.
Порт хоста 80 — привилегированный порт, так что его мы не трогаем. Вместо этого мы привяжем порт 80 службы nginx к порту 8080 хост-машины. Можно указать любой допустимый порт на ваш выбор.
Если вы запускаете службу в облаке, в перенаправлении портов нет необходимости, так как LoadBalancer службы ingress-nginx создается автоматически — служба определяется как LoadBalancer по умолчанию.
Теперь выполняем следующий запрос curl к конечной точке podinfo и получаем ответ:
Можно изменить код состояния с 400 на 500 и выполнять команду и для тестового трафика 5xx.
Для проверки задержки я использовал команду GET /delay/{seconds} waits за указанный период:
В последних версиях Grafana поддерживается собственный механизм отправки оповещений. Таким образом, можно собрать в одном месте все оповещения о конфигурации и правилах и даже аварийные оповещения. Давайте настроим оповещения для распространенных SLI.
Для получения частоты ошибок 4xx в процентах можно использовать следующую формулу: (общее количество запросов 4xx / общее количество запросов) * 100.
Добавьте в запрос следующее выражение:
В выражении B используйте операцию редукции с функцией Mean для вводных A.
В Alert Details назовите оповещение так, как вам нравится. Я свое назвал Ingress_Nginx_4xx.
Summary можно сделать максимально коротким: просто показать имя Ingress с меткой {{ $labels.ingress }}.
В Description я использовал printf "%0.2f", чтобы проценты отображались с точностью до двух знаков после запятой.
В целом оповещение должно быть похоже на снапшот ниже:
В конце можно добавить пользовательскую метку, например severity : critical.
Как и в случае с настройкой оповещений 4xx, для частоты ошибок 5xx можно использовать следующий запрос:
В соответствии с настройками оповещение отправляется, когда процент 5xx/4xx превышает 5 %. Настраиваем таким образом, чтобы это соответствовало нашим требованиям, а именно Error budget — времени, в течение которого система может испытывать проблемы без нарушений SLA.
Чтобы рассчитать 95-й процентиль продолжительности запросов за последние 15 минут, можно использовать метрику nginx_ingress_controller_request_duration_seconds_bucket. Так вы получите The request processing time in milliseconds. Поскольку это бакет, мы можем использовать функцию histogram_quantile. Создайте оповещение, похожее на пример выше, и используйте следующий запрос:
Я установил пороговое значение на уровне 1,5 секунды, но его можно изменить в соответствии с вашим SLO.
Чтобы получить частоту запросов в секунду (RPS), можно использовать следующий запрос:
В таком случае оповещение отправляется, когда частота запросов превышает 2000 RPS.
Скорость подключения. Измеряет количество активных подключений к Nginx ingress и может использоваться для выявления потенциальных проблем с подключениями.
Upstream response time. Время на ответ исходной службы на запрос; помогает выявлять проблемы не только с ingress, но и со службой.
Редактируем точку контакта slack, прокручиваем вниз и выбираем параметр Optional Slack settings.
В Title ниже укажем, какой шаблон использовать:
В Text Body введем приведенный ниже код и сохраним его:
Вот, наконец, и сообщение с оповещением!
Все шаги выполнены, мы получили результат: вот так выглядит оповещение в Slack.
Частота ошибок 4xx:
Частота ошибок 5xx:
Задержка p95:
В зависимости от актуальных требований можно исправить множество вещей. Например, если у вас несколько кластеров Kubernetes, можно добавить метку кластера, которая поможет идентифицировать в оповещении исходный кластер.
Aviator автоматизирует тяжелые рабочие процессы для разработчиков, управляя запросами Pull (Pr) в Git; благодаря тестированию в ходе непрерывной интеграции (CI) это помогает избежать сломанных сборок, оптимизировать утомительные процессы объединения, управлять cross-PR-зависимостями и справляться с нестабильными тестами, соблюдая при этом требования безопасности.
Aviator состоит из четырех основных компонентов:
MergeQueue — автоматизированная очередь, которая управляет рабочим процессом Merging для репозитория GitHub, защищая важные ветви от неисправных сборок. Бот Aviator использует GitHub Labels для идентификации готовых к объединению запросов Pull (PR), подтверждает проверки CI, обрабатывает семантические конфликты и автоматически объединяет PR.
ChangeSets — рабочие процессы, призванные синхронизировать валидацию и объединение нескольких PR в одном репозитории или в нескольких. Может пригодиться, если у вашей команды часто появляются группы связанных между собой PR, которые нужно объединить или иным образом обработать как единый, более крупный блок изменений.
FlakyBot — инструмент, который умеет автоматически определять и обрабатывать результаты нестабильных тестов в инфраструктуре CI.
Stacked PRs CLI — инструмент командной строки для работы с cross-PR-зависимостями. Этот инструмент также автоматизирует синхронизацию и объединение PR в стеке. Помогает развивать культуру небольших инкрементальных PR вместо больших изменений и подходит для ситуаций, когда ваши рабочие процессы завязаны на синхронизацию нескольких зависимых PR.
Вы можете опробовать мониторинг
Установим Helm chart , скопировав следующие команды в свой терминал. Так мы установим Grafana, Prometheus и другие компоненты для мониторинга.
Установив чарт, давайте для примера выполним деплоймент приложения в пространстве имен по умолчанию.
URL в браузере будет выглядеть симпатичнее:
Чтобы запустить Grafana, нужно открыть в браузере URL с учетными данными admin:admin : .
Чтобы импортировать дашборд, скопируйте thenginx.json и вставьте в . Вот так должен выглядеть импортированный дашборд:
Чтобы направить трафик в приложение podinfo, воспользуемся инструментом нагрузочного тестирования vegeta. Его можно взять . Для примера давайте создадим трафик HTTP 4xx. Для этого выполните следующую команду, которая запускается с частотой запросов 10 RPS на 10 минут:
Примечание: можно дополнительно почитать о конечных точках в приложении podinfo.
Чтобы создать оповещение, давайте перейдем в .
Чтобы сообщения с оповещениями были удобочитаемыми, можно использовать
Чтобы их настроить, перейдем в и создадим новый шаблон. Назовем его slack и скопируем следующий блок кода:
Настраиваем новую точку контакта типа Slack. Для этого нужно создать входящий вебхук из Slack. Все подробно расписано в .
Перейдем в и укажем Slack в параметре Default contact point.
