Ingress-Nginx Annotations 指南：配置要点全方面解读（下）

1.HTTP2 Push Preload

启用在“Link”响应头字段中指定的预加载链接自动转换为推送请求。
示例：

* `nginx.ingress.kubernetes.io/http2-push-preload: "true"`

2.Server Alias

允许在NGINX配置的服务器定义中使用注解nginx.ingress.kubernetes.io/server-alias: "<alias 1>,<alias 2>"定义一个或多个别名。这将创建一个具有相同配置的服务器，但是在server_name指令中添加新的值。
注意：服务器别名不能与现有服务器的主机名冲突。如果冲突，将忽略server-alias注解。如果创建了一个server-alias，然后创建了一个具有相同主机名的新服务器，新服务器的配置将取代别名配置。
有关更多信息，请参阅server_name文档。

3.Server snippet

使用注解nginx.ingress.kubernetes.io/server-snippet，可以在服务器配置块中添加自定义配置。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/server-snippet: |
        set $agentflag 0;

        if ($http_user_agent ~* "(Mobile)" ){
          set $agentflag 1;
        }

        if ( $agentflag = 1 ) {
          return 301 https://m.example.com;
        }

注意：自1.9.0版本开始，默认情况下禁用"server-snippet"注解，必须明确启用，参见allow-snippet-annotations。在多租户集群中启用它可能会很危险，因为它可能导致权限本来有限的人能够获取集群上的所有秘密。有关更多信息，请参阅CVE-2021-25742和github上的相关问题。
注意：每个主机只能使用一次此注解。

4.Client Body Buffer Size

设置每个位置读取客户端请求体的缓冲区大小。如果请求体大于缓冲区，整个体或只是其部分将被写入临时文件。默认情况下，缓冲区大小等于两个内存页。这在x86、其他32位平台和x86-64上是8K。在其他64位平台上通常是16K。这个注解应用于ingress规则中提供的每个位置。
注意：注解的值必须以Nginx能理解的格式给出。
示例：

* `nginx.ingress.kubernetes.io/client-body-buffer-size: "1000"` # 1000 bytes
* `nginx.ingress.kubernetes.io/client-body-buffer-size: 1k` # 1 kilobyte
* `nginx.ingress.kubernetes.io/client-body-buffer-size: 1K` # 1 kilobyte
* `nginx.ingress.kubernetes.io/client-body-buffer-size: 1m` # 1 megabyte
* `nginx.ingress.kubernetes.io/client-body-buffer-size: 1M` # 1 megabyte

5.External Authentication

为了使用提供认证的现有服务，可以在Ingress规则中添加注解nginx.ingress.kubernetes.io/auth-url，以指示应该向哪个URL发送HTTP请求。

nginx.ingress.kubernetes.io/auth-url: "URL to the authentication service"

除此之外，还可以设置以下内容：

• nginx.ingress.kubernetes.io/auth-keepalive:<Connections>：指定与auth-url保持的最大连接数。只有在URL主机部分未使用变量时才生效。默认为0（禁用keepalive）。
  注意：由于Lua子请求的限制，此设置无法与HTTP/2监听器一起使用。应禁用UseHTTP2配置！
