¿Cómo elijo? Puerta de enlace API frente a. Controlador de ingreso vs. Malla de servicios

En casi todos los seminarios web sobre controladores de Ingress y mallas de servicios que hemos realizado a lo largo de 2021, hemos escuchado alguna variación de las preguntas "¿En qué se diferencia esta herramienta de una puerta de enlace de API?" o "¿Necesito una puerta de enlace de API y un controlador de Ingress (o malla de servicios) en Kubernetes?"

La confusión es totalmente comprensible por dos razones:

• Los controladores de ingreso y las mallas de servicio pueden satisfacer muchos casos de uso de API Gateway.
• Algunos proveedores posicionan su herramienta de puerta de enlace API como una alternativa al uso de un controlador de Ingress o una malla de servicio, o combinan las tres capacidades en una sola herramienta.

En este blog abordamos en qué se diferencian estas herramientas y cuál utilizar para los casos de uso de API gateway específicos de Kubernetes. Para obtener un análisis más profundo, incluidas demostraciones, mire el seminario web Casos de uso de API Gateway para Kubernetes .

Definiciones

En esencia, las puertas de enlace de API, los controladores de ingreso y las mallas de servicio son cada uno un tipo de proxy, diseñado para llevar tráfico hacia sus entornos y alrededor de ellos.

¿Qué es una puerta de enlace de API?

Una puerta de enlace API dirige las solicitudes de API de un cliente a los servicios apropiados. Pero un gran malentendido acerca de esta definición simple es la idea de que una puerta de enlace API es una pieza única de tecnología. Que no es. En lugar de eso, “API gateway” describe un conjunto de casos de uso que pueden implementarse a través de diferentes tipos de servidores proxy: más comúnmente un ADC o balanceador de carga y proxy inverso, y cada vez más un controlador de Ingress o una malla de servicios.

No hay mucho acuerdo en la industria sobre qué capacidades son “imprescindibles” para que una herramienta funcione como puerta de enlace de API. Generalmente vemos clientes que requieren las siguientes habilidades (agrupadas por caso de uso):

Casos de uso de resiliencia

• Pruebas A/B, implementaciones canarias e implementaciones azul-verde
• Transformación de protocolo (entre JSON y XML, por ejemplo)
• 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 del encabezado y cuerpo de la solicitud/respuesta
• Enrutamiento de solicitudes en la capa 7

Casos de uso de seguridad

• Cumplimiento del esquema API
• Autenticación y autorización de clientes
• Respuestas personalizadas
• Control de acceso de grano fino
• Terminación de TLS

Casi todos estos casos de uso se utilizan comúnmente en Kubernetes. La transformación de protocolos y la manipulación del encabezado y el cuerpo de las solicitudes y respuestas son menos comunes, ya que generalmente están vinculadas a API heredadas que no son adecuadas para entornos de Kubernetes y microservicios.

Obtenga más información sobre los casos de uso de API Gateway en Implementación de NGINX como API Gateway, parte 1 en nuestro blog.

¿Qué es un controlador Ingress?

Un controlador de ingreso (también llamado controlador de ingreso de Kubernetes, KIC para abreviar) es un proxy especializado de capa 4 y capa 7 que lleva tráfico hacia Kubernetes, hacia los servicios y de regreso (lo que se conoce como tráfico de ingreso-egreso o norte-sur). Además de la gestión del tráfico, los controladores de Ingress también se pueden utilizar para visibilidad y resolución de problemas, seguridad e identidad, y todos los casos de uso de API gateway excepto los más avanzados.

Obtenga más información sobre cómo puede usar un controlador de Ingress para algo más que la gestión básica del tráfico en Una 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 maneja el tráfico que fluye entre los servicios de Kubernetes (denominado tráfico de servicio a servicio o de este a oeste) y se utiliza comúnmente para lograr el cifrado de extremo a extremo (E2EE). La adopción de la malla de servicios es pequeña, pero está creciendo a medida que más organizaciones lanzan implementaciones avanzadas o tienen requisitos para E2EE. Una malla de servicio se puede utilizar como una puerta de enlace de API distribuida (liviana) muy cerca de las aplicaciones, lo que es posible en el nivel del plano de datos gracias a los sidecars de la malla de servicio.

Obtenga más información sobre la malla de servicios (y cuándo estará listo para tener una) en Cómo elegir una malla de servicios en nuestro blog.

Utilice herramientas nativas de Kubernetes para entornos de Kubernetes

