Administración del tráfico de Gateway

Autopilot Estándar

---

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

Descripción general

Las herramientas de redes de Google Kubernetes Engine (GKE) se basan en Cloud Load Balancing. Con Cloud Load Balancing, una sola dirección IP Anycast proporciona administración de tráfico global. La administración del tráfico de Google proporciona balanceo de cargas global y regional, ajuste de escala automático y administración de la capacidad para proporcionar una distribución del tráfico igualada, estable y de baja latencia. Con el controlador de puerta de enlace de GKE, los usuarios de GKE pueden usar el control de administración del tráfico global de Google de manera declarativa y nativa de Kubernetes.

Para probar el derrame del tráfico entre clústeres, consulta Implementa el balanceo de cargas basado en la capacidad. Para probar el ajuste de escala automático basado en el tráfico, consulta Ajuste de escala automático basado en el tráfico del balanceador de cargas.

Administración del tráfico

El balanceo de cargas, el ajuste de escala automático y la administración de la capacidad son los cimientos de un sistema de administración del tráfico. Funcionan en conjunto para igualar y estabilizar la carga del sistema.

• El balanceo de cargas distribuye el tráfico entre los Pods de backend según la ubicación, el estado y los diferentes algoritmos de balanceo de cargas.
• El ajuste de escala automático escala las réplicas de la carga de trabajo para crear más capacidad y absorber más tráfico.
• La administración de la capacidad supervisa el uso de los Services para que el tráfico pueda desbordarse a backends con capacidad en lugar de afectar la disponibilidad o el rendimiento de la aplicación.

Estas funciones se pueden combinar de diferentes maneras según los objetivos. Por ejemplo:

• Si deseas aprovechar las VM Spot, es posible que desees optimizar la distribución uniforme del tráfico entre las VM Spot a costa de la latencia. Mediante el balanceo de cargas y la administración de capacidad, GKE desbordaría el tráfico entre regiones según la capacidad para que las VM Spot se usen por completo donde estén disponibles.

• Si deseas optimizar la latencia del usuario a costa del aprovisionamiento en exceso, puedes implementar clústeres de GKE en muchas regiones y aumentar la capacidad de forma dinámica siempre que aumente la carga. El uso del balanceo de cargas y el ajuste de escala automático de GKE escalaría automáticamente la cantidad de Pods cuando el tráfico aumente para que el tráfico no tenga que desbordarse a otras regiones. Las regiones aumentarían su capacidad para poder controlar por completo la carga lo más cerca posible de los usuarios.

En el siguiente diagrama, se muestran el balanceo de cargas, el ajuste de escala automático y la administración de la capacidad funcionando en conjunto:

En el diagrama, la carga de trabajo del clúster gke-us falló. El balanceo de cargas y la verificación de estado vacían las conexiones activas y redireccionan el tráfico al siguiente clúster más cercano. La carga de trabajo en gke-asia recibe más tráfico del que admite su capacidad, por lo que derrama carga a gke-eu. gke-eu recibe más carga de lo normal debido a los eventos en gke-us y gke-asia, por lo que gke-eu realiza un ajuste de escala automático para aumentar su capacidad de tráfico.

Para obtener más información sobre cómo Cloud Load Balancing maneja la administración del tráfico, consulta Administración de capacidad global.

Funciones de administración del tráfico

Los recursos de puerta de enlace, HTTPRoute, Service y política proporcionan los controles para administrar el tráfico en GKE. El controlador de Gateway de GKE es el plano de control que supervisa estos recursos.

Las siguientes funciones de administración del tráfico están disponibles cuando se implementan Services en GKE:

• Capacidad de Service: La posibilidad de especificar la cantidad de capacidad de tráfico que un Service puede recibir antes de que los Pods se escalen automáticamente o que el tráfico se desborde hacia otros clústeres disponibles.
• Ajuste de escala automático basado en el tráfico: Ajuste de escala automático de Pods dentro de un Service según las solicitudes HTTP recibidas por segundo

