HTTP404 для ресурсов при использовании перезаписи URL на шлюзе Istio

Я пытаюсь развернуть службу по определенному URL-адресу в AKS. Следующий yaml позволяет мне получить доступ к службе по желаемому адресу, например xxxx.europe.cloudapp.azure.com/service-a. Это отлично работает, мне удалось скрыть всю службу по желаемому URL-адресу:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: istio
spec:
  hosts:
  - "*"
  gateways:
  - istio-gateway
  http:
  - match:
    - uri:
        prefix: /service-a
    rewrite:
      uri: /    
    route:
    - destination:
        host: service-a.default.svc.cluster.local

Однако, когда отображается страница приветствия, я вижу только текст. Файлы css / javascript / изображения не загружаются. Все, что эта страница пытается загрузить, по-прежнему имеет исходный URL-адрес без какой-либо перезаписи, сделанной моей конфигурацией шлюза. Итак, домашняя страница запрашивает это:

http://xxxxx.europe.cloudapp.azure.com/icon.jpg

вместо этого:

http://xxxxx.europe.cloudapp.azure.com/service-a/icon.jpg

Как лучше всего справиться с перезаписью URL-адресов для ресурсов и ссылок на странице? Нужно ли вручную изменять URL-адреса на домашней странице?

РЕДАКТИРОВАТЬ:

Чтобы было понятнее.

  1. Перезапись URL-адреса работает, как ожидалось, адрес именно такой, как я хочу (вся служба скрыта в «xxxx.europe.cloudapp.azure.com/service-a».
  2. Как только я ввожу "xxxx.europe.cloudapp.azure.com/service-a", я вижу страницу приветствия службы, но без загруженных css / jpegs / js. Также не работают ссылки на странице приветствия.
  3. например, «icon.jpg» не загружается. Страница хочет загрузить его с http://xxxx.europe.cloudapp.azure.com/icon.jpg, но его больше нет. Из-за переписывания он доступен по адресу http://xxxx.europe.cloudapp.azure.com/service-a/icon.jpg, что соответствует ожиданиям.

Я как бы ожидал, что http://xxxx.europe.cloudapp.azure.com/icon.jpg будет автоматически переписан на http://xxxx.europe.cloudapp.azure.com/service-a/icon.jpg. Но, очевидно, я ошибался. Поэтому мне интересно, как я могу управлять ссылками внутри самой службы управляемым способом - я имею в виду, что могу изменить каждую возможную ссылку в приложении, но что, если мы снова изменим URL-адрес (с / service-a на / service-b) . Служба написана с использованием ASP.NET Core, я буду искать какое-то внутреннее решение для перезаписи, которое можно было бы обслуживать.


istio url-rewriting
person skyrunner    schedule 03.01.2019    source источник
comment
использует ли базовый корень вариант? (обновил ответ)   -  person Rinor    schedule 03.01.2019

Ответы (1)


arrow_upward
7
arrow_downward

Перезапись происходит из-за этой части конфига:

  - match:
    - uri:
        prefix: /service-a
    rewrite:
      uri: /

В результате соответствующий префикс заменяется значением свойства rewrite.uri.

Пример 1: (виртуальный сервис активирован)

Original: http://www.page.com/service-a/icon.jpg
                             ^--------^
Rewritten: http://www.page.com/icon.jpg

Пример 2: (эта виртуальная служба активирована)

Original: http://www.page.com/service-a/service-a/icon.jpg
                             ^--------^
Rewritten: http://www.page.com/service-a/icon.jpg

Пример 3: (эта виртуальная служба не активирована, используется другая виртуальная служба, маршрут по умолчанию или черная дыра, которая возвращает 404)

Original: http://www.page.com/icon.jpg

Rewriting: DOESN'T HAPPEN

По переписыванию рекомендаций нет и быть не может, это зависит от ваших услуг. Документацию Istio по переписыванию свойств можно найти здесь

Если у каждого поддомена будет собственная служба, это будет вариант:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: istio
spec:
  hosts:
  - "service-a.domain.com"
  gateways:
  - istio-gateway
  http:
  - match:
    - uri:
        prefix: /
    rewrite:
      uri: /service-a
    route:
    - destination:
        host: service-a.default.svc.cluster.local
person Rinor    schedule 03.01.2019
comment
Спасибо за ваш ответ. Я добавил в rewrite.uri специально, чтобы скрыть весь сервис в / service-a sub-route. Но ресурсы / URL-адреса, относящиеся к услуге, не перезаписываются. Поэтому, когда страница запрашивает css, она ничего не знает о перезаписи / service-a, поэтому файл не загружается. Так что мне интересно, как лучше всего это поддерживать. Нужно ли вручную изменять все ссылки / ресурсы в сервисе, чтобы они содержали / service-a часть? Я как бы надеялся, что есть какое-то встроенное решение для перезаписи запроса, исходящего от самой службы. Думаю, мне нужно вручную адаптировать URL-адреса. - person skyrunner; 03.01.2019
comment
@skyrunner, чтобы убедиться, что я вас правильно понял: вы хотите, чтобы запросы xhttp включали префикс (/ service-a), но когда вы запрашиваете статические файлы, вы не хотите их переписывать (т.е. избегать обновления веб-страницы)? Для этого вам просто нужно добавить второй сопоставитель (регулярное выражение), который отправляет в пункт назначения без перезаписи - person Rinor; 03.01.2019
comment
хорошо, я дал дополнительные объяснения в основном сообщении. вы заставили меня понять, что мне нужно выполнить дополнительную перезапись в самой службе, чтобы ресурсы снова заработали. - person skyrunner; 03.01.2019