Skalierungsgrenzen für Cloud Service Mesh auf der GKE

In diesem Dokument werden die Skalierungsgrenzen der Steuerungsebene für verwaltete Cloud Service Mesh-Architekturen auf der GKE beschrieben. Damit können Sie fundierte Entscheidungen in Bezug auf Ihre Bereitstellungen treffen.

Übersicht

Die Skalierbarkeit von Cloud Service Mesh auf der GKE hängt von der effizienten Ausführung der beiden Hauptkomponenten ab: der Datenebene und der Steuerungsebene. In diesem Dokument geht es um die Skalierungsgrenzen der Steuerungsebene. Weitere Informationen zu Best Practices für die Skalierbarkeit der Datenebene.

Einige der beschriebenen Skalierungsgrenzen werden durch Kontingentbeschränkungen erzwungen. Wenn Sie diese überschreiten, müssen Sie eine Kontingenterhöhung anfragen. Andere Grenzwerte werden nicht strikt durchgesetzt, können bei Überschreitung aber zu unerwartetem Verhalten und schlechterer Leistung führen.

Informationen dazu, wie Istio-Ressourcen in Google Cloud -Ressourcen übersetzt werden, finden Sie in der Anleitung Cloud Service Mesh API-Ressourcen.

Skalierungsgrenzen für Dienste

Die Dienstskalierung ist in zwei Dimensionen begrenzt.

Wenn Cloud Service Mesh für eine bestimmte Mitgliedschaft (d. h. einen GKE-Cluster) aktiviert ist, werden alle Kubernetes-Dienste im Cluster in Cloud Service Mesh-Dienste übersetzt. Das gilt auch für Dienste, die auf Arbeitslasten ohne Cloud Service Mesh-Sidecar ausgerichtet sind. Cloud Service Mesh erstellt für alle Dienste im GKE-Cluster zonale Netzwerk-Endpunktgruppen. Ist der Cluster regional, werden für alle Knotenpoolzonen in der Region Netzwerk-Endpunktgruppen erstellt.

Vergleich zwischen Cloud Service Mesh-Diensten und Kubernetes-Diensten

Cloud Service Mesh-Dienste unterscheiden sich von Kubernetes-Diensten, da bei Cloud Service Mesh ein Dienst pro Port ausgeführt wird.

Beispielsweise wird dieser Kubernetes-Dienst intern in zwei Cloud Service Mesh-Dienste übersetzt, einen für jeden Port.

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

Teilmengen von Zielregeln

Wenn Sie die Istio Destination Rule API mit Teilmengen konfigurieren, kann jede Teilmenge zur Generierung mehrerer neuer Cloud Service Mesh-Dienste führen.

Nehmen Sie beispielsweise die folgende DestinationRule, die auf den zuvor definierten Kubernetes-Dienst ausgerichtet ist:

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

Für jede der definierten Teilmengen werden neue synthetische Dienste erstellt. Wenn für den ursprünglichen Kubernetes-Dienst zwei Cloud Service Mesh-Dienste erstellt wurden, werden durch die DestinationRule nun vier weitere Cloud Service Mesh-Dienste erstellt, zwei für jede Teilmenge. Insgesamt sind dann also sechs Cloud Service Mesh-Dienste vorhanden.

Bereitstellungen in mehreren Projekten

Wenn für Arbeitslasten in verschiedenen Google Cloud-Projekten ein einzelnes Mesh-Netzwerk bereitgestellt wird, werden alle Cloud Service Mesh-Dienstressourcen im Flotten-Hostprojekt erstellt. Daher unterliegen alle Ressourcen den Cloud Service Mesh-Skalierungsgrenzen im Flotten-Hostprojekt.

Monitorlose Kubernetes-Dienste

Für monitorlose Kubernetes-Dienste gilt ein niedrigerer Grenzwert als für reguläre Dienste. Cloud Service Mesh unterstützt nur 50 monitorlose Cloud Service Mesh-Dienste pro Cluster. Ein Beispiel finden Sie in der Kubernetes-Dokumentation.

Skalierungsgrenzen für Endpunkte

In der Regel gelten für Endpunkte folgende Skalierungsgrenzen:

  • Cloud Service Mesh-Dienst

  • GKE-Cluster

Reguläre Kubernetes-Dienste

Kontingente für Endpunkte pro NEG wirken sich auf die maximale Anzahl an Endpunkten aus, die zu einem einzelnen Kubernetes-Dienst gehören können.

Monitorlose Kubernetes-Dienste

Für monitorlose Kubernetes-Dienste unterstützt Cloud Service Mesh maximal 36 Endpunkte pro monitorlosem Dienst. Ein Beispiel finden Sie in der Kubernetes-Dokumentation.

Skalierungsgrenzen für GKE-Cluster

Cloud Service Mesh unterstützt bis zu 5.000 Endpunkte (Pod-IPs) pro Cluster.

Skalierungsgrenzen für Gateways

Wenn Sie Istio-Gateways insbesondere für die Terminierung von HTTPS-Verbindungen mit TLS-Anmeldedaten in Kubernetes-Secrets verwenden, unterstützt Cloud Service Mesh maximal die folgende Anzahl an Pods:

  • 1.500 Gateway-Pods für regionale GKE-Cluster

  • 500 Gateway-Pods für zonale oder Autopilot-GKE-Cluster