Container Service for Kubernetes：Nginx Ingress FAQ

Nginx Ingress低版本已知缺陷

低版本Nginx Ingress有較多已知缺陷，您可參照下方的連結瞭解對應問題。推薦您將Nginx Ingress Controller升級到最新版本以規避潛在問題，具體操作，請參見升級Nginx Ingress Controller組件。

• Nginx ingress(v1.1.0) crashed

• Worker Segmentation Fault (v0.44.0)

• Ingress中的defaultBackend配置會覆蓋Nginx Ingress全域配置

  影響範圍：v1.2.1-aliyun.1及更早版本。

  解決方案：請升級到v1.5.1-aliyun.1或更新版本。

• nginx-cfg-xx臨時設定檔未被清理刪除，可能導致檔案系統磁碟被寫滿（請升級到v1.10.4+）

  影響範圍：v1.10.2-aliyun.1及更早版本。

  解決方案：請升級到v1.10.4-aliyun.1或更新版本。

• 上傳大檔案超過2G 失敗

  問題原因：client-body-buffer-size值超過了32-bit integer儲存上限。

  解決方案： 將client-body-buffer-size設定為較小值，例如200M。

Ingress支援哪些SSL/TLS版本？

Ingress-Nginx預設支援TLS V1.2及V1.3版本，對於部分舊版本的瀏覽器，或者移動用戶端TLS版本低於1.2時，會導致用戶端在與Ingress-Nginx服務SSL版本協商時報錯。

ssl-ciphers: "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA"
ssl-protocols: "TLSv1 TLSv1.1 TLSv1.2 TLSv1.3"

Nginx Ingress是否支援Lua指令碼？

ACK的Nginx Ingress與社區版本完全相容，配置方式和模組支援也保持了一致，支援通過ConfigMap  server-snippet、http-snippet或使用nginx.ingress.kubernetes.io/configuration-snippet、 nginx.ingress.kubernetes.io/server-snippet註解，注入自訂Lua指令碼或配置片段。

Ingress L7要求標頭預設是透傳的嗎？

enable-underscores-in-headers: true

後端服務為HTTPS服務訪問時是否可以通過Ingress-Nginx轉寄？

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: xxxx
  annotations:
    # 注意這裡：必須指定後端服務為HTTPS服務。
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

Ingress L7透傳用戶端IP嗎？

Ingress-Nginx預設會通過X-Forwarded-For和X-Real-IP來透傳用戶端IP，但是當用戶端主動在要求標頭裡指定了X-Forwarded-For和X-Real-IP時，會導致服務端無法擷取到真實的用戶端IP。

compute-full-forwarded-for: "true"
forwarded-for-header: "X-Forwarded-For"
use-forwarded-headers: "true"

proxy-real-ip-cidr: "0.0.0.0/0,::/0"  

Nginx Ingress Controller組件支援HSTS嗎？

Ingress-Nginx支援哪些Rewrite配置？

在ACK組件管理中升級Nginx Ingress Controller組件時，系統會有哪些更新？

所有其他資源的配置都會被覆蓋成預設配置。以deployment.apps/nginx-ingress-controller資源配置為例，其預設的replicas參數為2。如果您升級Nginx Ingress Controller組件之前的replicas為5，但是通過組件管理升級Ingress後，其replicas將會變為2，和預設配置一致。

如何將Ingress-nginx的監聽由四層改為七層（HTTPS/HTTP）？

1. 建立認證，並記錄cert-id。具體操作，請參見選擇阿里雲簽發認證。

2. 通過Annotation將Ingress所用負載平衡的監聽由四層改為七層。

   1. 登入Container Service管理主控台，在左側導覽列選擇叢集列表。

   2. 在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇網路 > 服務。

   3. 在服務頁面頂部設定命名空間為kube-system，單擊nginx-ingress-lb右側操作列下的YAML 編輯。

   4. 在查看YAML對話方塊中，將ports中443連接埠的targetPort改為80。

        - name: https
          port: 443
          protocol: TCP
          targetPort: 80 # 將443連接埠的targetPort改為80

      在annotations參數下添加以下內容，然後單擊更新。

      service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "http:80,https:443"
      service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cert-id: "${YOUR_CERT_ID}"

3. 結果驗證。

   1. 在服務頁面，單擊ingress-nginx-lb服務類型列的。

   2. 單擊監聽頁簽，可以看到監聽的前端協議/連接埠顯示HTTP:80和HTTPS:443，說明通過Annotation將負載平衡的監聽由四層改為七層成功。

