Gestión del tráfico de la pasarela

En esta página se explica cómo funciona la gestión del tráfico de Gateway.

Esta página está dirigida a desarrolladores, operadores y especialistas en redes que quieran desplegar y gestionar el tráfico mediante la API Gateway.

Información general

La red de Google Kubernetes Engine (GKE) se basa en Cloud Load Balancing. Con Cloud Load Balancing, una sola dirección IP anycast gestiona el tráfico global. La gestión del tráfico de Google ofrece balanceo de carga global y regional, autoescalado y gestión de la capacidad para proporcionar una distribución del tráfico equilibrada, estable y de baja latencia. Con el controlador Gateway de GKE, los usuarios de GKE pueden utilizar el control de gestión del tráfico global de Google de forma declarativa y nativa de Kubernetes.

Para probar el desbordamiento de tráfico entre clústeres, consulta Implementar el balanceo de carga basado en la capacidad. Para probar el autoescalado basado en el tráfico, consulta Autoescalado basado en el tráfico del balanceador de carga.

Gestión del tráfico

El balanceo de carga, el autoescalado y la gestión de la capacidad son los pilares de un sistema de gestión del tráfico. Funcionan conjuntamente para igualar y estabilizar la carga del sistema.

• El balanceo de carga distribuye el tráfico entre los pods de backend según la ubicación, el estado y los diferentes algoritmos de balanceo de carga.
• El autoescalado escala las réplicas de la carga de trabajo para crear más capacidad y absorber más tráfico.
• La gestión de la capacidad monitoriza el uso de los Servicios para que el tráfico pueda derivarse a backends con capacidad en lugar de afectar a la disponibilidad o el rendimiento de las aplicaciones.

Estas funciones se pueden combinar de diferentes formas en función de tus objetivos. Por ejemplo:

• Si quieres aprovechar las máquinas virtuales de Spot de bajo coste, puedes optimizar la distribución uniforme del tráfico entre las máquinas virtuales de Spot a costa de la latencia. Con el balanceo de carga y la gestión de la capacidad, GKE desviaría el tráfico entre regiones en función de la capacidad para que las VMs spot se utilicen por completo donde estén disponibles.

• Si quieres optimizar la latencia de los usuarios a costa de un aprovisionamiento excesivo, puedes desplegar clústeres de GKE en muchas regiones y aumentar la capacidad de forma dinámica donde aumente la carga. Con el balanceo de carga y el escalado automático, GKE escalaría automáticamente el número de pods cuando se produjeran picos de tráfico, de modo que el tráfico no tendría que desbordarse a otras regiones. Las regiones aumentarían su capacidad para poder gestionar la carga por completo lo más cerca posible de los usuarios.

En el siguiente diagrama se muestra cómo funcionan conjuntamente el balanceo de carga, el autoescalado y la gestión de la capacidad:

En el diagrama, la carga de trabajo del clúster gke-us ha fallado. El balanceo de carga y la comprobación del estado agotan las conexiones activas y redirigen el tráfico al clúster más cercano. La carga de trabajo de gke-asia recibe más tráfico del que puede gestionar, por lo que deriva carga a gke-eu. El gke-eu recibe más carga de lo habitual debido a los eventos de gke-us y gke-asia, por lo que gke-eu se ajusta automáticamente para aumentar su capacidad de tráfico.

Para obtener más información sobre cómo gestiona el tráfico Cloud Load Balancing, consulta la sección sobre la gestión de la capacidad global.

Funciones de gestión del tráfico y extensiones de servicio

Los recursos Gateway, HTTPRoute, Service y Policy proporcionan los controles para gestionar el tráfico en GKE. El controlador de GKE Gateway es el plano de control que monitoriza estos recursos.

Las extensiones de servicio de GKE Gateway personalizan y amplían la gestión del tráfico en GKE. Las extensiones insertan lógica personalizada para controlar el tráfico avanzado.

Las siguientes funciones de gestión del tráfico están disponibles al implementar servicios en GKE:

