istio.io/content/uk/docs/overview/dataplane-modes/index.md

title	description	weight	keywords	owner	test
Sidecar чи Ambient?	Дізнайтеся про два режими даних Istio та про те, який з них варто використовувати.	30	sidecar ambient	istio/wg-docs-maintainers-english	n/a

Сервісна мережа Istio логічно поділена на панель даних та панель управління.

{{< gloss "панель даних">}}Панель даних{{< /gloss >}} — це набір проксі-серверів, які контролюють усю мережеву комунікацію між мікросервісами. Вони також збирають і звітують про телеметрію всього трафіку мережі.

{{< gloss "панель управління">}}Панель управління{{< /gloss >}} керує та налаштовує проксі-сервери на рівні даних.

Istio підтримує два основних {{< gloss "режим панелі даних" >}}режими панелі даних{{< /gloss >}}:

• Режим sidecar, який розгортає проксі-сервер Envoy разом з кожним Podʼом, який ви запускаєте у вашому кластері, або працює поряд з сервісами, що працюють на віртуальних машинах.
• Режим ambient, який використовує проксі-сервер на рівні 4 для кожного вузла та, за потреби, проксі-сервер Envoy на рівні 7 для функцій на рівні 7.

Ви можете вибрати певні простори імен або навантаження для кожного режиму.

Режим Sidecar

Istio була побудована на патерні sidecar з першого релізу у 2017 році. Режим sidecar добре зрозумілий і ретельно перевірений, але має витрати на ресурси та операційні накладні витрати.

• Кожне застосування, яке ви розгортаєте, має проксі-сервер Envoy {{< gloss "інʼєкція" >}}вставлений{{< /gloss >}} як sidecar.
• Всі проксі-сервери можуть обробляти як рівень 4, так і рівень 7.

Режим Ambient

Запущений у 2022 році, режим ambient був створений для усунення недоліків, про які повідомляли користувачі режиму sidecar. В Istio 1.22, він готовий до використання в операційних середовищах для випадків використання в одному кластері.

• Увесь трафік пропускається через проксі-сервер на рівні 4.
• Застосування можуть вибрати маршрутизацію через проксі-сервер Envoy для отримання функцій рівня 7.

Вибір між Sidecar і Ambient

Користувачі часто розгортають мережу для забезпечення рівня нульової довіри як перший крок, а потім вибірково активують можливості L7 за потреби. Ambient-мережа дозволяє цим користувачам уникнути витрат на обробку L7, коли це не потрібно.

	Sidecar	Ambient
Управління трафіком	Повний набір функцій Istio	Повний набір функцій Istio (потребує використання waypoint)
Безпека	Повний набір функцій Istio	Повний набір функцій Istio: шифрування та авторизація L4 в режимі ambient. Потребує waypoint для авторизації L7.
Спостережуваність	Повний набір функцій Istio	Повний набір функцій Istio: телеметрія L4 в режимі ambient; спостережуваність L7 при використанні waypoint
Розширюваність	Повний набір функцій Istio	За допомогою втулків WebAssembly (вимагає використання waypoint) API EnvoyFilter не підтримується.
Додавання навантажень до мережі	Встановіть мітку на простір імен і перезапустіть усі Podʼи, щоб додати sidecar	Встановіть мітку на простір імен — перезапуск Podʼів не потрібен
Поетапне розгортання	Бінарний: sidecar доданий або ні	Поступове: L4 завжди ввімкнено, L7 може бути додано за допомогою конфігурації
Управління життєвим циклом	Проксі-сервери управляються розробником застосунків	Адміністратор платформи
Використання ресурсів	Неекономно; ресурси ЦП і памʼяті повинні бути виділені для найгіршого випадку використання кожного окремого Podʼа	Проксі-сервери waypoint можуть автоматично масштабуватися як будь-яке інше розгортання Kubernetes. Завантаження з великою кількістю реплік може використовувати один waypoint, на відміну від кожного з них, що має свій sidecar.
Середня вартість ресурсів	Велика	Маленька
Середня затримка (p90/p99)	0.63мс-0.88мс	Ambient: 0.16мс-0.20мс Waypoint: 0.40мс-0.50мс
Кроки обробки L7	2 (source і destination sidecar)	1 (destination waypoint)
Конфігурація в масштабі	Потребує конфігурації області кожного sidecar, щоб зменшити конфігурацію	Працює без спеціальної конфігурації
Підтримка протоколів "server-first"	Потребує конфігурації	Так
Підтримка завдань (Jobs) Kubernetes	Ускладнена тривалим життям sidecar	Прозора
Модель безпеки	Найсильніша: кожен робочий процес має свої власні ключі	Сильна: кожен агент вузла має лише ключі для навантажень на цьому вузлі
Скомпрометований Pod застосунку дає доступ до ключів мережі	Так	Ні
Підтримка	Стабільна, включаючи багатокластерні	Стабільна, тільки одиночний кластер
Платформи, що підтримуються	Kubernetes (будь-який CNI) Віртуальні машини	Kubernetes (будь-який CNI)