• nginx.ingress.kubernetes.io/auth-keepalive-share-vars：是否在当前请求和auth请求之间共享Nginx变量。一个例子是跟踪请求：当设置为"true"时，X-Request-ID HTTP头将对后端和auth请求保持一致。默认为"false"。
• nginx.ingress.kubernetes.io/auth-keepalive-requests:<Requests>：指定可以通过一个keepalive连接服务的最大请求数。默认为1000，仅在auth-keepalive设置为大于0时应用。
• nginx.ingress.kubernetes.io/auth-keepalive-timeout:<Timeout>：指定一个空闲keepalive连接到上游服务器将保持打开的秒数。默认为60，仅在auth-keepalive设置为大于0时应用。
• nginx.ingress.kubernetes.io/auth-method:<Method>：指定要使用的HTTP方法。
• nginx.ingress.kubernetes.io/auth-signin:<SignIn_URL>：指定错误页面的位置。
• nginx.ingress.kubernetes.io/auth-signin-redirect-param:<SignIn_URL>：指定错误页面中应包含失败登录请求的原始URL的URL参数。
• nginx.ingress.kubernetes.io/auth-response-headers:<Response_Header_1, …, Response_Header_n>：指定认证请求完成后传递给后端的头信息。
• nginx.ingress.kubernetes.io/auth-proxy-set-headers:<ConfigMap>：指定一个ConfigMap的名称，该ConfigMap指定要传递给认证服务的头信息。
• nginx.ingress.kubernetes.io/auth-request-redirect:<Request_Redirect_URL>：指定X-Auth-Request-Redirect头的值。
• nginx.ingress.kubernetes.io/auth-cache-key:<Cache_Key>：这个设置启用了auth请求的缓存。指定auth响应的查找键，例如: $remot{e}_{u}ser$http_authorization每个服务器和位置都有自己的键空间。因此，缓存响应只在每个服务器和每个位置的基础上有效。
• nginx.ingress.kubernetes.io/auth-cache-duration:<Cache_duration>：根据它们的响应代码，指定auth响应的缓存时间，例如200 202 30m。详情请参阅proxy_cache_valid。你可以指定多个，用逗号分隔的值：200 202 10m，401 5m。默认为200 202 401 5m。
• nginx.ingress.kubernetes.io/auth-always-set-cookie:<Boolean_Flag>：设置由auth请求返回的cookie。默认情况下，只有当上游以代码200、201、204、206、301、302、303、304、307或308报告时，才会设置cookie。
• nginx.ingress.kubernetes.io/auth-snippet:<Auth_Snippet>：指定与外部认证一起使用的自定义片段，例如:

nginx.ingress.kubernetes.io/auth-url: http://foo.com/external-auth
nginx.ingress.kubernetes.io/auth-snippet: |
    proxy_set_header Foo-Header 42;

注意：nginx.ingress.kubernetes.io/auth-snippet是一个可选的注解。然而，它只能与nginx.ingress.kubernetes.io/auth-url一起使用，如果没有设置nginx.ingress.kubernetes.io/auth-url，它将被忽略。
注意从1.9.0版本开始，"auth-snippet"注解默认是禁用的，必须明确启用，参见allow-snippet-annotations。在多租户集群中启用它可能会很危险，因为这可能导致原本权限有限的人能够获取集群上的所有秘密。更多信息请参考CVE-2021-25742以及github上的相关问题。

6.Global External Authentication

默认情况下，如果在NGINX ConfigMap中设置了global-auth-url，控制器会将所有请求重定向到一个提供身份验证的现有服务。如果你想为特定的ingress禁用这种行为，你可以使用注解nginx.ingress.kubernetes.io/enable-global-auth: “false”。**nginx.ingress.kubernetes.io/enable-global-auth:**表示是否应将GlobalExternalAuth配置应用到这个Ingress规则。默认值设置为"true"。

7.Rate Limiting

这些注解定义了连接和传输率的限制。它们可以用来缓解DDoS攻击。

• nginx.ingress.kubernetes.io/limit-connections: 允许单个IP地址并发连接的数量。超过此限制时返回503错误。
• nginx.ingress.kubernetes.io/limit-rps: 每秒钟接受的来自给定IP的请求数量。突发限制设置为此限制乘以突发倍数， 默认倍数是5。当客户端超过此限制时，返回limit-req-status-code默认值：503。
• nginx.ingress.kubernetes.io/limit-rpm: 每分钟接受的来自给定IP的请求数量。突发限制设置为此限制乘以突发倍数， 默认倍数是5。当客户端超过此限制时，返回limit-req-status-code默认值：503。
• nginx.ingress.kubernetes.io/limit-burst-multiplier: 突发大小的限制速率的倍数。默认的突发倍数是5，此注解覆盖默认的倍数。当客户端超过此限制时，返回limit-req-status-code默认值：503。
• nginx.ingress.kubernetes.io/limit-rate-after: 在进一步限制给定连接的响应传输之后的初始千字节数量。此功能必须与代理缓冲一起使用。
• nginx.ingress.kubernetes.io/limit-rate: 允许发送到给定连接的每秒千字节数量。零值禁用速率限制。此功能必须与代理缓冲一起使用。
• nginx.ingress.kubernetes.io/limit-whitelist: 被排除在速率限制之外的客户端IP源范围。该值是以逗号分隔的CIDR列表。
  如果你在单个Ingress规则中指定了多个注解，限制将按照limit-connections，limit-rpm，limit-rps的顺序应用。
  为了全局配置所有Ingress规则的设置，limit-rate-after和limit-rate值可以在NGINX ConfigMap中设置。在Ingress注解中设置的值将覆盖全局设置。
  客户端IP地址将基于PROXY协议的使用或者当启用use-forwarded-headers时，从X-Forwarded-For头部值设置。

