Límites de escalado de Cloud Service Mesh en GKE

En este documento se describen los límites de escalado del plano de control de las arquitecturas de Cloud Service Mesh gestionadas en GKE para que puedas tomar decisiones fundamentadas sobre tus implementaciones.

Información general

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 centra en los límites de escalado del plano de control. Consulta las prácticas recomendadas de escalabilidad para obtener información sobre las prácticas recomendadas de escalabilidad del plano de datos.

Algunos de los límites de escalado documentados se aplican mediante restricciones de cuota. Si los supera, deberá solicitar un aumento de cuota. Otras no se aplican estrictamente, pero pueden provocar un comportamiento y un rendimiento indefinidos si se superan.

Para saber cómo se traducen los recursos de Istio a recursos de Google Cloud , consulta primero la guía Información sobre los recursos de la API.

Nota: Las limitaciones que se describen en esta guía solo se aplican a la implementación del plano de control de TRAFFIC_DIRECTOR.

Límites de escalado de servicios

El escalado de servicios está limitado en dos dimensiones

• Por proyecto: se admiten un máximo de 1000 servicios de Cloud Service Mesh porGoogle Cloud proyecto (excepto los servicios sin encabezado de Kubernetes).

• Por zona y por proyecto: como Cloud Service Mesh crea grupos de puntos finales de red por zona para los servicios de GKE del clúster, los límites de cuota de NEG zonal se aplican al número de servicios por proyecto que pueden tener endpoints en esa zona.

Ten en cuenta que, una vez que Cloud Service Mesh se habilita en una pertenencia concreta (es decir, un clúster de GKE), todos los servicios de Kubernetes del clúster se traducen a servicios de Cloud Service Mesh, incluidos los que se dirigen a cargas de trabajo sin un sidecar de Cloud Service Mesh. Cloud Service Mesh crea grupos de puntos de conexión de red zonales para todos los servicios del clúster de GKE. Si el clúster es regional, se crean grupos de endpoints de red para todas las zonas del grupo de nodos de la región.

Servicios de Cloud Service Mesh y servicios de Kubernetes

Los servicios de Cloud Service Mesh no son lo mismo que los servicios de Kubernetes, ya que los servicios de Cloud Service Mesh son un servicio por puerto.

Por ejemplo, este servicio de Kubernetes se traduce internamente en dos servicios de Cloud Service Mesh, uno por cada puerto.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    -   port: 80
      targetPort: 80
      protocol: TCP
      name: http
    -   port: 443
      targetPort: 443
      protocol: TCP
      name: https

Subconjuntos de reglas de destino

Al configurar la API de reglas de destino de Istio con subconjuntos, cada subconjunto puede generar varios servicios de Cloud Service Mesh.

Por ejemplo, considere el siguiente DestinationRule que tiene como objetivo el servicio de Kubernetes definido anteriormente:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service-destinationrule
spec:
  host: my-service
  subsets:
  -   name: testversion
    labels:
      version: v3
  -   name: prodversion
    labels:
      version: v2

Se crearán servicios sintéticos para cada uno de los subconjuntos definidos. Si el servicio de Kubernetes original ha creado dos servicios de Cloud Service Mesh, DestinationRule creará cuatro servicios de Cloud Service Mesh adicionales (dos por cada subconjunto), lo que dará como resultado un total de seis servicios de Cloud Service Mesh.

Despliegues multiproyecto

Cuando se despliega una sola malla en cargas de trabajo de diferentes proyectos, todos los recursos de servicio de Cloud Service Mesh se crean en el proyecto host de la flota. Google CloudEsto significa que todos están sujetos a las limitaciones de escalabilidad de Cloud Service Mesh en el proyecto host de la flota.

Servicios sin encabezado de Kubernetes

Los servicios sin encabezado de Kubernetes tienen un límite inferior en comparación con los servicios normales. Cloud Service Mesh solo admite 50 servicios de Cloud Service Mesh sin encabezado por clúster. Consulta un ejemplo en la documentación de redes de Kubernetes.

Límites de escalado de endpoints

Los límites de escalado de los endpoints suelen ser los siguientes:

• Servicio Cloud Service Mesh

• Clúster de GKE

Servicios de Kubernetes normales

Las cuotas de puntos finales por NEG afectan al número máximo de puntos finales que pueden pertenecer a un mismo servicio de Kubernetes.

Servicios sin encabezado de Kubernetes

En el caso de los servicios sin encabezado de Kubernetes, Cloud Service Mesh admite un máximo de 36 endpoints por servicio sin encabezado. Consulta un ejemplo en la documentación de redes de Kubernetes.

Límites de clústeres de GKE

Cloud Service Mesh admite hasta 5000 endpoints (IPs de pods) por clúster.

Límite de escalado de la pasarela

Cuando se usan las pasarelas de Istio, sobre todo para finalizar las conexiones HTTPS con credenciales TLS en secretos de Kubernetes, Cloud Service Mesh admite como máximo el siguiente número de pods:

• 1500 pods de pasarela cuando se usan clústeres de GKE regionales

• 500 pods de pasarela al usar clústeres de GKE zonales o de Autopilot