Prácticas recomendadas para la escalabilidad de Cloud Service Mesh en GKE

En esta guía, se describen las prácticas recomendadas para resolver problemas de escalamiento de las arquitecturas de Cloud Service Mesh administradas en Google Kubernetes Engine. El objetivo principal de estas recomendaciones es garantizar un rendimiento, una confiabilidad y una utilización de recursos óptimos para tus aplicaciones de microservicios a medida que crecen.

La escalabilidad de Cloud Service Mesh en GKE depende del funcionamiento eficiente de sus dos componentes principales, el plano de datos y el plano de control. Este documento se enfoca principalmente en la escalabilidad del plano de datos.

Identificación de problemas de escalamiento del plano de control en comparación con el plano de datos

En Cloud Service Mesh, los problemas de escalamiento pueden ocurrir en el plano de control o en el plano de datos. A continuación, te mostramos cómo identificar el tipo de problema de escalamiento que tienes:

Síntomas de problemas de escalamiento del plano de control

Descubrimiento de servicios lento: Los servicios o extremos nuevos tardan mucho en detectarse y estar disponibles.

Retrasos en la configuración: Los cambios en las reglas de administración de tráfico o las políticas de seguridad tardan mucho tiempo en propagarse.

Mayor latencia en las operaciones del plano de control: Las operaciones, como crear, actualizar o borrar recursos de Cloud Service Mesh, se vuelven lentas o no responden.

Errores relacionados con Traffic Director: Es posible que observes errores en los registros de Cloud Service Mesh o en las métricas del plano de control que indiquen problemas con la conectividad, el agotamiento de recursos o la limitación de la API.

Alcance del impacto: Los problemas del plano de control suelen afectar a toda la malla, lo que genera una degradación generalizada del rendimiento.

Síntomas de problemas de escalamiento del plano de datos

Latencia incrementada en la comunicación de servicio a servicio: Las solicitudes a un servicio en la malla experimentan una latencia o tiempos de espera más altos, pero no hay un uso elevado de CPU o memoria en los contenedores del servicio.

Uso alto de CPU o memoria en los proxies de Envoy: El uso alto de CPU o memoria puede indicar que los proxies tienen dificultades para controlar la carga de tráfico.

Impacto localizado: Los problemas del plano de datos suelen afectar servicios o cargas de trabajo específicos, según los patrones de tráfico y el uso de recursos de los proxies de Envoy.

Escalamiento del plano de datos

Para escalar el plano de datos, prueba las siguientes técnicas:

Configura el ajuste de escala automático horizontal de pods (HPA) para las cargas de trabajo

Usa el ajuste de escala automático horizontal de pods (HPA) para escalar de forma dinámica las cargas de trabajo con pods adicionales según el uso de recursos. Ten en cuenta lo siguiente cuando configures la HPA:

  • Usa el parámetro --horizontal-pod-autoscaler-sync-period para kube-controller-manager ajustar la frecuencia de sondeo del controlador de HPA. La tasa de sondeo predeterminada es de 15 segundos y te recomendamos que la configures en un valor más bajo si esperas aumentos de tráfico más rápidos. Para obtener más información sobre cuándo usar el HPA con GKE, consulta Ajuste de escala automático horizontal de Pods.

  • El comportamiento de escalamiento predeterminado puede provocar que se implemente (o finalice) una gran cantidad de pods a la vez, lo que puede generar un aumento repentino en el uso de recursos. Considera usar políticas de escalamiento para limitar la velocidad a la que se pueden implementar los pods.

  • Usa EXIT_ON_ZERO_ACTIVE_CONNECTIONS para evitar que se pierdan las conexiones durante la reducción de escala.

Para obtener más detalles sobre el HPA, consulta Ajuste automático de escala horizontal de Pods en la documentación de Kubernetes.

Optimiza la configuración del proxy de Envoy

Para optimizar la configuración del proxy de Envoy, ten en cuenta las siguientes recomendaciones:

Límites de recursos

Puedes definir solicitudes y límites de recursos para los contenedores secundarios de Envoy en las especificaciones de tu Pod. Esto evita la contención de recursos y garantiza un rendimiento coherente.

