Маршрутизация
DestinationRule
Позволяет:
- Определить стратегию балансировки трафика между эндпоинтами сервиса:
- Алгоритм балансировки (LEAST_CONN, ROUND_ROBIN, …)
- Признаки смерти эндпоинта и правила его выведения из балансировки
- Лимиты TCP-соединений и реквестов для эндпоинтов
- Sticky Sessions
- Circuit Breaker
- Определить альтернативные группы эндпоинтов для обработки трафика (применимо для Canary Deployments). При этом, у каждой группы можно настроить свои стратегии балансировки.
- Настройка tls для исходящих запросов.
VirtualService
Использование VirtualService опционально, классические сервисы продолжают работать если вам достаточно их функционала.
Позволяет настроить маршрутизацию запросов:
- Аргументы для принятия решения о маршруте:
- Host
- uri
- Вес
- Параметры итоговых направлений:
- Новый хост
- Новый uri
- Если хост определён с помощью DestinationRule, то можно направлять запросы на subset’ы
- Таймаут и настройки ретраев
Важно! Istio должен знать о существовании
destination
, если вы используете внешний API, то зарегистрируйте его через ServiceEntry.
ServiceEntry
Аналог Endpoints + Service из ванильного Kubernetes. Позволяет сообщить Istio о существовании внешнего сервиса или даже переопределить его адрес.
Аутентификация
Решает задачу “кто сделал запрос?”. Не путать с авторизацией, которая определяет, “разрешить ли аутентифицированному элементу делать что-то или нет?”.
По факту есть два метода аутентификации:
- mTLS
- JWT-токены
PeerAuthentication
Позволяет определить стратегию MTLS в отдельном NS. Принимать или нет нешифрованные запросы. Каждый mTLS-запрос автоматически позволяет определить источник и использовать его в правилах авторизации.
RequestAuthentication
Позволяет настроить JWT-аутентификацию для реквестов.
Авторизация
Важно! Авторизация без mTLS- или jwt-аутентификации не будет работать в полной мере. В этом случае будут доступны только простейшие аргументы для составления политик, такие как source.ip и request.headers.
AuthorizationPolicy
Включает и определяет контроль доступа к workload. Поддерживает как ALLOW, так и DENY правила. Как только у workload появляется хотя бы одна политика, то начинает работать приоритет:
- Если под реквест есть политика DENY, то отклонить запрос
- Если под реквест нет политики ALLOW, то разрешить запрос
- Если под реквест есть политика ALLOW, то разрешить запрос
- Отклонить запрос
Аргументы для принятия решения об авторизации:
- source:
- namespace
- principal (читай идентификатор юзера, полученный после аутентификации)
- ip
- destination:
- метод (GET, POST, …)
- Host
- порт
- uri
Sidecar
Данный ресурс позволяет ограничить количество сервисов, о которых будет передана информация в сайдкар istio-proxy.