¿Cómo elegir? API Gateway frente a Ingress Controller frente a Service Mesh

Jenn GileResponsable de Marketing de Producto, NGINX

En prácticamente todos los seminarios web sobre controladores Ingress y mallas de servicios que hemos impartido a lo largo de 2021, hemos oído alguna variante de las preguntas: «¿En qué se diferencia esta herramienta de una puerta de enlace de API?» o «¿Necesito tanto una puerta de enlace de API como un controlador Ingress (o una malla de servicios) en Kubernetes?»

La confusión es totalmente comprensible por dos motivos:

• Los controladores de ingreso y las mallas de servicios pueden cubrir muchos casos de uso de las puertas de enlace de API.
• Algunos proveedores presentan su herramienta de puerta de enlace de API como una alternativa al uso de un controlador de Ingress o una malla de servicios, o bien integran las tres funcionalidades en una sola herramienta.

En este blog analizamos en qué se diferencian estas herramientas y cuál utilizar para casos de uso de gateways de API específicos de Kubernetes. Para profundizar en el tema y ver demostraciones, consulte el seminario web «Casos de uso de gateways de API para Kubernetes».

Definiciones

En esencia, las puertas de enlace de API, los controladores de Ingress y las mallas de servicios son distintos tipos de proxy diseñados para dirigir el tráfico hacia sus entornos y dentro de ellos.

¿Qué es una puerta de enlace de API?

Una puerta de enlace de API dirige las solicitudes de API de un cliente a los servicios adecuados. Sin embargo, esta sencilla definición suele dar lugar a un gran malentendido: pensar que una puerta de enlace de API es una tecnología específica. No lo es. En realidad, «puerta de enlace de API» describe un conjunto de casos de uso que pueden implementarse mediante distintos tipos de proxies, normalmente un ADC o balanceador de carga y un proxy inverso y, cada vez más, un controlador de Ingress o una malla de servicios.

No existe un gran consenso en el sector sobre qué funcionalidades son «imprescindibles» para que una herramienta pueda actuar como puerta de enlace de API. Por lo general, nuestros clientes requieren las siguientes capacidades (agrupadas por caso de uso):

Casos de uso de resiliencia

• Pruebas A/B, despliegues canary y despliegues blue-green
• Transformación de protocolos (por ejemplo, entre JSON y XML)
• Limitación de velocidad
• Descubrimiento de servicios

Casos de uso de la gestión del tráfico

• Enrutamiento y coincidencia basados en métodos
• Manipulación de las cabeceras y el cuerpo de las solicitudes y respuestas
• Enrutamiento de solicitudes en la capa 7

Casos de uso de seguridad

• Aplicación del esquema de la API
• Autenticación y autorización de clientes
• Respuestas personalizadas
• Control de acceso granular
• Terminación TLS

Casi todos estos casos de uso son habituales en Kubernetes. La transformación de protocolos y la manipulación de las cabeceras y el cuerpo de las solicitudes y respuestas son menos frecuentes, ya que suelen estar vinculadas a API heredadas que no se adaptan bien a los entornos de Kubernetes y microservicios.

Obtenga más información sobre los casos de uso de las puertas de enlace de API en «Implementación de NGINX como puerta de enlace de API, parte 1» en nuestro blog.

¿Qué es un controlador de Ingress?

Un controlador de Ingress (también denominado controlador de Ingress de Kubernetes, o KIC por sus siglas en inglés) es un proxy especializado de capa 4 y capa 7 que dirige el tráfico hacia Kubernetes y sus servicios, y de vuelta al exterior (lo que se conoce como tráfico de entrada y salida o tráfico norte-sur). Además de gestionar el tráfico, los controladores de Ingress también pueden utilizarse para proporcionar visibilidad y solucionar problemas, gestionar la seguridad y la identidad, y abordar prácticamente todos los casos de uso de las puertas de enlace de API, salvo los más avanzados.

Obtenga más información sobre cómo puede utilizar un controlador de Ingress para mucho más que la gestión básica del tráfico en Guía para elegir un controlador de Ingress, parte 1: identifique sus requisitos en nuestro blog.