8.Global Rate Limiting

注意：当同时配置（本地）速率限制和全局速率限制时要小心。它们是两种完全不同的速率限制实现。任何一种限制首先超过限制都将拒绝请求。在流量激增的情况下，配置这两者可能是减轻全局速率限制后端负载的好方法。
标准的NGINX速率限制并不在不同的NGINX实例之间共享其计数器。考虑到大多数ingress-nginx部署都是弹性的，副本的数量可能在任何一天都会改变，使用标准的NGINX功能配置适当的速率限制是不可能的。全局速率限制通过使用lua-resty-global-throttle来克服这个问题。lua-resty-global-throttle通过一个中心存储（如memcached）共享其计数器。这显然的缺点是用户必须部署并操作一个memcached实例才能从这个功能中受益。使用这些configmap设置来配置memcached。
以下是关于ingress-nginx集成lua-resty-global-throttle的一些备注：

1. 我们通过缓存超过限制的决定来最小化对memcached的访问。缓存条目的过期时间是lua-resty-global-throttle为我们计算的所需延迟。用于此的Lua共享字典是global_throttle_cache。目前，其大小默认为10M。根据您的需要使用lua-shared-dicts来自定义它。当我们无法缓存超过限制的决定时，我们会记录一个NGINX错误。您可以监视这个错误来决定是否需要增加缓存大小。没有缓存，处理一个请求的成本是两个memcached命令：GET和INCR。有缓存，只有INCR。
2. 记录NGINX变量$global_rate_limit_exceeding的值，以便对被拒绝的请求的比例（值y）、是否使用缓存决定拒绝（值c），或者是否没有被拒绝（默认值n）有一些可见性。您可以使用log-format-upstream将其包含在访问日志中。
3. 在出现错误的情况下，它将记录错误消息并开启失败。
4. 下面的注解为每个ingress创建全局速率限制实例。这意味着，如果在同一个ingress下配置了多个路径，全局速率限制将把所有路径的请求计入同一个计数器。如果需要隔离某个路径，可以将该路径提取到它自己的ingress中。

• nginx.ingress.kubernetes.io/global-rate-limit：配置每个窗口允许的最大请求数量。必需的。
• nginx.ingress.kubernetes.io/global-rate-limit-window：配置应用限制的时间窗口（例如1m）。必需的。
• nginx.ingress.kubernetes.io/global-rate-limit-key：配置用于计数样本的键。默认为$remote_addr您也可以在这里组合多个NGINX变量，如{remote_addr}-${http_x_api_client}，这意味着限制将应用到来自同一个API客户端（由X-API-Client HTTP请求头指示）的同一源IP地址的请求。
• nginx.ingress.kubernetes.io/global-rate-limit-ignored-cidrs：逗号分隔的IP和CIDR列表，用于匹配客户端IP。当有匹配的请求时，不考虑速率限制。

9.Permanent Redirect

这个注解允许返回一个永久重定向（返回码301），而不是将数据发送到上游。例如，nginx.ingress.kubernetes.io/permanent-redirect: https://www.google.com 将会把所有请求重定向到Google。

10.Permanent Redirect Code

这个注解允许你修改用于永久重定向的状态码。例如，nginx.ingress.kubernetes.io/permanent-redirect-code: ‘308’ 将会使你的永久重定向返回308状态码。

