Документация находится в разработке, может содержать неполную информацию.

Для обеспечения внешнего доступа к виртуальным машинам, например, для публикации сервисов или удалённого администрирования, можно воспользоваться ресурсами Ingress, которые управляются модулем ingress-nginx. Созданные ресурсы Ingress используют Nginx как обратный прокси-сервер и балансировщик нагрузки. Если в кластере предусмотрено несколько узлов для размещения Ingress-контроллера, он будет развернут в отказоустойчивом режиме, что повышает надежность доступа и устойчивость к сбоям.

Также поддерживается запуск нескольких экземпляров Nginx Ingress-контроллеров с раздельной конфигурацией — один основной и любое количество дополнительных. Такой подход позволяет, например, разделять обработку Ingress-ресурсов для внешних и внутренних (intranet) приложений, обеспечивая их изоляцию и более гибкое управление доступом.

Создание контроллера

Чтобы создать Nginx Ingress-контроллер, примените следующий ресурс IngressNginxController:

d8 k apply -f - <<EOF
apiVersion: deckhouse.io/v1
kind: IngressNginxController
metadata:
  name: main
spec:
  ingressClass: nginx
  inlet: HostWithFailover
  nodeSelector:
    node-role.deckhouse.io/frontend: ""
  tolerations:
    - effect: NoExecute
      key: dedicated.deckhouse.io
      value: frontend
EOF

Подробности о возможностях конфигурации ресурса IngressNginxController описаны в документации.

Терминация HTTPS

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

  • управление параметрами HSTS (HTTP Strict Transport Security);
  • настройку поддерживаемых версий протоколов SSL/TLS и протоколов шифрования.

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

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

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

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

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

  • по пространству имен;
  • по vhost;
  • по Ingress-ресурсу;
  • по location (в Nginx).

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

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

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