¿Qué es una malla de servicios?

Una malla de servicios gestiona el tráfico que fluye entre los servicios de Kubernetes (denominado tráfico de servicio a servicio o tráfico este-oeste) y se utiliza habitualmente para lograr el cifrado de extremo a extremo (E2EE). La adopción de las mallas de servicios es aún limitada, pero está creciendo a medida que más organizaciones ponen en marcha implementaciones avanzadas o necesitan E2EE. Una malla de servicios puede utilizarse como una puerta de enlace de API distribuida (ligera) muy próxima a las aplicaciones, lo que es posible en el plano de datos gracias a los sidecars de la malla de servicios.

Obtén más información sobre las mallas de servicios y descubre cuándo estarás preparado para utilizar una en Cómo elegir una malla de servicios en nuestro blog.

Utiliza herramientas nativas de Kubernetes para entornos de Kubernetes

Como escuchamos decir a Mark Church en su ponencia principal de NGINX Sprint 2.0 sobre Kubernetes y el futuro de las redes de aplicaciones, «las puertas de enlace de API, los balanceadores de carga y las mallas de servicios seguirán pareciéndose cada vez más entre sí y ofreciendo capacidades similares». Estamos totalmente de acuerdo con esta afirmación y añadiríamos que todo consiste en elegir la herramienta adecuada para cada tarea en función de dónde (y cómo) se vaya a utilizar. Al fin y al cabo, tanto un machete como un cuchillo para untar sirven para cortar, pero probablemente no usarías el primero para las tostadas del desayuno.

Entonces, ¿cómo decidir qué herramienta es la adecuada para ti? Te lo ponemos fácil: si necesitas funciones de puerta de enlace de API dentro de Kubernetes, normalmente es mejor elegir una herramienta que pueda configurarse mediante herramientas de configuración nativas de Kubernetes, como YAML. Por lo general, se tratará de un controlador de Ingress o una malla de servicios. Pero quizá estés pensando: «Mi herramienta de puerta de enlace de API tiene muchas más funciones que mi controlador de Ingress (o malla de servicios); ¿no me estaré perdiendo algo?». ¡No! Tener más funciones no significa que una herramienta sea mejor, especialmente en Kubernetes, donde la complejidad de las herramientas puede ser un obstáculo insalvable.

Nota: Nativo de Kubernetes (no es lo mismo que Knative) hace referencia a las herramientas diseñadas y desarrolladas para Kubernetes. Por lo general, funcionan con la CLI de Kubernetes, se pueden instalar mediante Helm y se integran con las funcionalidades de Kubernetes.

La mayoría de los usuarios de Kubernetes prefieren herramientas que puedan configurar de forma nativa para Kubernetes, ya que así evitan cambios en la experiencia de desarrollo o de GitOps. Una herramienta compatible con YAML ofrece tres ventajas principales:

• YAML es un lenguaje conocido para los equipos de Kubernetes, por lo que la curva de aprendizaje es reducida, o incluso inexistente, si se utiliza una herramienta de Kubernetes existente para ofrecer funcionalidades de puerta de enlace de API. Esto permite a los equipos trabajar con las competencias que ya poseen sin tener que aprender a configurar una nueva herramienta que quizá solo utilicen ocasionalmente.
• Puedes automatizar una herramienta compatible con YAML del mismo modo que el resto de tus herramientas de Kubernetes. Cualquier herramienta que se integre perfectamente en tus flujos de trabajo tendrá una buena acogida entre tu equipo, lo que aumentará la probabilidad de que la utilicen.
• Puede reducir el conjunto de herramientas de gestión del tráfico de Kubernetes utilizando su controlador Ingress, su malla de servicios o ambos. Al fin y al cabo, cada salto adicional cuenta y no hay motivo para añadir latencia innecesaria ni puntos únicos de fallo. Y, por supuesto, reducir el número de tecnologías implementadas en Kubernetes también beneficia a su presupuesto y a la seguridad general.

Casos de uso de una puerta de enlace de API norte-sur: utilice un controlador de Ingress

