Información general
Cloud Service Mesh ofrece funciones de redes de servicios a tus aplicaciones, como gestión avanzada del tráfico, observabilidad y seguridad. Sin embargo, configurar y operar una malla de servicios es una tarea compleja. En esta página se describe cómo configurar Cloud Service Mesh con las APIs Gateway de Kubernetes. Estas APIs se han diseñado para simplificar y mejorar tu experiencia general de configuración de la malla.
Las APIs de Kubernetes Gateway para Mesh te permiten configurar Cloud Service Mesh para despliegues de gRPC sin proxy y de proxy de Envoy. La API Gateway para el modelo de malla ofrece varias ventajas clave:
- Las APIs de Gateway proporcionan una interfaz única y coherente para gestionar el tráfico de entrada (norte-sur) y de malla de servicios (este-oeste) en tu clúster de Kubernetes.
- Las mallas de servicios permiten patrones de enrutamiento de tráfico avanzados. Las APIs de pasarela te permiten diseñar y gestionar reglas de enrutamiento complejas.
- Con las APIs de Gateway, los desarrolladores pueden centrarse en definir reglas y políticas de enrutamiento de alto nivel para su microservicio sin necesidad de tener un conocimiento profundo de la implementación de la malla de servicios subyacente.
- La API se ha diseñado para que sea extensible, lo que permite futuras mejoras y la compatibilidad con nuevos protocolos y casos prácticos.
- Las APIs de pasarela cuentan con un gran respaldo de la comunidad y con un ecosistema cada vez mayor de proveedores y herramientas de malla de servicios.
El trabajo de la iniciativa GAMMA para admitir casos prácticos de malla de servicios forma parte del canal estándar desde la versión 1.1.0 y se considera GA.
La especificación propone que el propietario de una aplicación configure las reglas de tráfico de un servicio de malla configurando un Route resource (a veces denominado xRoute) con un recurso Service de Kubernetes como parentRef. El enfoque depende de los roles "frontend" y "backend" de Kubernetes Service, tal como se definen en GEP-1324: Service Mesh in Gateway API. El rol "frontend" se usa como parentRef y el rol "backend" de Service se usa como backendRef. La implementación conforme usa el nombre Service para asociar el tráfico y los endpoints backendRef con las direcciones IP canónicas.
API Gateway para Mesh
API Gateway, un proyecto de Kubernetes, se centra en el enrutamiento de las capas 4 y 7 en Kubernetes. Sustituye a las APIs Ingress, Load Balancing y Service Mesh. Se ha diseñado para que sea versátil, descriptivo y centrado en los roles, y sus configuraciones se encuentran principalmente en la capa de enrutamiento.
Los recursos específicos de protocolos, como HTTPRoute y GRPCRoute, permiten el enrutamiento avanzado de entrada y de malla.
La iniciativa GAMMA (API Gateway para Service Mesh) define cómo se puede usar la API Gateway para el tráfico entre servicios o este-oeste dentro del mismo clúster. El objetivo de GAMMA es establecer cómo usar la API Gateway para configurar una malla de servicios con el mínimo de modificaciones en la API Gateway, manteniendo su naturaleza orientada a los roles. GAMMA también destaca la importancia de fomentar la coherencia entre las distintas implementaciones de malla de servicio de la API Gateway, independientemente de su tecnología o proxy subyacentes.
GAMMA aprovecha los puntos de extensibilidad de la especificación de la API Gateway, por lo que no requiere cambios en la API ni nuevos recursos. Para ello, se amplían las definiciones de recursos de ruta (GRPCRoute o HTTPRoute en la API Gateway) para indicar el caso práctico de la malla de servicios. En concreto, se asocian los recursos de ruta con los recursos de servicio, tal como se describe en API Gateway para malla de servicios.
En el siguiente ejemplo se ilustra el caso práctico de malla en el uso de HTTPRoute:
apiVersion: gateway.networking.k8s.io
kind: HTTPRoute
metadata:
name: echo-route
spec:
parentRefs:
- kind: Service
group: ""
name: echo-service
rules:
- backendRefs:
- name: echo-v1
port: 80
weight: 9
- backendRefs:
- name: echo-v2
port: 80
weight: 1
HTTPRoute hace referencia a un Service como su parentRef, lo que indica que la ruta de HTTPRoute está configurada para el caso de uso de malla de servicios. En el ejemplo anterior, el servicio echo-service se especifica como parentRef, lo que significa que HTTPRoute se adjunta al frontend de echo-service. El tráfico que un cliente envíe a echo-service se enrutará según la ruta HTTP echo-route.
GRPCRoute es otro recurso de la API Gateway de Kubernetes que se usa para enrutar el tráfico de gRPC a los servicios de Kubernetes. Los usuarios eligen usar GRPCRoute en lugar de HTTPRoute cuando quieren enrutar específicamente el tráfico de gRPC y aprovechar las funciones diseñadas para gRPC, como la coincidencia de métodos y servicios de gRPC.
En el siguiente ejemplo se muestra el uso de GRPCRoute:
apiVersion: gateway.networking.k8s.io
kind: GRPCRoute
metadata:
name: echo-route
spec:
parentRefs:
- kind: Service
group: ""
name: echo-service
rules:
- matches:
- method:
service:echo_basic.grpcecho.GrpcEcho
method: Echo
backendRefs:
- name: grpc-infra-backend-v1
port: 8080
- matches:
- method:
service:echo_basic.grpcecho.GrpcEcho
method: EchoTwo
backendRefs:
- name: grpc-infra-backend-v2
port: 8080
Al igual que en el ejemplo de HTTPRoute, este GRPCRoute se ha configurado para casos prácticos de malla de servicios. El tráfico que envíe un cliente gRPC sin proxy a xds:///echo-service.default.svc.cluster.local:8080
se enrutará según la ruta de eco de GRPCRoute. Las reglas de ruta de este ejemplo coinciden con un método gRPC y dirigen el tráfico a un backendRef específico. GRPCRoutes también se puede usar para enrutar solicitudes de clientes proxy con inyecciones de sidecar, como Envoy, cuando se elimina el prefijo xds:///.
