En casi todos los seminarios web sobre controladores de ingreso (Ingress Controller) y mallas de servicio (Service Mesh) que hemos entregado durante el transcurso de 2021, hemos escuchado algunas variaciones de las preguntas "¿En qué se diferencia esta herramienta de una puerta de enlace API (API Gateway)?" o "¿Necesito una puerta de enlace de API y un controlador de entrada (o malla de servicio) en Kubernetes?"
La confusión es totalmente comprensible por dos razones:
-
Los controladores de entrada y las mallas de servicio pueden cumplir con muchos casos de uso de puerta de enlace API.
-
Algunos proveedores posicionan su herramienta de puerta de enlace API como una alternativa al uso de un controlador de ingreso o una malla de servicio, o combinan las tres capacidades en una sola herramienta.
Definiciones
En sus núcleos, las puertas de enlace API, los controladores de entrada y las mallas de servicio son cada uno un tipo de proxy, diseñado para generar tráfico en sus entornos y sus alrededores.
¿Qué es una puerta de enlace API (API Gateway)?
Una puerta de enlace de API enruta las solicitudes de API de un cliente a los servicios adecuados. Pero un gran malentendido acerca de esta simple definición es la idea de que una puerta de enlace API es una pieza única de tecnología. No lo es. Más bien, "puerta de enlace API" describe un conjunto de casos de uso que se pueden implementar a través de diferentes tipos de proxies, más comúnmente un ADC o equilibrador de carga y proxy inverso, y cada vez más un controlador de ingreso o una malla de servicios.
No hay mucho acuerdo en la industria sobre qué capacidades son "imprescindibles" para que una herramienta sirva como puerta de enlace API. Por lo general, vemos clientes que requieren las siguientes habilidades (agrupadas por caso de uso):
Casos de uso de resiliencia
-
Pruebas A/B, despliegue canario e despliegue azul-verde.
-
Transformación de protocolo (entre JSON y XML, por ejemplo).
-
Limitación de velocidad.
-
Descubrimiento de servicios.
Casos de uso de gestión de tráfico
-
Enrutamiento y coincidencia basados en métodos.
-
Encabezado de solicitud/respuesta y manipulación del cuerpo.
-
Solicitar enrutamiento en la capa 7.
Casos de uso de seguridad
-
Aplicación del esquema de API.
-
Autenticación y autorización del cliente.
-
Respuestas personalizadas.
-
Control de acceso detallado.
-
Terminación de TLS.
Casi todos estos casos de uso se usan comúnmente en Kubernetes. La transformación de protocolos y la manipulación del cuerpo y encabezado de solicitud/respuesta son menos comunes, ya que generalmente están vinculadas a API heredadas que no son adecuadas para entornos de microservicios y Kubernetes.
¿Qué es un controlador de ingreso (Ingress Controller)?
Un controlador de entrada (también llamado controlador de entrada de Kubernetes - KIC para abreviar) es un proxy especializado de capa 4 y capa 7 que recibe tráfico en Kubernetes, a los servicios y vuelve a salir (lo que se conoce como entrada-salida o tráfico norte-sur). Además de la gestión del tráfico, los controladores de ingreso también se pueden utilizar para la visibilidad y la resolución de problemas, la seguridad y la identidad, y todos los casos de uso de la puerta de enlace API menos los más avanzados.
¿Qué es una malla de servicios (Service Mesh)?
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 usa 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 servicios se puede utilizar como una puerta de enlace 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 servicios .
Obtenga más información sobre la malla de servicios, y cuándo estará listo para utilizar una, en Cómo elegir una malla de servicios.
Utilice herramientas nativas de Kubernetes para entornos de Kubernetes
Como escuchamos de Mark Church en su discurso de apertura 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 servicio seguirán pareciéndose cada vez más entre sí y proporcionando capacidades similares”. Estamos totalmente de acuerdo con esta declaración y agregamos además que se trata de elegir la herramienta adecuada para el trabajo en función de dónde (y cómo) la usará. Después de todo, se usan tanto un machete como un cuchillo de mantequilla para cortar, pero probablemente no usará el primero en sus tostadas matutinas.
Entonces, ¿cómo decides qué herramienta es la adecuada para ti? Lo haremos simple: si necesita la funcionalidad de puerta de enlace API dentro de Kubernetes, generalmente es mejor elegir una herramienta que se pueda configurar utilizando herramientas de configuración nativas de Kubernetes como YAML. Por lo general, es un controlador de ingreso o una malla de servicios. Pero lo escuchamos decir: "Mi herramienta de puerta de enlace API tiene muchas más funciones que mi controlador de ingreso (o malla de servicio), ¿no me lo estoy perdiendo?" ¡No! Más funciones no equivalen a una mejor herramienta, especialmente dentro de Kubernetes, donde la complejidad de la herramienta puede ser fatal.
Nota: Kubernetes-native (no es lo mismo que Knative) se refiere a herramientas que fueron diseñadas y creadas para Kubernetes. Por lo general, funcionan con la CLI de Kubernetes, se pueden instalar mediante Helm e integrarse con las funciones de Kubernetes.
La mayoría de los usuarios de Kubernetes prefieren las herramientas que pueden configurar de forma nativa de Kubernetes porque eso evita cambios en el desarrollo o la experiencia de GitOps. Una herramienta compatible con YAML ofrece tres ventajas 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 sus equipos a trabajar dentro de su conjunto de habilidades existente sin la necesidad de aprender a configurar una nueva herramienta que solo pueden usar ocasionalmente.
-
Puede automatizar una herramienta compatible con YAML de la misma manera que sus otras herramientas de Kubernetes. Todo lo que se adapte perfectamente a sus flujos de trabajo será popular entre su equipo, lo que aumentará la probabilidad de que lo utilicen.
-
Puede reducir la pila de herramientas de gestión del tráfico de Kubernetes mediante el controlador de ingreso, la malla de servicios o ambos. Después de todo, cada salto adicional es importante 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 seguridad general.
Casos de uso de la puerta de enlace de API Norte-Sur: utilice un controlador de ingreso
Los controladores de ingreso tienen el potencial de habilitar muchos casos de uso de puerta de enlace API. Además de los descritos en Definiciones, encontramos que las organizaciones valoran más un controlador de ingreso 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 protocolo (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 mediante el controlador de ingreso para rechazar el POST método en las solicitudes de API.
Algunos atacantes buscan vulnerabilidades en las API enviando tipos de solicitud que no cumplen con una definición de API, por ejemplo, enviando POST solicitudes a una API que está definida para aceptar solo GET solicitudes. Los firewalls de aplicaciones web (WAF) no pueden detectar este tipo de ataques; solo examinan las cadenas de solicitud y los cuerpos para detectar ataques, por lo que es una buena práctica usar una puerta de enlace API en la capa de ingreso para bloquear las solicitudes incorrectas.
Como ejemplo, suponga que la nueva API /coffee/{coffee-store}/brand se acaba de agregar a su clúster. El primer paso es exponer la API usando NGINX Ingress Controller, simplemente agregando la API al campo upstreams.
apiVersion: k8s.nginx.org/v1
kind: 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, agregue una ruta /coffee/{coffee-store}/brand al campo routes y agregue dos conditions que usen la variable $request_method para distinguir entre solicitudes GET y POST. Cualquier tráfico HTTP que utilice el método GET se pasa automáticamente al servicio coffee. El tráfico que utiliza el método POST se dirige a una página de error con el mensaje "You are rejected!". Y así, ha protegido la nueva API del 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: "You are rejected!"
- conditions:
- variable: $request_method
value: GET
action:
pass: coffee
- path: /tea
action:
pass:tea
Casos de uso de la puerta de enlace de API Este-Oeste: utilice una malla de servicios
No se requiere una malla de servicio, ni siquiera es inicialmente útil, para la mayoría de los casos de uso de puerta de enlace API porque la mayor parte de lo que podría querer 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 usar 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 las pruebas A/B, los despliegues canarios y los despliegues azul-verde.
Escenario de muestra: despliegues de Canary
Desea configurar un despliegue canario entre servicios con enrutamiento condicional basado en criterios HTTP/S.
La ventaja es que puede implementar cambios de API gradualmente, como nuevas funciones o versiones, sin afectar la mayor parte de su tráfico de producción.
Actualmente, su NGINX Ingress Controller enruta el tráfico entre dos servicios administrados por NGINX Service Mesh: Coffee.frontdoor.svc y Tea.frontdoor,svc. Estos servicios reciben tráfico de NGINX Ingress Controller y lo enrutan a las funciones apropiadas de la aplicación, incluidas Tea.cream1.svc. Decides refactorizar Tea.cream1.svc, llamando a la nueva versión Tea.cream2.svc. Desea que sus probadores beta proporcionen comentarios sobre la nueva funcionalidad para que configure una división de tráfico canario basada en la cookie de sesión única de los probadores beta, asegurando que sus usuarios habituales solo experimenten Tea.cream1.svc.
Al usar NGINX Service Mesh, comienza creando una división de tráfico entre todos los servicios al frente Tea.frontdoor.svc, incluidos Tea.cream1.svc y Tea.cream2.svc. Para habilitar el enrutamiento condicional, crea un recurso HTTPRouteGroup (con nombre tea-hrg) y lo asocia con la división del tráfico, el resultado es que solo las solicitudes de sus usuarios beta (solicitudes con la cookie de sesión configurada 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 por detrás Tea.frontdoor.svc.
apiVersion: split.smi-spec.io/v1alpha3
kind: 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 su implementación canario con una división de 0 a 100, es decir, toda la experiencia de los probadores beta 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 simple de canario (sin el enrutamiento de cookies) para probar la resistencia de Tea.cream2.svc.
Consulte nuestros documentos para obtener más detalles sobre las divisiones de tráfico con NGINX Service Mesh. La configuración de división del tráfico anterior 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 la interfaz de malla de servicio (smi-spec); sin embargo, la especificación está actualmente en alfa y está sujeta a cambios.
Cuándo (y cómo) utilizar una herramienta de puerta de enlace API para aplicaciones de Kubernetes
Aunque la mayoría de los casos de uso de la puerta de enlace API para Kubernetes pueden (y deben) ser abordados por un controlador de ingreso o una malla de servicio, existen algunas situaciones especializadas en las que una herramienta de puerta de enlace API, como NGINX Plus, es adecuada.
Requisitos comerciales
Si bien varios equipos o proyectos pueden compartir un conjunto de controladores de ingreso, o los controladores de ingreso pueden especializarse por entorno, existen razones por las que puede optar por implementar una puerta de enlace API dedicada dentro de Kubernetes en lugar de aprovechar el controlador de ingreso 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 puerta de enlace de API no está familiarizado con Kubernetes y no usa YAML. Por ejemplo, si se sienten cómodos con la configuración de NGINX, alivia la fricción y disminuye la curva de aprendizaje si implementan NGINX Plus como una puerta de enlace API en Kubernetes.
-
Su equipo de Platform Ops prefiere dedicar el controlador de ingreso solo a la gestión del tráfico de aplicaciones.
-
Tiene un caso de uso de puerta de enlace API que solo se aplica a uno de los servicios en su clúster. En lugar de utilizar un controlador de ingreso para aplicar una política a todo su tráfico norte-sur, puede implementar una puerta de enlace API para aplicar la política solo donde sea necesario.
Migración de API a entornos de Kubernetes
Al migrar las API existentes a los entornos de Kubernetes, puede publicar esas API en una herramienta de puerta de enlace de API que se implemente fuera de Kubernetes. En este escenario, el tráfico de API generalmente se enruta a través de un balanceador de carga externo (para balancear la carga entre clústeres), luego a un balanceador de carga configurado para servir como una puerta de enlace de API y finalmente al controlador de ingreso dentro de su clúster de Kubernetes.
Compatibilidad con las API de SOAP en Kubernetes
Si bien la mayoría de las API modernas se crean mediante REST, en parte porque los servicios RESTful o gRPC y las API pueden aprovechar al máximo la plataforma Kubernetes, es posible que aún tenga algunas API de SOAP que no se hayan reestructurado. Si bien las API de SOAP no se recomiendan para Kubernetes porque no están optimizadas para microservicios, puede terminar necesitando implementar una API de SOAP en Kubernetes hasta que se pueda volver a diseñar. Es probable que la API necesite comunicarse con los clientes de API basados en REST, en cuyo caso necesita una forma de traducir entre los protocolos SOAP y REST. Si bien puede realizar esta funcionalidad con un controlador de ingreso, no lo recomendamos porque consume muchos recursos. En su lugar, recomendamos implementar una herramienta de puerta de enlace API como un proxy peer-pod o peer-service 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á interesado en administrar API que abarquen dentro y fuera de los entornos de Kubernetes. Si una estrategia de administración de API es una prioridad más alta que la selección de herramientas nativas de Kubernetes, entonces una puerta de enlace de API "compatible con Kubernetes" (que se pueda integrar con una solución de administración de API) implementada en Kubernetes podría ser la elección correcta.
Nota: A diferencia de las herramientas nativas de Kubernetes, las herramientas compatibles con Kubernetes (a veces también llamadas adaptativas de Kubernetes) no se diseñaron para Kubernetes y no se pueden administrar mediante las configuraciones de Kubernetes. Sin embargo, son ágiles y ligeros, lo que les permite funcionar en Kubernetes sin agregar una latencia significativa ni requerir grandes soluciones.
Introducción a NGINX
NGINX ofrece opciones para los tres tipos de escenarios de implementación.
Kubernetes - herramientas nativas:
-
NGINX Ingress Controller: controlador de ingreso basado en NGINX Plus para Kubernetes que maneja control y modelado de tráfico avanzados, monitoreo y visibilidad, autenticación e inicio de sesión único (SSO).
-
NGINX Service Mesh: malla de servicios ligera, llave en mano y amigable para los desarrolladores que presenta NGINX Plus como un sidecar 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 API compatible con Kubernetes dentro o fuera de sus entornos de Kubernetes:
-
NGINX Plus: el equilibrador de carga todo en uno, el proxy inverso, el servidor web y la puerta de enlace API con funciones de nivel empresarial como alta disponibilidad, comprobaciones de estado activas, descubrimiento del sistema DNS, persistencia de la sesión y una API RESTful. Se integra con NGINX Controller para una solución completa del ciclo de vida de la API.