Маршрутизация

Routing

Reference

Reference.

Позволяет:

• Определить стратегию балансировки трафика между эндпоинтами сервиса:
• алгоритм балансировки (LEAST_CONN, ROUND_ROBIN, …);
• признаки смерти эндпоинта и правила его выведения из балансировки;
• лимиты TCP-соединений и реквестов для эндпоинтов;
• Sticky Sessions;
• Circuit Breaker.
• Определить альтернативные группы эндпоинтов для обработки трафика (применимо для Canary Deployments). При этом у каждой группы можно настроить свои стратегии балансировки.
• Настройка TLS для исходящих запросов.

Allows you to:

• Define a strategy for balancing traffic between service endpoints:
• The balancing algorithm to use (LEAST_CONN, ROUND_ROBIN, …);
• Symptoms that an endpoint is unhealthy and rules for removing it from load balancing;
• Limits for TCP connections and endpoint requests;
• Sticky Sessions;
• Circuit Breaker;
• Define alternative endpoint groups for traffic processing (suitable for Canary Deployments). Also, you can configure balancing strategies for each group;
• Configuring TLS for outgoing requests.

Reference

Reference.

Использование VirtualService опционально, классические сервисы продолжают работать, если вам достаточно их функционала.

Using VirtualService is optional; regular services fit just fine if their capabilities match your requirements.

Позволяет настроить маршрутизацию запросов:

• Аргументы для принятия решения о маршруте:
• Host;
• URI;
• вес.
• Параметры итоговых направлений:
• новый хост;
• новый URI;
• если хост определен с помощью DestinationRule, можно направлять запросы на subset’ы;
• таймаут и настройки ретраев.

Allows you to configure request routing:

• Arguments on which routing decisions are based on:
• Host;
• URI;
• Weight;
• Parameters of the resulting directions:
• The new host;
• The new URI;
• If the host is defined using DestinationRule, then requests can be sent to subsets;
• Timeout and retry settings.

Важно! Istio должен знать о существовании destination, если вы используете внешний API, то зарегистрируйте его через ServiceEntry.

Caution! Istio must be aware of the destination; if you use an external API, register it via ServiceEntry.

Reference

Reference.

Аналог Endpoints + Service из ванильного Kubernetes. Позволяет сообщить Istio о существовании внешнего сервиса или даже переопределить его адрес.

It is similar to Endpoints + Service in vanilla Kubernetes. Informs Istio about the existence of an external service and lets you redefine its address.

Аутентификация

Authentication

Решает задачу «Кто сделал запрос?». Не путать с авторизацией, которая определяет, «разрешить ли аутентифицированному элементу делать что-то или нет».

Answers the question “Who has made the request?” Not to be confused with authorization - the latter determines what the authenticated subject can or cannot do.

По факту есть два метода аутентификации:

• mTLS;
• JWT-токены.

There are two authentication methods:

• mTLS;
• JWT tokens;

Reference

Reference.

Позволяет определить стратегию mTLS в отдельном NS — принимать или нет нешифрованные запросы. Каждый mTLS-запрос автоматически позволяет определить источник и использовать его в правилах авторизации.

Allows you to define the mTLS strategy for an individual NS. Defines how traffic will be tunneled (or not) to the sidecar. Each mTLS request can automatically identify the source and allows you to use it in the authorization rules.

Reference

Reference.

Позволяет настроить JWT-аутентификацию для реквестов.

Allows you to configure JWT authentication for requests.

Авторизация

Authorization

Важно! Авторизация без mTLS- или JWT-аутентификации не будет работать в полной мере. В этом случае будут доступны только простейшие аргументы для составления политик, такие как source.ip и request.headers.

Caution! Authorization without the use of mTLS or JWT authentication will not work fully. In this case, you will be able to use only basic arguments, such as source.ip and request.headers, for defining policies.

Включает и определяет контроль доступа к workload. Поддерживает как ALLOW-, так и DENY-правила. Как только у workload появляется хотя бы одна политика, начинает работать следующий приоритет:

Enables and defines access control to the workload. The AuthorizationPolicy custom resource supports both ALLOW and DENY rules. The following decision-making algorithm is used if at least one policy is defined for a workload:

• Если под реквест есть политика DENY — отклонить запрос.
• Если под реквест нет политики ALLOW — разрешить запрос.
• Если под реквест есть политика ALLOW — разрешить запрос.
• Отклонить запрос.

• Reject the request if there is a DENY policy for it;
• Allow the request if there is no ALLOW policy for it;
• Allow the request if there is ALLOW policy for it;
• Deny the request.

Аргументы для принятия решения об авторизации:

• source:
• namespace;
• principal (читай — идентификатор юзера, полученный после аутентификации);
• IP.
• destination:
• метод (GET, POST…);
• Host;
• порт;
• URI.

The following arguments are used in the decision-making algorithm:

• source:
• namespace
• principal (i.e., the ID the user has received after authentication)
• IP
• destination:
• method (GET, POST, …)
• Host
• port
• URI

Данный ресурс позволяет ограничить количество сервисов, информация о которых будет передана в сайдкар istio-proxy.

This resource limits the number of services for which information is transmitted to the istio-proxy sidecar.