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 GKE Gateway Controller, los usuarios de GKE pueden controlar la administración del tráfico de manera declarativa y nativa de Kubernetes.

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.

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

• 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 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:

• Regional: 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.

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.

• 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 repentinamente de 16 RPS a 60 RPS, no hay otros clústeres 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.

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. De lo contrario, la capacidad del Service no afecta 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 usa a fin de dividir el tráfico para los 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.

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.

¿Qué sigue?

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