Ingress vs Load Balancer

Я довольно смущен ролями Ingress и Load Balancer в Kubernetes.

Насколько я понимаю, Ingress используется для отображения входящего трафика из Интернета на сервисы, работающие в кластере.

Роль балансировщика нагрузки заключается в пересылке трафика на хост. В этом отношении чем отличается вход от балансировщика нагрузки? Кроме того, какова концепция балансировки нагрузки внутри кубернетов по сравнению с Amazon ELB и ALB?

Балансировщик нагрузки. Служба kubernetes LoadBalancer - это служба, которая указывает на внешние балансировщики нагрузки, которые НЕ находятся в вашем кластере kubernetes, но существуют в другом месте. Они могут работать с вашими модулями, предполагая, что они могут быть внешне маршрутизируемыми. Google и AWS предоставляют эту возможность изначально. В терминах Amazon это сопоставление напрямую с ELB и kubernetes при работе в AWS позволяет автоматически предоставлять и настраивать экземпляр ELB для каждой развернутой службы LoadBalancer.

Вход: вход - это просто набор правил, которые нужно передать контроллеру, который их слушает. Вы можете развернуть несколько правил входа, но ничего не произойдет, если у вас нет контроллера, который может их обрабатывать. Служба LoadBalancer может прослушивать входящие правила, если она настроена на это.

Вы также можете создать службу NodePort , которая имеет внешне маршрутизируемый IP-адрес вне кластера, но указывает на модуль, который существует в вашем кластере. Это может быть Ingress Controller.

Ingress Controller - это просто модуль, настроенный для интерпретации правил входа. Одним из самых популярных входных контроллеров, поддерживаемых kubernetes, является nginx. С точки зрения Amazon, ALB может использоваться как входной контроллер.

Например, этот контроллер nginx может принимать определенные вами правила входа и преобразовывать их в файл nginx.conf, который он загружает и запускает в своем модуле.

Допустим, например, что вы определили вход следующим образом:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
   ingress.kubernetes.io/rewrite-target: /
 name: web-ingress
spec:
  rules:
  - host: kubernetes.foo.bar
    http:
      paths:
      - backend:
          serviceName: appsvc
          servicePort: 80
        path: /app

Если вы затем осмотрите свой модуль контроллера nginx, вы увидите следующее правило, определенное в /etc/nginx.conf:

server {
    server_name kubernetes.foo.bar;
    listen 80;
    listen [::]:80;
    set $proxy_upstream_name "-";
    location ~* ^/web2\/?(?<baseuri>.*) {
        set $proxy_upstream_name "apps-web2svc-8080";
        port_in_redirect off;

        client_max_body_size                    "1m";

        proxy_set_header Host                   $best_http_host;

        # Pass the extracted client certificate to the backend

        # Allow websocket connections
        proxy_set_header                        Upgrade           $http_upgrade;
        proxy_set_header                        Connection        $connection_upgrade;

        proxy_set_header X-Real-IP              $the_real_ip;
        proxy_set_header X-Forwarded-For        $the_x_forwarded_for;
        proxy_set_header X-Forwarded-Host       $best_http_host;
        proxy_set_header X-Forwarded-Port       $pass_port;
        proxy_set_header X-Forwarded-Proto      $pass_access_scheme;
        proxy_set_header X-Original-URI         $request_uri;
        proxy_set_header X-Scheme               $pass_access_scheme;

        # mitigate HTTPoxy Vulnerability
        # https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
        proxy_set_header Proxy                  "";

        # Custom headers

        proxy_connect_timeout                   5s;
        proxy_send_timeout                      60s;
        proxy_read_timeout                      60s;

        proxy_redirect                          off;
        proxy_buffering                         off;
        proxy_buffer_size                       "4k";
        proxy_buffers                           4 "4k";

        proxy_http_version                      1.1;

        proxy_cookie_domain                     off;
        proxy_cookie_path                       off;

    rewrite /app/(.*) /$1 break;
    rewrite /app / break;
    proxy_pass http://apps-appsvc-8080;

    }

Nginx только что создал правило для маршрутизации, http://kubernetes.foo.bar/appуказывающей на службу appsvcв вашем кластере.

Вот пример того, как реализовать кластер kubernetes с входным контроллером nginx. Надеюсь это поможет!

Я нашел эту очень интересную статью, которая объясняет различия между NodePort, LoadBalancer и Ingress.

Из содержания, представленного в статье:

LoadBalancer:

Сервис LoadBalancer - это стандартный способ предоставления сервиса Интернету. На GKE это раскрутит балансировщик сетевой нагрузки, который даст вам один IP-адрес, который будет перенаправлять весь трафик на ваш сервис.

Если вы хотите напрямую предоставить сервис, это метод по умолчанию. Весь трафик на указанном вами порту будет перенаправлен на сервис. Нет фильтрации, маршрутизации и т. Д. Это означает, что вы можете отправлять на него практически любой трафик, например, HTTP, TCP, UDP, Websockets, gRPC или любой другой.

Большим недостатком является то, что каждый сервис, который вы предоставляете с помощью LoadBalancer, получит свой собственный IP-адрес, и вам придется платить за LoadBalancer за каждый предоставляемый сервис, который может дорого обойтись!

Ingress:

Вход на самом деле НЕ является видом обслуживания. Вместо этого он находится перед несколькими службами и действует как «умный маршрутизатор» или точка входа в ваш кластер.

С Ingress можно делать много разных вещей, и есть много типов контроллеров Ingress, которые имеют разные возможности.

Входной контроллер GKE по умолчанию раскрутит балансировщик нагрузки HTTP (S) для вас. Это позволит вам выполнять маршрутизацию как на основе пути, так и на основе поддоменов к внутренним службам. Например, вы можете отправить все на foo.yourdomain.com в службу foo и все, находящиеся по пути yourdomain.com/bar/ к службе bar.

Ingress, вероятно, является самым мощным способом раскрытия ваших услуг, но также может быть и самым сложным. Существует много типов контроллеров Ingress, от Google Cloud Load Balancer, Nginx, Contour, Istio и других. Существуют также плагины для контроллеров Ingress, такие как cert-manager, которые могут автоматически предоставлять SSL-сертификаты для ваших сервисов.

Вход является наиболее полезным, если вы хотите предоставить несколько служб под одним и тем же IP-адресом, и все эти службы используют один и тот же протокол L7 (обычно HTTP). Вы платите только за один балансировщик нагрузки, если используете встроенную интеграцию с GCP, и, поскольку Ingress «умный», вы можете получить множество функций из коробки (например, SSL, Auth, Routing и т. Д.)

TL: DR

1. Ingress находится между публичной сетью (Интернет) и сервисами Kubernetes, которые публично раскрывают реализацию нашего API.
2. Ingress способен обеспечить балансировку нагрузки, SSL-терминацию и виртуальный хостинг на основе имен.
3. Возможности Ingress позволяют безопасно предоставлять несколько API или приложений из одного доменного имени.

Давайте начнем с практического варианта использования: у вас есть несколько Apis, поддерживаемых пакетами реализации сервиса (ASIP для ясности и краткости) для развертывания под одним доменным именем. Поскольку вы являетесь передовым разработчиком, вы внедрили архитектуру микросервисов, которая требует отдельного развертывания для каждого ASIP, чтобы их можно было обновлять или масштабировать индивидуально. Разумеется, эти ASIP заключены в отдельный докер-контейнер и доступны Kubernetes (K8s) из хранилища контейнеров.

Предположим теперь, что вы хотите развернуть это на Google GKE K8s. Для обеспечения постоянной доступности каждый экземпляр ASIP (реплика) развертывается на разных узлах (ВМ), где каждая ВМ имеет свой собственный внутренний IP-адрес в облаке. Каждое развертывание ASIP настраивается в файле с именем «deploy.yaml», где вы точно указываете, среди прочего, количество реплик данных ASIP K8, которые следует развернуть.

Следующим шагом является предоставление API-интерфейса окружающему миру и передача запросов одному из развернутых экземпляров ASIP. Поскольку у нас много реплик одного и того же ASIP, работающих на разных узлах, нам нужно что-то, что будет распределять запрос по этим репликам. Чтобы решить эту проблему, мы можем создать и применить файл «service.yaml», который будет настраивать службу K8s (KServ), которая будет доступна извне и доступна через IP-адрес. Этот KServ будет отвечать за распределение запросов API между настроенными ASIP. Обратите внимание, что KServ будет автоматически перенастроен мастером K8s при сбое узла ASIP и перезапуске. Внутренний IP-адрес никогда не используется повторно в таком случае, и KServ должен быть уведомлен о месте размещения нового ASIP.

Но у нас есть другие сервисные пакеты Api, которые должны быть представлены на том же доменном имени. Вращение нового KServ создаст новый внешний IP-адрес, и мы не сможем выставить его на том же доменном имени. Ну, вот тут и приходит Ingress.

Входное сито находится между Интернетом и всеми KServices, которые мы открываем для внешнего мира. Ingress способен обеспечить балансировку нагрузки, SSL-терминацию и виртуальный хостинг на основе имен. Последняя возможность может направить входящий запрос к нужному сервису, проанализировав его URL. Конечно, Ingress должен быть настроен и применен с файлом ... "ingress.yaml", в котором будут указаны перезаписи и маршруты, необходимые для отправки запроса нужному KServ.

Интернет -> Вход -> Услуги K8s -> Реплики

Таким образом, при правильном входе, конфигурации KServices и ASIP мы можем безопасно предоставлять множество API, используя одно и то же доменное имя.

Существует 4 способа разрешить модулям в вашем кластере получать внешний трафик:
1.) Модуль с использованием HostNetworking: true и (позволяет 1 модулю на узел слушать напрямую порты на главном узле. Иногда идут мини-кубы, голые металлы и rasberry pi этот маршрут, который может позволить узлу хоста прослушивать порт 80/443, позволяет не использовать балансировщик нагрузки или расширенные конфигурации балансировщика нагрузки облака, он также обходит сервисы Kubernetes, которые могут быть полезны для предотвращения SNAT / достижения аналогичного эффекта externalTrafficPolicy: Local в сценариях где он не поддерживается, как в AWS.)
2.) Сервис NodePort
3.) Сервис LoadBalancer (который основан на Сервисе NodePort)
4.) Контроллер входа + Объекты входа (который основан на вышеупомянутом)

