Microservices Engine:FAQ about cloud-native gateways

¿Los gateways nativos de la nube de MSE son compatibles con IPv6?

Sí. La entrada de tráfico de un gateway es una instancia de Classic Load Balancer (CLB) o Network Load Balancer (NLB). En la página Overview, haga clic en la pestaña Gateway Ingress y asocie una instancia de CLB o NLB que tenga IPv6 habilitado.

¿Los gateways nativos de la nube admiten el encabezado de solicitud x-real-ip?

No, no admiten este encabezado de forma predeterminada. El encabezado x-real-ip es específico de Nginx. Para utilizarlo, debe habilitar el plugin http-real-ip del gateway. Este plugin extrae la dirección IP del cliente según su configuración y la escribe en el encabezado de solicitud x-real-ip.

¿Los gateways nativos de la nube admiten el encabezado de solicitud x-forwarded-for?

Sí. Si una solicitud original contiene el encabezado x-forwarded-for, el gateway agrega la dirección IP del salto anterior al final del encabezado. Si la solicitud original no contiene el encabezado x-forwarded-for, el gateway añade el encabezado e incluye la dirección IP del salto anterior.

¿Qué debo hacer si aparece el mensaje "upstream connect error or disconnect/reset header" cuando el gateway nativo de la nube reenvía una solicitud?

Este problema ocurre porque el security group del servicio backend no permite que el gateway acceda al puerto del servicio. En la página Overview de la instancia del gateway, haga clic en la pestaña Security Group Authorization. Luego, haga clic en Authorize Security Group para agregar una regla de security group. El gateway reenvía las solicitudes directamente a la dirección IP del pod del clúster ACK. Debe abrir el puerto que utiliza el pod en la autorización del security group.

¿Cómo utilizo un encabezado para coincidir con un nombre de dominio en un gateway nativo de la nube?

Al crear una ruta, puede agregar una regla de coincidencia de encabezado de solicitud. Para el nombre del encabezado, introduzca :authority. Para el valor del encabezado, introduzca el nombre de dominio específico.

¿Qué debo hacer si no puedo ver los registros del plugin del gateway nativo de la nube?

Este problema puede deberse a las siguientes razones:

• Los registros no se imprimen porque el nivel de registro actual está establecido en Trace o Debug. De forma predeterminada, el plugin solo imprime registros en el nivel Info o superior.

• El plugin no se inició como se esperaba debido a un problema de compilación. En este caso, borre la instrucción de búsqueda de registros predeterminada para ver los registros de error generados durante el inicio del plugin. Compile el código del plugin siguiendo las instrucciones de la documentación de desarrollo de plugins. A continuación, depure el plugin localmente mediante el modo docker compose para validarlo. Después de la validación, puede cargar el plugin en el gateway nativo de la nube.

¿Qué debo hacer si se reporta un error porque el cuerpo de la solicitud es demasiado grande?

Este problema ocurre porque el búfer de conexión del gateway es demasiado pequeño. Puede aumentar el tamaño del búfer:

• Si el protocolo es HTTP/1.x, ajuste el parámetro DownstreamConnectionBufferLimits en la consola.

• Si el protocolo es HTTP/2, ajuste los parámetros DownstreamConnectionBufferLimits y InitialStreamWindowSize en la consola.

¿Cuáles son los límites para agregar un origen de servicio a un gateway nativo de la nube?

• Una sola instancia de gateway puede asociarse con un máximo de tres servicios de contenedores ACK.

• Una sola instancia de gateway puede asociarse con un máximo de tres instancias de Nacos.

¿Por qué no puedo seleccionar una instancia existente de Nacos o ACK al agregar un origen de servicio a mi gateway nativo de la nube?

Los gateways nativos de la nube solo pueden agregar instancias de Nacos o ACK que se encuentren en la misma VPC. No es posible agregar orígenes de servicio entre diferentes VPC.

¿Los gateways nativos de la nube admiten certificados HTTPS personalizados?