11.Temporal Redirect

这个注解允许你返回一个临时重定向（返回码302），而不是将数据发送到上游。例如，nginx.ingress.kubernetes.io/temporal-redirect: https://www.google.com 将会把所有请求以302（暂时移动）的状态码重定向到Google。

12.SSL Passthrough

注解nginx.ingress.kubernetes.io/ssl-passthrough指示控制器将TLS连接直接发送到后端，而不是让NGINX解密通信。请参阅用户指南中的TLS/HTTPS部分。
注意：SSL直通默认是禁用的，需要使用–enable-ssl-passthrough标志启动控制器。
注意：由于SSL直通在OSI模型的第4层（TCP）上工作，而不是在第7层（HTTP），使用SSL直通会使设置在Ingress对象上的所有其他注解失效。

13.Service Upstream

默认情况下，Ingress-Nginx控制器在NGINX上游配置中使用所有端点（Pod IP/端口）的列表。
注解nginx.ingress.kubernetes.io/service-upstream可以禁用该行为，而是在NGINX中使用单一的上游，即服务的Cluster IP和端口。
这对于像零停机时间部署这样的事情可能是可取的。请参阅问题＃257。
如果指定了service-upstream注解，应考虑以下几点：

• 粘性会话将无法工作，因为只支持轮询负载均衡。
• proxy_next_upstream指令将不会有任何效果，这意味着在错误发生时，请求不会被分派到另一个上游。

14.Server-side HTTPS enforcement through redirect

默认情况下，如果为该Ingress启用了TLS，控制器将（308）重定向到HTTPS。如果你想全局禁用此行为，可以在NGINX ConfigMap中使用ssl-redirect: "false"。
如果要为特定的Ingress资源配置此功能，可以在特定资源中使用nginx.ingress.kubernetes.io/ssl-redirect: "false"注解。
当在集群外部使用SSL offloading（例如，AWS ELB）时，即使没有可用的TLS证书，强制重定向到HTTPS可能很有用。这可以通过在特定资源中使用nginx.ingress.kubernetes.io/force-ssl-redirect: "true"注解来实现。
要在使用ssl-redirect的URI中保留尾部斜杠，可以为该特定资源设置nginx.ingress.kubernetes.io/preserve-trailing-slash: "true"注解。
从/到 www 的重定向
在某些情况下，需要从 www.domain.com 重定向到 domain.com，或者反过来。要启用此功能，请使用注解 nginx.ingress.kubernetes.io/from-to-www-redirect: "true"
注意：如果某一点新建了一个Ingress，其主机等于其中一个选项（如 domain.com），则会忽略该注解。
注意：对于 HTTPS 到 HTTPS 的重定向，强制要求在 Ingress 的 TLS 部分位置的 Secret 中定义的 SSL 证书，包含证书公共名称中的两个 FQDN。

15.Denylist source range

您可以通过 nginx.ingress.kubernetes.io/denylist-source-range 注解指定被阻止的客户端 IP 源范围。其值是以逗号分隔的 CIDR 列表，例如 10.0.0.0/24,172.10.0.1。
要为所有 Ingress 规则全局配置此设置，可以在 NGINX ConfigMap 中设置 denylist-source-range 值。
注意：在 Ingress 规则中添加注解会覆盖任何全局限制。

16.Whitelist source range

你可以通过nginx.ingress.kubernetes.io/whitelist-source-range注解来指定允许的客户端IP源范围。其值是一个由CIDRs组成的逗号分隔的列表，例如：10.0.0.0/24,172.10.0.1。如果想全局配置这个设置应用于所有的Ingress规则，你可以在NGINX ConfigMap中设定whitelist-source-range值。
注意：在Ingress规则中添加注解会覆盖任何全局限制。

17.Custom timeouts

通过配置configmap，你可以设置到上游服务器的连接的全局默认超时。在某些场景中，可能需要有不同的值。为了实现这一点，我们提供了允许进行这种自定义的注解：