• Capacidad de servicio: capacidad para especificar la cantidad de tráfico que puede recibir un servicio antes de que los pods se escalen automáticamente o el tráfico se desborde a otros clústeres disponibles.
• Autoescalado basado en el tráfico: autoescalado de pods en un servicio en función de las solicitudes HTTP recibidas por segundo.
• Balanceo de carga entre clústeres: la capacidad de balancear la carga de los servicios alojados en varios clústeres de GKE o en varias regiones.
• División del tráfico: distribución del tráfico explícita y basada en el peso entre los back-ends.

• Gestión del tráfico personalizada con extensiones de servicio:

  Las extensiones de servicio te permiten hacer lo siguiente:

  • Modifica los encabezados y las cargas útiles de las solicitudes y respuestas HTTP.
  • Implementa una lógica de enrutamiento personalizada para controlar el flujo de tráfico.
  • Integrarse con servicios externos para funciones como la autorización.

Asistencia para la gestión del tráfico

Las funciones de gestión del tráfico disponibles dependen de la GatewayClass que implementes. Para ver una lista completa de las funciones compatibles, consulta Funciones de GatewayClass. En la siguiente tabla se resume la compatibilidad de GatewayClass con la gestión del tráfico:

Gestión del tráfico con balanceo de carga basado en métricas personalizadas

Trusted Cloud by S3NS Los balanceadores de carga de aplicaciones distribuyen el tráfico en función de métricas personalizadas. Estas métricas pueden incluir la carga de utilización de la GPU u otras señales de utilización específicas de la aplicación. Las métricas personalizadas proporcionan una visión más precisa del rendimiento de las cargas de trabajo. Tu aplicación registra estas métricas mediante el estándar de agregación de costes de solicitudes abiertas (ORCA). Para obtener más información, consulte Métricas personalizadas de Application Load Balancer.

En GKE, puedes integrar esta función avanzada de gestión del tráfico mediante la API Gateway de GKE. La API es útil para cargas de trabajo con un uso de recursos variable, como la inferencia de IA generativa. Puede configurar un comportamiento de tráfico personalizado configurando las siguientes políticas:

• GCPBackendPolicy para la selección de backend: el recurso GCPBackendPolicy permite controlar con precisión cómo distribuyen el tráfico los servicios de backend de un balanceador de carga a sus backends. Esta política incluye campos específicos que le permiten configurar varios modos de balanceo de carga, como el uso de métricas personalizadas. Para configurar la selección de backend con GCPBackendPolicy, consulta Configurar la selección de backend con GCPBackendPolicy.

• GCPTrafficDistributionPolicy para el enrutamiento a nivel de endpoint: GCPTrafficDistributionPolicyconfigura el algoritmo de balanceo de carga para la selección de endpoints en un backend. Cuando selecciona WEIGHTED_ROUND_ROBIN, el balanceador de carga usa pesos derivados de las métricas registradas (incluidas las métricas personalizadas) para distribuir el tráfico a instancias o endpoints concretos. Para configurar las métricas a nivel de endpoint, consulta Configurar el enrutamiento a nivel de endpoint con GCPTrafficDistributionPolicy.

Políticas basadas en la ubicación

Puedes aplicar estas políticas basadas en la ubicación a zonas o regiones específicas mediante un especificador de ubicación. Trusted Cloud by S3NS Especificadores de ubicación útiles para implementaciones canary, lanzamientos por fases o pruebas de cambios en políticas en regiones aisladas. Para obtener más información, consulta Configurar recursos de Gateway con políticas.

Monitorizar métricas personalizadas de backends de GKE

Los balanceadores de carga de aplicación externos globales y los balanceadores de carga de aplicación internos proporcionan funciones de registro y monitorización que te permiten observar las métricas personalizadas que informan tus back-ends de GKE para obtener información detallada sobre el tráfico. Para obtener más información, consulta Registro y monitorización de balanceadores de carga de aplicación externos globales.

Puede usar las etiquetas de métricas de GKE para consultar métricas personalizadas por servicio, clúster y espacio de nombres de GKE.

