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 administradas de Cloud Service Mesh en GKE, de modo que puedas tomar decisiones fundamentadas con respecto a 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.

Algunas de las limitaciones de escalamiento documentadas se aplican mediante restricciones de cuota. Si las superas, deberás solicitar aumentos de cuota. Otros no se aplican de manera estricta, pero pueden generar un comportamiento y un rendimiento indefinidos si se superan.

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

Límites de escalamiento de servicios

El escalamiento de servicios se limita 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 la malla de servicios de Cloud crea grupos de extremos de red por zona para los servicios de GKE en el clúster, los límites de cuota de NEG por zona se aplican a la cantidad de servicios por proyecto que pueden tener extremos en esa zona.

Ten en cuenta que, una vez que Cloud Service Mesh se habilita para una membresía en particular (es decir, el clúster de GKE), todos los servicios de Kubernetes del clúster se traducen a servicios de Cloud Service Mesh, incluidos los que se orientan a 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 de 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 de Kubernetes, ya que los servicios de Cloud Service Mesh son uno por puerto.

Por ejemplo, este servicio de Kubernetes se traduce de forma interna 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 la regla de destino de Istio con subconjuntos, cada subconjunto puede generar varios servicios nuevos de malla de servicios de Cloud.

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 da como resultado un total de 6 servicios de Cloud Service Mesh.

Implementaciones de varios proyectos

Cuando se implementa una sola malla en cargas de trabajo en diferentes Google Cloud proyectos, 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 cabeza de Kubernetes

Los servicios sin interfaz gráfica de Kubernetes tienen un límite más bajo 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 de las herramientas de redes de Kubernetes para ver un ejemplo.

Límites de escalamiento de extremos

Por lo general, los límites de escalamiento de extremos se establecen según lo siguiente:

• Servicio de Cloud Service Mesh

• Clúster de GKE

Servicios de Kubernetes normales

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

Servicios sin cabeza de Kubernetes

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

Límites de los clústeres de GKE

Cloud Service Mesh admite hasta 5,000 extremos (IPs de pod) por clúster.

Límite de escalamiento de la puerta de enlace

Cuando usas puertas de enlace de Istio, especialmente 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 zonal o Autopilot