Container Service for Kubernetes:NGINX Ingress FAQ

¿Cuáles son los problemas conocidos en versiones anteriores de NGINX Ingress Controller?

Las versiones anteriores presentan los siguientes problemas conocidos. Upgrade to the latest version para garantizar la estabilidad.

• NGINX Ingress (v1.1.0) a veces falla

• Fallo de segmentación del worker (v0.44.0)

• El valor del parámetro defaultBackend de un Ingress sobrescribe las configuraciones globales de NGINX Ingress Controller

  Versiones afectadas: 1.2.1-aliyun.1 y anteriores.

  Solución: actualice NGINX Ingress Controller a la versión 1.5.1-aliyun.1 o posterior.

• Los archivos de configuración temporales nginx-cfg-xx no se eliminan, lo que puede llenar los discos

  Versiones afectadas: 1.10.2-aliyun.1 y anteriores.

  Solución: actualice NGINX Ingress Controller a la versión 1.10.4-aliyun.1 o posterior.

• Errores al cargar archivos mayores a 2 GB

  Causa: el valor de client-body-buffer-size supera el límite de almacenamiento de los enteros de 32 bits.

  Solución: establezca client-body-buffer-size en un valor menor, como 200M.

¿Qué versiones de TLS son compatibles?

Ingress-nginx es compatible con TLS 1.2 y TLS 1.3. Los clientes que usen versiones de TLS anteriores a la 1.2 pueden experimentar errores de handshake.

server-tokens: "false"
ssl-ciphers: '@SECLEVEL=0:ECDHE-ECDSA-AES128-GCM-SHA256:E...
ssl-protocols: TLSv1 TLSv1.1 TLSv1.2 TLSv1.3
ssl-redirect: "false"

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"

¿Se pasan los encabezados de solicitud a los servidores backend?

enable-underscores-in-headers: true

¿Cómo reenvío solicitudes a servidores backend HTTPS?

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: xxxx
  annotations:
    # You must specify HTTPS as the protocol used by the backend server. 
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

¿Cómo paso las direcciones IP de cliente en la capa 7?

De forma predeterminada, ingress-nginx agrega los encabezados X-Forwarded-For y X-Real-IP para pasar las direcciones IP de los clientes. Sin embargo, si el cliente ya incluye estos encabezados, el servidor backend no podrá obtener la dirección IP original del cliente.

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"  

¿Cómo configuro HSTS?

General
  Request URL: http://xxx.bizprodmng xxx .com/crmhome/pageListQuery.json?pageNum=1&pageName=&pageSize=20&platform=
  Request Method: GET
  Status Code: 307 Internal Redirect
Response Headers
  Access-Control-Allow-Credentials: true
  Access-Control-Allow-Origin: http://zhbyak xxx net:3001
  Location: https://bizprodmng xxx .com/crmhome/pageListQuery.json?pageNum=1&pageName=&pageSize=20&platform=
  Non-Authoritative-Reason: HSTS
Request Headers
  Provisional headers are shown
  Referer: http://zhbyak xxx .net:3001/searchPage
  User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Saf...
Query String Parameters
  pageNum: 1
  pageName:

¿Qué reglas de rewrite son compatibles?

¿Qué recursos se actualizan durante una actualización de NGINX Ingress Controller?

Todas las demás configuraciones de recursos se restablecen a sus valores predeterminados. Por ejemplo, el valor predeterminado de replicas en el recurso deployment.apps/nginx-ingress-controller es 2. Si estableció replicas en 5 antes de actualizar NGINX Ingress Controller, este volverá al valor predeterminado de 2 después de la actualización.

¿Cómo cambio de listeners de capa 4 a capa 7?

1. Cree un certificado y anote su identificador (cert-id). Consulte Use a certificate from Certificate Management Service.