Para ver las métricas personalizadas que comunican tus back-ends de GKE, ve a Cloud Monitoring y consulta las métricas personalizadas en el recurso monitorizado network.googleapis.com/loadbalancer/backend/. Puedes usar etiquetas específicas de GKE para consultar y filtrar estas métricas.

Entre las métricas disponibles se incluyen las siguientes:

• /error_rate: errores que ha devuelto cada grupo de backend por segundo.
• /custom_metrics: el uso actual de cada grupo de backend, en función de las métricas personalizadas que haya definido.
• /fullness: la ocupación actual (carga o capacidad) de cada grupo de backend, que los balanceadores de carga usan para tomar decisiones de enrutamiento.
• /rate: solicitudes recibidas por cada grupo de backend por segundo.

Las etiquetas específicas de GKE que mejoran la monitorización de estas métricas son gke_service_name, gke_namespace y gke_cluster. Puedes usar estas etiquetas para consultar los datos de las métricas por servicio, espacio de nombres y clúster de GKE. Ten en cuenta que estas etiquetas de GKE solo se rellenan si el valor de backend_type es ZONAL_NETWORK_ENDPOINT_GROUP.

En la siguiente tabla se enumeran las etiquetas específicas de GKE:

Las entradas de registro de los balanceadores de carga de aplicaciones externos globales contienen información útil para monitorizar y depurar el tráfico HTTP(S).

Balanceo de carga global, regional y de zona

La capacidad, la ubicación y el estado del servicio determinan la cantidad de tráfico que el balanceador de carga envía a un backend determinado. Las decisiones de balanceo de carga se toman en los siguientes niveles, empezando por el nivel global para los balanceadores de carga globales y el nivel regional para los balanceadores de carga regionales:

• Global: el tráfico se envía a la Trusted Cloud región más cercana al cliente que tenga back-ends en buen estado y con capacidad. Siempre que la región tenga capacidad, recibirá todo el tráfico más cercano. Si una región no tiene capacidad, el tráfico excedente se desvía a la región más cercana que sí tenga capacidad. Para obtener más información, consulta el artículo sobre el balanceo de carga global.
• Regional: el balanceador de carga envía el tráfico a una región específica. El tráfico se balancea entre las zonas en proporción a la capacidad de servicio disponible de cada zona. Para obtener más información, consulta Balanceo de carga regional.
• Zonal una vez que se determina el tráfico de una zona específica, el balanceador de carga distribuye el tráfico de forma uniforme entre los backends de esa zona. Se conservan las conexiones TCP y los ajustes de persistencia de sesión, de modo que las solicitudes futuras se dirijan a los mismos backends, siempre que el pod de backend esté en buen estado. Para obtener más información, consulta el artículo sobre el balanceo de carga zonal.

Balanceo de carga global y desbordamiento de tráfico

Para probar los siguientes conceptos en tu propio clúster, consulta Balanceo de carga basado en la capacidad.

En condiciones normales, el tráfico se envía al backend más cercano al cliente. El tráfico termina en el punto de presencia (PoP) de Google más cercano al cliente y, a continuación, atraviesa la red troncal de Google hasta llegar al backend más cercano, determinado por la latencia de la red. Cuando los backends de una región no tienen capacidad restante, el tráfico se desvía al clúster más cercano con backends en buen estado que tengan capacidad. Si más del 50% de los pods de backend de una zona no están en buen estado, el tráfico se conmutará gradualmente a otras zonas o regiones, independientemente de la capacidad configurada.

El desbordamiento de tráfico solo se produce en las siguientes condiciones:

• Estás usando una pasarela de varios clústeres.
• Tienes el mismo servicio desplegado en varios clústeres, servido por la puerta de enlace multiclúster.
• Has configurado las capacidades de servicio de forma que el tráfico supera las capacidades de servicio en un clúster, pero no en otros.

En el siguiente diagrama se muestra cómo funciona el balanceo de carga global con el desbordamiento de tráfico:

En el diagrama:

