Я довольно смущен ролями Ingress и Load Balancer в Kubernetes.
Насколько я понимаю, Ingress используется для отображения входящего трафика из Интернета на сервисы, работающие в кластере.
Роль балансировщика нагрузки заключается в пересылке трафика на хост. В этом отношении чем отличается вход от балансировщика нагрузки? Кроме того, какова концепция балансировщика нагрузки в kubernetes по сравнению с Amazon ELB и ALB?
Балансировщик нагрузки: сервис Kubernetes LoadBalancer - это сервис, который указывает на внешние балансировки нагрузки, которые НЕ находятся в вашем кластере кубернетов, но существуют в другом месте. Они могут работать с вашими стручками, предполагая, что ваши стручки внешне маршрутизируются. Google и AWS предоставляют эту возможность изначально. Что касается Amazon, это напрямую связано с ELB и кубернетами, когда в AWS можно автоматически создавать и настраивать экземпляр ELB для каждой развернутой службы LoadBalancer.
Ingress: вход - это просто набор правил для перехода к контроллеру, который их прослушивает. Вы можете развернуть кучу правил доступа, но ничего не произойдет, если у вас нет контроллера, который может их обработать. Служба LoadBalancer могла бы прослушивать входные правила, если она настроена для этого.
Вы также можете создать службу NodePort, которая имеет внешний маршрутизируемый IP-адрес за пределами кластера, но указывает на контейнер, который существует в вашем кластере. Это может быть Ingress Controller.
Контроллер Ingress - это просто блок, который настроен для интерпретации правил доступа. Один из самых популярных входных контроллеров, поддерживаемых 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 в /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, и есть много типов контроллеров Ingress, которые имеют разные возможности.
Контроллер входа GKE по умолчанию запустит для вас балансировку нагрузки HTTP (S). Это позволит вам выполнять маршрутизацию на основе маршрутов и поддоменов на бэкэнд-услуги. Например, вы можете отправить все на foo.yourdomain.com в службу foo и все, что находится на пути yourdomain.com/bar/к службе бара.
Ingress, вероятно, самый мощный способ разоблачить ваши услуги, но также может быть самым сложным. Существует множество типов контроллеров Ingress, от балансировщика облачной нагрузки Google, Nginx, Contour, Istio и других. Существуют также плагины для Ingress-контроллеров, таких как cert-manager, которые могут автоматически предоставлять SSL-сертификаты для ваших услуг.
Ingress является наиболее полезным, если вы хотите разоблачить несколько сервисов по одному и тому же IP-адресу, и эти службы используют один и тот же протокол L7 (обычно HTTP). Вы платите только за один балансировщик нагрузки, если используете встроенную интеграцию GCP, а поскольку Ingress "умный", вы можете получить множество функций из коробки (например, SSL, Auth, Routing и т.д.),
TL: DR
Начнем с практического использования: у вас есть несколько Apis, поддерживаемых пакетами реализации службы (ASIP для clariy и краткости) для развертывания под одним доменным именем. Поскольку вы являетесь передовым разработчиком, вы внедрили архитектуру микросервисов, которая требует отдельных развертываний для каждого ASIP, чтобы их можно было обновлять или масштабировать по отдельности. Конечно, эти ASIP инкапсулируются в отдельный контейнер докеров и доступны Kubernetes (K8s) из хранилища контейнеров.
Скажем теперь, что вы хотите развернуть это на Google GKE K8s. Чтобы реализовать устойчивую доступность, каждый экземпляр ASIP (реплика) развертывается на разных узлах (VM), где каждая виртуальная машина имеет собственный внутренний IP-адрес облака. Каждое развертывание ASIP настроено в файле aptly name "deployment.yaml", где вы декларативно указываете, среди прочего, количество реплик данных ASIP K8s должно развертываться.
Следующий шаг заключается в том, чтобы предоставить API в мир ouside и запросы последовательности к одному из развернутых экземпляров 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 с использованием одного и того же имени домена.
Ingress: Ingress Object + Ingress Controller
Ingress Object:
Так же, как объект службы, за исключением того, что он ничего не делает сам по себе. 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 может использовать службу для прослушивания портов 80 и 443, а затем читать новые объекты входа и анализировать их в новые разделы сервера {}, которые он динамически помещает в него 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/concepts/services-networking/ingress/
Проще говоря, подсистема балансировки нагрузки распределяет запросы по нескольким внутренним службам (одного типа), тогда как входная информация больше похожа на шлюз API (обратный прокси-сервер), который направляет запрос в определенную внутреннюю службу на основе, например, URL-адреса.
Существует 4 способа разрешить модулям в вашем кластере получать внешний трафик:
1.) Сервис NodePort
2.) Сервис LoadBalancer (который основан на сервисе NodePort)
3.) Служба NodePort с HostNetworking: истинные и явные NodePorts за пределами нормального диапазона NodePort (позволяет 1 стручку на узел прослушивать непосредственно порты на хост-узле. Minikube, bare metal и rasberry pi иногда идут по этому пути, который может позволить узлу хоста прослушивать порт 80/443, разрешить не использовать балансировщик нагрузки или расширенные конфигурации балансировщика нагрузки в облаке, он также обходит сервисы Kubernetes, которые могут быть полезны для избежания SNAT/достижения аналогичного эффекта externalTrafficPolicy: Local в сценариях, где это не так поддерживается как на AWS.)
4.) Ingress Controller + Ingress Objects (который основан на любом из вышеперечисленного)
Допустим, у вас есть 10 веб-сайтов, размещенных в вашем кластере, и вы хотите выставить их все для внешнего трафика.
* Если вы используете сервис LoadBalancer типа, вы создадите балансировщики нагрузки 10 HA Cloud (каждый стоит денег)
* Если вы используете тип Ingress Controller, вы создадите балансировщик нагрузки 1 HA Cloud (экономит деньги), и он укажет на Ingress Controller, работающий в вашем кластере.
Ingress Controller:
LB LB/Ingress Controller внутри вашего кластера. Балансировка нагрузки/обратный прокси-трафик трафика к Cluster IP Services внутри вашего кластера, он также может завершить HTTPS, если у вас есть секрет Kubernetes типа TLS-сертификат и объект Ingress, который ссылается на него.)