• nginx.ingress.kubernetes.io/proxy-connect-timeout
• nginx.ingress.kubernetes.io/proxy-send-timeout
• nginx.ingress.kubernetes.io/proxy-read-timeout
• nginx.ingress.kubernetes.io/proxy-next-upstream
• nginx.ingress.kubernetes.io/proxy-next-upstream-timeout
• nginx.ingress.kubernetes.io/proxy-next-upstream-tries
• nginx.ingress.kubernetes.io/proxy-request-buffering

注意：所有的超时值都是无单位的，以秒为单位，例如：nginx.ingress.kubernetes.io/proxy-read-timeout: “120” 设置一个有效的120秒的代理读取超时。

18.Proxy redirect

注解nginx.ingress.kubernetes.io/proxy-redirect-from和nginx.ingress.kubernetes.io/proxy-redirect-to分别会设置NGINX的proxy_redirect指令的第一和第二个参数。可以设置应该在代理服务器响应的Location和Refresh头字段中更改的文本。
在注解nginx.ingress.kubernetes.io/proxy-redirect-from中设置"off"或"default"将禁用nginx.ingress.kubernetes.io/proxy-redirect-to，否则，两个注解必须一起使用。请注意，每个注解必须是没有空格的字符串。
默认情况下，每个注解的值为"off"。

19.Custom max body size

对于NGINX，当请求中的大小超过客户端请求体的最大允许大小时，将向客户端返回413错误。这个大小可以通过参数client_max_body_size进行配置。
要为所有Ingress规则全局配置此设置，可以在NGINX ConfigMap中设置proxy-body-size值。要在Ingress规则中使用自定义值，定义以下注解：

nginx.ingress.kubernetes.io/proxy-body-size: 8m

20.Proxy cookie domain

设置一个文本，该文本应在被代理服务器响应的"Set-Cookie"头字段的域属性中更改。
要为所有Ingress规则全局配置此设置，可以在NGINX ConfigMap中设置proxy-cookie-domain值。

21.Proxy cookie path

设置一个文本，该文本应在被代理服务器响应的"Set-Cookie"头字段的路径属性中更改。
要为所有Ingress规则全局配置此设置，可以在NGINX ConfigMap中设置proxy-cookie-path值。

22.Proxy buffering

启用或禁用代理缓冲proxy_buffering。在默认的NGINX配置中，代理缓冲是禁用的。
要为所有Ingress规则全局配置此设置，可以在NGINX ConfigMap中设置proxy-buffering值。要在Ingress规则中使用自定义值，可以定义这些注解：

nginx.ingress.kubernetes.io/proxy-buffering: "on"

23.Proxy buffers Number

设置proxy_buffers中用于读取从代理服务器接收的响应的第一部分的缓冲区数量。默认情况下，代理缓冲区的数量被设置为4。
要全局配置此设置，请在NGINX ConfigMap中设置proxy-buffers-number。要在Ingress规则中使用自定义值，请定义此注解：

nginx.ingress.kubernetes.io/proxy-buffers-number: "4"

24.Proxy buffer size

设置用于读取从代理服务器接收的响应的第一部分的缓冲区大小proxy_buffer_size。默认情况下，代理缓冲区的大小被设置为"4k"。
要全局配置此设置，请在NGINX ConfigMap中设置proxy-buffer-size。要在Ingress规则中使用自定义值，请定义此注解：

nginx.ingress.kubernetes.io/proxy-buffer-size: "8k"

25.Proxy max temp file size

当启用了来自被代理服务器的响应的缓冲时，如果整个响应无法适应由proxy_buffer_size和proxy_buffers指令设置的缓冲区，响应的一部分可以保存到临时文件中。此指令设置临时文件的最大大小，即设置proxy_max_temp_file_size。一次写入临时文件的数据大小由proxy_temp_file_write_size指令设置。
零值禁用对临时文件的响应缓冲。
要在Ingress规则中使用自定义值，请定义此注解：

nginx.ingress.kubernetes.io/proxy-max-temp-file-size: "1024m"

26.Proxy HTTP version

使用这个注解可以设置Nginx反向代理用于与后端通信的proxy_http_version。默认情况下，这个值被设置为"1.1"。