• Una puerta de enlace multiclúster proporciona balanceo de carga de Internet global para el storeservicio. El servicio se despliega en dos clústeres de GKE, uno en us-west1 y otro en europe-west1. Cada clúster ejecuta 2 réplicas.
• Cada servicio se configura con max-rate-per-endpoint="10", lo que significa que cada servicio tiene una capacidad total de 2 réplicas * 10 RPS = 20 RPS en cada clúster.
• Los PoPs de Google en Norteamérica reciben 6 RPS. Todo el tráfico se envía al backend en buen estado más cercano que tenga capacidad, que es el clúster de GKE de us-west1.
• Los PoPs europeos reciben 30 RPS acumulativas. Los backends más cercanos están en europe-west1, pero solo tienen una capacidad de 20 RPS. Como los backends de us-west1 tienen capacidad adicional, 10 RPS se transfieren a us-west1, que recibe 16 RPS en total y distribuye 8 RPS a cada pod.

Evitar el desbordamiento del tráfico

El desbordamiento de tráfico ayuda a evitar que se supere la capacidad de la aplicación, lo que puede afectar al rendimiento o a la disponibilidad.

Sin embargo, es posible que no quieras que el tráfico se desborde. Por ejemplo, las aplicaciones sensibles a la latencia no se beneficiarán del desbordamiento del tráfico a un backend mucho más distante.

Puede usar cualquiera de los siguientes métodos para evitar que se produzca un desbordamiento del tráfico:

• Usa solo Gateways de un solo clúster, que solo pueden alojar servicios en un único clúster.

• Incluso si se usan pasarelas de varios clústeres, las réplicas de una aplicación desplegada en varios clústeres se pueden desplegar como servicios independientes. Desde la perspectiva de la puerta de enlace, esto habilita el balanceo de carga entre clústeres, pero no agrega todos los endpoints de un servicio entre clústeres.

• Define las capacidades de los servicios en un nivel lo suficientemente alto como para que la capacidad de tráfico nunca se supere de forma realista, a menos que sea absolutamente necesario.

Balanceo de carga en una región

En una región, el tráfico se distribuye entre las zonas según las capacidades disponibles de los backends. No se trata de un desbordamiento, sino de un balanceo de carga directamente proporcional a las capacidades del servicio en cada zona. Cualquier flujo o sesión individual se envía siempre a un pod de backend único y coherente, y no se divide.

En el siguiente diagrama se muestra cómo se distribuye el tráfico en una región:

En el diagrama:

• Un servicio se ha desplegado en un clúster de GKE regional. El servicio tiene 4 pods que se han desplegado de forma desigual en las zonas. Hay 3 pods en la zona A, 1 pod en la zona B y 0 pods en la zona C.
• El servicio está configurado con maxRatePerEndpoint=10. La zona A tiene una capacidad total de 30 RPS, la zona B tiene una capacidad total de 10 RPS y la zona C tiene una capacidad total de 0 RPS, ya que no tiene pods.
• La puerta de enlace recibe un total de 16 RPS de tráfico de diferentes clientes. Este tráfico se distribuye entre las zonas en proporción a la capacidad restante de cada zona.
• El flujo de tráfico de cualquier fuente o cliente se equilibra de forma constante en un solo pod de backend según la configuración de persistencia de sesión. La distribución del tráfico se divide en diferentes flujos de tráfico de origen, de forma que ningún flujo se divide. Por lo tanto, se requiere una cantidad mínima de diversidad de fuentes o clientes para distribuir el tráfico de forma granular entre los back-ends.

Por ejemplo, si el tráfico entrante aumenta de 16 RPS a 60 RPS, se producirá una de las siguientes situaciones:

• Si se usan las puertas de enlace de un solo clúster, no habrá otros clústeres ni regiones a los que pueda derivarse este tráfico. El tráfico se sigue distribuyendo según las capacidades zonales relativas, aunque el tráfico entrante supere la capacidad total. Como resultado, la zona A recibe 45 RPS y la zona B recibe 15 RPS.
• Si usas gateways multiclúster con servicios distribuidos en varios clústeres, el tráfico puede desbordarse a otros clústeres y otras regiones, tal como se describe en Balanceo de carga global y desbordamiento de tráfico. La zona A recibe 30 RPS, la zona B recibe 10 RPS y 20 RPS se desbordan a otro clúster.

