在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
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/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/JPEG/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编写的，我将寻找某种可维护的内部重写解决方案.

解决方案

由于配置的这一部分，正在进行重写:

  - 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

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

如果每个子域都将拥有自己的服务，则可以选择以下方式:

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

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屋！