Los gateways nativos de la nube no alojan certificados; los obtienen de Alibaba Cloud SSL Certificate Service. Puede cargar su propio certificado en la consola de SSL Certificate Service y luego configurarlo para el nombre de dominio del gateway.

¿Los cambios de parámetros en la consola del gateway nativo de la nube afectan el tráfico existente?

• Después de modificar el parámetro XffTrustedNum, debe reiniciar el gateway para que el cambio surta efecto.

• Después de modificar el parámetro UpstreamIdleTimeout, la conexión upstream se cierra y luego se restablece.

• Después de modificar el parámetro DownstreamIdleTime, la conexión downstream se cierra y luego se restablece.

¿Qué debo hacer si el estado de la comprobación de salud del puerto 443 en la instancia CLB es anómalo?

El estado de la comprobación de salud del puerto 443 es anómalo porque el gateway no escucha en este puerto si no hay ningún nombre de dominio HTTPS configurado. Para resolverlo, debe configurar un nombre de dominio HTTPS en el gateway. Para obtener más información, consulte Create a domain name. Si utiliza un Ingress, consulte K8s Ingress.

¿Qué debo hacer si el estado de la comprobación de salud de un servicio es anómalo después de crear el servicio en el gateway nativo de la nube?

Para que un gateway reenvíe solicitudes a un servicio backend, debe poder conectarse a dicho servicio a través de la red. Si el estado de la comprobación de salud de un servicio es anómalo, la causa suele ser una de las siguientes:

• Para un servicio privado en una VPC, compruebe si el security group del servicio backend está configurado para permitir que el gateway acceda al puerto correspondiente. Para obtener más información, consulte Set security group rules.

• Para un servicio en Internet, compruebe si la VPC tiene acceso a Internet. Puede utilizar la función SNAT de un NAT Gateway de Internet para acceder a Internet. Para obtener más información, consulte Use the SNAT feature of an Internet NAT gateway to access the Internet.

• Para una comprobación de salud HTTP, asegúrese de que la ruta de solicitud y el nombre de dominio de solicitud estén configurados correctamente.

• Para una comprobación de salud HTTP, si se debe acceder a la interfaz de comprobación de salud del servicio backend mediante HTTPS, establezca el modo en One-way TLS en la Policy Configuration del servicio.

• Para una comprobación de salud HTTP, si el problema persiste después de realizar los pasos anteriores, es posible que el intervalo de comprobación de salud coincida con el tiempo de keep-alive de la conexión del servicio backend. Intente aumentar el intervalo de comprobación de salud.

¿Cómo identifico la causa de un error de solicitud?

• Compruebe si el encabezado de respuesta contiene el encabezado x-envoy-upstream-service-time. Si la respuesta contiene el encabezado x-envoy-upstream-service-time, significa que el gateway ha reenviado la solicitud al servicio backend para su procesamiento. En este caso, es probable que los errores posteriores de la solicitud sean causados por la lógica del servicio backend.

• Compruebe si el campo upstream_service_time en el registro de acceso del gateway está vacío. Si el campo upstream_service_time en el registro de acceso no está vacío, significa que el gateway ha reenviado la solicitud al servicio backend para su procesamiento. En este caso, es probable que los errores posteriores de la solicitud sean causados por la lógica del servicio backend.

¿Qué debo hacer si un certificado HTTPS no surte efecto después de actualizarlo en un gateway nativo de la nube?

Este problema suele ocurrir porque también hay un certificado HTTPS configurado en un nodo upstream, como una instancia de CLB, DCDN, WAF o Anti-DDoS Pro y Anti-DDoS Premium. Compruebe si el certificado HTTPS del nodo upstream también se actualizó. La práctica recomendada es configurar el certificado HTTPS en un solo lugar. Si DCDN o WAF está conectado upstream del gateway, puede configurar HTTPS solo en DCDN o WAF y usar HTTP para el gateway backend.

¿Qué debo hacer si los cambios en la configuración de parámetros del gateway nativo de la nube no surten efecto?