Como escuchamos de Mark Church en su discurso de apertura en NGINX Sprint 2.0 sobre Kubernetes y el futuro de las redes de aplicação , “las puertas de enlace de API, los balanceadores de carga y las mallas de servicios seguirán pareciendo cada vez más similares entre sí y brindarán capacidades similares”. Estamos totalmente de acuerdo con esta afirmación y añadimos además que se trata de elegir la herramienta adecuada para el trabajo en función de dónde (y cómo) la vas a utilizar. Después de todo, tanto un machete como un cuchillo de mantequilla sirven para cortar, pero probablemente no vayas a utilizar el primero para cortar tu tostada matutina.

Entonces, ¿cómo decide qué herramienta es la adecuada para usted? Lo haremos simple: si necesita la funcionalidad de API gateway dentro de Kubernetes, generalmente es mejor elegir una herramienta que pueda configurarse utilizando herramientas de configuración nativas de Kubernetes, como YAML. Normalmente, se trata de un controlador de ingreso o una malla de servicio. Pero te escuchamos decir: "Mi herramienta de puerta de enlace API tiene muchas más funciones que mi controlador de Ingress (o malla de servicio). ¿No me estoy perdiendo algo?" ¡No! Más funciones no equivalen a mejores herramientas, especialmente dentro de Kubernetes, donde la complejidad de la herramienta puede ser un problema.

Nota:  Kubernetes‑native (no lo mismo que Knative ) se refiere a herramientas que fueron diseñadas y creadas para Kubernetes. Normalmente, funcionan con la CLI de Kubernetes, se pueden instalar mediante Helm y se integran con las funciones de Kubernetes.

La mayoría de los usuarios de Kubernetes prefieren herramientas que puedan configurar de forma nativa de Kubernetes porque eso evita cambios en el desarrollo o en la experiencia de GitOps. Una herramienta compatible con YAML ofrece tres beneficios principales:

• YAML es un lenguaje familiar para los equipos de Kubernetes, por lo que la curva de aprendizaje es pequeña, o incluso inexistente, si está utilizando una herramienta de Kubernetes existente para la funcionalidad de puerta de enlace de API. Esto ayuda a que sus equipos trabajen dentro de sus habilidades existentes sin la necesidad de aprender a configurar una nueva herramienta que tal vez solo usen ocasionalmente.
• Puede automatizar una herramienta compatible con YAML de la misma manera que sus otras herramientas de Kubernetes. Cualquier cosa que se adapte claramente a sus flujos de trabajo será popular entre su equipo, lo que aumentará la probabilidad de que lo utilicen.
• Puede reducir su pila de herramientas de gestión de tráfico de Kubernetes mediante el uso de su controlador de Ingress, su malla de servicio o ambos. Después de todo, cada salto adicional importa y no hay razón para agregar latencia innecesaria o puntos únicos de falla. Y, por supuesto, reducir la cantidad de tecnologías implementadas dentro de Kubernetes también es bueno para su presupuesto y su seguridad general.

Casos de uso de la API Gateway Norte-Sur: Utilice un controlador de ingreso

Los controladores de ingreso tienen el potencial de habilitar muchos casos de uso de API Gateway. Además de los descritos en Definiciones , consideramos que las organizaciones valoran más un controlador de Ingress que pueda implementar:

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

Escenario de muestra: Enrutamiento a nivel de método

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

Algunos atacantes buscan vulnerabilidades en las API enviando tipos de solicitudes que no cumplen con una definición de API; por ejemplo, enviando solicitudes POST a una API que está definida para aceptar solo solicitudes GET . Los firewalls de aplicação web (WAF) no pueden detectar este tipo de ataques (solo examinan las cadenas y los cuerpos de las solicitudes en busca de ataques), por lo que se recomienda utilizar una puerta de enlace API en la capa de ingreso para bloquear las solicitudes incorrectas.

A modo de ejemplo, supongamos que la nueva API /coffee/{coffee-store}/brand acaba de agregarse a su clúster. El primer paso es exponer la API usando NGINX Ingress Controller, simplemente agregando la API al campo upstreams .

Versión de API: k8s.nginx.org/v1kind: Servidor Virtual
Metadatos:
Nombre: Cafe
Especificación:
Host: Cafe.ejemplo.com
TLS:
Secreto: Cafe-Secret
Subprocesos:
Nombre: Tea
Servicio: Tea-SVC
Puerto: 80
-nombre: café
servicio: servicio-café
puerto: 80

Para habilitar la coincidencia a nivel de método, agregue una ruta /coffee/{coffee-store}/brand al campo de rutas y agregue dos condiciones que usen la variable $request_method para distinguir entre solicitudes GET y POST . Cualquier tráfico que utilice el método HTTP GET se pasa automáticamente al servicio de café . El tráfico que utiliza el método POST se dirige a una página de error con el mensaje "¡Ha sido rechazado!". Y así, habrás protegido la nueva API del tráfico POST no deseado.

