在 Kubernetes 中使用 ingress-nginx 时,是否可以使用路径中捕获的组配置后端?
When using ingress-nginx in Kubernetes, is is possible to configure backends with captured groups from the path?
是否可以在 Kubernetes 中配置一个 nginx
class 入口,后端引用从路径正则表达式捕获的组? ingress-nginx 文档中没有这方面的指示 https://kubernetes.github.io/ingress-nginx/user-guide/ingress-path-matching/
我正在尝试降低入口路径/后端定义的复杂性,例如来自:
...
spec:
rules:
- http:
paths:
- path: /some/backend1/*
backend:
serviceName: backend1
- path: /some/otherbackend/*
backend:
serviceName: otherbackend
像这样:
spec:
rules:
- http:
paths:
- path: /some/([^/]+)/(.+)
backend:
serviceName: # or - possible to ref a capture group here?
在上面的示例中,path
的匹配正则表达式匹配“任何不是 '/' 重复的字符” - 即它将匹配下一个 URI 部分,直到 '/'。然后我想进入 serviceName
.
这可能吗?
编辑
我找到了一种方法来解决这个问题。这不是一个理想的实现方式,因为我将覆盖直接注入到 nginx 配置中。类似这样的功能是否值得作为 nginx 控制器功能请求?
我已经在下面发布了一个解决方案以使其正常工作,即使它存在问题 - 请参阅下面的免责声明/问题。
免责声明:在重现之前,了解直接使用 nginx 配置的一些问题是很有用的 - see this -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: dynamic-routing-ingress
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/configuration-snippet: |
set $proxy_upstream_name "default-$BackendService-8088";
spec:
rules:
- http:
paths:
- path: /dynamci/(?<BackendService>[^/]+)(.+)?
pathType: ImplementationSpecific
backend:
service:
name: backendservice
port:
number: 8088
现在对 /dynamic/x-backend
的请求将被路由到 x-backend
服务(如果存在)。严重警告 - 假设您对服务定义有一致的规范(例如主机/端口/命名空间等)。
上面讨论缺乏健壮性的 link 是 nginx 控制器以相关的方式转换为 nginx 配置,现在你正在接受那个 + 健全性检查(例如由准入验证者),以及将内部控制器命名约定理解为入口定义。如果没有 configuration-snippet
注释,nginx location 块会将 proxy_upstream_name
设置为 default-backendservice-8088
之类的东西,但是配置片段稍后会注入另一个 set $proxy_upstream_name
参数,该参数与从正则表达式捕获组 - 所以你必须知道如何创建反向引用并手动维护它,同时确保覆盖代理参数与你所有服务的定义方式一致(例如,如果你有不同的后端服务 运行 在不同的端口上,这不会解决它,它很快就会变得更加复杂)。
虽然它确实获得了所需的功能,但由于可靠性/稳健性问题,我不确定我是否会继续推进它....
是否可以在 Kubernetes 中配置一个 nginx
class 入口,后端引用从路径正则表达式捕获的组? ingress-nginx 文档中没有这方面的指示 https://kubernetes.github.io/ingress-nginx/user-guide/ingress-path-matching/
我正在尝试降低入口路径/后端定义的复杂性,例如来自:
...
spec:
rules:
- http:
paths:
- path: /some/backend1/*
backend:
serviceName: backend1
- path: /some/otherbackend/*
backend:
serviceName: otherbackend
像这样:
spec:
rules:
- http:
paths:
- path: /some/([^/]+)/(.+)
backend:
serviceName: # or - possible to ref a capture group here?
在上面的示例中,path
的匹配正则表达式匹配“任何不是 '/' 重复的字符” - 即它将匹配下一个 URI 部分,直到 '/'。然后我想进入 serviceName
.
这可能吗?
编辑
我找到了一种方法来解决这个问题。这不是一个理想的实现方式,因为我将覆盖直接注入到 nginx 配置中。类似这样的功能是否值得作为 nginx 控制器功能请求?
我已经在下面发布了一个解决方案以使其正常工作,即使它存在问题 - 请参阅下面的免责声明/问题。
免责声明:在重现之前,了解直接使用 nginx 配置的一些问题是很有用的 - see this -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: dynamic-routing-ingress
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/configuration-snippet: |
set $proxy_upstream_name "default-$BackendService-8088";
spec:
rules:
- http:
paths:
- path: /dynamci/(?<BackendService>[^/]+)(.+)?
pathType: ImplementationSpecific
backend:
service:
name: backendservice
port:
number: 8088
现在对 /dynamic/x-backend
的请求将被路由到 x-backend
服务(如果存在)。严重警告 - 假设您对服务定义有一致的规范(例如主机/端口/命名空间等)。
上面讨论缺乏健壮性的 link 是 nginx 控制器以相关的方式转换为 nginx 配置,现在你正在接受那个 + 健全性检查(例如由准入验证者),以及将内部控制器命名约定理解为入口定义。如果没有 configuration-snippet
注释,nginx location 块会将 proxy_upstream_name
设置为 default-backendservice-8088
之类的东西,但是配置片段稍后会注入另一个 set $proxy_upstream_name
参数,该参数与从正则表达式捕获组 - 所以你必须知道如何创建反向引用并手动维护它,同时确保覆盖代理参数与你所有服务的定义方式一致(例如,如果你有不同的后端服务 运行 在不同的端口上,这不会解决它,它很快就会变得更加复杂)。
虽然它确实获得了所需的功能,但由于可靠性/稳健性问题,我不确定我是否会继续推进它....