Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Precaución
La red SIG de Kubernetes y el Comité de respuesta a la seguridad anunciaron la próxima retirada del proyecto NGINX de entrada, con un mantenimiento que finaliza en marzo de 2026. En este momento no se requiere ninguna acción inmediata para los clústeres de AKS que utilizan el complemento de enrutamiento de aplicaciones con NGINX. Microsoft proporcionará soporte oficial para parches de seguridad críticos en los recursos de NGINX Ingress del complemento de enrutamiento de aplicaciones hasta noviembre de 2026.
AKS se alinea con Kubernetes ascendente al pasar a la API de puerta de enlace como estándar a largo plazo para la administración del tráfico de entrada y L7. Se recomienda empezar a planear la ruta de migración en función de la configuración actual:
- Usuarios del complemento de enrutamiento de aplicaciones: las cargas de trabajo de producción siguen siendo totalmente compatibles hasta noviembre de 2026. Migre a la implementación de la API de puerta de enlace de enrutamiento de aplicaciones para disfrutar de una experiencia de gestión del tráfico de entrada basada en la API de puerta de enlace.
-
Los usuarios de OSS NGINX tienen varias opciones:
- Migre al complemento de enrutamiento de aplicaciones con NGINX para beneficiarse del soporte técnico oficial hasta noviembre de 2026 mientras planea la migración a largo plazo de la API de Gateway.
- Migre a la implementación de la API de puerta de enlace de enrutamiento de aplicaciones para disfrutar de una experiencia de gestión del tráfico de entrada basada en la API de puerta de enlace.
- Migre a Application Gateway para contenedores, que admite tanto la API de Ingress como la API de puerta de enlace.
- Usuarios de malla de servicio: si tiene pensado adoptar una malla de servicio, considere el complemento de malla de servicio basado en Istio. Use entrada de Istio hoy y planifique migrar a la API de Istio Gateway, que ahora es GA.
La entrada en AKS es un recurso de Kubernetes que administra el acceso de tráfico externo similar a HTTP a servicios dentro de un clúster. Una entrada de AKS puede proporcionar servicios como equilibrio de carga, terminación SSL y hospedaje virtual basado en nombres. Para más información sobre la entrada de Kubernetes, consulte la documentación de entrada de Kubernetes.
Para la mayoría de las cargas de trabajo de producción, comience con AKS Automatic. AKS Automatic es el valor predeterminado recomendado para producción en AKS y proporciona valores predeterminados administrados para redes, escalado, seguridad, supervisión y actualizaciones. Para la entrada, esto significa que puede empezar con la ruta de acceso de entrada administrada y pasar solo a opciones más especializadas cuando necesita un mayor control sobre la topología, el comportamiento de enrutamiento o la integración de malla de servicio.
Use AKS Standard cuando necesite un control más explícito sobre la selección del controlador de entrada, la topología de implementación o la integración de red avanzada.
Modos y entrada del clúster de AKS
AKS admite dos modos de clúster:
- AKS Automático: punto de partida recomendado para la mayoría de las cargas de trabajo de producción. Reduce la sobrecarga operativa y proporciona una configuración predeterminada gestionada para los componentes de ingress y de red relacionados.
- AKS Estándar: mejor cuando se necesita un control explícito sobre el hospedaje del controlador de entrada, la exposición del servicio y los patrones avanzados de administración del tráfico.
La guía de entrada de este artículo se aplica a ambos modos. La principal diferencia es quién posee más de los valores predeterminados de la plataforma y la cantidad de personalización que necesita administrar directamente.
Controladores de entrada
Al administrar el tráfico de aplicaciones, los controladores de entrada proporcionan funcionalidades avanzadas al trabajar en el nivel 7. Pueden enrutar el tráfico HTTP a diferentes aplicaciones en función de la dirección URL de entrada, lo que permite reglas de distribución de tráfico más inteligentes y flexibles. Por ejemplo, un controlador de entrada puede dirigir el tráfico a diferentes microservicios en función de la ruta de acceso de la dirección URL, lo que mejora la eficacia y la organización de los servicios.
Por otro lado, un servicio de tipo LoadBalancer, cuando se crea, configura un recurso subyacente del equilibrador de carga de Azure. Este equilibrador de carga funciona en el nivel 4 y distribuye el tráfico a los pods del servicio en un puerto especificado. Sin embargo, los servicios de nivel 4 no son conscientes de las aplicaciones reales y no pueden implementar estos tipos de reglas de enrutamiento complejas.
Comprender la distinción entre estos dos enfoques ayuda a seleccionar la herramienta adecuada para sus necesidades de administración del tráfico.
Si usa AKS Automatic, comience primero con la ruta de acceso de entrada administrada y use opciones más especializadas solo cuando la carga de trabajo las requiera. En AKS Standard, tiene más flexibilidad para elegir el controlador de entrada y la topología que mejor se adapten a la arquitectura.
Comparación de las opciones de entrada
Comparación de características
En la tabla siguiente se enumeran las diferencias de características entre las distintas opciones del controlador de entrada. Para la mayoría de las cargas de trabajo de producción de AKS, la opción predeterminada recomendada es el enfoque de ingress administrado en AKS Automatic, a menos que necesite expresamente enrutamiento personalizado, integración con una malla de servicios o ingress hospedado en Azure.
| Característica | Complemento Enrutamiento de aplicaciones | Application Gateway para contenedores | malla de servicio de Azure / malla de servicio de Istio |
|---|---|---|---|
| Controlador de entrada/puerta de enlace | Controlador de entrada NGINX | Puerta de enlace de aplicaciones para contenedores | Puerta de enlace de entrada de Istio |
| API | API de entrada | API de entrada y API de puerta de enlace | API de entrada de Istio |
| Hospedaje | En el clúster | Hospedado en Azure | En el clúster |
| Escalado | Escalado automático | Escalado automático | Escalado automático |
| Equilibrio de carga | Interno o externo | Externo | Interno o externo |
| Terminación de TLS | En el clúster | Sí: Descarga y SSL de E2E | En el clúster |
| mTLS | N/D | Sí: front-end y back-end | Sí |
| Dirección IP estática | Sí | FQDN (sin dirección IP estática) | N/D |
| Certificados SSL almacenados de Azure Key Vault | Sí | Sí | N/D |
| Integración de Azure DNS para la administración de zonas DNS | Sí | Sí | N/D |
Cuándo usar cada controlador de entrada
En la tabla siguiente se enumeran los distintos escenarios en los que puede usar cada controlador de entrada:
| Opción de entrada | Cuándo se deben usar |
|---|---|
| NGINX administrado: complemento de enrutamiento de aplicaciones | • Controladores de entrada NGINX hospedados en clústeres, personalizables y escalables. • Funcionalidades básicas de equilibrio de carga y enrutamiento. • Configuración del equilibrador de carga interno y externo. • Configuración de direcciones IP estáticas. • Integración con Azure Key Vault para la administración de certificados. • Integración con Azure DNS Zones para la administración de DNS pública y privada. • Compatible con la API de Ingress. |
| Application Gateway para contenedores | • Puerta de enlace de entrada hospedada en Azure. • Estrategias de implementación flexibles administradas por el controlador o traiga su propia puerta de enlace de aplicaciones para contenedores. • Características avanzadas de administración del tráfico, como reintentos automáticos, resistencia de zona de disponibilidad, autenticación mutua (mTLS) en el destino de back-end, división de tráfico/round robin ponderado y escalado automático. • Integración con Azure Key Vault para la administración de certificados. • Integración con Azure DNS Zones para la administración de DNS pública y privada. • Admite las APIs de Ingress y Gateway. |
| Puerta de enlace de entrada de Istio | • Basado en Envoy, cuando se usa con Istio en una malla de servicio. • Características avanzadas de administración del tráfico, como la limitación de velocidad y la interrupción del circuito. • Compatibilidad con mTLS. |
Nota:
El complemento Istio no admite actualmente la API de puerta de enlace para el tráfico de entrada de Istio.
Creación de un recurso de entrada
El complemento Enrutamiento de aplicaciones es la manera recomendada de configurar un controlador de entrada en AKS y es la ruta de acceso de entrada administrada para empezar en AKS Automatic para la mayoría de las cargas de trabajo. El complemento de enrutamiento de aplicaciones es un controlador de entrada totalmente administrado para AKS que proporciona las siguientes características:
- Configuración sencilla de controladores de entrada NGINX administrados basados en el controlador de entrada NGINX de Kubernetes.
- Integración con Azure DNS para la administración de zonas públicas y privadas.
- Terminación SSL con certificados almacenados en Azure Key Vault.
Para la mayoría de las cargas de trabajo de producción, este es el valor predeterminado adecuado para empezar. Si necesita una topología de ingress personalizada, ingress hospedado en Azure o comportamiento de la malla de servicios, puede cambiar a una de las otras opciones de ingress.
Para obtener más información sobre el complemento de enrutamiento de aplicaciones, consulte Entrada NGINX administrada con el complemento de enrutamiento de aplicaciones.
Conservación de la dirección IP de origen de cliente
Configure el controlador de entrada para conservar la dirección IP de origen de cliente en las solicitudes a los contenedores en el clúster de AKS. Cuando el controlador de entrada enruta la solicitud de un cliente a un contenedor del clúster de AKS, la dirección IP de origen de la solicitud no está disponible para el contenedor de destino. Al habilitar la conservación de la dirección IP de origen de cliente, la dirección IP de origen para el cliente está disponible en el encabezado de solicitud en X-Forwarded-For.
Si usa la conservación de la dirección IP de origen de cliente en el controlador de entrada, no puede usar TLS de paso a través. La conservación de la dirección IP de origen de cliente y TLS de paso a través pueden usarse con otros servicios, como de tipo LoadBalancer.
Esto sigue siendo una opción de diseño importante en AKS Automatic y AKS Standard, ya que el control de IP de origen afecta a la observabilidad, la auditabilidad y el comportamiento de la aplicación independientemente del modo de clúster.
Para más información sobre la conservación de la dirección IP de origen del cliente, consulte Funcionamiento de la conservación de la dirección IP de origen del cliente para los servicios LoadBalancer en AKS.