Я дуже розгублений щодо ролей "Інгреси" та "Балансира навантаження" в "Кубернеті".
Наскільки я розумію, Ingress використовується для відображення вхідного трафіку з Інтернету до служб, що працюють в кластері.
Роль балансира навантаження полягає в тому, щоб пересилати трафік хосту. У зв'язку з цим, чим вхід відрізняється від балансира навантаження? Також, що таке концепція балансира навантаження всередині кубернетів порівняно з Amazon ELB та ALB?
Відповіді:
Балансир завантаження: Служба Kubernetes LoadBalancer - це послуга, яка вказує на зовнішні балансири навантаження, які НЕ знаходяться у вашому кластері кубернетів, але існують в іншому місці. Вони можуть працювати з вашими стручками, припускаючи, що ваші стручки зовні маршрутизовані. Google і AWS надають цю можливість самостійно. З точки зору Amazon, ця карта безпосередньо з ELB та kubernetes при запуску в AWS може автоматично надавати та налаштовувати примірник ELB для кожної розгорнутої служби LoadBalancer.
Інгрес: Вступ - це дійсно лише набір правил, які потрібно передати контролеру, який їх слухає. Ви можете розгорнути купу правил про вхід, але нічого не відбудеться, якщо у вас немає контролера, який може їх обробляти. Служба LoadBalancer може слухати правила входу, якщо вона налаштована для цього.
Ви також можете створити службу NodePort , у якої зовнішній маршрутизований IP зовнішнього кластера, але вказує на стручок, який існує у вашому кластері. Це може бути контролер Ingress.
Контролер Ingress - це просто стручок, який налаштований для інтерпретації правил вступу. Один з найпопулярніших контролерів входу, який підтримується в кубернетах, - це 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у вашому кластері.
Ось приклад того, як реалізувати кластер кубернетів з контролером входу nginx. Сподіваюсь, це допомагає!
Я знайшов цю дуже цікаву статтю, яка пояснює відмінності між NodePort, LoadBalancer та Ingress.
Із змісту, присутнього в статті:
Балансовий навантажувач:
Служба LoadBalancer - це стандартний спосіб відкрити послугу в Інтернеті. На GKE це створить балансовий навантажувач мережі, який надасть вам єдину IP-адресу, яка спрямовуватиме весь трафік на вашу службу.
Якщо ви хочете безпосередньо відкрити послугу, це метод за замовчуванням. Весь трафік на вказаному вами порту буде перенаправлений до служби. Немає фільтрації, маршрутизації тощо. Це означає, що ви можете пересилати на неї майже будь-який вид трафіку, як HTTP, TCP, UDP, Websockets, gRPC або будь-що інше.
Великий мінус полягає в тому, що кожна послуга, яку ви виставляєте з LoadBalancer, отримає власну IP-адресу, і вам доведеться платити за LoadBalancer за кожну піддану послугу, яка може дорого коштувати!
Інгрес:
Ingress насправді НЕ є типом послуги. Натомість він сидить перед декількома службами і виступає як «розумний маршрутизатор» або точка входу у ваш кластер.
З Ingress можна зробити багато різних речей, і є багато типів контролерів Ingress, які мають різні можливості.
За замовчуванням контролер входу GKE запустить вам балансир завантаження HTTP (S). Це дозволить вам здійснювати маршрутизацію, що базується на контурі, і на субдоменах до сервісів бекенда. Наприклад, ви можете надіслати все на foo.yourdomain.com до сервісу foo, а все під шляхом yourdomain.com/bar/ - до служби бар.
Інгрес - це, мабуть, найпотужніший спосіб викрити свої послуги, але може бути і найскладнішим. Існує багато типів контролерів Ingress - від хмарного балансоутримувача Google, Nginx, Contour, Istio тощо. Також є плагіни для контролерів Ingress, як-от cert-менеджер, які можуть автоматично надавати сертифікати SSL для ваших послуг.
Ingress є найбільш корисним, якщо ви хочете виставити кілька служб під однією IP-адресою, і всі ці служби використовують один і той же протокол L7 (як правило, HTTP). Ви платите за один балансир навантаження, якщо ви використовуєте вбудовану інтеграцію в GCP, а оскільки Ingress "розумна", ви можете отримати багато функцій з коробки (наприклад, SSL, Auth, маршрутизація тощо)
TL: DR
Почнемо з практичного випадку: у вас є декілька Apis, підкріплених пакетами реалізації служб (ASIP для пояснення та стислості) для розгортання під одним єдиним доменним іменем. Як ви передовий розробник, ви впровадили архітектуру мікропослуг, яка вимагає окремих розгортань для кожного ASIP, щоб їх можна було оновити або масштабувати окремо. Звичайно, ці ASIP інкапсульовані в індивідуальний контейнер докера та доступні Kubernetes (K8s) з сховища контейнерів.
Скажімо тепер, що ви хочете розгорнути це на GKE K8 Google. Для реалізації стійкої доступності кожен екземпляр (репліка) ASIP розгортається на різних вузлах (ВМ), де кожен VM має власну внутрішню IP-адресу хмари. Кожне розгортання ASIP налаштоване у влучному файлі імені "розміщення.yaml", де ви декларативно вказуєте, серед іншого, кількість реплік даних ASIP K8, які слід розгорнути.
Наступним кроком є розкриття API зовнішнього світу та запитів послідовності до одного з розгорнутих екземплярів ASIP. Оскільки у нас є багато реплік того ж ASIP, що працює на різних вузлах, нам потрібно щось, що поширюватиме запит серед цих реплік. Для вирішення цього питання ми можемо створити та застосувати файл "service.yaml", який налаштує службу K8s (KServ), яка буде відкрита зовнішньою та доступною через IP-адресу. Цей KServ візьме на себе відповідальність за розподіл запитів API між налаштованими ASIP. Зауважте, що KServ буде автоматично налаштований майстром K8s, коли вузол ASIP вийде з ладу і перезапуститься. Внутрішня IP-адреса ніколи не використовується в такому випадку, і KServ необхідно повідомити про нове місце розгортання ASIP.
Але у нас є інші пакети послуг Api, які будуть виставлені під тим самим доменним іменем. Спінінг нового KServ створить нову зовнішню IP-адресу, і ми не зможемо виставити його на те саме доменне ім’я. Ну, ось тут заходить Інгрес.
Інгресія знаходиться між Інтернетом та всіма сервісами KS, які ми піддаємо зовнішньому світу. Ingress здатний забезпечити балансування завантаження, завершення SSL та віртуальний хостинг на основі імен. Остання ємність здатна направити вхідний запит до потрібної служби шляхом аналізу його URL-адреси. Звичайно, Ingress має бути налаштовано та застосовано з файлом ... "ingress.yaml", який визначатиме переписування та маршрути, необхідні для відправки запиту в потрібний KServ.
Інтернет -> Інгрес -> Послуги K8s -> Репліки
Таким чином, при правильному введенні, конфігурації KServices та ASIP, ми можемо надійно відкрити багато API, використовуючи те саме ім’я домену.
Існує 4 способи дозволити стручкам у вашому кластері отримувати зовнішній трафік:
1.) Pod, використовуючи HostNetworking: true і (Дозволяє 1 струк на вузол безпосередньо слухати порти на вузлі вузла. Minikube, голий метал та rasberry pi іноді йдуть Цей маршрут, який може дозволити вузлу хоста прослуховувати порт 80/443, не дозволяє використовувати балансир навантаження або розширені конфігурації балансира навантаження в хмарі, він також обходить Kubernetes Services, який може бути корисним для уникнення SNAT / досягнення аналогічного ефекту зовнішньоїTrafficPolicy: Local у сценаріях там, де це не підтримується, як у AWS.)
2.) Служба NodePort
3.) Служба LoadBalancer (яка заснована на службі NodePort)
4.) Контролер Ingress + Об'єкти вторгнення
(Що спирається на вищезазначене)
Скажімо, у вашому кластері розміщено 10 веб-сайтів, і ви хочете піддавати їх усім зовнішньому трафіку.
* Якщо ви використовуєте службу LoadBalancer Service, ви нерестуєте 10 HA-балансові навантажувачі (кожен коштує гроші)
* Якщо ви використовуєте тип Ingress Controller, ви породжуєте балансир навантаження 1 HA (економить гроші), і це вказуватиме на Ingress Контролер працює у вашому кластері.
Контролер напруги:
Контролер L7 / Ingress у вашому кластері Load Balance / зворотний проксі-сервер до IP-послуг кластера всередині кластера, він також може припинити HTTPS, якщо у вас є кубернетівський секрет типу TLS cert та об’єкт 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 Objects
3. Creates internal L7 routing rules based on these Ingress Objects
Наприклад, контролер Nginx Ingress Controller міг би скористатися послугою для прослуховування на портах 80 і 443, а потім прочитати нові об'єкти Ingress і проаналізувати їх у нові розділи сервера {}, які він динамічно розміщує в nginx.conf
LoadBalancer: зовнішній постачальник балансового навантаження + тип послуги
Постачальник зовнішнього балансування навантаження:
Постачальники зовнішнього балансування навантаження зазвичай налаштовані в хмарах, таких як AWS та GKE, і забезпечують спосіб призначення зовнішніх IP-адрес шляхом створення зовнішніх балансирів навантаження. Цю функціональність можна використовувати, призначивши послугу типу "LoadBalancer".
Тип послуги:
Коли тип послуги встановлено на LoadBalancer, Kubernetes намагається створити та програмувати зовнішній балансир навантаження із записами для стручків Kubernetes, призначаючи їм зовнішні IP-адреси.
Контролер служби Kubernetes автоматизує створення зовнішнього балансира навантаження, перевірки стану здоров’я (якщо потрібно), правил брандмауера (якщо потрібно) і витягує зовнішній IP новоствореного або налаштованого LoadBalancer, який був виділений хмарним постачальником і заповнює його об’єкт обслуговування.
Відносини:
Послуги контролера Ingress часто розглядаються як тип 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-адреси.