В чем разница между Ingress и обратным прокси?

Question

В настоящее время я изучаю Kubernetes и наткнулся на термин Ingress object. Мне было интересно, есть ли список различий между ними, поскольку они кажутся мне синонимами. Мне кажется, что NGINX является более функциональным входом, поскольку он позволяет, например, сжатие видео и изображений, предварительную выборку и кэширование.

С другой стороны, кажется, что Ingresses перекрываются с NGINX 'обратными прокси-серверами, обеспечивая балансировку нагрузки, маршрутизацию traffi c, завершение TLS / SSL. Единственное, что я вижу по сравнению с NGINX / Envoy RP, это то, что это «объект API kubernetes».

Означает ли это, что он состоит из 2 частей - интерфейс между API а какой-то реальный обратный прокси? Имеется в виду, является ли «входной» просто термином kubernetes для оболочки NGINX RP, обеспечивающей работу API Kubernetes, ИЛИ ИЛИ это совершенно отдельный тип сервера?

Не могли бы вы перечислить некоторые различия между ними?

Answer 1

Вы правы в своем понимании. В Inress есть две части: контроллер, который реализует интерфейс API входа kubernetes для автоматического и быстрого способа настройки обратного прокси-сервера, такого как nginx или посланник.

Другая часть сам обратный прокси-сервер, такой как nginx, посланник.

Так что при развертывании входной настройки в kubernetes он развернет входной контроллер и обратный прокси-сервер в кластере kubernetes.

Answer 2

Существует несколько поставщиков, реализующих IngressController. Даже у nginx есть такой.

Вы правы в отношении ресурса Ingress в Kubernetes, который действует как обратный прокси-сервер, который мы использовали для развертывания вручную. Сервис IngressController - это реальный обратный прокси, который получает трафик c. Созданный вами ресурс kubernetes Ingress похож на файл конфигурации nginx.conf, который вы создали бы. Вы можете создать и запустить свой собственный Ingress, запустив развертывание nginx, обернув его службой LoadBalancer и выразив свои правила traffi c, вручную создав файл nginx.conf. Использование ресурса Ingress вместо этого - просто родной и более простой способ сделать это в Kubernetes.