También puedes configurar límites de recursos predeterminados para todos los proxies de Envoy en tu malla mediante anotaciones de recursos.

Los límites de recursos óptimos para tus proxies de Envoy dependen de factores, como el volumen de tráfico, la complejidad de la carga de trabajo y los recursos del nodo de GKE. Supervisa y ajusta tu malla de servicios de forma continua para garantizar un rendimiento óptimo.

Consideración importante:

  • Calidad de servicio (QoS): Configurar las solicitudes y los límites garantiza que tus proxies de Envoy tengan una calidad de servicio predecible.

Cómo definir las dependencias de los servicios

Considera recortar el gráfico de dependencias de tu malla declarando todas tus dependencias a través de la API de Sidecar. Esto limita el tamaño y la complejidad de la configuración que se envía a una carga de trabajo determinada, lo que es fundamental para mallas más grandes.

A modo de ejemplo, el siguiente es el gráfico de tráfico de la aplicación de ejemplo de la boutique en línea.

Árbol del gráfico de tráfico de la aplicación de ejemplo de Online Boutique con muchas hojas

Muchos de estos servicios son hojas en el gráfico y, por lo tanto, no necesitan tener información de salida para ninguno de los otros servicios de la malla. Puedes aplicar un recurso de sidecar que limite el alcance de la configuración de sidecar para estos servicios de hoja, como se muestra en el siguiente ejemplo.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: leafservices
  namespace: default
spec:
  workloadSelector:
    labels:
      app: cartservice
      app: shippingservice
      app: productcatalogservice
      app: paymentservice
      app: emailservice
      app: currencyservice
  egress:
  -   hosts:
    -   "~/*"

Consulta la aplicación de ejemplo de Online Boutique para obtener detalles sobre cómo implementarla.

Otro beneficio de definir el alcance del contenedor secundario es reducir las consultas de DNS innecesarias. El alcance de las dependencias de servicio garantiza que un sidecar de Envoy solo realice consultas de DNS para los servicios con los que se comunicará en lugar de todos los clústeres de la malla de servicios.

Para cualquier implementación a gran escala que tenga problemas con tamaños de configuración grandes en sus sidecars, se recomienda enfáticamente definir el alcance de las dependencias de servicio para la escalabilidad de malla.

Supervisa y ajusta

Después de establecer los límites de recursos iniciales, es fundamental supervisar tus proxies de Envoy para asegurarte de que tengan un rendimiento óptimo. Usa los paneles de GKE para supervisar el uso de la CPU y la memoria, y ajusta los límites de recursos según sea necesario.

Para determinar si un proxy de Envoy requiere un aumento de los límites de recursos, supervisa su consumo de recursos en condiciones de tráfico típicas y máximas. Esto es lo que debes buscar:

  • Uso alto de CPU: Si el uso de CPU de Envoy se acerca o supera su límite de forma constante, es posible que tenga dificultades para procesar las solicitudes, lo que genera una mayor latencia o la pérdida de solicitudes. Considera aumentar el límite de CPU.

    En este caso, es posible que quieras escalar con el escalamiento horizontal, pero si el proxy del contenedor secundario no puede procesar las solicitudes con la misma rapidez que el contenedor de la aplicación, ajustar los límites de la CPU puede producir los mejores resultados.

  • Uso alto de memoria: Si el uso de memoria de Envoy se acerca o supera su límite, es posible que comience a descartar conexiones o experimente errores de memoria insuficiente (OOM). Aumenta el límite de memoria para evitar estos problemas.

  • Registros de errores: Examina los registros de Envoy en busca de errores relacionados con el agotamiento de recursos, como error de conexión upstream, desconectar o restablecer antes de los encabezados o demasiados archivos abiertos. Estos errores pueden indicar que el proxy necesita más recursos. Consulta la documentación de solución de problemas de escalamiento para ver otros errores relacionados con problemas de escalamiento.

  • Métricas de rendimiento: Supervisa las métricas de rendimiento clave, como la latencia de las solicitudes, las tasas de error y la capacidad de procesamiento. Si observas una degradación del rendimiento correlacionada con un alto uso de recursos, es posible que sea necesario aumentar los límites.

Si configuras y supervisas de forma activa los límites de recursos de tus proxies de plano de datos, puedes asegurarte de que tu malla de servicios se escale de manera eficiente en GKE.