Este problema suele ocurrir cuando se utiliza un MSE Ingress. MseIngressConfig contiene elementos de configuración relacionados. El MSE Ingress sincroniza automáticamente los elementos de configuración de MseIngressConfig con la consola del gateway MSE. Si modifica los elementos de configuración en la consola, es posible que las modificaciones se sobrescriban con la información sincronizada desde el MSE Ingress. Se recomienda modificar los elementos de configuración únicamente en el MSE Ingress.

¿Cómo se ordenan las prioridades de enrutamiento de un gateway nativo de la nube?

El orden de las configuraciones de ruta en la página Route Settings de la instancia del gateway determina la prioridad de coincidencia de rutas. La lista se ordena en forma descendente según la prioridad. La prioridad de coincidencia depende del nombre de dominio y de la regla de enrutamiento. En cuanto a los nombres de dominio, un nombre de dominio de coincidencia exacta tiene mayor prioridad que un nombre de dominio comodín. Por ejemplo, test.example.com tiene mayor prioridad que *.example.com. Para reglas de enrutamiento con el mismo nombre de dominio, la prioridad de ruta es coincidencia exacta > coincidencia de prefijo > coincidencia de expresión regular. Para reglas de enrutamiento con el mismo nombre de dominio y ruta, la prioridad es más condiciones de coincidencia > menos condiciones de coincidencia. Las condiciones de coincidencia incluyen parámetros Header y Query.

¿Por qué fallan las solicitudes HTTPS cuando el gateway nativo de la nube está conectado a DCDN?

Este problema suele ocurrir porque DCDN no incluye un SNI cuando envía solicitudes de recuperación de origen al gateway. Puede establecer el SNI de origen en la configuración de recuperación de origen de DCDN.

¿Por qué fallan las solicitudes HTTPS cuando el gateway nativo de la nube está conectado a WAF?

Este problema suele ocurrir porque WAF no incluye un SNI cuando envía solicitudes de recuperación de origen al gateway. Si utiliza el modo de registro CNAME para agregar un nombre de dominio a WAF, debe modificar la configuración del nombre de dominio. En Forwarding Settings, seleccione Enable Origin SNI.

¿Los gateways nativos de la nube admiten WebSocket?

Sí. La compatibilidad con el protocolo WebSocket está habilitada de forma predeterminada.

¿Los gateways nativos de la nube admiten gRPC?

Sí. gRPC utiliza el protocolo HTTP/2 para la transmisión. En la página Parameter Settings del gateway, confirme que EnableHttp2 = true.

¿Los gateways nativos de la nube admiten la descompresión GZIP?

Sí. En la página Parameter Settings del gateway, confirme que EnableGzip = true. Se admiten los algoritmos de compresión Gzip y Brotli. Puede configurar el algoritmo mediante el parámetro ZipAlgorithm. El valor predeterminado es Gzip.

¿Los gateways nativos de la nube admiten conservar las mayúsculas y minúsculas de los encabezados de solicitud y respuesta?

Sí. En la página Parameter Settings del gateway, confirme que PreserveHeaderFormat = true. Este parámetro solo surte efecto para HTTP/1.0 o HTTP/1.1. Según la especificación, el protocolo HTTP/2 requiere que todos los encabezados de solicitud y respuesta estén en minúsculas.

¿Los gateways nativos de la nube admiten HTTP/3?

Sí. En la página Parameter Settings del gateway, confirme que EnableHttp3 = true.

¿Los gateways nativos de la nube admiten puertos de listener personalizados?

Sí. Los gateways nativos de la nube admiten HTTP (puerto 80) y HTTPS (puerto 443). En la consola de CLB, puede agregar un puerto de listener, como el puerto TCP 8080, y asignar el puerto 80 al mismo vServer group para procesar solicitudes HTTP.

¿Por qué todos los encabezados de solicitud y respuesta se convierten a minúsculas después de pasar por el gateway?

De forma predeterminada, el gateway convierte todos los encabezados de solicitud y respuesta a minúsculas. Para conservar las mayúsculas y minúsculas, en la página Parameter Settings del gateway, establezca PreserveHeaderFormat = true.