Balanceo de carga en una zona

Una vez que se ha enviado tráfico a una zona, se distribuye de forma uniforme entre todos los back-ends de esa zona. Las sesiones HTTP son persistentes en función del ajuste de afinidad de sesión. A menos que el backend deje de estar disponible, las conexiones TCP nunca se transfieren a otro backend. Esto significa que las conexiones de larga duración seguirán dirigiéndose al mismo pod de backend aunque se produzca un desbordamiento de nuevas conexiones debido a la capacidad limitada. El balanceador de carga prioriza el mantenimiento de las conexiones existentes sobre las nuevas.

Capacidad de servicio

Con la capacidad de servicio, puedes definir un valor de solicitudes por segundo (RPS) por pod en un servicio. Este valor representa el RPS máximo por pod de media que puede recibir un servicio. Este valor se puede configurar en los servicios y se usa para determinar el autoescalado basado en el tráfico y el balanceo de carga basado en la capacidad.

Requisitos

La capacidad del servicio tiene los siguientes requisitos y limitaciones:

• Solo se admite con los recursos de GatewayClass y los tipos de Ingress definidos en Compatibilidad con la gestión del tráfico.
• Solo afecta al balanceo de carga si usas el autoescalado basado en el tráfico o las pasarelas de varios clústeres. Si no utilizas estas funciones, la capacidad del servicio no afectará al tráfico de red.

Configurar la capacidad del servicio

apiVersion: v1
kind: Service
metadata:
  name: store
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: store
spec:
  default:
    maxRatePerEndpoint: RATE_PER_SECOND
  targetRef:
    group: ""
    kind: Service
    name: store

apiVersion: v1
kind: Service
metadata:
  name: store
  annotations:
    networking.gke.io/max-rate-per-endpoint: "RATE_PER_SECOND"
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP

Sustituye RATE_PER_SECOND por el número máximo de solicitudes HTTP/HTTPS por segundo que debe recibir un solo pod de este servicio.

El valor maxRatePerEndpoint crea una capacidad dinámica para un servicio en función del número de pods del servicio. El valor de capacidad total del servicio se calcula multiplicando el valor de maxRatePerEndpoint por el número de réplicas, tal como se describe en la siguiente fórmula:

Total Service capacity = maxRatePerEndpoint * number of replicas

Si un escalador automático aumenta el número de pods de un servicio, la capacidad total del servicio se calcula en consecuencia. Si un servicio se reduce a cero pods, tendrá cero capacidad y no recibirá tráfico del balanceador de carga.

Capacidad de servicio y NEGs independientes

La capacidad del servicio también se puede configurar cuando se usan NEGs independientes, pero no se utiliza el ajuste maxRatePerEndpoint. Cuando se usan NEGs independientes, el maxRatePerEndpoint se configura manualmente al añadir el NEG a un recurso BackendService. Con el comando gcloud compute backend-services add-backend, la marca --max-rate-per-endpoint puede configurar la capacidad de cada NEG de forma individual.

Esto puede ser útil en cualquiera de los siguientes flujos de trabajo:

• Cuando se despliegan balanceadores de carga internos y externos manualmente mediante NEGs independientes
• Al desplegar Cloud Service Mesh en GKE con NEGs independientes

No hay ninguna diferencia funcional al configurar la capacidad de servicio con NEGs independientes. Se admiten tanto el autoescalado como el desbordamiento del tráfico.

Determinar la capacidad de tu servicio

Para determinar el valor de maxRatePerEndpoint, debes conocer las características de rendimiento de tus aplicaciones y tus objetivos de balanceo de carga. Las siguientes estrategias pueden ayudarte a definir las características de rendimiento de tu aplicación:

• Observa tu aplicación en entornos de prueba y de producción cuando se haya configurado sin capacidad de servicio.

• Usa Cloud Monitoring para crear una correlación entre las solicitudes de tráfico y los objetivos de nivel de servicio (SLOs) de rendimiento.

• Usa métricas del balanceador de carga, como https o request_count, para asignar los niveles de RPS.