Допустим, у вас есть 10 веб-сайтов, размещенных в вашем кластере, и вы хотите выставить их все для внешнего трафика.
* Если вы используете тип LoadBalancer Service, вы создадите 10 HA Балансировщиков нагрузки Облака (каждый стоит денег)
* Если вы используете тип Ingress Controller, вы создадите 1 HA Облачный балансировщик нагрузки (экономит деньги), и он будет указывать на Ingress Контроллер работает в вашем кластере.

Ingress Controller - это:

• Служба типа Load Balancer, поддерживаемая развертыванием модулей, работающих в вашем кластере.
• Каждый стручок делает 2 вещи:
  1. Действует как балансировщик нагрузки уровня 7, работающий внутри кластера. (Поставляется во многих вкусах, Nginx популярен)
  2. Динамически настраивается на основе входных объектов в вашем кластере
     (входные объекты можно рассматривать как декларативные фрагменты конфигурации балансировщика нагрузки уровня 7).

LB LB / Ingress Controller в вашем кластере Балансы нагрузки / обратный прокси-трафик к IP-сервисам кластера внутри вашего кластера, он также может завершить HTTPS, если у вас есть секрет Kubernetes типа TLS-сертификат и объект Ingress, который ссылается на него.)

Ingress: Ingress Object + Ingress Controller

Ingress Object:

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

Контроллер входа:

Сервис, который:

  1. listens on specific ports (usually 80 and 443) for web traffic
  2. Listens for the creation, modification, or deletion of Ingress Objects
  3. Creates internal L7 routing rules based on these Ingress Objects

Например, Nginx Ingress Controller может использовать службу для прослушивания портов 80 и 443, а затем читать новые объекты Ingress и анализировать их в новые разделы server {}, которые он динамически помещает в свой nginx.conf.

LoadBalancer: поставщик внешней балансировки нагрузки + тип сервиса

Поставщик внешнего балансировщика нагрузки:

Внешние поставщики балансировщика нагрузки обычно настраиваются в облаках, таких как AWS и GKE, и предоставляют возможность назначать внешние IP-адреса посредством создания внешних балансировщиков нагрузки. Эту функциональность можно использовать, обозначив службу как тип «LoadBalancer».

Тип Обслуживания:

Когда тип сервиса установлен на LoadBalancer, Kubernetes пытается создать, а затем запрограммировать внешний балансировщик нагрузки с записями для модулей Kubernetes, назначая им внешние IP-адреса.

Контроллер службы Kubernetes автоматизирует создание внешнего балансировщика нагрузки, проверки работоспособности (при необходимости), правил брандмауэра (при необходимости) и извлекает внешний IP-адрес вновь созданного или настроенного LoadBalancer, который был выделен провайдером облака, и заполняет его в объект обслуживания.

Отношения:

Сервисы Ingress Controller часто предоставляются как тип LoadBalancer, так что запросы http и https могут быть прокси / направлены к определенным внутренним сервисам через внешний ip.

Тем не менее, LoadBalancer не является строго необходимым для этого. Поскольку с помощью hostNetwork или hostPort вы можете технически связать порт хоста со службой (что позволяет вам посещать его через внешний ip: порт хоста). Хотя официально это не рекомендуется, так как оно использует порты на реальном узле.

Ссылки:

https://kubernetes.io/docs/concepts/configuration/overview/#services

https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/

https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#external-load-balancer-providers

https://kubernetes.io/docs/concepts/services-networking/ingress/

Проще говоря, балансировщик нагрузки распределяет запросы по нескольким бэкэнд-сервисам (одного типа), тогда как вход больше похож на шлюз API (обратный прокси-сервер), который направляет запрос к конкретной бэкэнд-службе на основе, например, URL.