Descripción general
Cloud Service Mesh proporciona capacidades de redes de servicios a tu 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. Esta página se describe cómo configurar Cloud Service Mesh con la con las APIs de puerta de enlace de Google. Estas APIs están diseñadas para simplificar y mejorar la malla general de configuración de Terraform.
Las APIs de Kubernetes Gateway para mallas te permiten configurar Cloud Service Mesh para las implementaciones de proxy de Envoy y gRPC sin proxy. La API de puerta de enlace para el modelo de malla permite 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 de tráfico. Las APIs de puerta de enlace permiten te permite diseñar y administrar reglas de enrutamiento complejas.
- Con las APIs de puerta de enlace, los desarrolladores pueden enfocarse en definir reglas de enrutamiento de alto nivel y políticas a su microservicio sin necesidad de un conocimiento profundo en la implementación de la malla de servicios subyacente.
- La API está diseñada para ser extensible, lo que permite futuras mejoras y la compatibilidad con nuevos protocolos y casos de uso.
- Las APIs de la puerta de enlace tienen un sólido respaldo de la comunidad y son compatibles con un ecosistema en crecimiento de herramientas y proveedores de malla de servicios.
La iniciativa GAMMA funciona para los casos de uso de la malla de servicios sean parte del canal Standard v1.1.0 y se considera de disponibilidad general.
La spec
propone que el propietario de una aplicación configure las reglas de tráfico para una malla
servicio mediante la configuración de un Route resource (también 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: Service Mesh in Gateway API, en el que el rol de "frontend" se usa como parentRef y el rol de "backend" de Service se usa como backendRef. La implementación conforme usa el elemento
El nombre Service para que coincida con el tráfico y los extremos backendRef de la IP canónica
direcciones IP del proveedor.
API de puerta de enlace para mallas
API de puerta de enlace, una API
se enfoca en el enrutamiento de las capas 4 y 7 en Kubernetes. Tiene éxito Ingress,
balanceo de cargas
y APIs de Service Mesh. Diseñado para ser versátil, descriptivo y
y centrado en los roles, sus configuraciones están,
principalmente, en la capa de enrutamiento.
Los recursos específicos del protocolo, como HTTPRoute y GRPCRoute, habilitan el enrutamiento avanzado de entrada y malla.
GAMMA Initiative (API de Gateway) para Service Mesh) define cómo se puede usar la API de puerta de enlace también para la o tráfico del este/oeste dentro del mismo clúster. El objetivo de GAMMA es establecer cómo usar la API de puerta de enlace para configura una malla de servicios con modificaciones mínimas en la API de puerta de enlace, mientras para mantener su orientado a roles natural. GAMMA también enfatiza la importancia de promover la coherencia entre varias implementaciones de malla de servicios de la API de puerta de enlace, sin importar su tecnología subyacente o proxy.
GAMMA aprovecha los puntos de extensibilidad existentes en la especificación de la API de puerta de enlace, lo que requiere sin cambios en la API ni recursos nuevos. Para ello, se extiende el recurso de ruta definiciones (GRPCRoute o HTTPRoute en la API de puerta de enlace) para indicar el caso de uso de la malla de servicios, en particular asociando los recursos de ruta con los recursos de servicio como se describe en API de Gateway para Service Mesh.
En el siguiente ejemplo, se ilustra el caso de uso de la malla cuando se usa 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 una Service como su parentRef, lo que indica que la
La ruta HTTPRoute se configura para el caso de uso de la 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. Cualquier tráfico enviado a
El servicio echo de un cliente se enruta de acuerdo con la ruta echo-route de HTTP.
GRPCRoute es otro recurso de la API de Kubernetes Gateway 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 tráfico de gRPC y aprovechar de funciones adaptadas para gRPC, como el método de gRPC y la coincidencia de servicios.
El siguiente ejemplo 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
Como en el ejemplo de HTTPRoute, esta GRPCRoute está configurada para malla de servicios
casos de uso. 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 ruta de eco de GRPCRoute. El
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
clientes con proxy con inyecciones de sidecar, como Envoy, cuando el prefijo xds:///
se descarta.