• Balanceo de cargas de varios clústeres: La capacidad de balancear cargas a Services alojados en varios clústeres de GKE o en varias regiones.

• División del tráfico: Distribución del tráfico explícita basada en el peso entre backends. La división del tráfico es compatible con las puertas de enlace de un solo clúster en DG.

Compatibilidad de la administración del tráfico

Las funciones disponibles de administración del tráfico dependen de la GatewayClass que implementes. Para obtener una lista completa de la compatibilidad de funciones, consulta Funciones de GatewayClass. En la siguiente tabla, se resume la compatibilidad de GatewayClass para la administración del tráfico:

GatewayClass	Capacidad de Service	Ajuste de escala automático del tráfico	Balanceo de cargas de varios clústeres	División del tráfico^1
gke-l7-global-external-managed
gke-l7-regional-external-managed
gke-l7-rilb
gke-l7-gxlb
gke-l7-global-external-managed-mc
gke-l7-regional-external-managed-mc
gke-l7-rilb-mc
gke-l7-gxlb-mc

¹ La división del tráfico es compatible con las puertas de enlace de un solo clúster en DG.

Balanceo de cargas global, regional y zonal

La capacidad, la ubicación y el estado del Service determinan cuánto tráfico envía el balanceador de cargas a un backend determinado. Las decisiones de balanceo de cargas se toman en los siguientes niveles, comenzando en el global para los balanceadores de cargas globales y el regional para los balanceadores de cargas regionales:

• Global: El tráfico se envía a la región de Google Cloud más cercana al cliente que tiene backends en buen estado 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 exceso de tráfico se desborda hacia la siguiente región más cercana con capacidad. Para obtener más información, consulta Balanceo de cargas global.
• Regional: El tráfico se envía a una región específica mediante el balanceador de cargas. Se balancean las cargas del tráfico entre zonas en proporción a la capacidad de entrega disponible de la zona. Para obtener más información, consulta Balanceo de cargas regional.
• Zonal: Después de determinar el tráfico para una zona específica, el balanceador de cargas distribuye el tráfico de manera uniforme entre los backends dentro de esa zona. Las conexiones TCP existentes y la configuración de persistencia de la sesión se conservan, de modo que las solicitudes futuras vayan a los mismos backends, siempre que el Pod de backend esté en buen estado. Para obtener más información, consulta Balanceo de cargas zonal.

Balanceo de cargas global y desbordamiento del tráfico

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

En condiciones normales, el tráfico se envía al backend más cercano al cliente. El tráfico finaliza en el punto de presencia (PoP) de Google más cercano al cliente y, luego, recorre la red troncal de Google hasta llegar al backend más cercano, según lo determinado por la latencia de la red. Cuando los backends en una región no tienen capacidad restante, el tráfico se desborda al siguiente clúster más cercano con backends en buen estado que tengan capacidad. Si menos del 50% de los Pods de backend dentro de una zona están en mal estado, el tráfico se conmuta por error de forma gradual a otras zonas o regiones, sin importar la capacidad configurada.

El desbordamiento del tráfico solo ocurre en las siguientes condiciones:

• Usas una Gateway de varios clústeres.
• Tienes el mismo Service implementado en varios clústeres, entregado por la Gateway de varios clústeres.
• Tienes configuradas las capacidades del Service de modo que el tráfico supere las capacidades del Service en un clúster, pero no en otros.

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

En el diagrama:

• Una Gateway de varios clústeres proporciona balanceo de cargas global de Internet para el Service store. El Service se implementa en dos clústeres de GKE, uno en us-west1 y otro en europe-west1. Cada clúster ejecuta 2 réplicas.
• Cada Service se configura con max-rate-per-endpoint="10", lo que significa que cada Service tiene una capacidad total de 2 réplicas * 10 RPS = 20 RPS en cada clúster.
• Los PoP de Google en Norteamérica reciben 6 RPS. Todo el tráfico se envía al backend en buen estado más cercano y con capacidad, el clúster de GKE en us-west1.
• Los PoP europeos reciben 30 RPS acumulativos. Los backends más cercanos están en europe-west1, pero solo tienen 20 RPS de capacidad. Debido a que los backends en us-west1 tienen un exceso de capacidad, 10 RPS se desborda a us-west1 para que reciba 16 RPS en total y distribuya 8 RPS a cada Pod.

