Кубернец: Ingress против Load Balancer

Я очень озадачен ролью Ingress и Load Balancer в Kubernetes.

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

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

101 голос | спросил arunkjn 13 J000000Thursday17 2017, 14:59:29

3 ответа


0

Балансировщик нагрузки . Служба 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 контроллер. Надеюсь, это поможет!

ответил Lindsay Landry 13 J000000Thursday17 2017, 18:03:36
0

Я нашел Это очень интересная статья , которая объясняет различия между 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,   Истио и многое другое. Есть также плагины для контроллеров Ingress, такие как   сертификат-менеджер, который может автоматически предоставлять SSL-сертификаты   за ваши услуги.

     

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

ответил Ankit Agrawal 11 Mayam18 2018, 09:06:47
0

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, используя одно и то же доменное имя.

ответил softjake 14 Maypm18 2018, 23:59:54

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132