Тип сервиса LoadBalancer и Ingress - это способ внешнего доступа к вашему приложению, хотя они работают по-другому.
Сервис:
В Kubernetes служба - это абстракция, которая определяет логический набор модулей и политику доступа к ним (иногда этот шаблон называется микросервисом). Набор модулей, на которые ориентируется Сервис, обычно определяется селектором (см. ниже , чтобы узнать, почему вам может потребоваться Сервис без селектора).
Существует несколько типов Сервисов, и из них тип LoadBalancer позволяет вам выставлять приложение, назначая внешний IP для вашей службы. Для каждого сервиса LoadBalancer ему будет назначен новый внешний IP. Балансировка нагрузки будет обрабатываться kube-proxy.
Ingress:
Объект API, который управляет внешним доступом к службам в кластере, обычно HTTP , Вход может обеспечить балансировку нагрузки, завершение SSL и виртуальный хостинг на основе имен.
При настройке входа (т. Е. nginx -вход) для службы создается тип службы LoadBalancer. -контроллеры и балансировщик нагрузки в вашем облачном провайдере будут созданы автоматически, и для службы nginx будет назначен общедоступный c IP.
Этот балансировщик нагрузки / publi c ip будет используется для входящего соединения для всех ваших услуг, и nginx -ingress будет отвечать за обработку входящих соединений.
Например:
Предположим, у вас есть 10 услуг типа LoadBalancer : Это приведет к созданию 10 новых публичных ips, и вам нужно будет использовать соответствующий ip для службы, к которой вы хотите подключиться.
Но если вы используете вход, будет создан только 1 IP, и вход будет ответственный за обработку входящего соединения для правильного сервиса на основе PATH / URL, который вы определили во входной конфигурации. При входе вы можете:
- Использовать регулярное выражение в
path для определения службы для перенаправления; - Использовать SSL / TLS
- Вставить пользовательские заголовки;
- Перенаправление запросов на службу по умолчанию, если одна из служб завершилась неудачно (default-backend);
- Создание белых списков на основе IP-адресов
- Et c ...
Важное примечание о входной балансировке нагрузки во входе:
GCE / AWS балансировщики нагрузки не предоставляют веса для своих целевых пулов. Это не было проблемой со старыми правилами LB kube-proxy, которые корректно балансировали бы между всеми конечными точками.
С новой функциональностью внешний трафик c не одинаково сбалансирован по нагрузке между модулями, но скорее одинаково сбалансирован на уровне узла (поскольку GCE / AWS и другие внешние реализации LB не способны указывать вес на узел, они равномерно распределяются по всем целевым узлам, независимо от количества модулей на каждом узле).