Nota: Si usas Gateways de un solo clúster, un Service de tipo LoadBalancer o recursos Ingress, este ejemplo de balanceo de cargas global no se aplica, ya que estos recursos solo balancean cargas a un único clúster dentro de una sola región. Se recomienda usar Gateways de varios clústeres si tienes requisitos de balanceo de cargas global.

Evita el desbordamiento de tráfico

El desbordamiento del tráfico ayuda a evitar exceder la capacidad de la aplicación que puede afectar el rendimiento o la disponibilidad.

Sin embargo, es posible que no quieras desbordar el tráfico. Por ejemplo, las aplicaciones sensibles a la latencia podrían no beneficiarse del desbordamiento de tráfico a un backend mucho más distante.

Puedes usar cualquiera de los siguientes métodos para evitar el desbordamiento de tráfico:

• Usar Gateways de clúster único que pueden alojar Services en un solo clúster.

• Incluso si se usan Gateways de varios clústeres, las réplicas de una aplicación implementadas en varios clústeres se pueden implementar como Services independientes. Desde la perspectiva de la Gateway, esto habilita el balanceo de cargas de varios clústeres, pero no agrega todos los extremos de un Service entre clústeres.

• Configura las capacidades del Service a un nivel lo suficientemente alto como para que la capacidad de tráfico nunca se exceda de forma realista, a menos que sea absolutamente necesario.

Balanceo de cargas dentro de una región

Dentro de una región, el tráfico se distribuye entre zonas de acuerdo con las capacidades disponibles de los backends. Esto no es usar el desbordamiento, sino más bien balancear cargas en proporción directa a las capacidades del Service en cada zona. Cualquier flujo o sesión individual siempre se envía a un solo Pod de backend coherente y no se divide.

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

En el diagrama:

• Un Service se implementa en un clúster de GKE regional. El Service tiene 4 Pods que se implementan de manera desigual entre las zonas. 3 Pods están en la zona A, 1 Pod está en la zona B y 0 Pods están en la zona C.
• El Service se configura con max-rate-per-endpoint="10". La zona A tiene 30 RPS de capacidad total, la zona B tiene 10 RPS de capacidad total y la zona C tiene 0 RPS de capacidad total, porque no tiene Pods.
• La Gateway recibe un total de 16 RPS de tráfico de diferentes clientes. Este tráfico se distribuye entre zonas en proporción a la capacidad restante en cada zona.
• El flujo de tráfico desde cualquier fuente o cliente individual se balancea de forma coherente a un solo Pod de backend según la configuración de persistencia de la sesión. La distribución del tráfico se divide entre diferentes flujos de tráfico de origen de modo que los flujos individuales nunca se dividen. Como resultado, se requiere una cantidad mínima de diversidad de orígenes o clientes para distribuir el tráfico de forma detallada entre los backends.

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

• Si usas Gateways de un solo clúster, no hay otros clústeres o regiones a los que este tráfico pueda desbordarse. El tráfico se sigue distribuyendo de acuerdo con las capacidades zonales relativas, incluso si el tráfico entrante excede la capacidad total. Como resultado, la zona A recibe 45 RPS y la zona B recibe 15 RPS.
• Si usas Gateways de varios clústeres con Services distribuidos en varios clústeres, el tráfico puede desbordarse a otros clústeres y otras regiones, como se describe en Balanceo de cargas 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.

Nota: Cloud Load Balancing no reduce el tráfico de forma automática cuando los backends superan su capacidad. El tráfico se desborda a cualquier backend disponible que tenga capacidad. Si todos los backends superan su capacidad, el tráfico desbordado se distribuye entre todos los backends en proporción a sus capacidades totales. Esto excede la capacidad total del Service.

Balanceo de cargas dentro de una zona