2. Cambie los listeners del LoadBalancer que usa el Ingress de capa 4 a capa 7 mediante anotaciones.

   1. Inicie sesión en la consola de ACK. En el panel de navegación izquierdo, haga clic en Clusters.

   2. En la página Clusters, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, haga clic en Network > Services.

   3. En la parte superior de la página Services, establezca Namespace en kube-system. Busque el Service ingress-nginx-lb y haga clic en Edit YAML en la columna Actions.

   4. En el panel Edit YAML, actualice targetPort a 80 para el puerto llamado https (puerto 443).

        - name: https
          port: 443
          protocol: TCP
          targetPort: 80 # Set targetPort to 80 for port 443.

      Agregue lo siguiente al campo annotations y luego haga clic en OK.

      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. Compruebe el resultado.

   1. En la página Services, busque el Service ingress-nginx-lb y haga clic en el icono de la columna Type.

   2. Haga clic en la pestaña Listener. Si tanto HTTP:80 como HTTPS:443 aparecen en la columna Frontend Protocol/Port, los listeners del LoadBalancer cambiaron de capa 4 a capa 7.

¿Cómo uso una instancia SLB existente con ack-ingress-nginx?

1. Inicie sesión en la consola de ACK. En el panel de navegación izquierdo, haga clic en Marketplace > Marketplace.

2. En la pestaña App Catalog, seleccione ack-ingress-nginx o ack-ingress-nginx-v1 según la versión de su clúster:

   • Si su clúster ejecuta Kubernetes 1.20 o una versión anterior, seleccione ack-ingress-nginx.

   • Si su clúster ejecuta una versión de Kubernetes posterior a la 1.20, seleccione ack-ingress-nginx-v1.

3. Despliegue un Ingress controller. Consulte Deploy multiple Ingress controllers for traffic isolation.

   En la página del asistente Parameters:

   1. Elimine todas las anotaciones de la sección controller.service.annotations.

      # enable additional internal slb
      internal:
        enabled: false
        annotations:
          service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
          service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec: "slb.s1.small"

   2. Agregue nuevas anotaciones.

      # Specify the SLB instance that you want to use.
      service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "${YOUR_LOADBALANCER_ID}"
      # Overwrite the listeners.
      service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true"

4. Haga clic en OK para desplegar el Ingress controller.

5. Una vez desplegado el Ingress controller, configure una clase de Ingress. Consulte Deploy multiple Ingress controllers for traffic isolation.

¿Cómo habilito listeners TCP para nginx-ingress-controller?

De forma predeterminada, los Ingress solo reenvían solicitudes HTTP y HTTPS. Configure ingress-nginx para reenviar solicitudes TCP externas en los puertos especificados en el ConfigMap correspondiente.

¿Cómo asocia NGINX Ingress Controller un certificado TLS con una solicitud?

En un recurso Ingress de Kubernetes, el certificado TLS se define en el campo spec.tls, mientras que el nombre de host al que aplica se especifica en el campo spec.rules.host.

NGINX Ingress Controller procesa estas reglas y almacena la asignación entre cada nombre de host y su certificado correspondiente en una tabla Lua interna.

Flujo de la solicitud

1. Cuando un cliente inicia una solicitud HTTPS, incluye el nombre de host solicitado en la extensión Server Name Indication (SNI) del handshake TLS.

2. NGINX Ingress Controller recibe esta solicitud y utiliza la función certificate.call() para buscar el nombre de host SNI en su tabla de asignación de Lua.

3. Si encuentra un certificado coincidente, lo presenta al cliente para completar el handshake TLS.

4. Si no encuentra ningún certificado que coincida con el nombre de host solicitado, el controller presenta un certificado fake predeterminado autofirmado.

A continuación se muestra la configuración de NGINX que implementa esta lógica:

    ## 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 es compatible con Online Certificate Status Protocol (OCSP) Stapling, lo que elimina el contacto directo con la CA para comprobar revocaciones y reduce el tiempo inicial de conexión. Consulte Configure OCSP stapling.

¿Qué hago si ningún certificado coincide con un NGINX Ingress?

Pueden producirse errores de acceso HTTPS si el certificado TLS y su clave privada no coinciden, o si el nombre de dominio del certificado no coincide con el nombre de host que utiliza el cliente. Realice las siguientes operaciones para solucionar este problema:

• Compruebe que el certificado y la clave privada coincidan

  Extraiga el certificado y la clave privada del Secret de Kubernetes y compare sus módulos criptográficos:

  # Replace <YOUR-SECRET-NAME> and <SECRET-NAMESPACE> with your values
  kubectl get secret <YOUR-SECRET-NAME>  -n <SECRET-NAMESPACE> -o jsonpath='{.data.tls\.crt}' | base64 -d > /tmp/tls.crt && \ # Replace with <YOUR-SECRET-NAME> with the Secret you use.
  kubectl get secret <YOUR-SECRET-NAME>  -n <SECRET-NAMESPACE> -o jsonpath='{.data.tls\.key}' | base64 -d > /tmp/tls.key && \
  
  # Calculate and compare the MD5 hash of the moduli for the certificate and the key
  openssl x509 -noout -modulus -in /tmp/tls.crt | openssl md5 && \
  openssl rsa -noout -modulus -in /tmp/tls.key | openssl md5

  Estos comandos extraen el certificado y la clave a /tmp/tls.crt y /tmp/tls.key, respectivamente. Los comandos de openssl calculan el hash MD5 del módulo público de ambos.

  Si los valores de hash no son idénticos, el certificado y la clave privada no coinciden. Actualice el Secret con una key pair válida y coincidente.

• Compruebe que el certificado coincida con el nombre de dominio

  Inspeccione el certificado y revise los nombres de dominio que abarca:

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

  Revise el resultado:

  • Subject: busque el campo Common Name (CN), que tendrá un formato similar a CN = example.com.

  • Subject Alternative Name (SAN): busque las entradas DNS:.

  Si su nombre de host no aparece en CN ni en las entradas SAN, el certificado no es válido para ese dominio. Obtenga un nuevo certificado que cubra los nombres de host correctos.

¿Qué hago si los pods de NGINX fallan en las comprobaciones de estado con tráfico alto?

Contexto

La comprobación de estado del controlador NGINX Ingress accede a la ruta /healthz en el puerto 10246. De esta forma comprueba que el proceso de NGINX funciona correctamente.

Síntoma

Cuando las comprobaciones de estado fallan, los registros indican que no se puede acceder al endpoint healthz:

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

Causa

Con tráfico alto, los procesos worker de NGINX pueden alcanzar casi el 100 % de uso de CPU. Esto deja recursos insuficientes para responder a tiempo a las sondas de comprobación de estado.

Solución

Increase the number of pod replicas for the NGINX Ingress Controller para distribuir el tráfico y reducir la presión de CPU por pod.

¿Qué hago si cert-manager no emite un certificado?

Este problema ocurre cuando Web Application Firewall (WAF) está habilitado. WAF puede interceptar las solicitudes HTTP01 que cert-manager usa para verificar la propiedad del dominio. Como resultado, se impide la emisión del certificado.

Para resolverlo, deshabilite WAF temporalmente y permita que el desafío HTTP-01 se complete con éxito.

¿Por qué NGINX consume mucha memoria con tráfico alto?

¿Qué hago si el controlador NGINX Ingress queda atascado durante una actualización?

Síntoma

Durante un despliegue gradual (actualización canary) del controlador NGINX Ingress, el proceso se detiene en la fase de validación. Es posible que vea el mensaje: Operation is forbidden for task in a failed state.

Causa

Esto sucede cuando el sistema limpia la tarea de actualización del complemento porque superó su periodo de expiración de cuatro días. Para resolverlo, restablezca manualmente el estado de despliegue del complemento.

Nota: Si el complemento ya alcanzó la fase final Released de la actualización, no necesita hacer nada. Solo espere a que la tarea actual agote su tiempo de espera y termine automáticamente.

Procedimiento

Restablezca el Deployment y permita que la actualización continúe.

1. Abra el manifiesto Deployment para editarlo:

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

2. En el editor, busque los siguientes campos dentro de la sección spec y restáurelos a sus valores predeterminados, como se muestra a continuación:

   • spec.minReadySeconds: 0

   • spec.progressDeadlineSeconds: 600

   • spec.strategy.rollingUpdate.maxSurge: 25%

   • spec.strategy.rollingUpdate.maxUnavailable: 25%

   spec:
     minReadySeconds:0
     progressDeadlineSeconds: 600
     replicas: 2
     revisionHistoryLimit: 10
     selector:
       matchLabels:
         app: ingress-nginx
     strategy:
       rollingUpdate:
         maxSurge: 25%
         maxUnavailable: 25%

3. Guarde los cambios y salga del editor.

Resultado esperado

Después de guardar, la actualización del complemento se reanuda automáticamente. Los pods antiguos se reemplazan para completar el despliegue gradual.

¿Por qué dejó de funcionar la codificación de transferencia fragmentada (Transfer-Encoding: chunked) desde la versión 1.10 del controlador?

