Skalierungslimits für Cloud Service Mesh in GKE

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

Übersicht

Die Skalierbarkeit von Cloud Service Mesh in GKE hängt vom effizienten Betrieb der beiden Hauptkomponenten ab: der Datenebene und der Steuerungsebene. In diesem Dokument geht es um die Skalierungsgrenzen der Steuerungsebene. Best Practices für die Skalierbarkeit für die Skalierbarkeit der Datenebene

Einige der dokumentierten Skalierungsgrenzen werden durch Kontingentbeschränkungen erzwungen. Wenn Sie diese überschreiten, müssen Sie eine Kontingenterhöhung anfordern. Andere werden nicht streng durchgesetzt, können aber zu undefiniertem Verhalten und Leistung führen, wenn sie überschritten werden.

Informationen dazu, wie Istio-Ressourcen in Google Cloud -Ressourcen übersetzt werden, finden Sie zuerst im Leitfaden API-Ressourcen.

Limits für die Dienstskalierung

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, auch solche, die auf Arbeitslasten ohne Cloud Service Mesh-Sidecar ausgerichtet sind. Cloud Service Mesh erstellt zonale Netzwerk-Endpunktgruppen für alle Dienste im GKE-Cluster. Wenn der Cluster regional ist, werden Netzwerk-Endpunktgruppen für alle Knotenpoolzonen in der Region erstellt.

Cloud Service Mesh-Dienste im Vergleich zu Kubernetes-Diensten

Cloud Service Mesh-Dienste sind nicht mit Kubernetes-Diensten identisch, da Cloud Service Mesh-Dienste ein Dienst pro Port sind.

Dieser Kubernetes-Dienst wird 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.

Betrachten 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 DestinationRule vier zusätzliche Cloud Service Mesh-Dienste erstellt, zwei für jede Teilmenge. Insgesamt gibt es dann sechs Cloud Service Mesh-Dienste.

Bereitstellungen in mehreren Projekten

Wenn ein einzelnes Mesh für Arbeitslasten in verschiedenen Google Cloud-Projekten bereitgestellt wird, werden alle Cloud Service Mesh-Diensteressourcen im Flotten-Hostprojekt erstellt. Das bedeutet, dass sie alle den Cloud Service Mesh-Skalierbarkeitsbeschränkungen im Flotten-Hostprojekt unterliegen.

Headless-Dienste in Kubernetes

Für monitorlose Kubernetes-Dienste gilt ein niedrigeres Limit 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 zum Thema Netzwerke.

Istio-Sidecar-Ressourcen

Für die Istio Sidecar API gelten die folgenden Limits:

  • Sidecar ohne workloadSelector: 150 pro Cluster

  • Sidecar mit workloadSelector: 20 pro Cluster

Skalierungslimits für Endpunkte

Die Skalierungslimits für Endpunkte sind in der Regel:

  • Cloud Service Mesh-Dienst

  • GKE-Cluster

Reguläre Kubernetes-Dienste

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

Headless-Dienste in Kubernetes

Bei monitorlosen Kubernetes-Diensten unterstützt Cloud Service Mesh maximal 36 Endpunkte pro monitorlosem Dienst. Ein Beispiel finden Sie in der Kubernetes-Netzwerkdokumentation.

GKE-Clusterlimits

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

Skalierungslimit für Gateways

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

  • 1.500 Gateway-Pods bei Verwendung regionaler GKE-Cluster

  • 500 Gateway-Pods bei Verwendung von zonalen oder Autopilot-GKE-Clustern