Перед початком

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

Контекст: як змінюється застосування політик

Розуміння ключових відмінностей між застосуванням політик у режимах sidecar та Ambient допоможе вам зрозуміти кроки міграції та передбачити, де потрібні зміни.

У режимі sidecar:

  • Політики використовують selector для цілеспрямування на podʼи за міткою.
  • Проксі sidecar призначення застосовує як політики L4, так і L7.
  • Один AuthorizationPolicy може відповідати принципалу джерела, методу HTTP, шляху або заголовку і бути застосованим на pod призначення.

У режимі Ambient:

  • Застосування L4 обробляється ztunnel, який запускається на кожному вузлі.
  • Застосування L7 вимагає waypoint проксі, розгорнутого на кожен простір імен або сервіс у режимі Ambient.
  • Політики, що застосовуються waypoint, мають використовувати targetRefs, що вказують на Service або Gateway, а не pod selector. Ви не можете повторно використовувати селектор-базові політики L7 як є.
  • VirtualService є Alpha в режимі ambient. Міграція на HTTPRoute обовʼязкова для стабільного керування трафіком L7.

Вимоги

Якщо у вас ще не встановлені CRDs Gateway API, встановіть їх зараз:

Зверніть увагу, що CRD Kubernetes Gateway API стандартно не встановлені в більшості кластерів Kubernetes, тому переконайтеся, що вони встановлені перед використанням Gateway API:

$ kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \
  kubectl apply --server-side -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.1/experimental-install.yaml

Перевірка вашого поточного встановлення

Виконайте наступні команди для підтвердження стану вашого поточного встановлення sidecar:

$ istioctl version
$ kubectl get pods -n istio-system
$ kubectl get namespaces -l istio-injection=enabled

Перевірте наявність встановлень на основі ревізій (якщо ви використовуєте мітки istio.io/rev замість istio-injection):

$ kubectl get namespaces -l 'istio.io/rev'

Аудит наявних ресурсів

Перелічіть ресурси Istio, що використовуються у вашому кластері:

$ kubectl get virtualservice,destinationrule,authorizationpolicy,requestauthentication,peerauthentication,envoyfilter,wasmplugin -A

Перевірте, які ресурси AuthorizationPolicy містять правила L7. Цим знадобляться waypoint проксі для роботи в режимі ambient:

$ kubectl get authorizationpolicy -A --no-headers | while read ns name rest; do
    if kubectl get authorizationpolicy "$name" -n "$ns" -o yaml | grep -qE "(methods:|paths:|headers:|action: CUSTOM|action: AUDIT)"; then
      echo "$ns/$name"
    fi
  done

Перевірте наявність ресурсів PeerAuthentication з mode: DISABLE, ці несумісні з режимом ambient:

$ kubectl get peerauthentication -A -o yaml | grep -A2 "mtls:"

Будь-який PeerAuthentication з mode: DISABLE має бути видалений або змінений перед міграцією, оскільки режим ambient завжди примушує mTLS між робочими навантаженнями mesh.

Ресурси PeerAuthentication з mode: STRICT або mode: PERMISSIVE не є блокерами, але вони стають зайвими після міграції: режим ambient примушує mTLS через ztunnel незалежно від цих політик. Ви можете безпечно видалити їх після завершення міграції.

Резервне копіювання вашої конфігурації

Перед внесенням будь-яких змін, експортуйте вашу поточну конфігурацію Istio:

$ kubectl get virtualservice,destinationrule,authorizationpolicy,requestauthentication,peerauthentication,gateway,httproute,telemetry -A -o yaml > istio-config-backup.yaml
$ kubectl get namespaces -o yaml > namespace-backup.yaml

Зберігайте ці резервні копії десь безпечно поза кластером.

Налаштування моніторингу трафіку (опціонально)

Використовуйте Kiali або інший інструмент спостережовості для захоплення базового стану ваших поточних патернів трафіку перед внесенням змін. Див. Kiali для інструкцій з налаштування.

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

Перейдіть до Встановлення компонентів ambient.

Чи була ця інформація корисною?
Чи є у вас пропозиції щодо покращення?

Дякуємо за ваш відгук!