Síntoma

Su aplicación establece Transfer-Encoding: chunked y los registros del controlador muestran errores relacionados con encabezados duplicados.

Causa

A partir de la versión 1.10, la versión subyacente de NGINX (consulte los registros de actualización de NGINX) aplica una validación más estricta de las respuestas HTTP. Si un backend devuelve varios encabezados Transfer-Encoding: chunked, NGINX ahora considera la respuesta como no válida.

Solución

Asegúrese de que su backend devuelva solo un encabezado Transfer-Encoding: chunked. Consulte el issue #11162 de GitHub.

¿Cómo configuro una lista de permitidos o bloqueados de IP para el control de acceso?

Problema conocido en NGINX Ingress v1.2.1 con defaultBackend

Síntoma

Configurar un defaultBackend en un recurso Ingress puede anular de forma incorrecta la configuración de defaultBackend del servidor predeterminado.

Solución

Se trata de un problema conocido (consulte el issue #8823 de GitHub). Actualice el controlador NGINX Ingress a la versión 1.3 o posterior. Consulte Upgrade the NGINX Ingress Controller.

¿Por qué recibo un error Connection reset by peer al usar curl?

Síntoma

Al usar curl para acceder a un servicio público externo mediante HTTP, recibe el error: curl: (56) Recv failure: Connection reset by peer.

Causa

Esto suele ocurrir cuando una solicitud HTTP en texto plano contiene palabras clave que los intermediarios de red marcan como sensibles. Como consecuencia, la conexión se bloquea o se restablece.

Solución

Configure a TLS certificate for your Ingress route y use HTTPS en todas las comunicaciones para garantizar que el tráfico esté cifrado.

¿Cómo funciona la prioridad de coincidencia de rutas?

Las rutas de expresiones regulares de NGINX se evalúan en el orden en que se definen, y se utiliza la primera coincidencia. Para lograr una coincidencia de rutas más precisa, ingress-nginx primero ordena todas las rutas por longitud en orden descendente. Después, las escribe como bloques location en el archivo nginx.conf.

Consulte Ingress Path Matching.

¿Por qué no se reintentan las solicitudes no idempotentes?

A partir de la versión 1.9.13, NGINX no reintenta las solicitudes no idempotentes (POST, LOCK y PATCH) cuando ocurre un error.

Para restaurar el comportamiento anterior, establezca retry-non-idempotent: "true" en el ConfigMap nginx-configuration.

¿Cómo admito solicitudes con encabezados o cookies de cliente grandes?

Síntoma

Al acceder a su servicio a través de NGINX Ingress, recibe un error 400 Bad Request con el mensaje Request Header Or Cookie Too Large.

Causa

Este error ocurre cuando el tamaño de los encabezados o las cookies de la solicitud del cliente supera los tamaños de búfer predeterminados configurados en Nginx.

Solución

Aumente los tamaños de búfer correspondientes. Los dos parámetros clave son:

• client-header-buffer-size: el tamaño del búfer para los encabezados de solicitud del cliente. El valor predeterminado es 1k.

• large-client-header-buffers: el número máximo y el tamaño de los búferes para leer encabezados de solicitud de cliente grandes. El valor predeterminado es 4 8k.

Modifique estos parámetros al editar el ConfigMap nginx-configuration:kubectl edit cm -n kube-system nginx-configuration

Ejemplo:

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

Después de aplicar los cambios, compruebe que surtieron efecto en la configuración de NGINX. Inspeccione el archivo nginx.conf dentro de uno de los pods del controlador Ingress:kubectl exec <nginx-ingress-pod> -n kube-system -- cat /etc/nginx/nginx.conf

¿Por qué mis rutas Exact o Prefix se siguen tratando como expresiones regulares?

Si alguna regla de Ingress para un host determinado usa la anotación use-regex o rewrite-target, todas las rutas bajo ese mismo host se verán obligadas a usar coincidencias de expresiones regulares sin distinción entre mayúsculas y minúsculas. Esta es la lógica de implementación actual del controlador NGINX Ingress. Consulte la documentación de la comunidad.

¿Por qué el webhook de validación tarda en responder al agregar un Ingress en un clúster con muchos Ingress?

Se trata de un problema de rendimiento conocido en el controlador NGINX Ingress V1.12 y versiones anteriores. El webhook de validación realiza una comprobación completa contra todos los recursos Ingress existentes, lo cual puede ser lento en entornos grandes. Consulte el #11115.

Solución:

• Opción 1: aumentar el tiempo de espera del webhook. Si tolera tiempos de respuesta más largos y no desea usar la validación incremental, aumente el tiempo de espera del webhook de validación. El valor predeterminado es 10s.

  • Acción: edite el objeto validatingwebhookconfigurations llamado ingress-nginx-admission y aumente el valor de timeoutSeconds (máximo 30s).

  • Precaución: este valor se sobrescribirá durante una actualización del complemento.

• Opción 2: habilitar la validación incremental. Modifique el Deployment del controlador NGINX Ingress para agregar el argumento de inicio --disable-full-test=true.

  • Efecto: con este indicador, el webhook solo realizará una validación incremental de la nueva regla de Ingress. Esto mejora de forma significativa la velocidad de validación, pero no detectará conflictos entre distintos recursos Ingress.

Nota sobre el uso de snippets

Problema

Si configura anotaciones server-snippet para el mismo dominio en varios recursos Ingress, es posible que aparezca una advertencia en los registros y que solo se aplique el primer snippet. Esto puede provocar un comportamiento inesperado.

Ejemplo de advertencia en el registro:

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")

Esta advertencia indica que ya se definió un snippet para test.example.com. Por lo tanto, se ignoran las definiciones posteriores de otros recursos Ingress.

¿Por qué no funciona el certificado TLS que configuré en un Secret?

Revise los registros del controlador

Inspeccione los registros del pod del controlador NGINX Ingress para buscar errores relacionados con certificados.

kubectl -n kube-system logs <nginx-ingress-controller-pod-name> | grep "Error getting SSL certificate"

Si ve un error similar al siguiente, significa que hay un problema al cargar el Secret del certificado (donde xxxx es el nombre de su Secret).

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

Este error puede tener tres causas principales:

Causa 1: el Secret no existe

Compruebe que el Secret mencionado en el mensaje del registro exista realmente en el namespace correcto.

Causa 2: el certificado y la clave privada no coinciden

Los valores tls.crt (clave pública) y tls.key (clave privada) almacenados en el Secret deben formar un par coincidente.

• Si intenta crear un Secret tls con un par que no coincide mediante kubectl create secret tls, el comando fallará con el error:error: tls: private key does not match public key

• Para comprobar si un Secret existente tiene claves que no coinciden, ejecute el siguiente script:

  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"

  Este comando compara los módulos del certificado y la clave. Si la clave y el certificado no coinciden, la salida mostrará dos valores hash distintos y el mensaje Certificate and Key do not match. Actualice el Secret con un key pair válido.

  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

Causa 3: una entrada TLS mal configurada en otro Ingress del mismo dominio

Si definió secciones tls para el mismo dominio en varios recursos Ingress, un error en solo una de esas configuraciones puede impedir que el certificado se cargue correctamente. Revise todos los recursos Ingress que hacen referencia al dominio y corrija cualquier error de configuración.

¿Por qué sigo recibiendo alertas de caducidad de certificado después de actualizar mi certificado?

Causa

Las versiones anteriores tienen un bug conocido donde la métrica nginx_ingress_controller_ssl_expire_time_seconds no se actualiza después de renovar el certificado. Esto genera alertas obsoletas de certificate expired.

Solución

Elimine la métrica obsoleta mediante un reinicio gradual de los pods del controlador NGINX Ingress.

Upgrade NGINX Ingress Controller a la versión 1.11.4 o posterior, ya que este problema se resolvió en las versiones más recientes.

¿Cómo encuentro la configuración predeterminada de una versión específica del controlador NGINX Ingress?

Los valores predeterminados de los parámetros de configuración cambian entre las versiones del controlador NGINX Ingress. Por ejemplo, use-gzip estaba habilitado de forma predeterminada en la versión 0.35.0 y anteriores, pero se encuentra deshabilitado de forma predeterminada en la versión 1.11.4.

Para conocer el comportamiento predeterminado de un parámetro específico en una versión determinada, consulte el archivo configmap.md en la rama de la versión correspondiente de la documentación oficial.

Ejemplo: para controller-v1.8.0, use el selector de versión en el lado izquierdo de la página para cambiar a otras versiones.