Я не совсем понимаю роли Ingress и Load Balancer в Kubernetes.
Насколько я понимаю, Ingress используется для сопоставления входящего трафика из Интернета службам, работающим в кластере.
Роль балансировщика нагрузки заключается в перенаправлении трафика на хост. Чем в этом отношении Ingress отличается от балансировщика нагрузки? И какова концепция балансировщика нагрузки внутри кубернетов по сравнению с Amazon ELB и ALB?
Балансировщик нагрузки. Служба Kubernetes LoadBalancer - это служба, которая указывает на внешние балансировщики нагрузки, которые НЕ находятся в вашем кластере Kubernetes, но существуют где-то еще. Они могут работать с вашими модулями при условии, что они имеют внешнюю маршрутизацию. Google и AWS изначально предоставляют эту возможность. Что касается Amazon, это напрямую сопоставляется с ELB, а кубернеты при работе в AWS могут автоматически выделять и настраивать экземпляр ELB для каждой развернутой службы LoadBalancer.
Входящий. Входящий трафик - это просто набор правил, которые нужно передать контроллеру, который их прослушивает. Вы можете развернуть несколько правил входа, но ничего не произойдет, если у вас нет контроллера, который может их обрабатывать. Служба LoadBalancer может прослушивать правила входа, если она настроена для этого.
Вы также можете создать службу NodePort, которая имеет внешне маршрутизируемый IP-адрес за пределами кластера, но указывает на модуль, существующий в вашем кластере. Это может быть 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 для ваших служб.
Ingress наиболее полезен, если вы хотите предоставить доступ к нескольким службам под одним и тем же IP-адресом, и все эти службы используют один и тот же протокол L7 (обычно HTTP). Вы платите только за один балансировщик нагрузки, если используете встроенную интеграцию GCP, и, поскольку Ingress «умный», вы можете получить множество функций прямо из коробки (например, SSL, Auth, Routing и т. Д.)
TL:DR
Начнем с практического варианта использования: у вас есть несколько Apis, поддерживаемых пакетами реализации услуг (ASIP для ясности и краткости) для развертывания под одним доменным именем. Поскольку вы являетесь передовым разработчиком, вы реализовали архитектуру микросервисов, которая требует отдельного развертывания для каждого ASIP, чтобы их можно было обновлять или масштабировать по отдельности. Конечно, эти ASIP инкапсулированы в индивидуальный контейнер докеров и доступны Kubernetes (K8s) из репозитория контейнеров.
Предположим, теперь вы хотите развернуть это на Google GKE K8s. Чтобы реализовать устойчивую доступность, каждый экземпляр (реплика) ASIP развертывается на разных узлах (ВМ), где каждая ВМ имеет собственный внутренний IP-адрес в облаке. Каждое развертывание ASIP настраивается в файле с подходящим названием «deployment.yaml», где вы декларативно указываете, среди прочего, количество реплик заданных ASIP K8, которые следует развернуть.
Следующим шагом является предоставление API внешнему миру и воронка запросов к одному из развернутых экземпляров ASIP. Поскольку у нас есть много реплик одного и того же ASIP, запущенного на разных узлах, нам нужно что-то, что будет распределять запрос между этими репликами. Чтобы решить эту проблему, мы можем создать и применить файл «service.yaml», который будет настраивать службу K8s (KServ), которая будет доступна извне и доступна через IP-адрес. Этот KServ будет отвечать за распределение запросов API между настроенными ASIP. Обратите внимание, что KServ будет автоматически перенастроен мастером K8s при выходе из строя узла ASIP и его перезапуске. В этом случае внутренний IP-адрес никогда не используется повторно, и KServ должен быть уведомлен о месте развертывания нового ASIP.
Но у нас есть другие сервисные пакеты Api, которые будут доступны на том же доменном имени. Запуск нового KServ создаст новый внешний IP-адрес, и мы не сможем предоставить его на том же доменном имени. Что ж, здесь на помощь приходит Ingress.
Ingress находится между Интернетом и всеми KServices, которые мы предоставляем внешнему миру. Ingress может обеспечить балансировку нагрузки, завершение SSL и виртуальный хостинг на основе имен. Последняя возможность может направлять входящий запрос в нужную службу, анализируя ее URL. Конечно, Ingress необходимо настроить и применить с помощью файла ... "ingress.yaml", в котором будут указаны перезаписи и маршруты, необходимые для отправки запроса на правильный KServ.
Интернет -> Ingress -> K8s Services -> Реплики
Таким образом, с правильным входом, конфигурацией KServices и ASIP мы можем безопасно предоставить доступ ко многим API, используя одно и то же доменное имя.
Есть 4 способа разрешить модулям в вашем кластере получать внешний трафик:
1.) Модули с использованием HostNetworking: true и (Позволяет 1 модулю на узел напрямую прослушивать порты на узле хоста. Minikube, bare metal и rasberry pi иногда идут по этому пути, который может позволить хост-узлу прослушивать порт 80/443, что позволяет не использовать балансировщик нагрузки или расширенные конфигурации облачного балансировщика нагрузки, он также обходит службы Kubernetes, которые могут быть полезны для предотвращения SNAT / достижения аналогичного эффекта externalTrafficPolicy: Локально в сценариях, где он не поддерживается, как в AWS.)
2.) Служба NodePort
3.) Служба LoadBalancer (которая основана на службе NodePort)
4.) Контроллер входящего трафика + объекты входа (В основе которого лежит над)
Допустим, у вас есть 10 веб-сайтов, размещенных в вашем кластере, и вы хотите открыть их все для внешнего трафика.
* Если вы используете тип LoadBalancer Service, вы создадите 10 балансировщиков нагрузки HA Cloud (каждый стоит денег).
* Если вы используете тип Ingress Controller, вы создадите 1 балансировщик нагрузки HA Cloud (экономит деньги), и он Укажу на Ingress Controller, работающий в вашем кластере.
Контроллер Ingress - это:
L7 LB / Ingress Controller внутри вашего кластера балансирует нагрузку / обратный прокси-трафик для IP-служб кластера внутри вашего кластера, он также может завершить HTTPS, если у вас есть Kubernetes Secret типа TLS cert и объект Ingress, который на него ссылается.)
Проще говоря, балансировщик нагрузки распределяет запросы между несколькими серверными службами (одного и того же типа), тогда как входящий больше похож на шлюз API (обратный прокси), который направляет запрос на конкретную серверную службу на основе, например, URL-адреса.
Ingress: объект Ingress + контроллер Ingress
Ресурс Ingress:
Точно так же, как и сервисный ресурс, за исключением того, что он ничего не делает сам по себе. Ресурс Ingress просто описывает способ маршрутизации трафика уровня 7 в ваш кластер, указывая такие вещи, как путь запроса, домен запроса и целевой сервис Kubernetes, в то время как объект сервиса фактически создает сервисы.
Контроллер входящего трафика:
Сервис, который:
1. listens on specific ports (usually 80 and 443) for web traffic
2. Listens for the creation, modification, or deletion of Ingress Resources
3. Creates internal L7 routing rules based on these Ingress Resources
Например, контроллер Nginx Ingress может использовать службу для прослушивания портов 80 и 443, а затем читать новые ресурсы Ingress и анализировать их в новых разделах сервера {}, которые он динамически помещает в свой nginx.conf.
LoadBalancer: поставщик внешнего балансировщика нагрузки + тип службы
Поставщик внешнего балансировщика нагрузки:
Поставщики внешних балансировщиков нагрузки обычно настраиваются в облаках, таких как AWS и GKE, и предоставляют способ назначения внешних IP-адресов путем создания внешних балансировщиков нагрузки. Эту функциональность можно использовать, обозначив службу как тип LoadBalancer.
Тип услуги:
Когда тип службы установлен на LoadBalancer, Kubernetes пытается создать и затем настроить внешний балансировщик нагрузки с записями для модулей Kubernetes, тем самым назначая им внешние IP-адреса.
Контроллер службы Kubernetes автоматизирует создание внешнего балансировщика нагрузки, проверки работоспособности (при необходимости), правил брандмауэра (при необходимости) и извлекает внешний IP-адрес вновь созданного или настроенного LoadBalancer, который был выделен облачным провайдером, и заполняет его в сервисный объект.
В кластере может быть установлен дополнительный облачный контроллер, которому будут назначены ресурсы службы чтения и их аннотации, чтобы автоматически развертывать и настраивать балансировщики облачной нагрузки, которые будут получать трафик для службы kubernetes.
Отношения:
Службы 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/concepts/services-networking/ingress/ < / а>
У Pod есть свои собственные IP:PORT, но они динамические по своей природе и меняются при удалении или повторном развертывании.
Службам назначается ClusterIPили NodePort (порт в виртуальной машине, где создается ресурс службы), который может быть сопоставлен с набором модулей или другой серверной частью [см .: безголовые службы]
Чтобы получить доступ к правильному модулю, используйте ClusterIP (из clutser)
NodePort можно использовать для доступа к модулям извне кластера.
LoadBalancer [Внешний / Внутренний]: предоставляется облачными провайдерами и указывает на ClusterIP или NodePort. Вы можете получить доступ к услуге, используя IP LB
LB ~ ›СЕРВИС (ClusterIP или NodePort) ~› POD
Ресурс Ingress - это точка входа в кластер. LB может прослушивать правила входа и может маршрутизировать к определенной службе. [См. Это пример]
LB (управляемый входом) ~ ›СЕРВИС (ClusterIP или NodePort) ~› POD
Служба балансировки нагрузки: это прокси-сервер уровня 4 (TCP, UDP, ...). Он работает вне кластерной сети Kubernetes. У него нет функций уровня 7: CircuitBreaker, измерения количества запросов, задержки запроса, сбоя, маршрутизации и т. Д.
ingress: прокси уровня 7 (http, https, gRPC, ..). Это приложение в модуле внутри кластерной сети Kubernetes. Если входящий модуль умирает, Kubernetes перезапускает его или перемещает на другой узел в кластере.
