текст перекладу
Фото від Paul White на Unsplash
У попередній статті ми охопили основи Istio, включаючи його архітектуру. Ми зосередилися на DestinationRules та їхніх особливостях, а також VirtualServices.
Ви можете прочитати її тут: Ознайомлення з основами керування трафіком в Istio.
Сьогодні ми обговоримо Ingress та Egress трафік, використовуючи Gateways, і розглянемо деякі сценарії.
Gateways: теорія
Під час встановлення контрольної плати Istio, ми можемо вибрати, чи встановлювати Ingress або Egress Gateways. Є різні способи зробити це, наприклад, за допомогою CLI:
istioctl install --set profile=demo
Встановивши флаг профілю, ми можемо визначити, яку інсталяцію контрольної плати ми хочемо виконати. За замовчуванням у профілі включено istio-ingressgateway, а профіль Demo включає як ingress, так і egress gateways.
Ми також можемо розгорнути gateways за допомогою ресурсу IstioOperator наступним чином:
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
name: myoperator
spec:
profile: demo
components:
egressGateways:
- name: istio-egressgateway
enabled: false
ingressGateways:
- name: istio-ingressgateway
enabled: false
- name: app-gateway
enabled: true
namespace: my-app
label:
appgateway: my-app
- name: internal-gateway
enabled: true
namespace: internal
label:
gatewayType: internal
У цьому коді ми вимикаємо за замовчуванням istio-ingressgateway та istio-egressgateway для профілю Demo та створюємо два нових ingress gateway під назвами app-gateway та internal-gateway.
Крім того, ми можемо встановити мітки для цих gateways і визначити простір імен, де вони будуть розміщені.
Ми також можемо встановити деякі специфікації Kubernetes, такі як affinity, tolerations, envs, кількість реплік для розгортання... Вся інформація доступна тут.
Ми поговорили про те, як розгортати gateways… але що це за gateways?
Gateways в Istio — це в основному проксі Envoy (так, точно, такі ж, як ті, що працюють як sidecars), але розміщені на межі мережі. Це означає, що gateways — це проксі Envoy, через які проходить весь вхідний і вихідний трафік мережі... або принаймні для цього вони й призначені.
Ці проксі Envoy розгортаються як pods, якими керує розгортання:
Розгортання контрольної плати Istio
Важливо підкреслити, що оскільки gateways є просто проксі Envoy, вони не додають жодних функцій безпеки до вашої системи за замовчуванням.
А ось і найважливіша частина: для конфігурації цих gateways ми використовуємо Gateway CRD, що насправді є набором конфігурацій, які застосовуються до pods gateway.
Gateways: Сценарії
Тепер, коли ви знаєте, що таке gateway, давайте подивимося на деякі приклади.
За замовчуванням весь вхідний/вихідний трафік мережі НЕ проходить через gateways. Нам потрібно встановити правила, щоб трафік проходив через них. Це робиться за допомогою VirtualServices.
HTTP Ingress
Основний випадок, коли ми хочемо, щоб наш сервіс був доступний ззовні мережі. Нам потрібен gateway, щоб опублікувати наш сервіс через ingress-gateway і VirtualService, щоб спрямувати трафік від ingress-gateway до нашого реального сервісу.
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
name: httpbin-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "httpbin.example.com"
Ми вибираємо через поле spec.selector той gateway, до якого хочемо застосувати цю конфігурацію. Потім вказуємо порт і хост, до яких має підключатися Gateway.
текст перекладу
Це означає, що наш Gateway буде слухати порт 80 (протокол HTTP) для будь-якого вхідного запиту на httpbin.example.com.
Тепер створимо ресурс VirtualService, щоб направити запити з Gateway до сервісу:
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: httpbin
spec:
hosts:
- "httpbin.example.com"
gateways:
- httpbin-gateway
http:
- match:
- uri:
prefix: /status
- uri:
prefix: /delay
route:
- destination:
port:
number: 8000
host: httpbin
HTTPS Ingress: Безпечний Gateway
У цьому випадку нам необхідно мати сертифікати, які ми будемо використовувати для захисту робочого навантаження. Сертифікат і ключ будуть розміщені в секреті Kubernetes для TLS.
Ідея тут така ж, як і в попередньому сценарії, але в цьому випадку ми застосуємо конфігурацію в gateway для активації TLS.
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
name: mygateway
spec:
selector:
istio: ingressgateway # використовуємо за замовчуванням istio ingress gateway
servers:
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: httpbin-credential
hosts:
- httpbin.example.com
spec.servers[0].tls посилається на секрет, що містить сертифікат і ключ, більше про це можна прочитати тут.
Також існує режим MUTUAL (серед інших). У mTLS секрет повинен містити сертифікат, ключ і CA, оскільки він необхідний для перевірки цілісності клієнта.
Тепер створимо VirtualService:
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: httpbin
spec:
hosts:
- "httpbin.example.com"
gateways:
- mygateway
http:
- match:
- uri:
prefix: /status
- uri:
prefix: /delay
route:
- destination:
port:
number: 8000
host: httpbin
Для egress Gateways ми припускаємо, що egress трафік закритий.
текст перекладу
Тому нам потрібно створити ServiceEntry, щоб дозволити вихідний трафік до кінцевих точок поза мережею.
HTTP Egress
Спочатку створимо ServiceEntry для відкриття вебсайту cnn:
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
name: cnn
spec:
hosts:
- edition.cnn.com
ports:
- number: 80
name: http-port
protocol: HTTP
resolution: DNS
Створюємо ресурс Gateway для прослуховування запитів, що надходять зсередини мережі:
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
name: istio-egressgateway
spec:
selector:
istio: egressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- edition.cnn.com
І створюємо VirtualService, щоб маршрутизувати трафік зсередини мережі до egress gateway, а звідти — до зовнішнього сервісу:
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: direct-cnn-through-egress-gateway
spec:
hosts:
- edition.cnn.com
gateways:
- istio-egressgateway
- mesh
http:
- match:
- gateways:
- mesh
port: 80
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
port:
number: 80
weight: 100
- match:
- gateways:
- istio-egressgateway
port: 80
route:
- destination:
host: edition.cnn.com
port:
number: 80
weight: 100
Зверніть особливу увагу на слово “mesh”, яке є спеціальним терміном, що використовується для позначення всіх проксі-серверів sidecar, розташованих всередині мережі.
Для HTTPS змінюємо ServiceEntry, щоб відкривати порт 443, протокол TLS:
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
name: cnn
spec:
hosts:
- edition.cnn.com
ports:
- number: 443
name: tls
protocol: TLS
resolution: DNS
Змінюємо конфігурацію Gateway:
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
name: istio-egressgateway
spec:
selector:
istio: egressgateway
servers:
- port:
number: 443
name: tls
protocol: TLS
hosts:
- edition.cnn.com
tls:
mode: PASSTHROUGH
Як ви можете побачити, ми виконуємо passthrough на рівні gateway, оскільки розшифровка TLS відбувається на зовнішньому кінці.
Тепер змінюємо VirtualService, щоб маршрутизувати TLS трафік:
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: direct-cnn-through-egress-gateway
spec:
hosts:
- edition.cnn.com
gateways:
- mesh
- istio-egressgateway
tls:
- match:
- gateways:
- mesh
port: 443
sniHosts:
- edition.cnn.com
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
port:
number: 443
- match:
- gateways:
- istio-egressgateway
port: 443
sniHosts:
- edition.cnn.com
route:
- destination:
host: edition.cnn.com
port:
number: 443
weight: 100
HTTPS Egress: TLS орігінування
Може бути так, що наш мікросервіс не підтримує відправку HTTPS трафіку, але він підключається до зовнішньої кінцевої точки, яка приймає лише цей тип трафіку. У цьому випадку завдяки Istio, зміни в логіці мікросервісу не потрібні.
текст перекладу
Замість цього egress gateway може ініціювати TLS запити.
Ще одна перевага дозволяти Istio ініціювати TLS — це контроль над телеметрією та більше можливостей для маршрутизації.
Спочатку створимо ServiceEntry для зовнішнього сервісу:
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
name: cnn
spec:
hosts:
- edition.cnn.com
ports:
- number: 80
name: http
protocol: HTTP
- number: 443
name: https
protocol: HTTPS
resolution: DNS
Створимо конфігурацію для gateway для зовнішнього сервісу, зверніть увагу, що порт встановлений на 80, оскільки наш мікросервіс генерує HTTP трафік:
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
name: istio-egressgateway
spec:
selector:
istio: egressgateway
servers:
- port:
number: 80
name: https-port-for-tls-origination
protocol: HTTPS
hosts:
- edition.cnn.com
tls:
mode: ISTIO_MUTUAL
Створимо DestinationRule для egress-gateway, щоб забезпечити безпечну комунікацію між мікросервісом та gateway:
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
name: egressgateway-for-cnn
spec:
host: istio-egressgateway.istio-system.svc.cluster.local
subsets:
- name: cnn
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 80
tls:
mode: ISTIO_MUTUAL
sni: edition.cnn.com
Режим ISTIO_MUTUAL налаштовує використання автоматично згенерованих сертифікатів Istio для робочого навантаження, таким чином досягається mTLS між мікросервісом і gateway без необхідності керувати сертифікатами вручну.
Тепер створимо VirtualService, як і раніше, щоб маршрутизувати трафік з будь-якої точки всередині мережі до egress gateway, а звідти — до зовнішнього сервісу, зверніть увагу на посилання на створений subset для маршруту egress-gateway:
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: direct-cnn-through-egress-gateway
spec:
hosts:
- edition.cnn.com
gateways:
- istio-egressgateway
- mesh
http:
- match:
- gateways:
- mesh
port: 80
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
subset: cnn
port:
number: 80
weight: 100
- match:
- gateways:
- istio-egressgateway
port: 80
route:
- destination:
host: edition.cnn.com
port:
number: 443
weight: 100
Останнім кроком створимо DestinationRule, який виконає ініціацію TLS для зовнішнього сервісу:
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
name: originate-tls-for-edition-cnn-com
spec:
host: edition.cnn.com
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 443
tls:
mode: SIMPLE # ініціює HTTPS для з'єднань з edition.cnn.com
Як ми визначили TLS режим як SIMPLE, Istio перевірить цілісність зовнішнього сервісу за допомогою CA пакету, наданого в контейнерному образі. Але ми можемо визначити конкретний CA пакет, який буде попередньо завантажено в контейнер.
Заключні слова
Istio Gateways — потужний інструмент для включення в наші архітектури. На мою думку, я не використовую gateways для покращення безпеки (оскільки це не їх основна функція), а скоріше для того, щоб забезпечити, що весь трафік проходить через єдину точку системи. Це допомагає нам краще відслідковувати трафік.
текст перекладу
Gateways також пропонують додаткові можливості, які спрощують наше життя, такі як управління сертифікатами та налаштування TLS.
Посилання:
[
Ingress
Контроль вхідного трафіку для мережі сервісів Istio.
istio.io
](https://istio.io/latest/docs/tasks/traffic-management/ingress/?source=post_page-----e32286360796--------------------------------)
[
Egress
Контроль вихідного трафіку для мережі сервісів Istio.
istio.io
](https://istio.io/latest/docs/tasks/traffic-management/egress/?source=post_page-----e32286360796--------------------------------)
[
Gateway
Конфігурація, що впливає на балансувальник навантаження на кордоні мережі.
istio.io
](https://istio.io/latest/docs/reference/config/networking/gateway/?source=post_page-----e32286360796--------------------------------)
Перекладено з: Demistifying Istio Gateways