基于路径的路由问题将Traefik用作入口控制器 [英] Path based routing issues Traefik as Ingress Controller

问题描述

我正在解决看起来像配置问题的问题！我正在使用traefik作为kubernetes中的入口控制器，并且我有一个入口来路由一些URL，以将一些前端路由到各种后端.假设我有这样的事情:

I'm running through what looks like a configuration issue! I am using traefik as ingress controller within kubernetes and I have an ingress to route some URLs to route some frontends to various backends. Let's say I have something like this:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
  annotations:
    kubernetes.io/ingress.class: traefik
    traefik.frontend.rule.type: ReplacePathRegex
spec:
  rules:
  - host: foo.io
    http:
      paths:
      - path: /api/authservice/(.*) /$1
        backend:
          serviceName: auth
          servicePort: 8901
      - path: /api/svcXXX/v1/files/cover/(.*) /v1/files/cover/$1
        backend:
          serviceName: files
          servicePort: 8183
      - path: /api/svcXXX/v1/files/image/(.*) /v1/files/image/$1
        backend:
          serviceName: files
          servicePort: 8183

使用邮递员(或任何其他客户端)，如果我在http://foo.io/api/authservice/auth/oauth/token上发布请求，则在访问日志中查找时，似乎将其路由到http://foo.io/api/svcXXX/v1/files/image/(.*) /v1/files/image/$1.我在访问日志中看到了这一点:

Using Postman (or any other client), if I POST a request on http://foo.io/api/authservice/auth/oauth/token, while looking in the access logs, it seems that it is routed to http://foo.io/api/svcXXX/v1/files/image/(.*) /v1/files/image/$1. I'm seeing this in the access logs:

[03/Jul/2018:12:57:17 +0000] "POST /api/authservice/auth/oauth/token HTTP/1.1" 401 102 "-" "PostmanRuntime/7.1.5" 15 "foo.io/api/svcXXX/v1/files/image/(.*) /v1/files/image/$1" 37ms

我做错什么了吗?

推荐答案

ReplacePathRegex是修饰符规则.根据文档:

修改器规则仅修改请求.它们对正在做出的路由决策没有任何影响.

Modifier rules only modify the request. They do not have any impact on routing decisions being made.

以下是现有修改器规则的列表:

Following is the list of existing modifier rules:

• AddPrefix:/products:在将请求转发到后端之前，将路径前缀添加到现有请求路径.
• ReplacePath:/serverless-path:替换路径，并将旧路径添加到X-Replaced-Path标头中.对于映射到AWS Lambda或Google Cloud Functions很有用.
• ReplacePathRegex:^/api/v2/(.*) /api/$1:用正则表达式替换路径，并将旧路径添加到X-Replaced-Path标头中.将正则表达式分隔，并用空格代替.

• AddPrefix: /products: Add path prefix to the existing request path prior to forwarding the request to the backend.
• ReplacePath: /serverless-path: Replaces the path and adds the old path to the X-Replaced-Path header. Useful for mapping to AWS Lambda or Google Cloud Functions.
• ReplacePathRegex: ^/api/v2/(.*) /api/$1: Replaces the path with a regular expression and adds the old path to the X-Replaced-Path header. Separate the regular expression and the replacement by a space.

要路由请求，您应该使用 匹配器 :

To route requests, you should use matchers:

匹配器规则确定是否应将特定请求转发到后端.

Matcher rules determine if a particular request should be forwarded to a backend.

用，(逗号)分隔多个规则值，以启用ANY语义(即，如果有任何规则匹配，则转发请求).不适用于Headers和HeadersRegexp.

Separate multiple rule values by , (comma) in order to enable ANY semantics (i.e., forward a request if any rule matches). Does not work for Headers and HeadersRegexp.

用;分隔多个规则值(分号)以启用所有语义(即，如果所有规则均匹配，则转发请求).

Separate multiple rule values by ; (semicolon) in order to enable ALL semantics (i.e., forward a request if all rules match).

本节说明何时使用各种路径匹配器.

This section explains when to use the various path matchers.

如果后端仅在确切路径上侦听，请使用Path.例如， Path: /products将匹配/products，但不匹配/products/shoes.

Use Path if your backend listens on the exact path only. For instance, Path: /products would match /products but not /products/shoes.

如果您的后端在特定基础上进行侦听，请使用*Prefix*匹配器 路径，但也可以在子路径上提供请求.例如，PathPrefix: /products会匹配/products，但也会匹配/products/shoes和 /products/shirts.由于路径是按原样转发的，因此您的后端是 预期会收听/products.

Use a *Prefix* matcher if your backend listens on a particular base path but also serves requests on sub-paths. For instance, PathPrefix: /products would match /products but also /products/shoes and /products/shirts. Since the path is forwarded as-is, your backend is expected to listen on /products.

如果后端在根路径(/)上侦听，则使用*Strip匹配器，但是 应该可以在特定前缀上路由.例如， PathPrefixStrip: /products将与/products匹配，但也 /products/shoes和/products/shirts.由于路径先被剥离 要转发，您的后端应该在/上侦听.如果你的 后端正在提供资产(例如图像或Javascript文件)，机会 是否必须返回正确构造的相对URL.继续 在该示例中，后端应返回/products/shoes/image.png(并且 不是 Traefik可能无法关联的 具有相同的后端). X-Forwarded-Prefix标头(自 可以查询Traefik 1.3)来动态构建此类URL.

Use a *Strip matcher if your backend listens on the root path (/) but should be routable on a specific prefix. For instance, PathPrefixStrip: /products would match /products but also /products/shoes and /products/shirts. Since the path is stripped prior to forwarding, your backend is expected to listen on /. If your backend is serving assets (e.g., images or Javascript files), chances are it must return properly constructed relative URLs. Continuing on the example, the backend should return /products/shoes/image.png (and not /images.png which Traefik would likely not be able to associate with the same backend). The X-Forwarded-Prefix header (available since Traefik 1.3) can be queried to build such URLs dynamically.

您可以添加一个 主机匹配器.这样，后端的命名空间 除了路径以外，还基于主机.

Instead of distinguishing your backends by path only, you can add a Host matcher to the mix. That way, namespacing of your backends happens on the basis of hosts in addition to paths.

匹配器及其描述的完整列表可在此处

Full list of matchers and their descriptions can be found here

这篇关于基于路径的路由问题将Traefik用作入口控制器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！