Cómo incorporar la capacidad de recuperación

Puedes ajustar los siguientes parámetros de configuración para escalar tu plano de control:

Detección de valores atípicos

La detección de valores atípicos supervisa los hosts en un servicio upstream y los quita del grupo de balanceo de cargas cuando se alcanza un umbral de error determinado.

  • Configuración de claves:
    • outlierDetection: Configuración que controla la expulsión de hosts en mal estado del grupo de balanceo de cargas.
  • Beneficios: Mantiene un conjunto de hosts en buen estado en el grupo de balanceo de cargas.

Para obtener más información, consulta Detección de valores atípicos en la documentación de Istio.

Reintentos

Mitiga los errores transitorios volviendo a intentar automáticamente las solicitudes que fallaron.

  • Configuración de claves:
    • attempts: Es la cantidad de intentos reiterados.
    • perTryTimeout: Es el tiempo de espera por intento de reintento. Establece este valor más corto que el tiempo de espera general. Determina cuánto tiempo esperarás por cada intento de reintento individual.
    • retryBudget: Es la cantidad máxima de reintentos simultáneos.
  • Beneficios: Mayores tasas de éxito para las solicitudes, reducción del impacto de las fallas intermitentes.

Factores que se deben tener en cuenta:

  • Idempotency: Asegúrate de que la operación que se vuelve a intentar sea idempotente, lo que significa que se puede repetir sin efectos secundarios no deseados.
  • Max Retries: Limita la cantidad de reintentos (p.ej., 3 reintentos como máximo) para evitar bucles infinitos.
  • Interrupción de circuitos: Integra los reintentos con disyuntores para evitar reintentos cuando un servicio falla de forma constante.

Para obtener más información, consulta Reintentos en la documentación de Istio.

Tiempos de espera

Usa tiempos de espera para definir el tiempo máximo permitido para el procesamiento de solicitudes.

  • Configuración de claves:
    • timeout: Tiempo de espera de la solicitud para un servicio específico.
    • idleTimeout: Es el tiempo que una conexión puede permanecer inactiva antes de cerrarse.
  • Beneficios: Mejora la capacidad de respuesta del sistema, evita fugas de recursos y endurece el sistema contra el tráfico malicioso.

Factores que se deben tener en cuenta:

  • Latencia de red: Ten en cuenta el tiempo de ida y vuelta (RTT) esperado entre los servicios. Deja un margen para las demoras inesperadas.
  • Gráfico de dependencias de servicios: Para las solicitudes encadenadas, asegúrate de que el tiempo de espera de un servicio de llamada sea más corto que el tiempo de espera acumulativo de sus dependencias para evitar fallas en cascada.
  • Tipos de operaciones: Es posible que las tareas de larga duración necesiten tiempos de espera mucho más largos que las recuperaciones de datos.
  • Manejo de errores: Los tiempos de espera deben activar la lógica de manejo de errores adecuada (p.ej., reintento, resguardo, corte de circuito).

Para obtener más información, consulta Tiempo de espera en la documentación de Istio.

Supervisa y ajusta

Considera comenzar con la configuración predeterminada de los tiempos de espera, la detección de valores atípicos y las reintentos y, luego, ajustarlos gradualmente según los requisitos específicos de tu servicio y los patrones de tráfico observados. Por ejemplo, observa los datos del mundo real sobre cuánto tiempo tardan, por lo general, tus servicios en responder. Luego, ajusta los tiempos de espera para que coincidan con las características específicas de cada servicio o extremo.

Telemetría

Usa la telemetría para supervisar de forma continua tu malla de servicios y ajustar su configuración para optimizar el rendimiento y la confiabilidad.

  • Métricas: Usa métricas integrales, en particular, los volúmenes de solicitudes, la latencia y las tasas de error. Realiza la integración con Cloud Monitoring para la visualización y las alertas.
  • Seguimiento distribuido: Habilita la integración del seguimiento distribuido con Cloud Trace para obtener estadísticas detalladas sobre los flujos de solicitudes en tus servicios.
  • Registro: Configura el registro de acceso para capturar información detallada sobre las solicitudes y respuestas.

Lecturas adicionales