In diesem Dokument sind die Kontingente und Systemlimits für Diensterweiterungen aufgeführt.
- Kontingente haben Standardwerte, aber Sie können in der Regel Anpassungen anfordern.
- Systemlimits sind feste Werte, die nicht geändert werden können.
Kontingente
Google Cloud nutzt Kontingente, um für Fairness zu sorgen und Spitzen bei der Ressourcennutzung und ‑verfügbarkeit zu reduzieren. Ein Kontingent schränkt ein, wie viel von einerGoogle Cloud Ressource Ihr Google Cloud Projekt nutzen kann. Kontingente gelten für eine Reihe von Ressourcentypen, einschließlich Hardware, Software und Netzwerkkomponenten. Mit Kontingenten können Sie beispielsweise die Anzahl der API-Aufrufe an einen Dienst, die Anzahl der von Ihrem Projekt nebenläufig verwendeten Load Balancer oder die Anzahl der Projekte begrenzen, die Sie erstellen können. Kontingente sollen eine Überlastung von Diensten verhindern und dadurch die Community derGoogle Cloud Nutzer schützen. Sie helfen Ihnen auch bei der Verwaltung Ihrer eigenen Google Cloud Ressourcen.
Das Cloud-Kontingentsystem tut Folgendes:
- Es überwacht Ihren Verbrauch von Google Cloud Produkten und Diensten.
- Es schränkt Ihren Verbrauch dieser Ressourcen ein.
- Es bietet eine Möglichkeit, Änderungen am Kontingentwert zu beantragen und Kontingentanpassungen zu automatisieren.
Wenn Sie versuchen, mehr von einer Ressource zu verbrauchen, als das Kontingent zulässt, blockiert das System in den meisten Fällen den Zugriff auf die Ressource. Die Aufgabe, die Sie auszuführen versuchen, schlägt dann fehl.
Kontingente gelten in der Regel auf Google Cloud Projektebene. Die Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf das verfügbare Kontingent in einem anderen Projekt. Innerhalb eines Google Cloud Projekts werden die Kontingente für alle Anwendungen und IP-Adressen gemeinsam genutzt.
Weitere Informationen finden Sie unter Cloud-Kontingente – Übersicht.
Die meisten Kontingente können Sie in der Google Cloud Console anpassen. Weitere Informationen finden Sie unter Kontingentanpassung anfordern.
Für Dienstextensions gelten die folgenden Kontingente. Sie können auf Anfrage erhöht werden.
| Kontingente | Wert | |
|---|---|---|
| Maximale Anzahl globaler Autorisierungserweiterungen in einem Projekt | 10 | |
| Maximale Anzahl globaler Edge-Erweiterungen in einem Projekt | 100 | |
| Maximale Anzahl globaler Routenerweiterungen in einem Projekt | 100 | |
| Maximale Anzahl globaler Traffic-Erweiterungen in einem Projekt | 100 | |
| Maximale Anzahl von Autorisierungserweiterungen pro Region in einem Projekt | 10 | |
| Maximale Anzahl von Routenerweiterungen pro Region in einem Projekt | 100 | |
| Maximale Anzahl von Traffic-Erweiterungen pro Region in einem Projekt | 100 | |
| Maximale Anzahl von Plugins pro Projekt | 100 | |
| Nur Cloud Load Balancing: Maximale Anzahl von Plug-ins, die Application Load Balancern über Edge-Erweiterungen pro Projekt angehängt werden | 5 zu einem beliebigen Zeitpunkt | |
| Nur Cloud Load Balancing: Maximale Anzahl von Plug-ins, die über Routenerweiterungen pro Projekt, pro Standort und pro Load-Balancing-Schema an Application Load Balancer angehängt werden | 5 zu einem beliebigen Zeitpunkt | |
| Nur Cloud Load Balancing: Maximale Anzahl von Plug-ins, die über Traffic-Erweiterungen pro Projekt, pro Standort und pro Load-Balancing-Schema an Application Load Balancer angehängt werden | 5 zu einem beliebigen Zeitpunkt | |
Nur Media CDN: Maximale Anzahl von Plug-in-Ressourcen, die über WasmAction-Ressourcen pro Projekt an Media CDN-Dienste angehängt werden |
5 zu einem beliebigen Zeitpunkt |
Limits
Für Diensterweiterungsressourcen gelten außerdem Systemlimits. Systemlimits können nicht geändert werden.
Für Service Extensions gelten folgende Nutzungslimits:
| Nutzungsbeschränkung | Wert | |
|---|---|---|
| Maximale Anzahl von Erweiterungsketten pro Ankerpunkt | 5 | |
| Maximale Anzahl von Plug-ins in einer Edge-Erweiterungskette | 1 | |
| Maximale Anzahl von Plug-ins oder Zusatzinformationen in einer Routenerweiterungskette | 1 | |
| Maximale Anzahl von Plugins oder Zusatzinformationen in einer Traffic-Erweiterungskette | 3 | |
Maximale Ausführungsdauer pro Anfrage. Die Dauer ist die Summe der Dauern aller Proxy-Wasm-Callbacks, die der Anfrage zugeordnet sind. Plugins, die das Limit überschreiten, werden beendet. Die zugehörige Anfrage gibt dann den HTTP-Statuscode |
1 ms | |
| Maximale Größe eines kompilierten Plug‑ins zusammen mit den Konfigurationsdaten des Plug‑ins. | 5 MiB | |
Maximale Größe der Konfigurationsdaten des Plug-ins, wenn sie direkt angegeben werden (durch Hochladen einer Datei in der Google Cloud Konsole, mit der Option --plugin-config oder --plugin-config-file im Cloud SDK oder mit dem Feld WasmPluginVersion.plugin_config_data in der REST API) und nicht über Artifact Registry.
|
900 KiB | |
Maximale CPU-Nutzung pro Anfrage. Maximale normalisierte vCPU, die pro Plug-in-Aufruf verwendet wird.
Plugins, die dieses Limit überschreiten, werden beendet. Die zugehörige Anfrage gibt dann den HTTP-Statuscode |
1 ms | |
Maximaler Arbeitsspeicher, der von einem Plug-in verwendet wird Maximaler zugewiesener Arbeitsspeicher einer Plug-in-Instanz.
Plugins, die dieses Limit überschreiten, werden beendet. Die zugehörige Anfrage gibt dann den HTTP-Statuscode |
16 MiB | |
Maximale Größe der Log-Inhalte, die von einem Plug-in pro Aufruf ausgegeben werden Wenn das Limit überschritten wird, werden weitere Logs verworfen. |
16 KiB | |
Maximale Anzahl von Logeinträgen, die von einem Plugin pro Aufruf ausgegeben werden Wenn das Limit überschritten wird, werden weitere Logs verworfen. |
16 | |
| Maximale Anzahl von Versionen pro Plug-in | 100 |