nginx.ingress.kubernetes.io/rewrite-target: /$1 在 minikube 注释中到底是什么意思？

Question

在使用 minikube ingress 时，我必须写 nginx.ingress.kubernetes.io/rewrite-target: /$1。我一直在努力理解为什么我们需要这个注解以及如何使用它。

我知道doc 表示以下内容：

在某些情况下，后端服务中暴露的 URL 与 Ingress 规则中指定的路径不同。如果不进行重写，任何请求都将返回 404。将注释 nginx.ingress.kubernetes.io/rewrite-target 设置为服务预期的路径。

但我无法确切了解the exposed URL in the backend service differs from the specified path in the Ingress rule 的确切含义。我无法清楚地理解这个想法。

此外，在尝试使用服务执行入口文件时：

代码 1：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: example-namespace
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  rules:
    - host: myexample.com
      http:
        paths:
          - path: /
            pathType: Prefix 
            backend:
              service:
                name: example-service
                port:
                  number: 80

代码 2：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: example-namespace
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: myexample.com
      http:
        paths:
          - path: /
            pathType: Prefix 
            backend:
              service:
                name: example-service
                port:
                  number: 80

代码 3：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: example-namespace
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  rules:
    - host: myexample.com
      http:
        paths:
          - path: /index
            pathType: Prefix 
            backend:
              service:
                name: example-service
                port:
                  number: 80

上述3个代码sn-ps中的每一对在上面提到的rewrite-target和path方面到底有什么区别？

PS：我是 minikube 的新手，并试图弄清楚事情的确切运作方式。请帮忙。

Answer 1

我不知道新版本的 Ingress 资源或新版本的 Nginx Ingress Controller 是否会发生变化，但我认为它是这样工作的。

假设我想为同一个域下的 2 个不同的 Web 应用程序提供一个 Ingress。

• 应用 A 正在等待/ 下的请求
• 应用 B 正在等待/ 下的请求

因此，两个应用程序都希望它们的请求直接在 root 下，这（乍一看）似乎使它们无法在同一个域中提供服务。

除了重写目标，我可以。我可以在不同的路径下为它们提供服务，但将目标重写为/

• 在myexample.com/aaa/下服务应用A
• 在myexample.com/bbb/下服务应用B

并添加一个重写目标以删除路径的第一部分。这只是重写目标的一个示例，它只是让您能够在与应用程序本身预期的路径不同的路径下为应用程序提供服务。

入口示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: example-namespace
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
    - host: myexample.com
      http:
        paths:
          - path: /aaa(/|$)(.*)
            pathType: Prefix 
            backend:
              service:
                name: app-a
                port:
                  number: 80
          - path: /bbb(/|$)(.*)
            pathType: Prefix 
            backend:
              service:
                name: app-b
                port:
                  number: 80

请注意，虽然这在 Rest API 和类似的东西上效果很好，但它在网页上的效果可能不太好，因为网页可能会尝试以不同的路径加载资源（例如如果它不使用相对路径）。这就是为什么（通常）前端应用程序需要知道它们在域下的哪个路径上提供服务。

---

关于重写目标的语法，我以我上面写的 Ingress 为例。有几点需要考虑：

• 路径
• 路径类型
• 重写目标

让我们从path 和pathType 交互开始。通过路径，我可以定义在哪里提供服务。取决于pathType，它可能只是整个路径的Prefix，Exact 路径，或者它可以取决于入口控制器（又名ImplementationSpecific）。文档中的所有内容都通过一长串示例 (https://kubernetes.io/docs/concepts/services-networking/ingress/#examples) 得到了很好的解释

我几乎可以只用 path 和 pathType 做所有事情，除非我要服务的应用程序期望在与 Ingress 中指定的路径不同的路径上提供服务；这就是rewrite-target 发挥作用的时候了。

与上面的示例一样，我可以使用rewrite-target 在与预期路径不同的路径下为应用程序提供服务，并根据需要组成 url。我还可以使用正则表达式和捕获组（这就是 $1、$2 等等）

例如，如果我写path: /bbb(/|$)(.*)，我的意思是这条路径将匹配/bbb 下的所有内容，无论bbb 后面有没有/。如果我然后写 rewrite-target: /$2 我的意思是请求将被重写以用 / 替换 /bbb 然后获取第二个捕获组（这意味着第二个正则表达式，(.*)）

文档解释得很好，即使它仍然使用旧的 Ingress 资源 (https://kubernetes.github.io/ingress-nginx/examples/rewrite/)