Увімкнення режиму ambient

Увімкніть режим ambient по одному простору імен за раз. Це дозволяє вам перевірити кожен простір імен перед переходом до наступного, та відкотити один простір імен, якщо щось піде не так.

Міграція простору імен

Вимоги до порядку дій

Недотримання цієї послідовності може призвести до того, що трафік буде оброблятися ані sidecar, ані ztunnel, що спричинить порушення роботи ваших робочих навантажень.

Крок 1: Активуйте waypoints

Активуйте waypoints, розгорнуті на попередньому кроці, додавши мітку istio.io/use-waypoint.

Для активації waypoint для всього простору імен:

$ kubectl label namespace <namespace> istio.io/use-waypoint=waypoint

Для активації waypoint для конкретного Service:

$ kubectl label service <service-name> -n <namespace> istio.io/use-waypoint=waypoint

Перевірте, що waypoint готовий:

$ kubectl get gateway waypoint -n <namespace>

Стовпець READY має показувати True.

Крок 2: Увімкніть режим ambient для простору імен

Додайте мітку istio.io/dataplane-mode=ambient до простору імен. Це повідомляє CNI втулку, що нові та перезапущені podʼи в цьому просторі імен мають використовувати ztunnel замість (або поряд з) sidecar:

$ kubectl label namespace <namespace> istio.io/dataplane-mode=ambient

Перевірте, що простір імен тепер зарахований у ambient mesh:

$ istioctl ztunnel-config workloads -n istio-system | grep <namespace>

Робочі навантаження в просторі імен зʼявляться з HBONE як їхнім протоколом. Podʼи все ще мають свої sidecars на цьому етапі. Sidecar має пріоритет над ztunnel для podʼів, що мають обидва.

Крок 3: Видаліть інʼєкцію sidecar

Видаліть мітку інʼєкції sidecar з простору імен:

Якщо ви використовуєте стандартну мітку інʼєкції:

$ kubectl label namespace <namespace> istio-injection-

Якщо ви використовуєте мітку ревізії:

$ kubectl label namespace <namespace> istio.io/rev-

Крок 4: Перезапустіть podʼи

Перезапустіть робочі навантаження в просторі імен. При перезапуску podʼи піднімуться без sidecar контейнерів і будуть використовувати ztunnel (та waypoint, якщо налаштовано) замість них:

$ kubectl rollout restart deployment -n <namespace>
$ kubectl rollout status deployment -n <namespace>

Крок 5: Видаліть старі sidecar політики

Видаліть будь-які ресурси AuthorizationPolicy, що використовували робоче навантаження selector з правилами L7, тепер, коли вони були замінені targetRefs-базованими еквівалентами:

$ kubectl delete authorizationpolicy <sidecar-policy-name> -n <namespace>

Також видаліть ресурси VirtualService та DestinationRule, замінені HTTPRoute:

$ kubectl delete virtualservice <name> -n <namespace>
$ kubectl delete destinationrule <name> -n <namespace>

Ресурси AuthorizationPolicy L4, що використовують selector (без правил L7), безпечно зберігати, ztunnel застосовує їх коректно.

Крок 6: Перевірка

Перевірте, що podʼи працюють без sidecar контейнерів:

$ kubectl get pods -n <namespace>

Підтвердьте, що ztunnel керує робочими навантаженнями:

$ istioctl ztunnel-config workloads -n istio-system | grep <namespace>

Якщо ви розгорнули waypoints, перевірте, що правила L7 політик та маршрутизації застосовуються waypoint, протестувавши конкретні поведінки (маршрутизація на основі заголовків, обмеження HTTP методів тощо), що визначають ваші ресурси HTTPRoute та AuthorizationPolicy.

Повторіть для кожного простору імен

Повторіть кроки Міграція простору імен для кожного простору імен, який ви хочете мігрувати. Простори імен, не позначені istio.io/dataplane-mode=ambient, продовжують використовувати свої sidecars і не зазнають впливу.

Відкат

Кожен крок є незалежно зворотним. Використовуйте процедуру відкату, що відповідає тому, як далеко ви пройшли:

Після будь-якого відкату, що включає перезапуск podʼів, перевірте, що podʼи показують 2/2 контейнери (що вказує на повторну інʼєкцію sidecar) та підтвердьте, що трафік тече, перед продовженням.

Зміни в спостережовості після міграції

Після переходу в режим ambient зверніть увагу на такі зміни в телеметрії:

Метрики: У режимі sidecar, метрики надаються з reporter="source" та reporter="destination". У режимі ambient, метрики від ztunnel використовують reporter="source", а метрики від waypoint проксі використовують reporter="waypoint". Оновіть будь-які дашборди або правила алертингу, що покладаються на мітку reporter.

Обʼєднання метрик: У режимі sidecar, проксі-агент підтримує обʼєднання метрик, яке поєднує метрики Istio та застосунку в єдину ціль сканування за допомогою стандартних анотацій prometheus.io. Ця функція недоступна в режимі ambient. Після міграції ви повинні налаштувати Prometheus на сканування компонентів Istio (podʼів ztunnel та waypoint) та ваших додаткових podʼів як окремих цілей. Оновіть будь-які ресурси PodMonitor або ServiceMonitor, що покладалися на єдину обʼєднану кінцеву точку.

Трасування: У режимі sidecar, кожен перехід генерує два відрізки (один від sidecar джерела, один від sidecar призначення). У режимі ambient з waypoints, один відрізок генерується на waypoint. Оновіть SLO на основі трасувань відповідно.

istioctl proxy-status: Ця команда не показує робочі навантаження ztunnel. Використовуйте istioctl ztunnel-config workloads замість цього для перевірки стану ambient проксі.

Для отримання додаткової інформації див.:

• Вирішення проблем з ztunnel
• Вирішення проблем з waypoints