應用市場部署的ack-ingress-nginx如何使用已有SLB？

1. 登入Container Service管理主控台，在左側導覽列選擇市場 > 應用市場。

2. 在應用目錄頁面搜尋ack-ingress-nginx或ack-ingress-nginx-v1。

   • 1.20以下叢集選中ack-ingress-nginx。

   • 1.20以上叢集選中ack-ingress-nginx-v1。

3. 部署Ingress Controller。詳細資料，請參見部署多個Ingress Controller實現流量隔離。

   在部署過程中的參數頁面，刪除舊註解，添加新註解。

   1. 刪除controller.service.annotations下的所有註解。

      

   2. 添加新的註解。

      # 指定SLB
      service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "${YOUR_LOADBALANCER_ID}"
      # 強制覆蓋監聽
      service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true"

      

4. 單擊確定，繼續部署。

5. 部署成功後，配置對應的IngressClass，使用Ingress Controller。詳細資料，請參見部署多個Ingress Controller實現流量隔離。

如何開啟nginx-ingress-controller的TCP協議？

ACK叢集中的Ingress資源預設僅支援路由外部HTTP和HTTPS流量至服務內，通過修改ingress-nginx組件的配置，可以實現來自非HTTP協議的外部TCP流量通過在ConfigMap中定義的TCP連接埠映射，路由至叢集內的服務。

Nginx Ingress認證匹配邏輯是什嗎？

當在Ingress資源配置中指定TLS認證時，認證的配置位於spec.tls欄位下，但實際使用的網域名稱則引用spec.rules.host欄位。而在Nginx Ingress Controller中，Controller會以Lua Table的形式儲存網域名稱與認證的映射關係。

當用戶端向Nginx發起HTTPS請求時，會通過SNI攜帶請求的網域名稱host資訊，Nginx Ingress採用certificate.call()來尋找對應的網域名稱是否存在配置的認證，若不存在則返回fake認證。

相關的Nginx配置如下：

    ## start server _
    server {
        server_name _ ;
        listen 80 default_server reuseport backlog=65535 ;
        listen [::]:80 default_server reuseport backlog=65535 ;
        listen 443 default_server reuseport backlog=65535 ssl http2 ;
        listen [::]:443 default_server reuseport backlog=65535 ssl http2 ;
        set $proxy_upstream_name "-";
        ssl_reject_handshake off;
        ssl_certificate_by_lua_block {
            certificate.call()
        }
   ...
   }
    
    
    ## start server www.example.com
    server {
        server_name www.example.com ;
        listen 80  ;
        listen [::]:80  ;
        listen 443  ssl http2 ;
        listen [::]:443  ssl http2 ;
        set $proxy_upstream_name "-";
        ssl_certificate_by_lua_block {
            certificate.call()
        }
    ...
    }

Ingress Nginx支援OCSP Stapling技術功能，可以改進認證狀態的驗證過程。基於此功能，用戶端無需直接向CA網站查詢認證狀態，從而減少認證驗證時間，提升訪問速度。更多資訊，請參見配置OCSP Stapling。

Nginx Ingress認證為什麼不匹配？

認證與私密金鑰不匹配，或認證的網域名稱與使用者使用的網域名稱不一致時，會產生訪問錯誤。您可通過下方的操作排查問題原因。

• 檢查Secret中儲存的認證與私密金鑰是否匹配：

  kubectl get secret <YOUR-SECRET-NAME>  -n <SECRET-NAMESPACE> -o jsonpath='{.data.tls\.crt}' | base64 -d > /tmp/tls.crt && \ # <YOUR-SECRET-NAME>需要替換為您使用的Secret
  kubectl get secret <YOUR-SECRET-NAME>  -n <SECRET-NAMESPACE> -o jsonpath='{.data.tls\.key}' | base64 -d > /tmp/tls.key && \
  openssl x509 -noout -modulus -in /tmp/tls.crt | openssl md5 && \
  openssl rsa -noout -modulus -in /tmp/tls.key | openssl md5

  上方的命令使用kubectl從認證Secret中提取認證內容，經過base64解碼後，將認證儲存到/tmp/tls.crt，私密金鑰儲存到/tmp/tls.key。然後使用OpenSSL MD5對認證和私密金鑰進行雜湊計算。

  如果認證與私密金鑰的雜湊值不同，則說明認證與私密金鑰不匹配，建議您通過重新設定正確的認證和私密金鑰進行修複。

