В Kubernetes много движущихся частей. Этого следует ожидать от любой модели, предназначенной для распределенных вычислений. Чтобы понять, в чем помогает Kubernetes Ingress, давайте сначала кратко рассмотрим несколько важных деталей типичного кластера Kubernetes:

Приложение, развернутое в кластере Kubernetes, работает как модули сбора.
Поды по сути являются контейнерами, которые распределяются между несколькими узлами.
Узлы могут быть физическими серверами или виртуальными машинами, предлагаемыми вашим хостинг-провайдером. Очевидно, вы также можете использовать Kubernetes на локальном сервере, если хотите.
Каждый модуль имеет уникальный IP-адрес.
Ваше приложение разделено на множество подкомпонентов, часто называемых микросервисами.
Для каждого микросервиса вашего приложения есть соответствующий Сервис в Kubernetes.
В контексте Kubernetes Услуга предоставляет коллекцию модулей остальной части кластера как единую абстракцию. Единый виртуальный IP.
Это помогает одной службе вашего приложения взаимодействовать с другой службой. Это абстракция, которая позволяет вам обращаться к набору модулей вместо того, чтобы указывать IP-адрес модуля каждый раз, когда вы хотите с ним поговорить.
Сервис Kubernetes также действует как балансировщик нагрузки для всех подов, которые он представляет. Трафик равномерно распределяется по всем узлам.

Все идет нормально. Каждая служба может взаимодействовать с другой службой. Такое общение возможно во всем кластере Kubernetes

Выставочные услуги

«Если дерево падает в лесу и его никто не слышит, издает ли оно звук??”

Аналогичным образом, если ваше приложение не служит цели за пределами кластера Kubernetes, действительно ли имеет значение, хорошо ли построен ваш кластер?? Возможно нет.

Чтобы дать вам конкретный пример, допустим, у нас есть классическое веб-приложение, состоящее из внешнего интерфейса, написанного на Nodejs, и внутреннего интерфейса, написанного на Python, который использует базу данных MySQL. Вы развертываете две соответствующие службы в своем кластере Kubernetes.

Вы создаете Dockerfile, определяющий, как упаковать программное обеспечение внешнего интерфейса в контейнер, и аналогичным образом вы упаковываете свой серверный интерфейс. Затем в кластере Kubernetes вы развернете две службы, каждая из которых запускает набор подов. Веб-сервис может взаимодействовать с кластером базы данных и наоборот.

Однако Kubernetes не предоставляет остальному миру ни одну из этих служб (которые являются важной конечной точкой HTTP). Как указано в официальных документах:

«Предполагается, что службы имеют виртуальные IP-адреса, маршрутизируемые только в сети кластера”

Это вполне разумно с точки зрения безопасности, ваши службы могут взаимодействовать друг с другом, но кластер не позволяет внешним объектам напрямую общаться со службами. Например, только ваш веб-интерфейс может взаимодействовать со службой базы данных, и никто другой не может даже отправлять запросы к службе базы данных.

Проблема возникает, когда мы смотрим на вариант использования интерфейсной службы. Он должен быть открыт для остальной части общественности, чтобы конечные пользователи могли использовать ваше приложение. Мы предоставляем такие Сервисы с помощью Kubernetes Ingress.

Kubernetes Ingress

Ingress предоставляет маршруты HTTP и HTTPS извне кластера службам в кластере. Вы можете управлять правилами маршрутизации, определив ресурс Kubernetes Ingress. Но это намного больше, чем это. Раскрытие одной службы может быть достигнуто с помощью различных других альтернатив, таких как NodePort или балансировщики нагрузки, но эти средства не имеют функций, достаточно сложных для современного веб-приложения.

Такие функции, как отображение нескольких приложений на одном IP-адресе, определение маршрутов и т. Д.

Итак, давайте разберемся с этими функциями до конца статьи:

Единый входящий сервис

Это простейшая версия предоставления одной службы, такой как веб-интерфейс, с IP (или доменным именем) и портами HTTP и HTTPS по умолчанию (i.д, 80 и 443).

Один разветвитель

Это настройка входа, которая позволяет разрешить входящий трафик на один IP-адрес и направить его на несколько служб.

Это состоит из:

Входящий ресурс состоит из имени хоста foo.бар.ком
Список путей, по которым будет маршрутизироваться трафик, например foo.бар.com / admin foo.бар.com / home foo.бар.com / sso

Один разветвитель - это случай, когда один IP-адрес используется для нескольких сервисов. Службы могут находиться по разным путям в URI, например foo.бар.com / admin может быть службой для администраторов, а foo.бар.com / home может быть службой, которая генерирует домашнюю страницу каждого пользователя.

Входной порт всегда будет 80 или 443, но порт, на котором работают службы (внутри кластера), может немного отличаться.

Такой тип входящего трафика помогает нам минимизировать количество балансировщиков нагрузки в кластере, поскольку он, по сути, действует как один.

Виртуальный хостинг на основе имени

Публичные IP-адреса ограничены. К тому же они довольно дорогие. Идея виртуального хостинга на основе имен старше Kubernetes. Суть в том, что вы указываете записи DNS для разных веб-сайтов, таких как ww1.пример.com и ww2.пример.com на тот же IP-адрес. Сервер, работающий на этом IP-адресе, увидит входящий запрос, и если имя хоста, указанное в запросе, относится к ww1.пример.com, то он обслуживает этот веб-сайт для вас, и если ww2.пример.com запрашивается, затем он обслуживается.

В контексте Kubernetes мы можем запустить две службы, работающие, скажем, на порту 80, и выставить их обе на одном IP-адресе, используя входящий также порт 80. В точке входа трафик ww1.пример.com будет отделен от трафика для ww2.пример.ком. Отсюда и термин виртуальный хостинг на основе имени.

Заключение

Ingress в Kubernetes довольно сложен, чтобы рассказать о нем в одном посте. Для него существует множество вариантов использования и множество контроллеров Ingress, которые добавят функциональность Ingress в ваш кластер. Я бы рекомендовал начать с Nginx Ingress Controller.

Для получения дополнительной информации и спецификаций вы также можете следовать официальной документации.