Cloud Service Mesh API-Ressourcen
Wenn Sie die Gateway API und die Istio API verwenden, um Ihr Service Mesh in GKE zu konfigurieren, werden die KRM-basierten API-Ressourcen, die Sie in GKE verwalten, automatisch in eine Reihe von Google Cloud API-Ressourcen übersetzt:
- Für Sie fallen keine zusätzlichen Kosten an.
- Sie werden ausschließlich von der Infrastruktur des verwalteten Cloud Service Mesh verwaltet(basierend auf den API-Ressourcen, die Sie in Ihren GKE-Clustern erstellen). Sie können diese Google Cloud API-Ressourcen nicht ändern oder löschen. Änderungen an der KRM API würden eine Aktualisierung oder Entfernung der entsprechenden Google Cloud API-Ressourcen auslösen. DieGoogle Cloud API-Ressourcen werden automatisch entfernt, wenn Sie Ihr Cloud Service Mesh-Servicemesh bereitstellen.
- Sie sind funktional gleichwertig mit den API-Ressourcen, die Sie in GKE verwaltet haben. Die Cloud Service Mesh-Infrastruktur programmiert die Datenebene in Ihren GKE-Clustern basierend auf diesen Google Cloud API-Ressourcen.
- Für sie gilt die standardmäßige Google Cloud API-Kontingentsteuerung. Die aktuelle Kontingentnutzung Ihres Google Cloud Projekts können Sie sich ansehen. Die Konfigurationsübertragung an die Datenebene wird unterbrochen, wenn das Google Cloud -Ressourcenkontingent überschritten wird. Google Cloud erzwingt das Ressourcenkontingent auf Projektebene und diese Google Cloud API-Ressourcen teilen sich das Kontingent mit derselben Art von Google Cloud API-Ressource, die von Ihnen verwaltet wird.
Im Folgenden finden Sie einen allgemeinen Überblick darüber, wie API-Ressourcen in GKE Google Cloud API-Ressourcen zugeordnet werden. In den meisten Fällen ist es nicht erforderlich, die API-Zuordnung zu verstehen, um Ihr Service Mesh in GKE zu verwenden, da Sie Ihr Service Mesh in GKE mit der Gateway API oder der Istio API verwalten. Andererseits hilft Ihnen ein grundlegendes Verständnis der API-Zuordnung, IhrGoogle Cloud API-Kontingent effizienter zu planen und zu verwalten, wenn Ihr Service Mesh skaliert wird.
API-Ressourcen verstehen
Die API-Ressourcen, die Sie in GKE verwalten, werden einer Reihe von Google Cloud API-Ressourcen zugeordnet, die verschiedene Aspekte des Verhaltens des Traffics in der Datenebene steuern. Wir empfehlen, Kontingentbenachrichtigungen für diese Ressourcen einzurichten.
Istio API mit verwaltetem Cloud Service Mesh
| Element | Istio API-Ressourcen | Google Cloud API-Ressourcen | Umfang | Kontingente und Limits | Obergrenze |
|---|---|---|---|---|---|
| Traffic-Routing | VirtualService |
HTTPRoute TCPRoute TLSRoute |
Global |
HTTPRoute-Kontingent TCPRoute-Kontingent TLSRoute-Kontingent |
1 pro Dienstport und für jede Istio-VirtualService-HTTPRoute, -TCPRoute und -TLSRoute. |
| Dienstdarstellung(für Routen-/Richtlinienanhang) |
Service ServiceEntry |
BackendService | Global | BackendService-Kontingent | 1 pro Dienstport (einschließlich Istio ServiceEntry). |
| Arbeitslasteigenschaften(z. B. IP:Port, Lokalität) |
Service ServiceEntry |
NetworkEndpointGroup | Zonal | Kontingent für Netzwerk-Endpunktgruppen | 1 pro (Dienstport, Zone). In einem regionalen GKE-Cluster wird für einen bestimmten Dienstport in jeder Zone, in der der Cluster mindestens einen Knoten hat, eine NetworkEndpointGroup erstellt. |
| Monitoring des Arbeitslaststatus | Dienst | HealthCheck | Global | Kontingent für Systemdiagnosen | 1 pro GKE-Cluster. |
| Anhängungspunkt für Arbeitslastrichtlinien |
PeerAuthentication AuthorizationPolicy RequestAuthentication EnvoyFilter |
EndpointPolicy | Global | Kontingent für EndpointPolicy | 1 pro Dienstport und für jede der Arbeitslastrichtlinien. |
| Authentifizierung | PeerAuthentication |
ClientTlsPolicy ServerTlsPolicy |
Global |
ClientTlsPolicy-Kontingent ServerTlsPolicy-Kontingent |
1 ClientTlsPolicy pro Dienstport. 1 ServerTlsPolicy für jedes TLS-Gateway. |
| Autorisierung | AuthorizationPolicy | HttpFilter | Global | HttpFilter-Kontingent | 1 pro Istio AuthorizationPolicy |
| Gateway | Gateway | Gateway | Global | Gateway-Kontingent | 1 pro Istio-Gateway-Serverport |
| Richtlinie zur Traffic-Verteilung | GCPTrafficDistributionPolicy 1 | ServiceLbPolicy | Global | Kontingent für ServiceLbPolicy | 1 pro GCPTrafficDistributionPolicy |
Wenn sich Ihr Service Mesh über mehrere Cluster in verschiedenen Projekten erstreckt, werden alleGoogle Cloud -Ressourcen im Flottenprojekt erstellt.
1GCPTrafficDistributionPolicy ist keine Istio-API. Sie erweitert die Istio API, um eine erweiterte Trafficverwaltung zu ermöglichen.
Kubernetes Gateway API mit Managed Cloud Service Mesh
| Element | Kubernetes Gateway API-Ressourcen | Google Cloud API-Ressourcen | Umfang | Kontingente und Limits | Obergrenze |
|---|---|---|---|---|---|
| Traffic-Routing |
HTTPRoute GRPCRoute |
HTTPRoute GRPCRoute |
Global |
HTTPRoute-Kontingent GRPCRoute-Kontingent |
1 pro Dienstport und für jede HTTPRoute und GRPCRoute. |
| Dienstdarstellung(für Routen-/Richtlinienanhang) | Dienst | BackendService | Global | BackendService-Kontingent | 1 pro Serviceport, der von HTTPRoute und GRPCRoute angehängt wird. |
| Arbeitslasteigenschaften(z. B. IP:Port, Lokalität) | Dienst | NetworkEndpointGroup | Zonal | Kontingent für Netzwerk-Endpunktgruppen | 1 pro (Dienstport, Zone). In einem regionalen GKE-Cluster wird für einen bestimmten Dienstport in jeder Zone, in der der Cluster mindestens einen Knoten hat, eine NetworkEndpointGroup erstellt. |
| Monitoring des Arbeitslaststatus | Dienst | HealthCheck | Global | Kontingent für Systemdiagnosen | 1 pro Serviceport, der von HTTPRoute und GRPCRoute angehängt wird. |