• 檢查認證是否與網域名稱匹配：

  kubectl get secret  <YOUR-SECRET-NAME>  -n <SECRET-NAMESPACE>  -o jsonpath={.data."tls\.crt"} | base64 -d  | openssl x509  -text -noout

  上方的命令會輸出認證的部分詳細資料。其中的CN（Common Name）欄位會包含認證的網域名稱資訊，形式類似於CN = example.com。如果CN中不包含使用者使用的網域名稱，說明認證的網域名稱與實際網域名稱不匹配，請進行修複。

流量高負載情況下健全狀態檢查失敗怎麼辦？

健全狀態檢查將通過訪問Nginx在10246連接埠上監聽的/healthz路徑，以驗證Nginx的狀態是否健康且服務正常運行。

健全狀態檢查失敗時，預期如下：

I0412 11:01:52.581960       7 healthz.go:261] nginx-ingress-controller check failed: healthz
[-]nginx-ingress-controller failed: the ingress controller is shutting down
2024/04/12 11:01:55 Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
W0412 11:01:55.895683       7 nginx_status.go:171] unexpected error obtaining nginx status info: Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
I0412 11:02:02.582247       7 healthz.go:261] nginx-ingress-controller check failed: healthz
[-]nginx-ingress-controller failed: the ingress controller is shutting down
2024/04/12 11:02:05 Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
W0412 11:02:05.896126       7 nginx_status.go:171] unexpected error obtaining nginx status info: Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
I0412 11:02:12.582687       7 healthz.go:261] nginx-ingress-controller check failed: healthz
[-]nginx-ingress-controller failed: the ingress controller is shutting down
2024/04/12 11:02:15 Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
W0412 11:02:15.895719       7 nginx_status.go:171] unexpected error obtaining nginx status info: Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
I0412 11:02:22.582516       7 healthz.go:261] nginx-ingress-controller check failed: healthz
[-]nginx-ingress-controller failed: the ingress controller is shutting down
2024/04/12 11:02:25 Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
W0412 11:02:25.896955       7 nginx_status.go:171] unexpected error obtaining nginx status info: Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
I0412 11:02:28.983016       7 nginx.go:408] "NGINX process has stopped"
I0412 11:02:28.983033       7 sigterm.go:44] Handled quit, delaying controller exit for 10 seconds
I0412 11:02:32.582587       7 healthz.go:261] nginx-ingress-controller check failed: healthz
[-]nginx-ingress-controller failed: the ingress controller is shutting down
2024/04/12 11:02:35 Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
W0412 11:02:35.895853       7 nginx_status.go:171] unexpected error obtaining nginx status info: Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
I0412 11:02:38.986048       7 sigterm.go:47] "Exiting" code=0

當Nginx背景工作處理序負載過高時，會消耗大量CPU資源，有時甚至導致CPU資源接近100%。這種情況可能引發健全狀態檢查失敗。建議增加Pod副本數量，以便分散負載，確保健全狀態檢查能夠成功執行。

cert-manager不符合預期，導致認證簽發失敗怎麼辦？

如果您使用的認證管理工具Cert-manager未能按預期工作，導致認證簽發失敗，原因可能是啟動了Web應用程式防火牆（WAF）。WAF在開啟狀態下可能會干擾HTTP01請求，妨礙認證的簽發流程。建議關閉WAF，從而消除對認證簽發過程的影響。關閉WAF前，需充分評估其他因素，避免帶來不必要的影響。

Nginx大壓力流量下為什麼佔用大量記憶體？

如果發現Nginx在處理大流量時記憶體佔用異常增高，導致OOM事件，可以進入Pod內部重點檢查Controller進程的記憶體佔用較多，應該是Metrics相關效能指標導致記憶體流失。這個問題為Nginx Ingress Controller v1.6.4的已知問題，推薦您將Nginx Ingress Controller升級至最新版本，配置高負載情境的Nginx Ingress Controller特別注意那些會顯著影響記憶體的指標，比如nginx_ingress_controller_ingress_upstream_latency_seconds。更多詳情，請參見Ingress Controller高壓測試和Prometheus Metric記憶體流失及相關的Metrics PR。

修正Nginx Ingress Controller到期的升級狀態

當Nginx Ingress Controller灰階升級過程中，如果遇到卡在驗證階段的情況，無法繼續操作（出現提示“Operation is forbidden for task in failed state”），這通常是因為組件升級任務由於超出預定的4天有效期間而被系統清除導致的。在這種情況下，您需要手動調整組件的灰階狀態以糾正問題。

如果組件的升級進度已經達到發布階段，那麼無需執行額外操作。等待當前的任務因超過預設的到期時間（4天）而自動終止即可。

