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上的相關問題。