nginx.ingress.kubernetes.io/proxy-http-version: "1.0"

27.SSL ciphers

指定启用的密码套件。
使用这个注解将在服务器级别设置ssl_ciphers指令。这个配置对主机中的所有路径都有效。

nginx.ingress.kubernetes.io/ssl-ciphers: "ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP"

以下的注解将在服务器级别设置ssl_prefer_server_ciphers指令。这个配置指定在使用SSLv3和TLS协议时，应优先考虑服务器密码套件而不是客户端密码套件。

nginx.ingress.kubernetes.io/ssl-prefer-server-ciphers: "true"

28.Connection proxy header

使用这个注解将覆盖NGINX设置的默认连接头。要在Ingress规则中使用自定义值，请定义以下注解：

nginx.ingress.kubernetes.io/connection-proxy-header: "keep-alive"

29.Enable Access Log

访问日志默认是启用的，但在某些情况下，可能需要为给定的ingress禁用访问日志。要做到这一点，使用以下注解：

nginx.ingress.kubernetes.io/enable-access-log: "false"

30.Enable Rewrite Log

重写日志默认情况下是未启用的。在某些场景中，可能需要启用NGINX重写日志。请注意，重写日志会以通知级别发送到error_log文件。要启用此功能，请使用以下注解：

nginx.ingress.kubernetes.io/enable-rewrite-log: "true"

31.Enable Opentracing

通过ConfigMap，可以全局启用或禁用Opentracing，但有时需要覆盖它，以便为特定的ingress启用或禁用它（例如，关闭对外部健康检查端点的追踪）。

nginx.ingress.kubernetes.io/enable-opentracing: "true"

32.Opentracing Trust Incoming Span

通过ConfigMap，可以全局启用或禁用信任传入的追踪跨度选项，但有时需要覆盖它，以便为特定的ingress启用或禁用它（例如，仅在私有端点上启用）。

nginx.ingress.kubernetes.io/opentracing-trust-incoming-span: "true"

33.Enable Opentelemetry

通过ConfigMap，可以全局启用或禁用Opentelemetry，但有时需要覆盖它，以便为特定的ingress启用或禁用它（例如，关闭对外部健康检查端点的遥测）。

nginx.ingress.kubernetes.io/enable-opentelemetry: "true"

34.Opentelemetry Trust Incoming Span

选项信任传入的追踪跨度可以通过ConfigMap全局启用或禁用，但有时需要覆盖它以便为特定的ingress启用或禁用（例如，只在私有端点上启用）。
nginx.ingress.kubernetes.io/opentelemetry-trust-incoming-spans: “true”

35.X-Forwarded-Prefix Header

要将非标准的X-Forwarded-Prefix头部添加到具有字符串值的上游请求中，可以使用以下注解：

nginx.ingress.kubernetes.io/x-forwarded-prefix: "/path"

36.ModSecurity（安全性）

ModSecurity是一个开源的Web应用防火墙。它可以为特定的ingress位置启用。首先必须在ConfigMap中启用ModSecurity模块。注意，这将为所有路径启用ModSecurity，并且每个路径必须手动禁用。
可以使用以下注解来启用它：

nginx.ingress.kubernetes.io/enable-modsecurity: "true"

ModSecurity将使用推荐的配置在"仅检测"模式下运行。
你可以通过设置以下注解来启用OWASP核心规则集：

nginx.ingress.kubernetes.io/enable-owasp-core-rules: "true"

你可以通过设置以下内容来从nginx传递transactionIDs：

nginx.ingress.kubernetes.io/modsecurity-transaction-id: "$request_id"

你也可以通过一个片段添加你自己的modsecurity规则集：

nginx.ingress.kubernetes.io/modsecurity-snippet: |
SecRuleEngine On
SecDebugLog /tmp/modsec_debug.log

注意：如果你同时使用enable-owasp-core-rules和modsecurity-snippet注解，只有modsecurity-snippet会生效。如果你想要包含OWASP核心规则集或推荐的配置，只需使用include语句：
nginx 0.24.1及以下版本

