在 Istio 网关上使用 url 重写时资源的 HTTP404 [英] HTTP404 for resources when using url rewriting on Istio gateway

问题描述

我正在尝试将服务部署到 AKS 上的特定 url 地址.下面的 yaml 让我访问所需地址的服务，例如 xxxx.europe.cloudapp.azure.com/service-a.这很好用，我设法将整个服务隐藏在所需的 url 下:

apiVersion:networking.istio.io/v1alpha3种类:网关元数据:名称:istio-网关规格:选择器:istio:入口网关服务器:- 港口:数量:80名称:http协议:HTTP主持人:- "*"---api 版本:networking.istio.io/v1alpha3种类:虚拟服务元数据:名称:istio规格:主持人:- "*"网关:- istio-网关网址:- 比赛:- uri:前缀:/service-a改写:里:/路线:- 目的地:主机:service-a.default.svc.cluster.local

但是，当显示欢迎页面时，我只能看到文字.没有加载 css/javascript/image 文件.此页面尝试加载的所有内容仍然具有原始 url 地址，而我的网关配置没有进行任何重写.所以主页请求这个:

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

而不是这个:

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

处理页面上资源和链接的重写 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 编写的，我将寻找某种可维护的内部重写解决方案.

解决方案

重写是因为这部分配置:

 - 匹配:- uri:前缀:/service-a改写:里:/

结果匹配的前缀被替换为 rewrite.uri 属性的值.

示例一:(激活虚拟服务)

原文:http://www.page.com/service-a/icon.jpg^--------^改写:http://www.page.com/icon.jpg

示例 2:(此虚拟服务已激活)

原文:http://www.page.com/service-a/service-a/icon.jpg^--------^重写:http://www.page.com/service-a/icon.jpg

示例3:(这个虚拟服务没有被激活，回退到其他一些虚拟服务上，或者在默认路由上，或者返回404的黑洞)

原文:http://www.page.com/icon.jpg重写:不会发生

对于重写，没有建议也不能，这取决于您的服务.可以在 此处

如果每个子域都有自己的服务，那么这将是一个选择:

apiVersion:networking.istio.io/v1alpha3种类:虚拟服务元数据:名称:istio规格:主持人:- service-a.domain.com"网关:- istio-网关网址:- 比赛:- uri:字首:/改写:uri:/service-a路线:- 目的地:主机:service-a.default.svc.cluster.local

I'm trying to deploy a service to a specific url address on AKS. The following yaml let's me access the service at desired address, like xxxx.europe.cloudapp.azure.com/service-a. This works great, i've managed to hide the entire service under desired 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

However when the welcome page is displayed, i only see text. No css/javascript/image files are loaded. Everything that this page is trying to load still has original url address without any rewriting being made by my gateway configuration. So the home page requests this:

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

instead of this:

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

What is the best way to handle rewriting urls for resources and links on a page? Do i have to manually change the urls on a home page?

EDIT:

To be more clear.

1. Rewriting of the url works as expected, the address is exactly how i want (the entire service is hidden under "xxxx.europe.cloudapp.azure.com/service-a".
2. Once i enter the "xxxx.europe.cloudapp.azure.com/service-a" i see service's welcome page, but without any css/jpegs/js loaded. Also the links visible on the welcome page don't work.
3. for example, "icon.jpg" is not loaded. Page wants to load it from http://xxxx.europe.cloudapp.azure.com/icon.jpg but it's not there anymore. Due to rewriting it's available at http://xxxx.europe.cloudapp.azure.com/service-a/icon.jpg which is as expected.

I kind of expected that the http://xxxx.europe.cloudapp.azure.com/icon.jpg request will be automatically rewritten to http://xxxx.europe.cloudapp.azure.com/service-a/icon.jpg. But obviously i was mistaken. So i wonder how i can handle the links within the service itself in a manageable way - i mean i can modify every possible link within the app, but what if we change the url again (from /service-a to /service-b). The service is written with ASP.NET Core, i will look for some kind of internal rewriting solution that is maintainable.

解决方案

The rewriting is happening because of this part of the config:

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

Which results that the matched prefix is replaced with the value of the rewrite.uri property.

Example 1: (virtual service is activated)

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

Example 2: (this virtual service is activated)

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

Example 3: (this virtual service is not activated, fall back on some other virtual service, or on a default route, or blackhole which returns 404)

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

Rewriting: DOESN'T HAPPEN

For rewriting there are no recommendations and cannot be, it's dependent on your services. Istio's docs for rewriting props can be found here

If every subdomain will have it's own service then this would be an option:

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

这篇关于在 Istio 网关上使用 url 重写时资源的 HTTP404的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！