Los controladores de Ingress pueden hacer posibles muchos casos de uso de las puertas de enlace de API. Además de los descritos en Definiciones, observamos que las organizaciones valoran especialmente un controlador de Ingress que pueda implementar:

• Delegación de la autenticación y la autorización
• Enrutamiento basado en la autorización
• Enrutamiento y coincidencia de nivel de capa 7 (HTTP, HTTP/S, encabezados, cookies, métodos)
• Compatibilidad con protocolos (HTTP, HTTP/2, WebSocket, gRPC)
• Limitación de velocidad

Escenario de ejemplo: enrutamiento a nivel de método

Quiere implementar la coincidencia y el enrutamiento a nivel de método, utilizando el controlador Ingress para rechazar el método POST en las solicitudes a la API.

Algunos atacantes buscan vulnerabilidades en las API enviando tipos de solicitudes que no se ajustan a la definición de una API; por ejemplo, enviando solicitudes POST a una API definida para aceptar únicamente solicitudes GET. Los cortafuegos de aplicaciones web (WAF) no pueden detectar este tipo de ataques, ya que solo examinan las cadenas y los cuerpos de las solicitudes en busca de ataques. Por ello, se recomienda utilizar una puerta de enlace de API en la capa de Ingress para bloquear las solicitudes maliciosas.

Como ejemplo, supongamos que se acaba de añadir a su clúster la nueva API /coffee/{coffee-store}/brand. El primer paso es exponer la API mediante NGINX Ingress Controller; para ello, basta con añadirla al campo upstreams.

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
name: cafe
spec:
host: cafe.example.com
tls:
secret: cafe-secret
upstreams:
-name: tea
service: tea-svc
port: 80
-name: coffee
service: coffee-svc
port: 80

Para habilitar la coincidencia a nivel de método, añade una ruta /coffee/{coffee-store}/brand al campo routes y dos condiciones que utilicen la variable $request_method para distinguir entre las solicitudes GET y POST. Todo el tráfico que utilice el método HTTP GET se envía automáticamente al servicio de café. El tráfico que utilice el método POST se dirige a una página de error con el mensaje «¡Solicitud rechazada!». Así de fácil, habrá protegido la nueva API frente al tráfico POST no deseado.

routes: - path: /coffee/{coffee-store}/brand
matches:
- conditions:
- variable: $request_method
value: POST
action:
return:
code: 403
type: text/plain
body: "¡Se ha rechazado tu solicitud!"
- conditions:
- variable: $request_method
value: GET
action:
pass: coffee
- path: /tea
action:
pass:tea

Para obtener más información sobre cómo usar el enrutamiento y la coincidencia a nivel de método con páginas de error, consulte la documentación de NGINX Ingress Controller. Para ver un ejemplo relacionado con la seguridad sobre el uso de un controlador Ingress para implementar funciones de puerta de enlace de API, lea Implementación de la autenticación OpenID Connect para Kubernetes con Okta y NGINX Ingress Controller en nuestro blog.

Casos de uso de una puerta de enlace de API este-oeste: utilice una malla de servicios

Una malla de servicios no es necesaria —ni siquiera resulta útil al principio— para la mayoría de los casos de uso de una puerta de enlace de API, ya que casi todo lo que se quiera conseguir puede y debe hacerse en la capa de entrada. Sin embargo, a medida que aumenta la complejidad de la arquitectura, es más probable que el uso de una malla de servicios aporte valor. Los casos de uso que consideramos más beneficiosos están relacionados con el cifrado de extremo a extremo (E2EE) y la división del tráfico —como las pruebas A/B y las implementaciones canary y blue-green.

Escenario de ejemplo: despliegue canario

Quieres configurar un despliegue canary entre servicios con enrutamiento condicional basado en criterios HTTP/S.

La ventaja es que puede implementar gradualmente cambios en la API, como nuevas funciones o versiones, sin afectar a la mayor parte del tráfico de producción.

