Сторонні балансувальники навантаження

 2 хвилин(и)  

Istio надає як ingress, так і service mesh рішення, які можуть використовуватися разом або окремо. Хоча вони розроблені для безшовної роботи разом, бувають випадки, коли необхідна інтеграція зі стороннім ingress. Це може бути необхідно для міграції, специфічних функцій або через особисті вподобання.

Режими інтеграції

У “самостійній” конфігурації сторонній ingress безпосередньо надсилає запити до backend. У цьому випадку, припускається, що у backend вже є інжектовані sidecar для Istio.

graph LR cc((Клієнт)) tpi(Сторонній Ingress) a(Backend) cc-->tpi-->a

У цьому режимі все зазвичай працює “з коробки”. Клієнти в service mesh не повинні знати, що backend, до якого вони підключаються, має sidecar. Однак ingress не використовуватиме mTLS, що може призвести до небажаної поведінки. Основна конфігурація для цього налаштування стосується ввімкнення mTLS.

У “ланцюговому” режимі використовується як сторонній ingress, так і власний Istio Gateway. Це може бути корисно, коли потрібен функціонал обох шарів. Особливо це корисно з керованими хмарними балансувальниками навантаження, які мають такі функції, як глобальні адреси та керовані сертифікати.

graph LR cc((Клієнт)) tpi(Сторонній Ingress) ii(Istio Gateway) a(Backend) cc-->tpi tpi-->ii ii-->a

Хмарні балансувальники навантаження

Зазвичай хмарні балансувальники працюють “з коробки” у самостійній конфігурації без mTLS. Для підтримки ланцюгового режиму або самостійного режиму з mTLS потрібна специфічна конфігурація від постачальника.

Google HTTP(S) Load Balancer

Інтеграція з Google HTTP(S) Load Balancer працює “з коробки” у самостійній конфігурації, якщо mTLS не потрібен, оскільки mTLS не підтримується.

Ланцюговий режим можливий. Дивіться документацію Google для налаштування.

Внутрішньокластерні балансувальники навантаження

Зазвичай внутрішньокластерні балансувальники працюють “з коробки” у самостійній конфігурації без mTLS.

Самостійний режим з mTLS можна реалізувати шляхом інʼєкції sidecar у Pod внутрішньокластерного балансувальника. Це зазвичай вимагає двох додаткових кроків:

  1. Вимкнення перенаправлення вхідного трафіку. Хоча це не є обовʼязковим, зазвичай ми хочемо використовувати sidecar лише для вихідного трафіку, оскільки вхідні зʼєднання від клієнтів вже обробляються самим балансувальником. Це також дозволяє зберігати оригінальну IP-адресу клієнта, яка інакше була б втрачена через sidecar. Цей режим можна ввімкнути, додавши анотацію traffic.sidecar.istio.io/includeInboundPorts: "" на Pod балансувальника.

  2. Увімкнення маршрутизації до сервісу. Sidecar Istio може коректно працювати, коли запити надсилаються до Service, а не до конкретних IP-адрес Pod. Більшість балансувальників стандартно надсилають запити на конкретні IP-адреси Pod, що порушує роботу mTLS. Кроки для вирішення цієї проблеми залежать від постачальника; наведено кілька прикладів, але рекомендується ознайомитися з документацією конкретного постачальника.

    Альтернативно, можна встановити заголовок Host до імені сервісу. Однак це може призвести до несподіваної поведінки; балансувальник обере конкретний Pod, але Istio ігноруватиме його. Дивіться тут для отримання додаткової інформації про те, чому це так працює.

ingress-nginx

ingress-nginx можна налаштувати для маршрутизації до сервісу, додавши анотацію до ресурсів Ingress:

nginx.ingress.kubernetes.io/service-upstream: "true"

Emissary-Ingress

Emissary-ingress стандартно використовує маршрутизацію до сервісу, тому додаткові налаштування не потрібні.

Чи була ця інформація корисною?
Чи є у вас пропозиції щодо покращення?

Дякуємо за ваш відгук!