• Define los SLOs de rendimiento de tu aplicación. Puede ser uno o varios de los siguientes, en función de lo que consideres un rendimiento "malo" o "inestable". Puedes obtener toda la información siguiente de las métricas de balanceador de carga de Cloud Monitoring:

  • Códigos de error de respuesta
  • Latencia de respuesta o total
  • Backend en mal estado o inactivo

• Observa tu aplicación bajo carga de tráfico en entornos de prueba y de producción. En entornos de prueba, somete tu aplicación a una carga de solicitudes cada vez mayor para ver cómo influye el aumento del tráfico en las diferentes métricas de rendimiento. En los entornos de producción, observa niveles de patrones de tráfico realistas.

Capacidad de servicio predeterminada

Todos los servicios asociados a recursos de GKE tienen una capacidad de servicio predeterminada configurada, aunque no se haya configurado explícitamente. Para obtener más información, consulta Capacidad de servicio predeterminada.

En la siguiente tabla se describen las capacidades predeterminadas:

Autoescalado basado en el tráfico

El autoescalado basado en el tráfico es una función de GKE que integra de forma nativa las señales de tráfico de los balanceadores de carga para autoescalar los pods. El escalado automático basado en el tráfico solo se admite en las pasarelas de un solo clúster.

Para usar el autoescalado basado en el tráfico, consulta Autoescalado basado en el tráfico del balanceador de carga.

El ajuste de escala automático basado en el tráfico ofrece las siguientes ventajas:

• Las aplicaciones que no están estrictamente limitadas por la CPU o la memoria pueden tener límites de capacidad que no se reflejan en su uso de la CPU o la memoria.
• El tráfico o las solicitudes por segundo (RPS) son una métrica más fácil de entender en algunos casos, ya que se ajusta más al uso de la aplicación y a las métricas de negocio, como las vistas de páginas o los usuarios activos diarios (UAD).
• El tráfico es un indicador adelantado que representa la demanda instantánea en comparación con la CPU o la memoria, que son indicadores retrasados.
• La combinación de métricas de autoescalado de CPU, memoria y tráfico proporciona una forma integral de autoescalar aplicaciones que usa varias dimensiones para asegurarse de que la capacidad se aprovisiona correctamente.

En el siguiente diagrama se muestra cómo funciona el escalado automático basado en el tráfico:

En el diagrama:

• El propietario del servicio configura la capacidad del servicio y un uso objetivo de la implementación.
• La pasarela recibe tráfico de los clientes que van al servicio store. La puerta de enlace envía telemetría de utilización al autoescalador de pods de GKE. La utilización es igual al tráfico real recibido por un Pod dividido entre la capacidad configurada del Pod.
• El autoescalador de pods de GKE aumenta o reduce la escala de los pods en función del uso objetivo configurado.

Comportamiento del autoescalado

En el siguiente diagrama se muestra cómo funciona el escalado automático basado en el tráfico en una aplicación que recibe 10 RPS a través del balanceador de carga:

En el diagrama, el propietario del servicio ha configurado la capacidad de storeService en 10 RPS, lo que significa que cada pod puede recibir un máximo de 10 RPS. El HorizontalPodAutoscaler se configura con averageValue, que se define en 70, lo que significa que la utilización objetivo es el 70% de 10 RPS por pod.

La herramienta de escalado automático intenta escalar las réplicas para conseguir la siguiente ecuación:

replicas = ceiling[ current traffic / ( averageValue * maxRatePerEndpoint) ]

En el diagrama, esta ecuación se calcula de la siguiente manera:

ceiling[ 10 rps / (0.7 * 10 rps) ] = ceiling[ 1.4 ] = 2 replicas

Si el tráfico es de 10 RPS, se crearán 2 réplicas. Cada réplica recibe 5 RPS, que es inferior al uso objetivo de 7 RPS.

División del tráfico

La división del tráfico usa una proporción explícita, llamada peso, que define la proporción de solicitudes HTTP que se envían a un servicio. Los recursos HTTPRoute te permiten configurar pesos en una lista de servicios. Las ponderaciones relativas entre los servicios definen la división del tráfico entre ellos. Esto resulta útil para dividir el tráfico durante los lanzamientos, probar los cambios o en caso de emergencia.

