#Обновление waypoint-прокси

Waypoint-прокси развертываются через Kubernetes Gateway API и управляются плоскостью управления Istio. Когда вы обновляете плоскость управления с помощью стратегии InPlace, istiod самостоятельно поэтапно переводит развертывания waypoint на соответствующую версию proxy — вы не обновляете waypoint отдельно, и рабочие нагрузки приложения, которые они обслуживают, продолжают работать на протяжении всего процесса.

Поскольку waypoint всегда следует за активной плоскостью управления, держите его не более чем в одной minor-версии от плоскости управления (та же версия или n-1). Это соответствует политике поддержки Istio, которая требует, чтобы компоненты data plane никогда не опережали плоскость управления; то же правило применяется к плагину Istio CNI и ZTunnel. Стратегия RevisionBased недоступна в ambient mode — см. Updating Alauda Service Mesh in ambient mode, чтобы понять почему.

Предварительные требования

• Вы обновили плоскость управления Istio, как описано в Обновление компонентов ambient mode.
• Приложение Bookinfo развернуто в ambient mode; см. Развертывание приложения Bookinfo в ambient mode.
• В пространстве имен bookinfo существует waypoint-прокси с именем waypoint; см. Waypoint-прокси.

#Проверка версии waypoint-прокси

Убедитесь, что waypoint-прокси повторно подключился к обновленной плоскости управления и работает под новой версией proxy:

istioctl proxy-status | grep waypoint

Пример вывода

waypoint-7b6bcffd55-lj54j.bookinfo     Kubernetes     istiod-85c76b5b66-qgbrv     1.28.6-asm-r3     4 (CDS,LDS,EDS,WDS)

В выводе перечислены pod waypoint, pod istiod, к которому он подключен, версия proxy, под которой он работает, а также типы конфигурации xDS, на которые proxy подписан. Заполненный список подписок подтверждает, что waypoint получает конфигурацию от плоскости управления, а в столбце VERSION теперь должна отображаться обновленная версия.

#Проверка маршрутизации трафика L7

После обновления waypoint-прокси убедитесь, что управление трафиком уровня 7 (L7) по-прежнему работает так, как настроено. Если вы маршрутизируете трафик с помощью ресурсов HTTPRoute, проверьте, что настроенные веса по-прежнему применяются.

Предварительные требования

• Сервисы bookinfo-versions созданы (это часть развертывания Bookinfo в ambient mode).
• Ресурс HTTPRoute разделяет трафик reviews.

Процедура

1. Необязательно: если ресурс HTTPRoute еще не существует, создайте его, чтобы распределять трафик reviews в соотношении 80/20 между reviews-v1 и reviews-v2:

   cat <<EOF | kubectl apply -f -
   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: reviews
     namespace: bookinfo
   spec:
     parentRefs:
       - group: ""
         kind: Service
         name: reviews
         port: 9080
     rules:
       - backendRefs:
           - name: reviews-v1
             port: 9080
             weight: 80
           - name: reviews-v2
             port: 9080
             weight: 20
   EOF

2. Отправьте повторяющиеся запросы через mesh и наблюдайте, какая версия reviews отвечает:

   kubectl exec "$(kubectl get pod -l app=ratings -n bookinfo -o jsonpath='{.items[0].metadata.name}')" \
     -c ratings -n bookinfo \
     -- bash -lc '\
        for i in {0..19}; do \
          curl -sS productpage:9080/productpage | grep -om1 "reviews-v[12]"; \
        done'

   Ответы должны примерно соответствовать заданному распределению — при весах 80/20 примерно шестнадцать из двадцати запросов достигают reviews-v1, а остальные — reviews-v2. Балансировка нагрузки вносит некоторую вариативность в каждом запуске, но при повторных попытках соотношение сходится к заданным весам.

#Проверка политик авторизации L7

Убедитесь, что решения авторизации L7 сохраняются после обновления. В следующем примере используется AuthorizationPolicy с именем productpage-waypoint, которая разрешает только запросы GET, отправленные service account curl в namespace curl, к сервису productpage.

Предварительные требования

• В namespace curl запущен клиент curl, а namespace помечен метками istio-discovery=enabled и istio.io/dataplane-mode=ambient. Шаги развертывания см. в разделе Функции уровня 7 в ambient mode.

Процедура

1. Необязательно: если ресурс AuthorizationPolicy еще не существует, создайте его:

   cat <<EOF | kubectl apply -f -
   apiVersion: security.istio.io/v1
   kind: AuthorizationPolicy
   metadata:
     name: productpage-waypoint
     namespace: bookinfo
   spec:
     targetRefs:
       - kind: Service
         group: ""
         name: productpage
     action: ALLOW
     rules:
       - from:
           - source:
               principals:
                 - cluster.local/ns/curl/sa/curl
         to:
           - operation:
               methods: ["GET"]
   EOF
   1. Principal должен соответствовать namespace и service account вашей клиентской рабочей нагрузки. В этом примере используется service account curl в namespace curl.

2. Убедитесь, что запрос GET от разрешенного клиента завершается успешно с ответом HTTP 200:

   kubectl -n curl exec deploy/curl -- sh -c '\
     curl -s -o /dev/null -w "HTTP %{http_code}\n" \
       -X GET \
       http://productpage.bookinfo.svc.cluster.local:9080/productpage'

   Ожидаемый вывод

   HTTP 200

3. Убедитесь, что рабочая нагрузка вне списка разрешений, например pod ratings, по-прежнему отклоняется:

   kubectl exec "$(kubectl get pod -l app=ratings -n bookinfo \
     -o jsonpath='{.items[0].metadata.name}')" \
     -c ratings -n bookinfo \
     -- curl -X GET -sS productpage:9080/productpage

   Ожидаемый вывод

   RBAC: access denied

   Отказ подтверждает, что обновленный waypoint-прокси по-прежнему применяет правила авторизации L7: service account ratings не указан в политике, тогда как клиент curl соответствует и principal, и операции GET.

Очистка ресурсов проверки

Если вы создали ресурсы маршрутизации и авторизации только для этой проверки, удалите их после завершения:

kubectl delete -n bookinfo httproute reviews
kubectl delete -n bookinfo authorizationpolicy productpage-waypoint