¿Por qué falla el acceso después de crear un servicio de nombre de dominio DNS en el gateway nativo de la nube?

Si el nombre de dominio DNS configurado es un nombre de dominio de Internet, debe configurar SNAT en la consola de NAT Gateway para permitir que el gateway acceda a Internet. De forma predeterminada, el gateway no tiene acceso a Internet.

¿Qué debo hacer si se produce un error 400 en una solicitud?

Este error suele ocurrir por una de las dos razones siguientes:

• El protocolo enviado por el cliente no es válido. Puede consultar el registro de acceso del gateway. El registro contiene response_flags = DPE.

• El servicio backend devuelve un error 400. Puede confirmarlo al consultar el registro de acceso del gateway. Si el campo response_flags está vacío y el campo upstream_host tiene un valor, significa que el servicio backend devolvió el error 400. El valor de upstream_host es la dirección IP del backend al que el gateway reenvió la solicitud.

Se recomienda utilizar la función AI Diagnostics para un análisis preliminar.

¿Qué debo hacer si se produce un error 401 en una solicitud?

Este error suele ocurrir por una de las dos razones siguientes:

• El gateway devuelve un mensaje que indica que no se proporcionó ninguna credencial de acceso. Compruebe si la autenticación o un plugin Wasm están habilitados.

• El servicio backend devuelve un error 401. Puede confirmarlo al consultar el registro de acceso del gateway. Si el campo response_flags está vacío y el campo upstream_host tiene un valor, significa que el servicio backend devolvió el error 401. El valor de upstream_host es la dirección IP del backend al que el gateway reenvió la solicitud.

Se recomienda utilizar la función AI Diagnostics para un análisis preliminar.

¿Qué debo hacer si se produce un error 403 en una solicitud?

Este error suele ocurrir por una de las dos razones siguientes:

1. El gateway devuelve un mensaje que indica que no tiene los permisos necesarios para acceder al recurso. Compruebe si hay listas de bloqueados y permitidos basadas en direcciones IP, autenticación o un plugin Wasm habilitado.

2. El servicio backend devuelve un error 403. Puede confirmarlo al consultar el registro de acceso del gateway. Si el campo response_flags está vacío y el campo upstream_host tiene un valor, significa que el servicio backend devolvió el error 403. El valor de upstream_host es la dirección IP del backend al que el gateway reenvió la solicitud.

Se recomienda utilizar la función AI Diagnostics para un análisis preliminar.

¿Qué debo hacer si se produce un error 404 en una solicitud?

Este error suele ocurrir por una de las dos razones siguientes:

• El gateway no tiene una regla de enrutamiento correspondiente. Puede consultar el registro de acceso del gateway. Si el registro contiene response_flags = NR, significa que no hay ninguna regla de enrutamiento configurada en el gateway.

• El servicio backend devuelve un error 404. Puede confirmarlo al consultar el registro de acceso del gateway. Si el campo response_flags está vacío y el campo upstream_host tiene un valor, significa que el servicio backend devolvió el error 404. El valor de upstream_host es la dirección IP del backend al que el gateway reenvió la solicitud.

Se recomienda utilizar la función AI Diagnostics para un análisis preliminar.

¿Qué debo hacer si se produce un error 405 en una solicitud?

La protección WAF está habilitada y la solicitud activó una regla de protección de WAF. Este código de estado lo devuelve WAF.

¿Qué debo hacer si se produce un error 413 en una solicitud?

Este error suele ocurrir por una de las dos razones siguientes:

• El tamaño de la solicitud supera el tamaño del búfer de conexión del gateway. En la página Parameter Settings, aumente el valor del parámetro DownstreamConnectionBufferLimits.

• El servicio backend devuelve un error 413. Puede confirmarlo al consultar el registro de acceso del gateway. Si el campo response_flags está vacío y el campo upstream_host tiene un valor, significa que el servicio backend devolvió el error 413. El valor de upstream_host es la dirección IP del backend al que el gateway reenvió la solicitud.

