Додавання робочих навантажень до сервісної мережі

4 хвилин(и) перевірка сторінки

У більшості випадків адміністратор кластера розгорне інфраструктуру сервісної мережі Istio. Після успішного розгортання Istio з підтримкою ambient режиму панелі даних, цей режим буде прозоро доступний для всіх застосунків, розгорнутих користувачами в просторах імен, які налаштовані на його використання.

Увімкнення режиму ambient для застосунків в mesh

Щоб додати застосунки або простори імен до сервісної мережі в режимі ambient, додайте мітку istio.io/dataplane-mode=ambient до відповідного ресурсу. Цю мітку можна застосувати до простору імен або окремого podʼа.

Режим ambient може бути безперешкодно увімкнений (або вимкнений) прозоро для podʼів застосунків. На відміну від режиму sidecar панелі даних, нема потреби перезапускати застосунки для їх додавання до мережі, і вони не відображатимуться як такі, що мають додатковий контейнер у своєму podʼі.

Функціональність рівня 4 та рівня 7

Захищений L4 overlay підтримує політики автентифікації та авторизації. Дізнайтеся більше про підтримку політики L4 в режимі ambient. Щоб скористатися функціональністю L7 від Istio, наприклад маршрутизацією трафіку, вам потрібно буде розгорнути проксі waypoint і зареєструвати свої робочі навантаження для його використання.

Ambient та Kubernetes NetworkPolicy

Дивіться ambient та Kubernetes NetworkPolicy.

Комунікація між podʼами в різних режимах панелі даних

Існують кілька варіантів взаємодії між podʼами застосунків, що використовують режим ambient панелі даних, і неконтрольованими (non-ambient) точками доступу (включаючи podʼи застосунків Kubernetes, шлюзи Istio або екземпляри Kubernetes Gateway API). Ця взаємодія забезпечує кілька варіантів безперешкодної інтеграції робочих навантажень ambient та non-ambient у межах однієї мережі Istio, що дозволяє поступове впровадження можливостей ambient відповідно до потреб розгортання та експлуатації вашої сервісної мережі.

Podʼи поза мережею

У вас можуть бути простори імен, які не є частиною сервісної мережі взагалі, ні в режимі sidecar, ні в режимі ambient. У цьому випадку podʼи поза мережею ініціюють трафік безпосередньо до цільових podʼів, минаючи ztunnel вихідного вузла, тоді як ztunnel цільового podʼа забезпечує виконання будь-якої політики L4 для контролю доступу до трафіку.

Наприклад, встановлення політики PeerAuthentication з режимом mTLS, встановленим на STRICT, у просторі імен з увімкненим режимом ambient, призведе до блокування трафіку з-поза мережі.

Podʼи в мережі, що використовують режим sidecar

Istio підтримує взаємодію на напрямку схід-захід між podʼом із sidecar та podʼом, що використовує режим ambient, у межах однієї сервісної мережі. Проксі sidecar знає про використання протоколу HBONE, оскільки ціль була виявлена як ціль HBONE.

Політика PeerAuthentication з режимом mTLS, встановленим на STRICT, дозволить трафік від podʼа з проксі Istio sidecar.

Ingress та egress gateway та podʼи в режимі ambient

Шлюз ingress може працювати в просторі імен, що не є ambient, і надавати сервіси, що працюють у режимі ambient, sidecar або поза мережею. Взаємодія також підтримується між podʼами в режимі ambient та шлюзами egress Istio.

Логіка вибору podʼів для режимів ambient та sidecar

Два режими панелі даних Istio, sidecar та ambient, можуть співіснувати в одному кластері. Важливо переконатися, що той самий pod або простір імен не налаштовані на використання обох режимів одночасно. Однак, якщо це станеться, режим sidecar наразі має перевагу для такого podʼа або простору імен.

Зверніть увагу, що теоретично два podʼи в межах одного простору імен можуть бути налаштовані на використання різних режимів шляхом позначення мітками окремих podʼів, незалежно від мітки простору імен; однак, це не рекомендується. Для більшості поширених випадків використання один режим слід використовувати для всіх pod\sd у межах одного простору імен.

Точна логіка для визначення того, чи налаштований pod на використання режиму ambient, виглядає наступним чином:

Використовується список виключення конфігурації втулка istio-cni, налаштований у cni.values.excludeNamespaces, щоб пропустити простори імен зі списку виключень.
Режим ambient використовується для podʼа, якщо:
- Простір імен або pod мають мітку istio.io/dataplane-mode=ambient
- Pod не має мітки відмови від режиму istio.io/dataplane-mode=none
- Анотація sidecar.istio.io/status відсутня на podʼі

Найпростішим варіантом уникнення конфлікту конфігурації є забезпечення того, щоб для кожного простору імен була мітка для інʼєкції sidecar (istio-injection=enabled) або для режиму ambient (istio.io/dataplane-mode=ambient), але ніколи обидві одночасно.

Довідка по мітках

Наступні мітки керують тим, чи включений ресурс у сервісну мережу в режимі ambient, чи використовується проксі waypoint для забезпечення політики L7 для вашого ресурсу, і як контролюється передача трафіку до waypoint.

Назва	Статус функції	Ресурс	Опис
`istio.io/dataplane-mode`	Бета	`Namespace` або `Pod` (останній має пріоритет)	Додає ваш ресурс до сервісної мережі ambient. Дійсні значення: `ambient` або `none`.
`istio.io/use-waypoint`	Бета	`Namespace`, `Service` або `Pod`	Використання waypoint для трафіку до позначеного міткою ресурсу для забезпечення політики L7. Дійсні значення: `{waypoint-name}` або `none`.
`istio.io/waypoint-for`	Альфа	`Gateway`	Визначає, для яких типів точок доступу waypoint оброблятиме трафік. Дійсні значення: `service`, `workload`, `none` або `all`. Ця мітка є необовʼязковою, стандартне значення — `service`.

Щоб значення мітки istio.io/use-waypoint було ефективним, потрібно переконатися, що waypoint налаштований для тих типів ресурсів, для яких він буде обробляти трафік. Стандартно waypoint приймає трафік для сервісів. Наприклад, коли ви позначаєте міткою pod для використання певного waypoint через мітку istio.io/use-waypoint, waypoint має бути позначений міткою istio.io./waypoint-for зі значенням workload або all.