操作步驟

完成修改後，組件升級將自動繼續，替換舊版本Pod以完成灰階升級。不過，在控制台的組件管理介面中仍將顯示升級中的狀態，該狀態將在大約兩周后消失恢複正常。

1. 執行以下命令，編輯nginx-ingress-controller的Deployment。

   kubectl edit deploy -n kube-system  nginx-ingress-controller

2. 將以下參數修正回指定值。

   • spec.minReadySeconds: 0

   • spec.progressDeadlineSeconds: 600

   • spec.strategy.rollingUpdate.maxSurge: 25%

   • spec.strategy.rollingUpdate.maxUnavailable: 25%

   

3. 編輯完成後儲存退出。

從控制器v1.10版本起，為什麼分塊傳輸（Transfer-Encoding: chunked）無法正常工作？

如果您的代碼設定了HTTP頭部Transfer-Encoding: chunked，並且控制器的日誌中出現關於重複頭部的錯誤資訊，這可能與Nginx的更新有關，關於更新記錄請參見Nginx的更新日誌。v1.10起的Nginx版本強化了對HTTP響應的校正，導致後端返回多個Transfer-Encoding: chunked頭部時被視為無效響應。因此，需要確保您的後端服務僅返回一個Transfer-Encoding: chunked頭。更多詳情，請參見GitHub Issue #11162。

Nginx Ingress如何配置IP黑白名單存取控制

Nginx Ingress v1.2.1已知問題

在Ingress資源中配置defaultBackend時，可能會覆蓋預設server的defaultBackend設定。更多詳情請參見GitHub Issue #8823。為瞭解決這個問題，建議將Nginx Ingress Controller組件升級至v1.3或更高版本。關於升級組件的操作步驟，請參見升級Nginx Ingress Controller組件。

使用curl命令訪問公網服務時出現串連重設

在使用curl命令通過HTTP協議訪問境外公網服務時，可能會遇到錯誤提示：curl: (56) Recv failure: Connection reset by peer。通常是由於HTTP明文請求中可能包含敏感詞，這些敏感詞導致請求被阻斷或響應被重設。您可以為路由規則配置HTTPS認證，確保使用加密方式進行通訊。

路徑匹配優先順序的邏輯是什嗎？

在 NGINX 中，Regex遵循最初相符策略。為了實現更準確的路徑匹配，ingress-nginx 首先按長度降序排列路徑，然後將其作為位置塊寫入 NGINX conf 下，具體參考： https://kubernetes.github.io/ingress-nginx/user-guide/ingress-path-matching/

為什麼不會重試非等冪請求？

自1.9.13起，NGINX 在發生錯誤時不會重試非等冪請求（POST、LOCK、PATCH）。您可以通過修改配置 ConfigMap nginx-configuration 中的retry-non-idempotent=true恢複以前的行為

如何支援用戶端Header或者Cookie過大的請求？

若用戶端請求Header或者Cookie過大，訪問Nginx Ingress時遇到報錯資訊類似"400 Request Header Or Cookie Too Large /Bad Request"時，您需要調整相關buffer size 配置。具體有如下兩個配置參數：

• client-header-buffer-size：用戶端header buffer大小，預設值為1k。

• large-client-header-buffers：設定用於讀取大型用戶端請求header的緩衝區的最大數量和大小，預設值為4 8k。

您可通過執行kubectl edit cm -n kube-system nginx-configuration編輯ConfigMap並修改這兩個配置參數。例如：

client-header-buffer-size: "16k"
large-client-header-buffers: "4 32k" 

配置完之後，請確認配置在Nginx資料面是否生效。您可通過執行kubectl exec <nginx-ingress-pod> -n kube-system -- cat /etc/nginx/nginx.conf | vim -查看nginx.conf配置，確認是否與ConfigMap中的修改同步。

為什麼我的Ingress下針對特定路徑設定pathType為Exact或Prefix，最終生效的還是正則匹配呢？

如果在給定的host下其中任意一個Ingress規則下有配置use-regex或者rewrite-target註解，該host下的所有路徑將強制執行不區分大小寫正則匹配規則。這個是當前Nginx Ingress Controller的實現邏輯。更多資訊，請參見社區文檔：

在具有很多Ingress規則的叢集下新增Ingress，為什麼validation webhook響應較慢？

這是當前Nginx Ingress Controller版本（v1.12及以下版本）社區實現的已知效能問題，請參見Issue: #11115。

解決辦法：