Una vez que el tráfico se envía a una zona, se distribuye de manera uniforme en todos los backends de esa zona. Las sesiones HTTP son persistentes según la configuración de afinidad de sesión. A menos que el backend no esté disponible, las conexiones TCP existentes nunca se trasladan a un backend diferente. Esto significa que las conexiones de larga duración continúan dirigiéndose al mismo Pod de backend, incluso si las conexiones nuevas se desbordan debido a la capacidad limitada. El balanceador de cargas prioriza el mantenimiento de las conexiones existentes sobre las nuevas.

Capacidad de Service

Con la capacidad de Service, puedes definir un valor de solicitudes por segundo (RPS) por Pod en un Service. Este valor representa el máximo de RPS por Pod en promedio que un Service puede recibir. Este valor se puede configurar en Services y se usa para determinar el ajuste de escala automático basado en el tráfico y el balanceo de cargas basado en la capacidad.

Requisitos

La capacidad de Service tiene los siguientes requisitos y limitaciones:

• Solo es compatible con los recursos GatewayClass y los tipos de Ingress definidos en Compatibilidad de la administración del tráfico.

• Solo afecta al balanceo de cargas si usas el ajuste de escala automático basado en el tráfico o Gateways de varios clústeres. Si no usas estas funciones, la capacidad de Service no tendrá efecto en el tráfico de red.

Configura la capacidad de Service

Para configurar la capacidad de Service, crea un Service con la anotación networking.gke.io/max-rate-per-endpoint. En el siguiente manifiesto, se describe un Service con un RPS máximo:

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

Reemplaza RATE_PER_SECOND por la cantidad máxima de solicitudes HTTP/HTTPS por segundo que debe recibir un solo Pod en este Service.

El valor max-rate-per-endpoint crea una capacidad dinámica para un Service en función de la cantidad de Pods en el Service. La capacidad total del Service se calcula mediante la multiplicación del valor max-rate-per-endpoint por la cantidad de réplicas, como se describe en la siguiente fórmula:

Total Service capacity = max-rate-per-endpoint * number of replicas

Si un escalador automático escala verticalmente la cantidad de Pods dentro de un Service, la capacidad total del Service se calcula en consecuencia. Si se reduce verticalmente la escala de un Service a cero Pods, tiene cero capacidad y no recibe tráfico del balanceador de cargas.

Nota: La configuración de la capacidad del Service con la anotación max-rate-per-endpoint solo se aplica al tráfico que entra a través de una Gateway compatible. No afecta el balanceo de cargas basado en la capacidad para el balanceo de cargas de ClusterIP dentro del clúster o para los Services de tipo LoadBalancer.

Capacidad de Service y NEG independientes

La capacidad de Service también se puede configurar cuando se usan NEG independientes. Sin embargo, no usa la anotación max-rate-per-endpoint. Cuando se usan NEG independientes, max-rate-per-endpoint se configura de forma manual cuando se agrega el NEG a un recurso de Service de backend. 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 para cualquiera de los siguientes flujos de trabajo:

• Cuando implementas balanceadores de cargas internos y externos de forma manual mediante NEG independientes
• Cuando implementas Cloud Service Mesh en GKE mediante NEG independientes

No hay diferencia funcional cuando se configura la capacidad del Service con NEG independientes. Se admite el ajuste de escala automático del tráfico y el derrame del tráfico.

Determina la capacidad de tu Service

Para determinar el valor de max-rate-per-endpoint, es necesario comprender las características de rendimiento de tus aplicaciones y tus objetivos de balanceo de cargas. 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 configure sin capacidad de Service.
• Usa Cloud Monitoring para crear una correlación entre las solicitudes de tráfico y los objetivos de nivel de servicio (SLO) de rendimiento.

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

• Define cuáles son tus SLO de rendimiento para tu aplicación. Pueden ser uno o más de los siguientes, según lo que consideres que es un rendimiento “incorrecto” o “inestable”. Se puede recopilar todo lo siguiente de las métricas del balanceador de cargas de Cloud Monitoring:
  • Códigos de error de respuesta
  • Latencia de respuesta o total
  • Mal estado o tiempo de inactividad del backend