Actualmente, NGINX Ingress Controller enruta el tráfico entre dos servicios gestionados por NGINX Service Mesh: Coffee.frontdoor.svc y Tea.frontdoor.svc. Estos servicios reciben tráfico de NGINX Ingress Controller y lo dirigen a las funciones correspondientes de la aplicación, incluida Tea.cream1.svc. Decide refactorizar Tea.cream1.svc y denominar Tea.cream2.svc a la nueva versión. Quiere que sus probadores beta le den su opinión sobre la nueva funcionalidad, por lo que configura una división de tráfico canary basada en la cookie de sesión única de los probadores beta, lo que garantiza que los usuarios habituales solo utilicen Tea.cream1.svc.

Con NGINX Service Mesh, primero se crea una división del tráfico entre todos los servicios expuestos a través de Tea.frontdoor.svc, incluidos Tea.cream1.svc y Tea.cream2.svc. Para habilitar el enrutamiento condicional, se crea un recurso HTTPRouteGroup (denominado tea-hrg) y se asocia a la división del tráfico. Como resultado, solo las solicitudes de los usuarios beta (aquellas cuya cookie de sesión está configurada como version=beta) se enrutan desde Tea.frontdoor.svc hasta Tea.cream2.svc. Los usuarios habituales siguen accediendo únicamente a los servicios de la versión 1 situados detrás de Tea.frontdoor.svc.

apiVersion: split.smi-spec.io/v1alpha3kind: TrafficSplit
metadata:
name: tea-svc
spec:
service: tea.1
backends:
- service: tea.1
weight: 0
- service: tea.2
weight: 100
matches:
- kind: HTTPRouteGroup
name: tea-hrg

apiVersion: specs.smi-spec.io/v1alpha3
kind: HTTPRouteGroup
metadata:
name: tea-hrg
namespace: default
spec:
matches:
- name: beta-session-cookie
headers:
- cookie: "version=beta"

Este ejemplo inicia el despliegue canary con un reparto de 0‑100, lo que significa que todos los probadores beta utilizan Tea.cream2.svc, aunque, por supuesto, puede empezar con la proporción que mejor se adapte a su estrategia de pruebas beta. Una vez finalizadas las pruebas beta, puede utilizar un despliegue canary sencillo (sin el enrutamiento mediante cookies) para probar la resiliencia de Tea.cream2.svc.

Consulta nuestra documentación para obtener más información sobre la distribución del tráfico con NGINX Service Mesh. La configuración anterior de distribución del tráfico es autorreferencial, ya que el servicio raíz también figura como servicio de backend. Actualmente, esta configuración no es compatible con la especificación de Service Mesh Interface (smi-spec); sin embargo, la especificación se encuentra actualmente en fase alfa y está sujeta a cambios.

Cuándo (y cómo) usar una herramienta de puerta de enlace de API para aplicaciones de Kubernetes

Aunque la mayoría de los casos de uso de una puerta de enlace de API para Kubernetes pueden (y deben) resolverse mediante un controlador de Ingress o una malla de servicios, existen algunas situaciones específicas en las que resulta adecuada una herramienta de puerta de enlace de API, como NGINX Plus.

Requisitos empresariales

Aunque varios equipos o proyectos pueden compartir un conjunto de controladores Ingress, o estos pueden especializarse para cada entorno, existen motivos por los que podría optar por implementar una puerta de enlace de API dedicada dentro de Kubernetes en lugar de aprovechar el controlador Ingress existente. El uso conjunto de un controlador Ingress y una puerta de enlace de API dentro de Kubernetes puede proporcionar a las organizaciones la flexibilidad necesaria para cumplir los requisitos empresariales. Algunos de estos escenarios son:

• El equipo responsable de la puerta de enlace de API no está familiarizado con Kubernetes y no utiliza YAML. Por ejemplo, si se siente cómodo con la configuración de NGINX, implementar NGINX Plus como puerta de enlace de API en Kubernetes reduce las dificultades y facilita el aprendizaje.
• Tu equipo de Operaciones de Plataforma prefiere dedicar el controlador de Ingress exclusivamente a la gestión del tráfico de las aplicaciones.
• Tiene un caso de uso de puerta de enlace de API que solo se aplica a uno de los servicios de su clúster. En lugar de usar un controlador de Ingress para aplicar una política a todo el tráfico norte-sur, puede implementar una puerta de enlace de API para aplicar la política únicamente donde sea necesario.