Rutas: - ruta: /café/{cafetería}/marca
coincidencias:
- condiciones:
- variable: $request_method
valor: POST
acción:
devolución:
código: 403
Tipo: texto/sin formato
Cuerpo: "¡Rechazado!"
- Condiciones:
- Variable: $request_method
Valor: OBTENER
acción:
contraseña: café
- ruta: /té
acción:
contraseña:té

Para obtener más detalles sobre cómo puede utilizar el enrutamiento a nivel de método y la coincidencia con páginas de error, consulte la documentación del controlador de ingreso NGINX . Para obtener un ejemplo relacionado con la seguridad sobre el uso de un controlador de ingreso para la funcionalidad de puerta de enlace de API, lea Implementación de la autenticación OpenID Connect para Kubernetes con Okta y el controlador de ingreso NGINX en nuestro blog.

Casos de uso de la puerta de enlace API Este-Oeste: Utilice una malla de servicios

No se requiere una malla de servicios (ni siquiera es útil inicialmente) para la mayoría de los casos de uso de API gateway porque la mayor parte de lo que se desea lograr puede, y debe, suceder en la capa de ingreso. Pero a medida que su arquitectura aumenta en complejidad, es más probable que obtenga valor al utilizar una malla de servicios. Los casos de uso que consideramos más beneficiosos están relacionados con E2EE y la división del tráfico , como pruebas A/B, implementaciones canarias e implementaciones azul-verde.

Escenario de muestra: Despliegue de Canary

Desea configurar una implementación canaria entre servicios con enrutamiento condicional basado en criterios HTTP/S.

La ventaja es que puedes implementar gradualmente cambios en la API (como nuevas funciones o versiones) sin afectar la mayor parte de tu tráfico de producción.

Actualmente, su controlador de ingreso NGINX enruta el tráfico entre dos servicios administrados por NGINX Service Mesh: Café.puertadelantera.svc y Té.puertadelantera.svc . Estos servicios reciben tráfico del controlador de ingreso NGINX y lo dirigen a las funciones de aplicación adecuadas, incluido Tea.cream1.svc . Decides refactorizar Tea.cream1.svc y llamar a la nueva versión Tea.cream2.svc . Desea que sus evaluadores beta brinden comentarios acerca de la nueva funcionalidad, por lo que configura una división de tráfico canario basada en la cookie de sesión única de los evaluadores beta, asegurando así que sus usuarios habituales solo experimenten Tea.cream1.svc .

Al utilizar NGINX Service Mesh, comienza creando una división de tráfico entre todos los servicios gestionados por Tea.frontdoor.svc , incluidos Tea.cream1.svc y Tea.cream2.svc . Para habilitar el enrutamiento condicional, crea un recurso HTTPRouteGroup (llamado tea-hrg ) y lo asocias con la división del tráfico; el resultado es que solo las solicitudes de tus usuarios beta (solicitudes con la cookie de sesión establecida en version=beta ) se enrutan desde Tea.frontdoor.svc a Tea.cream2.svc . Sus usuarios habituales continúan experimentando solo los servicios de la versión 1 detrás de Tea.frontdoor.svc .

apiVersion: split.smi-spec.io/v1alpha3tipo: División de tráfico
Metadatos:
Nombre: tea-svc
Especificación:
Servicio: tea.1
Backends:
Servicio: tea.1
Peso: 0
- servicio: té.2
peso: 100
coincidencias:
- tipo: Grupo de Rutas HTTP
Nombre: tea-hrg

Versión de API: specs.smi-spec.io/v1alpha3
Tipo: HTTPRouteGroup
Metadatos:
Nombre: tea-hrg
Espacio de nombres: predeterminado
Especificación:
Coincidencias:
- Nombre: cookie de sesión beta
Encabezados:
- Cookie: "versión=beta"

Este ejemplo inicia su implementación canaria con una división de 0 a 100, lo que significa que todos sus evaluadores beta experimentan Tea.cream2.svc , pero, por supuesto, puede comenzar con cualquier proporción que se alinee con su estrategia de prueba beta. Una vez que se complete la prueba beta, puede usar una implementación canaria simple (sin el enrutamiento de cookies) para probar la resistencia de Tea.cream2.svc .