• Observa tu aplicación bajo carga de tráfico en entornos de prueba y de producción. En entornos de prueba, haz que tu aplicación reciba una carga de solicitudes creciente para que puedas ver cómo se ven afectadas las diferentes métricas de rendimiento a medida que aumenta el tráfico. En entornos de producción, observa los niveles de los patrones de tráfico realistas.

Capacidad predeterminada de Service

Todos los Services conectados a los recursos de GKE tienen configurada una capacidad de Service predeterminada, incluso si no se configuró de forma explícita mediante la anotación. Para obtener más información, consulta Capacidad de Service predeterminada.

En la siguiente tabla, se describen las capacidades predeterminadas:

Tipo de recurso de balanceo de cargas	max-rate-per-endpoint predeterminado
Ingress (interno y externo)	1 RPS
Gateway (todas las GatewayClasses)	100,000,000 RPS
MultiClusterIngress	100,000,000 RPS

Ajuste de escala automático basado en el tráfico

El ajuste de escala automático 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 cargas para ajustar automáticamente la escala de los Pods. El ajuste de escala automático basado en el tráfico solo es compatible con puertas de enlace de un solo clúster.

Para usar el ajuste de escala automático basado en el tráfico, consulta Ajuste de escala automático basado en el tráfico del balanceador de cargas.

El ajuste de escala automático basado en el tráfico proporciona los siguientes beneficios:

• Las aplicaciones que no están estrictamente vinculadas a la CPU o la memoria pueden tener límites de capacidad que no se reflejan en su uso de CPU o memoria.
• El tráfico o las solicitudes por segundo (RPS) son una métrica más fácil de comprender en algunos casos, ya que está más alineada con el uso de la app y las métricas empresariales, como las vistas de páginas o los usuarios activos por día (DAU).
• El tráfico es un indicador principal que representa la demanda instantánea en comparación con la CPU o la memoria, que son indicadores rezagados.
• La combinación de CPU, memoria y métricas de ajuste de escala automático de tráfico proporciona una manera holística de ajustar automáticamente la escala de las aplicaciones que usan varias dimensiones para garantizar que la capacidad se aprovisione de manera adecuada.

En el siguiente diagrama, se muestra cómo funciona el ajuste de escala automático basado en el tráfico:

En el diagrama:

• El propietario del Service configura la capacidad del Service y un uso objetivo para el objeto Deployment.
• La Gateway recibe tráfico de los clientes hacia el Service store. La Gateway envía la telemetría de uso al escalador automático de Pods de GKE. El uso es igual al tráfico real que recibe un Pod individual dividido por la capacidad configurada del Pod.
• El escalador automático de Pods de GKE aumenta o reduce la escala de los Pods según el uso objetivo configurado.

Comportamiento del ajuste de escala automático

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

En el diagrama, el propietario del Service configuró la capacidad del Service de almacenamiento en 10 RPS, lo que significa que cada Pod puede recibir un máximo de 10 RPS. El HorizontalPodAutoscaler configurado se configuró con averageUtilization establecido en 70, lo que significa que el uso objetivo es el 70% de 10 RPS por Pod.

El escalador automático intenta escalar las réplicas para lograr la siguiente ecuación:

replicas = ceiling[ current traffic / ( averageUtilization * max-rate-per-endpoint) ]

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

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

10 RPS de tráfico da como resultado 2 réplicas. Cada réplica recibe 6 RPS, que está bajo el uso objetivo de 7 RPS.

Nota: Los cambios en los niveles de tráfico o los aumentos de tráfico pueden hacer que el escalador automático se aproxime a la ecuación de las réplicas objetivo. En condiciones de estado estable, la cantidad de réplicas se acerca al objetivo, pero puede que no siempre sea exacta, especialmente con tráfico fluctuante.

División del tráfico

