Descripción general
Cloud Service Mesh proporciona funciones de redes de servicios a tus aplicaciones, incluida la administración avanzada del tráfico, la observabilidad y la 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 de Gateway de Kubernetes. Estas APIs están diseñadas para simplificar y mejorar tu experiencia general con la configuración de mallas.
Las APIs de puerta de enlace de Kubernetes para Mesh te permiten configurar Cloud Service Mesh para implementaciones de proxies de Envoy y de gRPC sin proxy. El modelo de la API de Gateway para Mesh ofrece varios beneficios clave:
- Las APIs de Gateway proporcionan una interfaz única y coherente para administrar el tráfico de entrada (norte-sur) y de malla de servicios (este-oeste) dentro de tu clúster de Kubernetes.
- Las mallas de servicios habilitan patrones avanzados de enrutamiento del tráfico. Las APIs de Gateway te permiten diseñar y administrar reglas de enrutamiento complejas.
- Con las APIs de Gateway, los desarrolladores pueden enfocarse en definir reglas y políticas de enrutamiento de alto nivel para sus microservicios sin necesidad de tener un conocimiento profundo de la implementación de la malla de servicios subyacente.
- La API está diseñada para ser extensible, lo que permite mejoras futuras y compatibilidad con nuevos protocolos y casos de uso.
- Las APIs de Gateway tienen un fuerte respaldo de la comunidad y son compatibles con un ecosistema en crecimiento de proveedores y herramientas de malla de servicios.
El trabajo de la iniciativa GAMMA para admitir casos de uso de malla de servicios forma parte del canal estándar desde la versión 1.1.0 y se considera de DG.
La especificación
propone que el propietario de una aplicación configure reglas de tráfico para 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 de "frontend" y "backend" de Service de Kubernetes, como se define en
GEP-1324: Malla de servicios en la API de Gateway,
en el que el rol de "frontend" se usa como un parentRef y el rol de "backend" de
Service se usa como un backendRef. La implementación conforme usa el nombre Service para hacer coincidir el tráfico y los extremos backendRef para las direcciones IP canónicas.
API de Gateway para Mesh
La API de Gateway, un proyecto de Kubernetes, se enfoca en el enrutamiento de las capas 4 y 7 dentro de Kubernetes. Sucede a las APIs de Ingress,
balanceo de cargas y malla de servicios. Diseñado para ser versátil, descriptivo
y centrado en los roles, sus configuraciones se encuentran principalmente en la capa de enrutamiento.
Los recursos específicos del protocolo, como HTTPRoute y GRPCRoute, habilitan el enrutamiento avanzado de entrada y de malla.
La iniciativa GAMMA (API de Gateway para la malla de servicios) define cómo se puede usar la API de Gateway para el tráfico entre servicios o este/oeste dentro del mismo clúster. GAMMA tiene como objetivo establecer cómo usar la API de Gateway para configurar una malla de servicios con modificaciones mínimas en la API de Gateway y, al mismo tiempo, mantener su naturaleza orientada a roles. GAMMA también destaca la importancia de promover la coherencia entre varias implementaciones de la malla de servicios de la API de Gateway, sin importar su tecnología o proxy subyacentes.
GAMMA aprovecha los puntos de extensibilidad existentes en la especificación de la API de Gateway, por lo que no requiere cambios en la API ni recursos nuevos. Esto se hace extendiendo las definiciones de recursos de ruta (GRPCRoute o HTTPRoute en la API de Gateway) para indicar el caso de uso de la malla de servicios, específicamente asociando los recursos de ruta con los recursos de Service, como se describe en API de Gateway para la malla de servicios.
En el siguiente ejemplo, se ilustra el caso de uso de la 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
La 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 la malla de servicios. En el ejemplo anterior,
el Service echo-service se especifica como parentRef, lo que significa que
HTTPRoute se adjunta al frontend de echo-service. Cualquier tráfico que un cliente envíe a
echo-service se enruta según la HTTPRoute echo-route.
GRPCRoute es otro recurso de la API de 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 adaptadas para gRPC, como la coincidencia de métodos y servicios de gRPC.
En el siguiente ejemplo, se ilustra 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, esta GRPCRoute se configura para casos de uso de malla de servicios. Cualquier tráfico que un cliente de gRPC sin proxy envíe a xds:///echo-service.default.svc.cluster.local:8080
se enruta según la GRPCRoute echo-route. Las
reglas de enrutamiento de este ejemplo coinciden con un método de gRPC y enrutan el tráfico a un
backendRef específico. Las GRPCRoutes también se pueden usar para enrutar solicitudes de
clientes con proxy con inyecciones de sidecar, como Envoy, cuando se quita el prefijo
xds:///.
