• Ingress支持哪些SSL/TLS版本？

• Ingress L7請求頭默認是透傳的嗎？

• 后端服務為HTTPS服務訪問時是否可以通過Ingress-Nginx轉發？

• Ingress L7透傳客戶端IP嗎？

• Nginx Ingress Controller組件支持HSTS嗎？

• Ingress-Nginx支持哪些Rewrite配置？

• 配置公網和私網類型的Nginx Ingress Controller

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

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

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

• 如何獲取多個Ingress Controller對應的訪問日志？

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

• Nginx Ingress證書匹配邏輯是什么？

• Nginx Ingress證書為什么不匹配？

• 流量高負載情況下健康檢查失敗怎么辦？

• cert-manager不符合預期，導致證書簽發失敗怎么辦？

• Nginx大壓力流量下為什么占用大量內存？

• 修正Nginx Ingress Controller過期的升級狀態

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

• Nginx Ingress如何配置IP黑白名單訪問控制

• Nginx Ingress v1.2.1已知問題

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"

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. 登錄容器服務管理控制臺，在左側導航欄選擇集群。

   2. 在集群列表頁面，單擊目標集群名稱，然后在左側導航欄，選擇網絡 > 服務。

   3. 在服務頁面頂部設置命名空間為kube-system，單擊ingress-nginx-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. 登錄容器服務管理控制臺，在左側導航欄選擇市場 > 應用市場。

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下對應的證書內容保存為文件（需要BASE64解碼后的內容），然后使用openssl命令進行解碼查看。

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

查看CN（Common Name）字段中是否包含您請求的域名，如果不符，您需要重新生成證書

流量高負載情況下健康檢查失敗怎么辦？

健康檢查將通過訪問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升級至最新版本，關閉Metrics采集，修改啟動參數，添加--enable-metrics=false。特別注意那些會顯著影響內存的指標，比如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組件。