Límites de escalamiento de Cloud Service Mesh en GKE

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

Descripció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 escalamiento del plano de control. Consulta las prácticas recomendadas de escalabilidad para conocer las prácticas recomendadas de escalabilidad del plano de datos.

Algunos de los límites de escalamiento documentados se aplican a través de restricciones de cuota. Si los superas, deberás solicitar aumentos de cuota. Otros no se aplican estrictamente, pero pueden generar un comportamiento y un rendimiento indefinidos si se superan.

Para comprender cómo se traducen los recursos de Istio en recursos de Google Cloud , primero consulta la guía Cómo comprender los recursos de la API.

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

Límites de escalamiento de servicios

El escalamiento de servicios está limitado en dos dimensiones

• Por proyecto: Se admite un máximo de 1,000 servicios de Cloud Service Mesh por proyectoGoogle Cloud (con la excepción de los servicios sin interfaz gráfica de Kubernetes).

• Por zona y por proyecto: Dado que Cloud Service Mesh crea grupos de extremos de red por zona para los servicios de GKE en el clúster, los límites de cuota de NEG zonales se aplican a la cantidad de servicios por proyecto que pueden tener extremos en esa zona.

Ten en cuenta que, una vez que se habilita Cloud Service Mesh para una membresía en particular (es decir, un clúster de GKE), todos los servicios de Kubernetes del clúster se traducen a servicios de Cloud Service Mesh, incluidos aquellos que segmentan cargas de trabajo sin un archivo adicional de Cloud Service Mesh. Cloud Service Mesh crea grupos de extremos de red zonales para todos los servicios del clúster de GKE. Si el clúster es regional, se crean grupos de extremos de red para todas las zonas del grupo de nodos en la región.

Servicios de Cloud Service Mesh en comparación con los servicios de Kubernetes

Los servicios de Cloud Service Mesh no son iguales a 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 para 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

Cuando configuras la API de Istio Destination Rule con subconjuntos, cada subconjunto puede generar varios servicios nuevos de Cloud Service Mesh.

Por ejemplo, considera el siguiente DestinationRule que se orienta al 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 nuevos para cada uno de los subconjuntos definidos. Si el servicio de Kubernetes original creó dos servicios de Cloud Service Mesh, el DestinationRule creará 4 servicios de Cloud Service Mesh adicionales, 2 para cada subconjunto, lo que generará un total de 6 servicios de Cloud Service Mesh.

Implementaciones en varios proyectos

Cuando se implementa una sola malla en cargas de trabajo en diferentes proyectos de Google Cloud, todos los recursos de servicio de Cloud Service Mesh se crean en el proyecto host de la flota. Esto 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 interfaz gráfica de Kubernetes tienen un límite inferior en comparación con los servicios normales. Cloud Service Mesh solo admite 50 servicios sin interfaz gráfica de Cloud Service Mesh por clúster. Consulta la documentación sobre las herramientas de redes de Kubernetes para ver un ejemplo.

Recursos de sidecar de Istio

Para la API de Istio Sidecar, se aplican los siguientes límites:

• Archivo adicional sin workloadSelector: 150 por clúster

• Complemento con workloadSelector: 20 por clúster

Límites de escalamiento de extremos

Por lo general, los límites de escalamiento de los extremos se basan en lo siguiente:

• Servicio de Cloud Service Mesh

• Clúster de GKE

Servicios de Kubernetes regulares

Las cuotas de extremos por NEG afectan la cantidad máxima de extremos que pueden pertenecer a un solo servicio de Kubernetes.

Servicios sin encabezado de Kubernetes

En el caso del servicio sin interfaz gráfica de Kubernetes, Cloud Service Mesh admite no más de 36 extremos por servicio sin interfaz gráfica. Consulta la documentación de redes de Kubernetes para ver un ejemplo.

Límites de clúster de GKE

Cloud Service Mesh admite hasta 5,000 extremos (direcciones IP de Pod) por clúster.

Límite de escalamiento de la puerta de enlace

Cuando usas puertas de enlace de Istio, en especial para finalizar conexiones HTTPS con credenciales de TLS en secretos de Kubernetes, Cloud Service Mesh admite, como máximo, la siguiente cantidad de Pods:

• 1,500 pods de puerta de enlace cuando se usan clústeres de GKE regionales

• 500 pods de puerta de enlace cuando se usan clústeres de GKE zonales o de Autopilot