Устанавливает и управляет NGINX Ingress Controller при помощи Custom Resources. Если узлов для размещения Ingress-контроллера больше одной, то он устанавливается в отказоустойчивом режиме и учитывает все особенности реализации инфраструктуры облаков и bare metal, а также кластеров Kubernetes различных типов.
Поддерживает запуск и раздельное конфигурирование одновременно нескольких NGINX Ingress контроллеров — один основной и сколько угодно дополнительных. Например, это позволяет отделять внешние и intranet Ingress-ресурсы приложений.
Варианты терминирования трафика
Трафик к nginx-ingress может быть отправлен несколькими способами:
- напрямую без внешнего балансировщика
- через внешний LoadBalancer, в том числе поддерживаются:
- Qrator
- Cloudflare
- AWS LB
- GCE LB
- ACS LB
- Yandex LB
- OpenStack LB
Терминация HTTPS
Модуль позволяет управлять для каждого из NGINX Ingress контроллера политиками безопасности HTTPS, в частности:
- параметрами hsts;
- набором доступных версий SSL/TLS и протоколов шифрования.
Также модуль интегрирован с модулем cert-manager, при взаимодействии с которым возможен автоматический заказ SSL-сертификатов и их дальнейшее использование NGINX Ingress контроллерами.
Мониторинг и статистика
В нашей реализации Ingress Nginx добавлена система сбора статистики в Prometheus с множеством метрик по:
- длительности времени всего ответа и апстрима отдельно;
- кодам ответа;
- количеству повторов запросов (retry);
- размерам запроса и ответа;
- методам запросов;
- типам
content-type
; - географии распределения запросов и т.д.
Данные доступны в нескольких разрезах по:
namespace
,vhost
,ingress
-ресурсу,location
(в nginx).
Все графики собраны в виде удобных досок в Grafana, при этом есть возможность drill-down по графикам: при просмотре, например, статистики в разрезе namespace – есть возможность нажав на ссылку на dashboard в Grafana углубиться в статистику по vhosts
в этом namespace
и т.д.
Статистика
Основные принципы сбора статистики
- На каждый запрос, на стадии
log_by_lua_block
, вызывается наш модуль, который рассчитывает необходимые данные и складывает их в буфер (у каждого nginx worker’а свой буфер). - На стадии
init_by_lua_block
для каждого nginx worker’а запускается процесс, который раз в секунду асинхронно отправляет данные в форматеprotobuf
через tcp socket вprotobuf_exporter
(наша собственная разработка). protobuf_exporter
запущен sidecar-контейнером в Pod’е с ingress-controller’ом, принимает сообщения в формате protobuf, разбирает, агрегирует их по установленным нами правилам и экспортирует в формате для Prometheus.- Prometheus каждые 30 секунд scrape’ает как сам ingress-controller (там есть небольшое количество нужных нам метрик), так и protobuf_exporter, и на основании этих данных все и работает!
Какая статистика собирается и как она представлена
У всех собираемых метрик есть служебные лейблы, позволяющие идентифицировать экземпляр контроллера: controller
, app
, instance
и endpoint
(они видны в /prometheus/targets
).
- Все метрики (кроме geo), экспортируемые protobuf_exporter’ом, представлены в трех уровнях детализации:
ingress_nginx_overall_*
— “вид с вертолета”, у всех метрик есть лейблыnamespace
,vhost
иcontent_kind
.ingress_nginx_detail_*
— кроме лейблов уровня overall добавляются:ingress
,service
,service_port
иlocation
.ingress_nginx_detail_backend_*
— ограниченная часть данных, собирается в разрезе по бекендам. У этих метрик, кроме лейблов уровня detail, добавляется лейблpod_ip
.
- Для уровней overall и detail собираются следующие метрики:
*_requests_total
— counter количества запросов (дополнительные лейблы:scheme
,method
).*_responses_total
— counter количества ответов (дополнительные лейблы:status
).*_request_seconds_{sum,count,bucket}
— histogram времени ответа.*_bytes_received_{sum,count,bucket}
— histogram размера запроса.*_bytes_sent_{sum,count,bucket}
— histogram размера ответа.*_upstream_response_seconds_{sum,count,bucket}
— histogram времени ответа upstream’а (используется сумма времен ответов всех upstream’ов, если их было несколько).*_lowres_upstream_response_seconds_{sum,count,bucket}
— то же самое, что предыдущая метрика, только с меньшей детализацией (подходит для визуализации, но не подходит для расчета quantile).*_upstream_retries_{count,sum}
— количество запросов, при обработке которых были retry бекендов, и сумма retry’ев.
- Для уровня overall собираются следующие метрики:
*_geohash_total
— counter количества запросов с определенным geohash (дополнительные лейблы:geohash
,place
).
- Для уровня detail_backend собираются следующие метрики:
*_lowres_upstream_response_seconds
— то же самое, что аналогичная метрика для overall и detail.*_responses_total
— counter количества ответов (дополнительный лейблstatus_class
, а не простоstatus
).*_upstream_bytes_received_sum
— counter суммы размеров ответов backend’а.