Модуль ingress-nginx

Устанавливает и управляет Ingress NGINX Controller с помощью кастомных ресурсов. Если узлов для размещения Ingress-контроллера больше одного, он устанавливается в отказоустойчивом режиме и учитывает все особенности реализации инфраструктуры облаков и bare metal, а также кластеров Kubernetes различных типов.

Поддерживает запуск и раздельное конфигурирование одновременно нескольких Ingress-контроллеров — один основной и неограниченное количество дополнительных. Например, это позволяет отделять внешние и intranet Ingress-ресурсы приложений.

Текущая используемая версия nginx - 1.30.2.

Маршрутизация трафика

Трафик к ingress-nginx может быть отправлен несколькими способами:

• напрямую без внешнего балансировщика;
• через внешний LoadBalancer, в том числе поддерживаются:
  • Qrator;
  • Cloudflare;
  • AWS LB;
  • GCE LB;
  • ACS LB;
  • Yandex LB;
  • OpenStack LB.

Поддерживаемые протоколы

Модуль позволяет использовать следующие протоколы для приема и дальнейшей маршрутизации трафика:

• HTTP/HTTPS: основной протокол маршрутизация трафика, допускается выбор используемых версий между HTTP/1.1, HTTP/2 и HTTP/3;
• WebSocket: поддерживается nginx нативно, без дополнительной настройки со стороны пользователя;
• gRPC: поддерживается, для использования необходимо указать соответствующую аннотацию;
• FCGI: поддерживается, для использования необходимо указать соответствующую аннотацию;
• Proxy Protocol: поддерживается организация приема Proxy Protocol-трафика засчет использования соответствующих инлетов;
• SSL Passthrough: поддерживается сквозная маршрутизация SSL-трафика засчет использования соответствующих инлетов.

На данный момент в нашей реализации ingress-nginx не поддерживается маршрутизация TCP/UDP трафика (функционал tcp-services/udp-services). Для маршрутизации TCP/UDP трафика предлагается применять нативное решение Kubernetes NodePort Service или рассмотреть использование модуля alb для организации маршрутизации трафика на основе Gateway API (доступен к использованию начиная с версии DKP 1.76).

Использование HTTPS

Модуль позволяет управлять политиками безопасности HTTPS каждого Ingress NGINX Controller, в том числе:

• параметрами HSTS;
• набором доступных версий SSL/TLS и протоколов шифрования.

По умолчанию во всех версиях контроллера используется TLSv1.2 и TLSv1.3 с возможностью ручной настройки устаревших версий. В случае использования TLSv1.2 применяются следующие протоколы шифрования:

• обмен ключами: ECDHE, DHE;
• аутентификация: ECDSA, RSA;
• шифрование (AEAD): AES-GCM (128/256), ChaCha20-Poly1305;
• целостность данных (MAC): SHA256, SHA384.

При использовании TLSv1.3 набор протоколов шифрования определяется библиотекой OpenSSL (версии 3.3.3+).

Также модуль ingress-nginx интегрирован с модулем cert-manager, при взаимодействии с которым возможны автоматический заказ SSL-сертификатов и дальнейшее использование сертификатов Ingress NGINX Controller.

Мониторинг и статистика

В нашей реализации ingress-nginx добавлена система сбора статистики в Prometheus с множеством метрик:

• по длительности времени всего ответа и апстрима отдельно;
• кодам ответа;
• количеству повторов запросов (retry);
• размерам запроса и ответа;
• методам запросов;
• типам content-type;
• географии распределения запросов и т. д.

Данные доступны в нескольких параметрах:

• по namespace;
• vhost;
• ingress-ресурсу;
• location (в nginx).

Все графики собраны в виде удобных дашбордов в Grafana, при этом есть возможность drill-down’а по графикам. Например, при просмотре статистики пространств имён, можно нажать ссылку на дашборд в Grafana, углубиться в статистику по vhosts в соответствующем namespace и т.д.

Статистика

Основные принципы сбора статистики

1. На каждый запрос на стадии log_by_lua_block вызывается модуль, который рассчитывает необходимые данные и складывает их в буфер (у каждого nginx worker собственный буфер).
2. На стадии init_by_lua_block для каждого nginx worker запускается процесс, который раз в секунду асинхронно отправляет данные в формате protobuf через TCP socket в protobuf_exporter (разработка DKP).
3. protobuf_exporter запущен sidecar-контейнером в поде с ingress-controller, принимает сообщения в формате protobuf, разбирает, агрегирует их по установленным правилам и экспортирует в формате для Prometheus.
4. Prometheus каждые 30 секунд собирает метрики как в 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 суммы размеров ответов бэкенда.

Внешние компоненты

Список стороннего программного обеспечения, используемого в модуле ingress-nginx (информация представлена на английском языке):

• Ingress NGINX Controller

  License: Apache License 2.0

  A ingress controller for Kubernetes using NGINX as a reverse proxy and load balancer.

• OpenKruise

  License: Apache License 2.0

  OpenKruise is an extended component suite for Kubernetes, which mainly focuses on application automations, such as deployment, upgrade, ops and availability protection.