Міграція з Sidecar на Ambient

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

Цей посібник проведе вас через процес міграції поточного розгортання Istio з sidecar режиму в режим Ambient. Міграція розроблена як поступова та зворотна: робочі навантаження sidecar та ambient можуть співіснувати в одній сервісній мережі під час процесу, дозволяючи вам мігрувати один простір імен за раз.

Якщо у вас є політики L7, міграція без простою наразі неможлива. Під час переходу існує вікно, де політики L7 не застосовуються: старі політики на основі селектора мають бути видалені зі сторони sidecar, а нові еквіваленти на основі waypoint повинні зайняти їхнє місце. Між цими двома операціями правила L7 не застосовуються. Це відома прогалина. Плануйте технічне вікно, якщо безперервне застосування політик L7 обовʼязкове. Спільнота Istio зараз працює над тим, щоб зробити можливою міграцію без простою, будь ласка, перевірте поточні тікети та обговорення щодо цього в нашому slack.

Стратегія міграції

Міграція слідує покроковому підходу:

Встановіть компоненти ambient: Додайте ztunnel та оновіть CNI для підтримки режиму ambient, залишивши всі наявні робочі навантаження sidecar без змін.
Мігруйте політики: Перетворіть ресурси VirtualService на HTTPRoute, оновіть ресурси AuthorizationPolicy для цілеспрямування на waypoints за необхідності, та привʼяжіть ресурси RequestAuthentication та WasmPlugin до waypoints. Пропустіть цей крок, якщо ви використовуєте лише політики L4. Якщо у вас є політики L7, майте на увазі, що під час міграції існує короткий проміжок, коли застосування політик відсутнє, дивіться попередження вище.
Увімкніть режим ambient для простору імен: Позначте простори імен для приєднання до ambient mesh, активуйте waypoints, видаліть інʼєкцію sidecar та перезапустіть podʼи.

Кожен крок є незалежно зворотним. Немає вимоги мігрувати всі простори імен одночасно.

Огляд міграції ресурсів

Наступна таблиця показує, як ресурси режиму sidecar відображаються на їхні ambient еквіваленти:

Ресурс Sidecar	Дія в режимі ambient
`VirtualService`	Мігруйте на `HTTPRoute` (підтримка `VirtualService` в ambient є Alpha)
`DestinationRule` (політики трафіку: пул зʼєднань, виявлення викидів, TLS)	Без змін; waypoints застосовують політики трафіку
`DestinationRule` (підмножини маршрутизації, що використовуються з `HTTPRoute`)	Створіть версійно-специфічні Kubernetes Services як `backendRefs` для `HTTPRoute`
`AuthorizationPolicy` з правилами L4	Без змін; ztunnel застосовує політики L4 безпосередньо
`AuthorizationPolicy` з правилами L7	Привʼяжіть до waypoint за допомогою `targetRefs`
`RequestAuthentication`	Привʼяжіть до waypoint за допомогою `targetRefs`
`EnvoyFilter`	Не підтримується на waypoints
`WasmPlugin`	Привʼяжіть до waypoint за допомогою `targetRefs`
`Gateway` (networking.istio.io/v1)	Змін не потрібно; ресурси Istio Gateway продовжують працювати в режимі ambient. Додайте `istio.io/ingress-use-waypoint` для маршрутизації вхідного трафіку через waypoint.

Чи потрібні вам проксі waypoint?

Вам потрібні waypoint проксі, якщо ваші робочі навантаження використовують будь-що з наступного:

Правила AuthorizationPolicy L7 (відповідність методам HTTP, шляхам або заголовкам).
Маршрутизація трафіку L7 (повторні спроби, інʼєкція помилок, маніпуляція заголовками, розділення трафіку) через HTTPRoute. Якщо ви зараз використовуєте VirtualService для цього, вам потрібно буде мігрувати на HTTPRoute, підтримка VirtualService в ambient є Alpha.
RequestAuthentication (валідація JWT).
Збагачення телеметрії L7.

Якщо ви не впевнені, сторінка міграція політик допоможе вам провести аудит ваших існуючих ресурсів.

Що не підтримується

Наступне є жорсткими блокерами, міграція неможлива, доки вони не будуть вирішені:

Робочі навантаження VM в сервісній мережі. Робочі навантаження на базі VM не можуть приєднатися до ambient mesh.
SPIRE як постачальник сертифікатів. Режим ambient не підтримує інтеграцію SPIRE.
PeerAuthentication з mode: DISABLE. Режим ambient завжди примушує mTLS між робочими навантаженнями mesh. Політики з режимом DISABLE будуть ігноруватися і не можуть бути мігровані.
Конфігурації multicluster primary-remote. Підтримуються лише кластери multiple-primary. Розгортання з одним або кількома remote кластерами не будуть працювати коректно.

Наступне є відомими обмеженнями, що впливають на поведінку під час або після міграції:

Ресурси EnvoyFilter, що спрямовані на waypoints, не підтримуються. Якщо ви покладаєтеся на EnvoyFilter для розширеної конфігурації Envoy на ваших sidecar проксі, ці конфігурації не можуть бути перенесені на waypoints. Цей API може бути підтриманий у майбутньому випуску.
Трафік від робочих навантажень режиму sidecar оминає waypoint проксі. Під час інкрементальної міграції, якщо робоче навантаження режиму sidecar викликає робоче навантаження режиму ambient, яке має waypoint, трафік повністю оминає waypoint. Політики L7 на waypoint не застосовуються для цього трафіку, доки джерело робочого навантаження також не буде мігроване на режим ambient.
Вхідні шлюзи типово оминають waypoints, але можуть бути налаштовані для маршрутизації трафіку через waypoint шляхом додавання мітки istio.io/ingress-use-waypoint до ресурсу Gateway.
Змішування VirtualService та HTTPRoute для одного робочого навантаження не підтримується і призводить до невизначеної поведінки. Мігруйте кожне робоче навантаження повністю на один API перед продовженням.

Наступні кроки

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