Разница между обратным прокси и ingress контроллером
Эта статья навеяна комментарием к предыдущей.
Обратный прокси
В предыдущей статье мы уже разбирали как работает обратный прокси, но повторение будет не лишним.
Обратный прокси можно в какой-то мере ассоциировать с старой телефонной станцией. Когда кто-то хочет воспользоваться телефоном, он сначала соединяется с коммутационным узлом, и общается с живым оператором, называя тому имя и адрес человека, которому нужно позвонить. После чего оператор соединяет звонящего с абонентом (при условии доступности второго).
Обратный прокси делает похожую работу, получая пользовательские запросы, и затем пересылая эти запросы на соответствующие сервера (как показано на картинке ниже).
У обратного прокси очень простая функция - он ставится перед приложением (или группой приложений), и служит посредником между пользователем и сервисом.
Как упомянуто выше, обратный прокси маршрутизирует пользовательские запросы на соответствующий сервер (при условии, конечно, что вы используете несколько серверов). На этом месте те, кто использует один сервер с одним экземпляром приложения, вполне справедливо зададутся вопросом, имеет ли вообще смысл внедрять обратный прокси-сервер. Ответ: да, смысл есть.
Обратный прокси будет полезен и в инсталляциях с одним сервером, за счёт предоставления таких своих преимуществ как: ограничение скорости, IP-фильтрация и контроль доступа, аутентификация, проверка запросов и кэширование.
Ingress контроллер
Если в двух словах, то в мире Kubernetes ingress контроллер является обратным прокси (кстати именно поэтому тот же Istio в прошлой статье был упомянут в контексте перечисления вариантов обратных прокси).
Он действует по принципу обратного прокси, маршрутизируя трафик из внешней сети к целевому сервису в пределах кластера Kubernetes, и позволяя вам настроить балансировщик нагрузки HTTP и HTTPS для кластера.
Чтобы лучше понять принцип работы, давайте сделаем шаг назад и попробуем разобраться, что такое Ingress.
Kubernetes Ingress - это объект API, задача которого определять как приходящий трафик из интернета будет направляться на внутренние сервисы кластера, которые затем в свою очередь будут отправлять запросы Pod'ам. Сам по себе Ingress не имеет влияния на систему, представляя собой просто набор правил для Ingress контроллера. Для проведения аналогии можно сравнить Ingress с автомобилем, у которого снят двигатель, а Ingress контроллер с самим двигателем, то есть при наличие Ingress ресурса, без установленного контроллера, работать ничего не будет.
Ingress контроллер принимает трафик снаружи Kubernetes платформы, и распределяет его по Pod'ам внутри платформы, таким образом накладывая еще один уровень абстракции на маршрутизацию трафика. Контроллеры Ingress преобразуют конфигурации из ресурсов Ingress в правила маршрутизации, распознаваемые и реализуемые обратными прокси-серверами.
Обычно Ingress контроллеры используются для предоставления доступа к множеству сервисов через единую точку входа (DNS-имя или IP-адрес).
В частности, входные контроллеры используются для:
предоставления нескольких служб под одним DNS-именем
реализации маршрутизации на основе пути, при которой разные URL-адреса сопоставляются с разными службами
реализации маршрутизации на основе хоста, при которой разные имена хостов сопоставляются с разными службами
реализации базовой аутентификации, или других методы контроля доступа для ваших приложений.
включения ограничения скорости для ваших приложения
Заключение
Если ingress контроллер делает практически ту же самую работу, что и обратный прокси (обрабатывает входящий трафик и перенаправляет на соответствующий сервер/сервис), то чем они отличаются?
Ingress контроллер - это частный случай прокси-сервера, предназначенный для работы в кластерах Kubernetes. Он находится не на границе инфраструктуры, а на границе кластера.