Skalierungslimits für Cloud Service Mesh in GKE

In diesem Dokument werden die Skalierungslimits der Steuerungsebene für verwaltete Cloud Service Mesh-Architekturen in GKE beschrieben, damit Sie fundierte Entscheidungen bezüglich Ihrer 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 Skalierungslimits der Kontrollebene. Best Practices für die Skalierbarkeit der Datenebene finden Sie unter Best Practices für die Skalierbarkeit.

Einige der dokumentierten Skalierungslimits werden durch Kontingenteinschränkungen erzwungen. Wenn Sie diese Grenzwerte überschreiten, müssen Sie eine Kontingenterhöhung beantragen. Andere werden nicht streng durchgesetzt, können aber bei Überschreitung zu undefiniertem Verhalten und Leistungseinbußen führen.

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

Limits für die Dienstskalierung

Die Dienstskalierung ist in zwei Dimensionen eingeschränkt

Hinweis: Sobald Cloud Service Mesh für eine bestimmte Mitgliedschaft (z. B. GKE-Cluster) aktiviert ist, werden alle Kubernetes-Dienste im Cluster in Cloud Service Mesh-Dienste umgewandelt, einschließlich derjenigen, 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 unterscheiden sich von Kubernetes-Diensten dadurch, dass es bei Cloud Service Mesh-Diensten einen Dienst pro Port gibt.

Dieser Kubernetes-Dienst wird beispielsweise intern in zwei Cloud Service Mesh-Dienste umgewandelt, 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 der ursprüngliche Kubernetes-Dienst zwei Cloud Service Mesh-Dienste erstellt hat, werden mit der DestinationRule vier weitere Cloud Service Mesh-Dienste erstellt, zwei für jede Teilmenge, was insgesamt sechs Cloud Service Mesh-Dienste ergibt.

Bereitstellungen mehrerer Projekte

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

Kubernetes-Headless-Dienste

Für Kubernetes-Headless-Dienste gilt ein niedrigeres Limit als für reguläre Dienste. Cloud Service Mesh unterstützt nur 50 headless Cloud Service Mesh-Dienste pro Cluster. Ein Beispiel finden Sie in der Kubernetes-Netzwerkdokumentation.

Limits für die Endpunktskalierung

Die Limits für die Endpunktskalierung sind in der Regel so:

  • Cloud Service Mesh-Dienst

  • GKE-Cluster

Regelmäßige 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.

Kubernetes-Headless-Dienste

Für einen Kubernetes-Headless-Dienst unterstützt Cloud Service Mesh nicht mehr als 36 Endpunkte pro Headless-Dienst. Ein Beispiel finden Sie in der Dokumentation zum Kubernetes-Netzwerk.

GKE-Clusterlimits

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

Gateway-Skalierungslimit

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