1. 如果對回應時間可以容忍，並且不接受增量校正。若當前響應已遇到Webhook逾時問題，可以將Webhook配置validatingwebhookconfigurations ingress-nginx-admission的逾時時間調大，預設值為10s，最大不能超過30s。請注意，該參數取值會在組件升級流程中被覆蓋。

2. 修改Nginx ingress controller的deployment啟動參數，增加--disable-full-test=true配置。該配置開啟後，對Ingress規則只做增量校正，可以提高校正速度，但無法校正出Ingress條目之間衝突的情況。

Snippet問題說明

若在多個Ingress下配置了針對同一個網域名稱的多個snippet，會出現類型報錯，會導致配置不符合預期。

W0619 14:58:49.323721       7 controller.go:1314] Server snippet already configured for server "test.example.com", skipping (Ingress "default/test.example.com")
W0619 14:58:49.323727       7 controller.go:1314] Server snippet already configured for server "test.example.com", skipping (Ingress "default/test.example.com")
W0619 14:58:49.323734       7 controller.go:1314] Server snippet already configured for server "test.example.com", skipping (Ingress "default/test.example.com")

通過Secret配置的認證為什麼沒生效？

您可執行kubectl -n kube-system logs <nginx-ingress-controller-pod-name> | grep "Error getting SSL certificate"確認Nginx Ingress Controller Pod日誌。若日誌出現下列內容，請根據下方的步驟排查問題，其中xxxx對應為您的Secret名稱。

Error getting SSL certificate "xxxx": local SSL certificate xxxx tls was not found. Using default certificate

這個日誌資訊出現有三種原因：

1. 這個xxxx對應的Secret不存在。

2. Secret配置的tls.crt和tls.key，即認證的公開金鑰和私密金鑰不匹配。當tls.crt和tls.key不匹配時，若通過命令kubectl create secret tls方式建立tls類型的Secret會提示錯誤資訊，例如：

   root@Aliyun ~/ssl # kubectl create secret tls tls-test-ingress --key example.com.key --cert httpbin.example.com.crt
   error: tls: private key does not match public key

   對於已經建立的Secret，您可通過執行下方命令確認Secret是否有此問題：

   export SECRET_NAME=<Your Secret Name>
   export NAME_SPACE=<Your Secret Namespace>
   diff <(kubectl get secret $SECRET_NAME -n $NAME_SPACE -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -modulus | openssl md5) <(kubectl get secret $SECRET_NAME -n $NAME_SPACE -o jsonpath='{.data.tls\.key}' | base64 -d | openssl rsa -noout -modulus | openssl md5) && echo "Certificate and Key match" || echo "Certificate and Key do not match"

   如果Secret有此不匹配問題，則會輸出類似於下方的內容：

   root@Aliyun ~/ssl # export SECRET_NAME=test
   root@Aliyun ~/ssl # export NAME_SPACE=default
   root@Aliyun ~/ssl # diff <(kubectl get secret $SECRET_NAME -n $NAME_SPACE -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -modulus | openssl md5) <(kubectl get secret $SECRET_NAME -n $NAME_SPACE -o jsonpath='{.data.tls\.key}' | base64 -d | openssl rsa -noout -modulus | openssl md5) && echo "Certificate and Key match" || echo "Certificate and Key do not match"
   1c1
   < (stdin)= 66a309089e87e32d1b6fe361ebf8cd88
   ---
   > (stdin)= 12e15c5fe35585b6fd9920abc8e8706d
   Certificate and Key do not match

3. 對同一個網域名稱在多個Ingress下配置了多個TLS，但其中一個配置有誤。請您檢查TLS配置並修複。

認證到期，然後我更新了認證，為什麼還是收到認證到期的警示資訊？

低版本Nginx Ingress Controller存在相關bug，更新認證後，metrics nginx_ingress_controller_ssl_expire_time_seconds指標可能會存在殘留，需要變換Nginx Ingress Controller。建議更新群組件版本到v1.11.4+ 版本，高版本不存在此問題。關於升級組件的操作步驟，請參見升級Nginx Ingress Controller組件。

如何查看Nginx Ingress Controller不同版本下的預設配置?

Nginx Ingress Controller已經迭代發布了多個版本，同一個參數在不同的版本可能有不同的預設配置，例如use-gzip在低版本v0.35.0及之前的版本中預設開啟，而在v1.11.4版本中預設不開啟。

您可通過查看對應版本分支下configmap.md文檔確認參數的在特定版本中的行為，例如controller-v1.8.0，您可在左側切換版本。