Routing

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

Reference.

Reference

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.

Позволяет:

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

Reference.

Reference

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

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

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.

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

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

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

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

Reference.

Reference

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

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

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.

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

There are two authentication methods:

• mTLS;
• JWT tokens;

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

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

Reference.

Reference

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.

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

Reference.

Reference

Allows you to configure JWT authentication for requests.

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

Authorization

Авторизация

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.

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

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:

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

• 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.

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

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

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

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

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

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