La división del tráfico usa una proporción explícita, llamada ponderación, que define la proporción de solicitudes HTTP que se envían a un Service. Los recursos HTTPRoute te permiten configurar ponderaciones en una lista de Service. Las ponderaciones relativas entre los Services definen la división del tráfico entre ellos. Esto es útil para dividir el tráfico durante lanzamientos, cambios de versiones canary o emergencias.

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

En el diagrama:

• El propietario del Service configura dos Services para una sola ruta, con una regla que divide el tráfico en un 90% a store-v1 y un 10% a store-v2.
• La puerta de enlace recibe tráfico de los clientes que van a la URL de la aplicación de la tienda y el tráfico se divide de acuerdo con la regla configurada. El 90% de las rutas de tráfico a store-v1 y el 10% de las rutas a store-v2.

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

• División del tráfico entre Services: Se usa a fin de dividir el tráfico para lanzamientos de versiones de la aplicación. Según el ejemplo de división del tráfico, tendrías dos objetos Deployment independientes, store-v1 y store-v2, cada uno con su propio Service, store-v1 y store-v2. Las ponderaciones se configuran entre los dos Services para cambiar el tráfico de forma gradual hasta que store-v2 se haya lanzado por completo.

  Nota: La GatewayClass gke-l7-gxlb no admite la división del tráfico.

• División del tráfico entre ServiceImports: Se usa para cambiar el tráfico hacia o desde clústeres específicos en caso de mantenimiento, migración o emergencia. Las ServiceImports representan Services de varios clústeres y permiten la división del tráfico entre diferentes Services en clústeres diferentes. El ejercicio Enrutamiento azul-verde de varios clústeres con la puerta de enlace demuestra cómo dividir el tráfico entre los clústeres.

  Nota: La GatewayClass gke-l7-gxlb-mc no admite la división del tráfico.

Ponderación frente a capacidad

Las ponderaciones y las capacidades controlan cuánto tráfico se envía a diferentes Services. Si bien tienen efectos similares, operan de forma diferente y tienen diferentes casos prácticos. Sin embargo, pueden y deben usarse en conjunto, pero con diferentes propósitos.

Peso

La ponderación es un control explícito del tráfico. Define las proporciones exactas del tráfico, sin importar el tráfico entrante y el uso de backend. En el ejemplo de división del tráfico, si store-v2 tuviera exceso de capacidad o si todas sus réplicas fallaran, el 10% del tráfico aún se asignaría a store-v2, lo que podría provocar que se descartara el tráfico. Esto se debe a que la ponderación no cambia la proporción de tráfico en función del uso ni el estado.

La ponderación es más adecuada para los siguientes casos de uso:

• Cambiar el tráfico entre diferentes versiones de un Service para lanzamientos.
• Integrar servicios de forma manual con divisiones de tráfico explícitas.
• Cambiar el tráfico desde un conjunto de backends en caso 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, el uso del backend y la ubicación del origen del tráfico. La capacidad es una propiedad inherente de un Service y, por lo general, se actualiza con mucha menos frecuencia.

La capacidad es más adecuada para los siguientes casos de uso:

• Evitar la sobreutilización del backend durante los aumentos repentinos de tráfico.
• Controlar la tasa de ajuste de escala automático con respecto al tráfico.

Configurar la capacidad del Service para desbordar el tráfico no siempre es un comportamiento deseable. Considera el ejemplo de balanceo de cargas global. La capacidad del Service protege el backend de la sobreutilización mediante el desbordamiento de tráfico, pero esto podría provocar una latencia adicional para 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, te recomendamos configurar una capacidad del Service muy alta de modo que sea poco probable que el tráfico se desborde hacia otra región. Si la disponibilidad o latencia de tu aplicación son sensibles a la sobreutilización, entonces el desbordamiento de tráfico a otros clústeres o regiones puede ser mejor que absorber el exceso de tráfico en backends sobreutilizados. Si deseas obtener más información sobre cómo configurar la capacidad del Service para tu aplicación, consulta Determina la capacidad de tu Service.

¿Qué sigue?

• Obtén más información sobre cómo implementar puertas de enlace.

• Obtén más información sobre cómo implementar puertas de enlace de varios clústeres.