nginx.ingress.kubernetes.io/modsecurity-snippet: |
Include /etc/nginx/owasp-modsecurity-crs/nginx-modsecurity.conf
Include /etc/nginx/modsecurity/modsecurity.conf

nginx 0.25.0 及以下版本

nginx.ingress.kubernetes.io/modsecurity-snippet: |
Include /etc/nginx/owasp-modsecurity-crs/nginx-modsecurity.conf

注意：自版本1.9.0起，默认禁用"modsecurity-snippet"注解，必须明确启用，请参见allow-snippet-annotations。在多租户集群中启用它可能会很危险，因为这可能导致原本权限有限的人能够获取集群上的所有秘密。关于更多信息，请参见CVE-2021-25742和github上的相关问题。

37.Backend Protocol（后端协议）

使用backend-protocol注解，可以指示NGINX应如何与后端服务进行通信。（在旧版本中替换了secure-backends）
有效值：HTTP，HTTPS，GRPC，GRPCS和FCGI
默认情况下，NGINX使用HTTP。
例如：
nginx.ingress.kubernetes.io/backend-protocol: “HTTPS”

38.Use Regex（正则表达）

注意：当将此注解与类型为cookie的NGINX注解nginx.ingress.kubernetes.io/affinity一起使用时，必须同时设置nginx.ingress.kubernetes.io/session-cookie-path；会话cookie路径不支持正则表达式。
使用nginx.ingress.kubernetes.io/use-regex注解将表示在Ingress上定义的路径是否使用正则表达式。默认值为false。
以下内容将表示正在使用正则表达式路径：
nginx.ingress.kubernetes.io/use-regex: “true”
以下将表示不使用正则表达式路径：
nginx.ingress.kubernetes.io/use-regex: “false”
当此注解设置为true时，不区分大小写的正则表达式位置修饰符将被强制应用于给定主机的所有路径，无论它们在哪个Ingress上定义。
另外，如果在给定主机的任何Ingress上使用了rewrite-target注解，那么不区分大小写的正则表达式位置修饰符将被强制应用于给定主机的所有路径，无论它们在哪个Ingress上定义。
在使用此修饰符之前，请阅读有关Ingress路径匹配的内容。

39.Satisfy

默认情况下，一个请求需要满足所有的认证要求才会被允许。通过使用这个注解，基于配置值，只要满足任何或所有认证要求的请求都将被允许。
nginx.ingress.kubernetes.io/satisfy: “any”

40.Mirror（镜像）

这使得请求可以被镜像到一个镜像后端。镜像后端的响应将被忽略。这个特性对于观察请求在"测试"后端的反应是非常有用的。
通过应用以下设置，可以设定镜像后端：

nginx.ingress.kubernetes.io/mirror-target: https://test.env.com/$request_uri

默认情况下，请求体会被发送到镜像后端，但是可以通过应用以下设置来关闭：

nginx.ingress.kubernetes.io/mirror-request-body: "off"

同样，默认情况下，镜像请求的Host头将会被设置为"mirror-target"注解中uri的host部分相同。你可以通过"mirror-host"注解来覆盖它：

nginx.ingress.kubernetes.io/mirror-target: https://1.2.3.4/$request_uri
nginx.ingress.kubernetes.io/mirror-host: "test.env.com"

注意：镜像指令将应用于Ingress资源内的所有路径。
发送到镜像的请求与原始请求相连。如果你有一个响应慢的镜像后端，那么原始请求会被节流。
更多关于镜像模块的信息，请参见ngx_http_mirror_module

41.Stream snippet

通过使用注解nginx.ingress.kubernetes.io/stream-snippet，你可以添加自定义的流配置。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/stream-snippet: |
      server {
        listen 8000;
        proxy_pass 127.0.0.1:80;
      }

注意自版本1.9.0起，"stream-snippet"注解默认被禁用，需要显式启用，参见 allow-snippet-annotations。在多租户集群中启用它可能会很危险，因为这可能导致原本权限有限的人能够获取集群上的所有秘密信息。更多信息请参见CVE-2021-25742和github上的相关问题。