Функції рівня 4 проти рівня 7

Навантаження для обробки протоколів на рівні 7 суттєво вищі, ніж для обробки мережевих пакетів на рівні 4. Для конкретного сервісу, якщо ваші вимоги можуть бути виконані на L4, сервісна мережа може бути реалізована за суттєво меншу вартість.

Безпека

	L4	L7
Шифрування	Увесь трафік між Podʼами шифрується за допомогою {{< gloss "Взаємна TLS автентифікація" >}}mTLS{{< /gloss >}}.	Н/Д—службова ідентичність в Istio базується на TLS.
Автентифікація між службами	{{< gloss >}}SPIFFE{{< /gloss >}}, через сертифікати mTLS. Istio видає короткоживучий X.509 сертифікат, який кодує ідентичність службового облікового запису Podʼа.	Н/Д—службова ідентичність в Istio базується на TLS.
Авторизація між службами	Мережева авторизація, плюс політика на основі ідентичності, наприклад: A може приймати вхідні виклики лише від "10.2.0.0/16"; A може викликати B.	Повна політика, наприклад: A може GET /foo на B тільки з дійсними обліковими даними кінцевого користувача, які містять READ область.
Автентифікація кінцевого користувача	Н/Д—не можна застосувати налаштування для кожного користувача.	Локальна автентифікація JWT, підтримка віддаленої автентифікації через OAuth та OIDC потоки.
Авторизація кінцевого користувача	Н/Д—див. вище.	Політики між службами можуть бути розширені для вимоги облікових даних кінцевого користувача з певними областями, видавцями, принципалами, аудиторіями тощо Повний доступ користувача до ресурсу може бути реалізований за допомогою зовнішньої авторизації, що дозволяє політику на кожний запит з рішеннями з зовнішньої служби, наприклад, OPA.

Спостережуваність

	L4	L7
Логування	Основна мережева інформація: мережевий 5-кортеж, байти надіслані/отримані тощо. Див. документацію Envoy.	Повні метадані запиту, окрім основної мережевої інформації.
Трейсинг	На даний момент ні; можливий в майбутньому з HBONE.	Envoy бере участь у розподіленому трейсі. Див. огляд Istio по трейсу.
Метрики	TCP тільки (байти надіслані/отримані, кількість пакетів тощо).	Метрики L7 RED: кількість запитів, кількість помилок, тривалість запиту (затримка).

Управління трафіком

	L4	L7
Балансування навантаження	Тільки на рівні зʼєднання. Див. завдання зміщення TCP трафіку.	На запит, що дозволяє, наприклад, розгортання canary, трафік gRPC тощо. Див. завдання зміщення HTTP трафіку.
Запобіжник (Circuit breaking)	TCP тільки.	HTTP налаштування на додачу до TCP.
Виявлення аномалій	При встановленні/збої зʼєднання.	При успіху/збої запиту.
Обмеження швидкості	Обмеження швидкості на даних зʼєднання L4 тільки, при встановленні зʼєднання, з глобальними та локальними опціями обмеження швидкості.	Обмеження швидкості на метаданих запиту L7, на кожний запит.
Тайм-аути	Тільки встановлення зʼєднання (продовження зʼєднання конфігуроване через налаштування розриву зʼєднання).	На кожний запит.
Повторні спроби	Повторна спроба встановлення зʼєднання	Повторна спроба кожного запиту.
Інʼєкція збоїв	Н/Д—інʼєкція збоїв не може бути налаштована на TCP зʼєднаннях.	Повні помилки рівня застосунка та зʼєднання (тайм-аути, затримки, конкретні коди відповідей).
Моніторинг трафіку	Н/Д—тільки HTTP	Моніторинг запитів на кілька бекендів за відсотком.

Функції, що не підтримуються

Наступні функції доступні в режимі sidecar, але ще не реалізовані в режимі ambient:

• Взаємодія з sidecar-to-waypoint
• Мультикластерні установки
• Підтримка мультимереж
• Підтримка ВМ