Consulte nuestra documentación para obtener más detalles sobre las divisiones de tráfico con NGINX Service Mesh. La configuración de división de tráfico anterior es autorreferencial, ya que el servicio raíz también figura como servicio de backend. Esta configuración no es compatible actualmente con la especificación de la interfaz de Service Mesh ( smi-spec ); sin embargo, la especificación está actualmente en versión alfa y está sujeta a cambios.

Cuándo (y cómo) utilizar una herramienta API Gateway para aplicaciones de Kubernetes

Si bien la mayoría de los casos de uso de API gateway para Kubernetes pueden (y deben) ser abordados por un controlador de Ingress o una malla de servicios, hay algunas situaciones especializadas en las que una herramienta de API gateway, como NGINX Plus, es adecuada.

Requisitos comerciales

Si bien varios equipos o proyectos pueden compartir un conjunto de controladores de Ingress, o los controladores de Ingress pueden especializarse por entorno, existen motivos por los que podría optar por implementar un API gateway dedicado dentro de Kubernetes en lugar de aprovechar el controlador de Ingress existente. El uso de un controlador de ingreso y una puerta de enlace API dentro de Kubernetes puede brindar flexibilidad a las organizaciones para lograr los requisitos comerciales. Algunos escenarios incluyen:

• Su equipo de API Gateway no está familiarizado con Kubernetes y no usa YAML. Por ejemplo, si se sienten cómodos con la configuración de NGINX, entonces se reduce la fricción y se disminuye la curva de aprendizaje si implementan NGINX Plus como una puerta de enlace de API en Kubernetes.
• Su equipo de operaciones de plataforma prefiere dedicar el controlador de Ingress únicamente a la gestión del tráfico de la aplicación.
• Tiene un caso de uso de API Gateway que solo se aplica a uno de los servicios de su clúster. En lugar de utilizar un controlador de ingreso para aplicar una política a todo el tráfico de norte a sur, puede implementar una puerta de enlace API para aplicar la política solo donde sea necesaria.

Migración de API a entornos de Kubernetes

Al migrar API existentes a entornos de Kubernetes, puede publicar esas API en una herramienta de puerta de enlace de API que esté implementada fuera de Kubernetes. En este escenario, el tráfico de API generalmente se enruta a través de un balanceador de carga externo (para equilibrar la carga entre clústeres), luego a un balanceador de carga configurado para funcionar como puerta de enlace de API y, finalmente, al controlador de Ingress dentro de su clúster de Kubernetes.

Compatibilidad con API SOAP en Kubernetes

Si bien la mayoría de las API modernas se crean utilizando REST (en parte porque los servicios y API RESTful o gRPC pueden aprovechar al máximo la plataforma Kubernetes), es posible que aún tenga algunas API SOAP que no hayan sido rediseñadas. Si bien las API SOAP no se recomiendan para Kubernetes porque no están optimizadas para microservicios, es posible que termine necesitando implementar una API SOAP en Kubernetes hasta que pueda rediseñarse. 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. Si bien puedes realizar esta funcionalidad con un controlador Ingress, no lo recomendamos porque consume muchos recursos. En su lugar, recomendamos implementar una herramienta de puerta de enlace de API como un 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 pequeño de nuestros clientes están interesados en administrar API que abarcan dentro y fuera de entornos de Kubernetes. Si una estrategia de gestión de API es una prioridad mayor que la selección de herramientas nativas de Kubernetes, entonces 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 correcta.

Nota:  A diferencia de las herramientas nativas de Kubernetes, las herramientas compatibles con Kubernetes (también llamadas "Kubernetes-accommodative ") no fueron diseñadas para Kubernetes y no se pueden administrar mediante configuraciones de Kubernetes. Sin embargo, son ágiles y ligeras, lo que les permite funcionar en Kubernetes sin añadir latencia significativa ni requerir soluciones alternativas complejas.

Introducción a NGINX

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

Herramientas nativas de Kubernetes:

• Controlador de ingreso NGINX : controlador de ingreso basado en NGINX Plus para Kubernetes que maneja control y modelado de tráfico avanzado, monitoreo y visibilidad, y autenticación e inicio de sesión único (SSO) .
• Malla de servicio NGINX : malla de servicio liviana, llave en mano y fácil de usar para desarrolladores que incluye NGINX Plus como complemento empresarial.

Comience solicitando su prueba gratuita de 30 días de NGINX Ingress Controller con NGINX App Protect WAF y DoS, y descargue NGINX Service Mesh siempre gratuito.

Para una puerta de enlace de API compatible con Kubernetes dentro o fuera de sus entornos de Kubernetes:

• NGINX Plus : Balanceador de carga, proxy inverso, servidor web y puerta de enlace API todo en uno con funciones 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 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 Cómo implementar NGINX como puerta de enlace de API .