Se recomienda utilizar la función AI Diagnostics para un análisis preliminar.

¿Qué debo hacer si se produce un error 429 en una solicitud?

Se activó una regla de limitación en el gateway. Puede consultar el registro de acceso del gateway. Si el registro contiene response_flags = RL, revise la regla de limitación del gateway.

Se recomienda utilizar la función AI Diagnostics para un análisis preliminar.

¿Qué debo hacer si se produce un error 502 en una solicitud?

Este error suele ocurrir por una de las dos razones siguientes:

• El servicio backend devuelve un error de protocolo de solicitud. Puede consultar el registro de acceso del gateway. Si el registro contiene response_flags = UPE, la causa más común es que el encabezado devuelto por el servicio backend contiene un campo Transfer-Encoding duplicado. En este caso, revise el servicio backend.

• El servicio backend devuelve un error 502. Puede confirmarlo al consultar el registro de acceso del gateway. Si el campo response_flags está vacío y el campo upstream_host tiene un valor, significa que el servicio backend devolvió el error 502. El valor de upstream_host es la dirección IP del backend al que el gateway reenvió la solicitud.

Se recomienda utilizar la función AI Diagnostics para un análisis preliminar.

¿Qué debo hacer si se produce un error 503 en una solicitud?

Este error suele ocurrir por una de las siguientes razones:

• El servicio de destino en la regla de enrutamiento configurada para el gateway no tiene una dirección IP saludable. Puede consultar el registro de acceso del gateway. El registro contiene response_flags = UH.

• El servicio backend cierra la conexión cuando el gateway reenvía la solicitud. Puede consultar el registro de acceso del gateway. Si el registro contiene response_flags = UC, generalmente significa que el idle timeout del servicio backend es más corto que el UpstreamIdleTimeout del gateway. En la página Parameter Settings del gateway, disminuya el valor de UpstreamIdleTimeout.

• El gateway no puede conectarse a la dirección IP del servicio backend. Puede consultar el registro de acceso del gateway. Si el registro contiene response_flags = UF o response_flags = URX, generalmente significa que el security group del servicio backend impide el acceso desde el gateway. Compruebe si el security group del servicio backend está configurado para permitir que el gateway acceda al puerto correspondiente. Para obtener más información, consulte Set security group rules.

• El gateway no tiene un servicio backend correspondiente. Puede consultar el registro de acceso del gateway. Si el registro contiene response_flags = NC, la causa suele ser una de las siguientes:

  • El servicio correspondiente ya no existe.

  • Si el servicio backend tiene varios puertos, debe seleccionar un puerto fijo en lugar de un puerto dinámico al elegir un servicio de destino para la regla de enrutamiento.

  • El servicio backend seleccionó un puerto fijo, pero el puerto del servicio ha cambiado.

• El servicio backend devuelve un error 503. Si el campo response_flags está vacío y el campo upstream_host tiene un valor, significa que el servicio backend devolvió el error 503. El valor de upstream_host es la dirección IP del backend al que el gateway reenvió la solicitud.

Se recomienda utilizar la función AI Diagnostics para un análisis preliminar.

¿Por qué el valor del campo response_code en el registro es 0?

Un valor de 0 en el campo response_code del registro indica que el cliente no recibió un código de respuesta.

Este error suele ocurrir por una de las dos razones siguientes:

• El cliente cierra la conexión prematuramente. Por ejemplo, el cliente puede cerrar la conexión antes de tiempo si la señal de la red celular es débil o si el tiempo de respuesta del backend es demasiado largo. En el registro, puede confirmar esto comprobando si el valor del campo response_flags es "DC".

• La solicitud HTTPS no incluye un SNI y no hay ningún certificado HTTPS configurado para el nombre de dominio comodín (*). SNI es una extensión TLS que incluye información del nombre de dominio. En el registro, puede confirmar esto comprobando si el campo requested_server_name está vacío.

Se recomienda utilizar la función AI Diagnostics para un análisis preliminar.