Kubernetes: вход против балансировщика нагрузки

Я совершенно запутался в роли входа и балансировки нагрузки в Kubernetes.

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

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

3 81
kubernetes load-balancing

3 ответа:

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

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

вы также можете создать NodePort сервис, который имеет внешне маршрутизируемый IP вне кластера, но указывает на pod это существует в пределах вашего кластера. Это может быть входной контроллер.

контроллер входа-это просто модуль, который настроен для интерпретации правил входа. Одним из самых популярных входных контроллеров, поддерживаемых 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/(.*) / break;
    rewrite /app / break;
    proxy_pass http://apps-appsvc-8080;

    }

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

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

75

нашел это очень интересная статья, который объясняет различия между NodePort, балансировщик нагрузки и попадания.

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

LoadBalancer:

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

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

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

попадание:

Ingress на самом деле не является типом сервиса. Вместо этого он сидит впереди множественных обслуживаний и подействуйте как "умный маршрутизатор" или entrypoint в ваш кластер.

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

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

вход, вероятно, самый мощный способ выставить свои услуги, но также может быть самым сложным. Есть много типов входа контроллерами, от виртуального балансировщика нагрузки , Nginx, Контур, Истио и многое другое. Есть также плагины для входных контроллеров, таких как cert-менеджер, который может автоматически предоставлять SSL сертификаты за ваши услуги.

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

6

TL: DR

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

давайте начнем с практического использования: у вас есть несколько API поддерживается пакетами реализации служб (ASIP для clariy и краткости) для развертывания под одним доменным именем. Поскольку вы являетесь передовым разработчиком, вы реализовали архитектуру микрослужб, которая требует отдельных развертываний для каждого ASIP, чтобы их можно было обновить или масштабировать по отдельности. Конечно, эти ASIPs инкапсулированы в отдельный контейнер docker и доступны для Kubernetes (K8s) из хранилища контейнеров.

предположим теперь, что вы хотите развернуть это на GKE Google K8s. для реализации устойчивой доступности каждый экземпляр (реплика) ASIP развертывается на разных узлах (VM), где каждая виртуальная машина имеет свой собственный внутренний IP-адрес облака. Каждое развертывание ASIP настраивается в подходящем имени " развертывание.файл "yaml", в котором вы декларативно указываете, среди прочего, количество реплик данного ASIP K8s должны развертываться.

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

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

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

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

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

3