Migración de API a entornos de Kubernetes

Al migrar API existentes a entornos de Kubernetes, puede publicar dichas API en una herramienta de puerta de enlace de API implementada fuera de Kubernetes. En este escenario, el tráfico de las API suele dirigirse primero a través de un balanceador de carga externo (para equilibrar la carga entre clústeres), después a un balanceador de carga configurado para actuar como puerta de enlace de API y, por último, al controlador Ingress de su clúster de Kubernetes.

Compatibilidad con las API SOAP en Kubernetes

Aunque la mayoría de las API modernas se crean con REST —en parte porque los servicios y las API RESTful o gRPC pueden aprovechar al máximo la plataforma Kubernetes—, es posible que aún tenga algunas API SOAP cuya arquitectura no se haya rediseñado. Aunque no se recomienda usar API SOAP en Kubernetes porque no están optimizadas para microservicios, puede que necesite implementar una API SOAP en Kubernetes hasta que se pueda rediseñar su arquitectura. Es probable que la API necesite comunicarse con clientes de API basados en REST, en cuyo caso necesitará una forma de traducir entre los protocolos SOAP y REST. Aunque puede realizar esta función con un controlador Ingress, no lo recomendamos porque consume una enorme cantidad de recursos. En su lugar, recomendamos implementar una herramienta de puerta de enlace de API como proxy por pod o por servicio para traducir entre SOAP y REST.

Gestión del tráfico de API tanto dentro como fuera de Kubernetes

Un número relativamente reducido de nuestros clientes está interesado en gestionar API que abarquen entornos tanto internos como externos a Kubernetes. Si una estrategia de gestión de API tiene mayor prioridad que la selección de herramientas nativas de Kubernetes, una puerta de enlace de API «compatible con Kubernetes» (que pueda integrarse con una solución de gestión de API) implementada en Kubernetes podría ser la opción adecuada.

Nota: A diferencia de las herramientas nativas de Kubernetes, las herramientas compatibles con Kubernetes (también denominadas en ocasiones «adaptadas a Kubernetes») no se diseñaron para Kubernetes y no se pueden gestionar mediante configuraciones de Kubernetes. Sin embargo, son ágiles y ligeras, lo que les permite funcionar en Kubernetes sin añadir una latencia significativa ni requerir soluciones alternativas complejas.

Primeros pasos con NGINX

NGINX ofrece opciones para los tres tipos de escenarios de implementación.

Herramientas nativas de Kubernetes:

• Controlador de Ingress de NGINX – Controlador de Ingress para Kubernetes basado en NGINX Plus que ofrece funciones avanzadas de control y gestión del tráfico, monitorización y visibilidad, así como autenticación e inicio de sesión único (SSO).
• NGINX Service Mesh – Malla de servicios ligera, lista para usar y fácil de utilizar para los desarrolladores, que incorpora NGINX Plus como sidecar empresarial.

Empieza solicitando tu prueba gratuita de 30 días de NGINX Ingress Controller con NGINX App Protect WAF y protección contra ataques DoS, y descarga NGINX Service Mesh, que es gratuito para siempre.

Para una puerta de enlace de API compatible con Kubernetes, tanto dentro como fuera de sus entornos de Kubernetes:

• NGINX Plus – El equilibrador de carga, proxy inverso, servidor web y puerta de enlace de API todo en uno, con funcionalidades de nivel empresarial como alta disponibilidad, comprobaciones de estado activas, detección de sistemas DNS, persistencia de sesiones y una API RESTful. Se integra con NGINX Controller [ahora F5 NGINX Management Suite] para ofrecer una solución completa para el ciclo de vida de las API.

Para obtener más información sobre el uso de NGINX Plus como puerta de enlace de API, solicite su prueba gratuita de 30 días y consulte Implementación de NGINX como puerta de enlace de API.

Sobre el autor

Jenn GileResponsable de Marketing de Producto, NGINX

Más artículos de Jenn Gile