En el siguiente diagrama se describe un ejemplo de configuración de división del tráfico:

En el diagrama:

• El propietario del servicio configura dos servicios para una sola ruta, con una regla que divide el tráfico en un 90% para store-v1 y un 10% para store-v2.
• La pasarela recibe el tráfico de los clientes que van a la URL de la aplicación de la tienda y el tráfico se divide según la regla configurada. El 90% del tráfico se dirige a store-v1 y el 10% a store-v2.

La división del tráfico se admite entre servicios del mismo clúster y entre servicios de clústeres diferentes:

• División del tráfico entre servicios: se usa para dividir el tráfico en las implementaciones de versiones de aplicaciones. En el ejemplo de división del tráfico, tendrías dos implementaciones independientes, store-v1 y store-v2, cada una con su propio servicio, store-v1 y store-v2. Los pesos se configuran entre los dos servicios para cambiar el tráfico de forma gradual hasta que store-v2 se haya implementado por completo.

• División del tráfico entre ServiceImports: se usa para dirigir el tráfico a clústeres específicos o desde ellos para tareas de mantenimiento, migraciones o emergencias. Los ServiceImports representan servicios de varios clústeres y permiten dividir el tráfico entre diferentes servicios de distintos clústeres. En el ejercicio Enrutamiento multiclúster azul-verde con Gateway se muestra cómo dividir el tráfico entre clústeres.

Peso frente a capacidad

Tanto los pesos como las capacidades controlan la cantidad de tráfico que se envía a los diferentes servicios. Aunque tienen efectos similares, funcionan de forma diferente y tienen casos prácticos distintos. Se pueden y se deben usar juntas, aunque con fines diferentes.

Ponderación

El peso es un control explícito del tráfico. Define las proporciones exactas del tráfico, independientemente del tráfico entrante y de la utilización del backend. En el ejemplo de división del tráfico, si store-v2 superara su capacidad o si fallaran todas sus réplicas, el 10% del tráfico se seguiría asignando a store-v2, lo que podría provocar que se perdiera tráfico. Esto se debe a que el peso no cambia la proporción del tráfico en función de la utilización o el estado.

El peso es más adecuado para los siguientes casos prácticos:

• Cambiar el tráfico entre diferentes versiones de un servicio para las implementaciones.
• Incorporar servicios manualmente mediante divisiones de tráfico explícitas.
• Desviar el tráfico de un conjunto de backends por motivos de emergencia o mantenimiento.

Capacidad

La capacidad es un control implícito del tráfico. Define las proporciones del tráfico de forma indirecta, ya que dependen de la cantidad de tráfico entrante, la utilización del backend y la ubicación de origen del tráfico. La capacidad es una propiedad inherente de un servicio y suele actualizarse con mucha menos frecuencia.

La capacidad es la opción más adecuada para los siguientes casos prácticos:

• Evitar la sobreutilización del backend durante los picos de tráfico.
• Controlar la frecuencia del autoescalado en relación con el tráfico.

Configurar la capacidad de un servicio para que el tráfico se desborde no siempre es el comportamiento que quieres. Consulta el ejemplo de balanceo de carga global. La capacidad de servicio protege los backends frente a la sobreutilización al desbordar el tráfico, pero esto puede provocar una latencia adicional en las solicitudes que se han desbordado, ya que esas solicitudes se dirigen a una región más remota.

Si tu aplicación no es muy sensible a la sobreutilización, puedes configurar una capacidad de servicio muy alta para que sea poco probable que el tráfico se desborde a otra región. Si la disponibilidad o la latencia de tu aplicación son sensibles a la sobreutilización, puede que sea mejor desviar el tráfico a otros clústeres o regiones que absorber el exceso de tráfico en back-ends sobreutilizados. Para obtener más información sobre cómo configurar la capacidad de un servicio para tu aplicación, consulta Determinar la capacidad de un servicio.

Siguientes pasos

• Consulta información sobre la implementación de pasarelas.
• Consulta información sobre cómo desplegar pasarelas de varios clústeres.