Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Ausgehender Direct VPC-Traffic

Ausgehender Direct VPC-Traffic bietet eine leistungsstarke Netzwerklösung für Ihren App Engine-Dienst, um Traffic an ein VPC-Netzwerk (Virtual Private Cloud) zu senden. Durch ausgehenden Direct VPC-Traffic können Arbeitslasten nahtlos auf VPC-Netzwerkressourcen zugreifen. Die Konfiguration von Connectors für Serverloser VPC-Zugriff ist nicht mehr erforderlich.

Hauptvorteile

Vereinfachte Verwaltung: Der Betriebsaufwand für die Verwaltung von Connector-Instanzen, Maschinentypen und Skalierungseinstellungen wird reduziert. In App Engine werden Konfigurationen direkt in der Datei app.yaml Ihres Dienstes verarbeitet.
Kosteneffizienz: Für ausgehenden Direct VPC-Traffic fallen keine zusätzlichen Gebühren an und Sie müssen keine festen monatlichen Gebühren für Connector-VMs bezahlen.
Bessere Leistung und Zuverlässigkeit: Da kein Connector mehr erforderlich ist, bietet ausgehender Direct VPC-Traffic eine schnellere und zuverlässigere Verbindung zu Ihren VPC-Netzwerkressourcen. Es lässt sich so schnell skalieren wie Ihr App Engine-Dienst und vermeidet Verbindungsabbrüche, die bei Connectors während der Wartung auftreten können.
Granulare Sicherheit: Sie können Netzwerk-Tags direkt auf Ihre App Engine-Dienstversionen anwenden und so präzise, dienstspezifische Firewallregeln und Netzwerkrichtlinien erstellen.
Unterstützt VPC-Flusslogs: Sie können VPC-Flusslogs für Ihr Subnetz aktivieren, um den ausgehenden Traffic von Ihrem App Engine-Dienst zu protokollieren.

Beschränkungen

Verbrauch von IP-Adressen: Die IP-Adressnutzung Ihres Dienstes skaliert direkt mit der Anzahl der ausgeführten Instanzen. Ihre Skalierungsfähigkeit wird durch die Anzahl der verfügbaren IP-Adressen im ausgewählten Subnetz begrenzt.
Wartungsereignisse: Bei Wartungsereignissen der Netzwerkinfrastruktur kann es bei Ihrem Dienst zu kurzen Verbindungsunterbrechungen kommen. Wir empfehlen die Verwendung von Clientbibliotheken, bei denen gelegentlich Verbindungen zurückgesetzt werden können ohne dass es Probleme gibt.
Kaltstarts: Die anfänglichen Kaltstartzeiten hängen von der Region und dem jeweiligen Anwendungsfall ab. In seltenen Fällen kann ein Kaltstart bis zu einer Minute dauern.
Direct VPC Ingress: App Engine unterstützt Direct VPC Ingress nicht.
Anzahl der Instanzen: Sie können nur bis zu 100 Instanzen pro App Engine-Version für die Verwendung von Direct VPC-Ausgang konfigurieren.
VPC-Flusslogs: Die Version Ihres App Engine-Dienstes wird in den Logeinträgen nicht angezeigt. Der Dienstname wird im Feld AppEngineServiceDetails angezeigt.

Zuweisung von IP-Adressen

Wenn Sie Ihren App Engine-Dienst in einem VPC-Netzwerk platzieren möchten, geben Sie entweder ein VPC-Netzwerk oder ein Subnetz oder beides an. Wenn Sie nur ein Netzwerk angeben, hat das Subnetz denselben Namen wie das Netzwerk. App Engine weist IP-Adressen aus Ihrem Subnetz zu.

IP-Adressen sind sitzungsspezifisch. Erstellen Sie also keine Richtlinien, die auf einzelnen IP-Adressen basieren. Wenn Sie eine Richtlinie anhand von IP-Adressen erstellen müssen, z. B. in Firewallregeln, müssen Sie den IP-Adressbereich des gesamten Subnetzes verwenden.

Wenn Sie das von Ihrem Dienst verwendete Netzwerk oder Subnetz ändern möchten, stellen Sie eine neue Version bereit, die die neuen Netzwerk- und Subnetzwerte verwendet.

Hoch- und Herunterskalieren

Damit bei einem Trafficanstieg schnell eine vertikale Skalierung möglich ist, reserviert App Engine IP-Adressen in Blöcken von 16 Adressen (28-Subnetzmaske). Damit genügend IPv4-Adressen für die Verwendung in App Engine verfügbar sind, muss der IPv4-Adressbereich Ihres Subnetzes /26 oder größer sein.

Für eine effiziente IP-Zuweisung und einfachere Verwaltung platzieren Sie mehrere Ressourcen im selben Subnetz. Wenn Ihr IPv4-Adressbereich begrenzt ist, finden Sie weitere Optionen unter Unterstützte IPv4-Bereiche.

Wenn Sie das Subnetz löschen möchten, müssen Sie zuerst Ihren App Engine-Dienst löschen oder noch einmal bereitstellen, um das Subnetz nicht mehr zu verwenden. Warten Sie dann 1–2 Stunden.

IP-Adressverbrauch für Dienste

Im stabilen Zustand verwendet App Engine doppelt so viele IP-Adressen wie die Anzahl der Instanzen. Wenn eine Version herunterskaliert wird, behält App Engine ihre IP-Adressen bis zu 20 Minuten lang bei. Reservieren Sie insgesamt mindestens das Doppelte der Anzahl der IP-Adressen plus einen Puffer für Versionsupdates.

Wenn Sie beispielsweise die Versionen so aktualisieren, dass version 1 von 100 Instanzen auf null skaliert wird, während version 2 von null auf 100 skaliert wird, behält App Engine die version 1-IP-Adressen für bis zu 20 Minuten nach dem Herunterskalieren bei. Während des 20-minütigen Aufbewahrungszeitraums müssen Sie mindestens 400 IP-Adressen ((100 + 100) * 2) reservieren.

Unterstützte IPv4-Bereiche

App Engine unterstützt die folgenden IPv4-Bereiche für Ihr Subnetz:

RFC 1918
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
RFC 6598
- 100.64.0.0/10
Klasse E
- 240.0.0.0/4

Hinweis

Sie benötigen ein vorhandenes VPC-Netzwerk und ein Subnetz in Ihrem Projekt. Wenn Sie noch keine VPC haben, folgen Sie der Anleitung unter VPC-Netzwerk erstellen.
Aktivieren Sie die Compute Engine API und die Cloud Build API:

APIs aktivieren
Wenn Sie Direct VPC-Ausgang verwenden möchten, müssen Sie die neueste Version der Google Cloud CLI ausführen:
```
gcloud components update
```

Erforderliche Rollen

Achten Sie darauf, dass App Engine Zugriff auf das VPC-Netzwerk hat, indem Sie Ihrem Dienstkonto für die Bereitstellung die folgenden Rollen zuweisen:

Rolle „App Engine-Dienst-Agent“: Standardmäßig hat der App Engine-Dienst-Agent die Rolle App Engine-Dienst-Agent (roles/appengine.serviceAgent), die die erforderlichen Berechtigungen enthält.
Benutzerdefinierte Berechtigungen: Für eine detaillierte Kontrolle erteilen Sie dem App Engine-Dienst-Agent die folgenden zusätzlichen Berechtigungen für das Projekt:
- compute.networks.get
- compute.subnetworks.get
- compute.subnetworks.use für das Projekt oder das spezifische Subnetz
- compute.addresses.get
- compute.addresses.list
- compute.addresses.create
- compute.addresses.delete
- compute.addresses.createInternal
- compute.addresses.deleteInternal
- compute.regionOperations.get
Rolle „Compute-Netzwerknutzer“: Wenn Sie die Standardrolle „App Engine-Dienst-Agent“ oder die benutzerdefinierten Berechtigungen nicht verwenden, weisen Sie die Rolle Compute-Netzwerknutzer (roles/compute.networkUser) für das Dienstkonto von App Engine-Dienst-Agent zu. Für Subnetze mit externen IPv6-Adressen ist auch die Rolle Administrator öffentlicher IP-Adressen für Compute Engine (roles/compute.publicIpAdmin) erforderlich.

Führen Sie beispielsweise den folgenden Befehl aus, um die Rolle „Compute Network User“ zuzuweisen:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:service-PROJECT_NUMBER@gcp-gae-service.iam.gserviceaccount.com" \
--role "roles/compute.networkUser"
```
Ersetzen Sie Folgendes:
- PROJECT_ID: die Projekt-ID.
- PROJECT_NUMBER: Die Projektnummer, in der Sie Ihren App Engine-Dienst bereitstellen.

App Engine-Dienst mit ausgehendem Direct VPC-Traffic konfigurieren

So aktivieren Sie einen neuen oder vorhandenen App Engine-Dienst, damit er direkt eine Verbindung zu Ihrem VPC-Netzwerk herstellen kann:

Fügen Sie der Datei app.yaml die folgende vpc_access-Einstellung hinzu:
```
vpc_access:
  network_interface:
    network: NETWORK
    subnet: SUBNET
    tags:
        - NETWORK_TAGS
  vpc_egress: EGRESS_SETTING
```
Ersetzen Sie Folgendes:
- NETWORK: Der Name des vorhandenen Netzwerks, mit dem die Anwendungsinstanzen verbunden werden, z. B. default. Geben Sie entweder ein VPC-Netzwerk oder ein Subnetz oder beides an. Wenn Sie nur ein Netzwerk angeben, hat das Subnetz denselben Namen wie das Netzwerk.
- SUBNET: Der Name des vorhandenen Subnetzwerks, mit dem die Anwendungsinstanzen verbunden werden, z. B. default. Geben Sie entweder ein VPC-Netzwerk oder ein Subnetz oder beides an. Wenn Sie nur ein Netzwerk angeben, hat das Subnetz denselben Namen wie das Netzwerk.
- Optional: NETWORK_TAGS: Eine Liste von Netzwerk-Tags, die den Instanzen Ihres App Engine-Dienstes zugeordnet werden sollen und in Firewallregeln und Routingrichtlinien verwendet werden können.
- Optional: EGRESS_SETTING: Steuert, wie ausgehender Traffic weitergeleitet wird. Dieses Feld unterstützt die folgenden Konfigurationseinstellungen:
  - all-traffic: Alle ausgehenden Anfragen werden über das VPC-Netzwerk weitergeleitet.
  - private-ranges-only (Standard): Nur Traffic an interne IP-Adressen wird über das VPC-Netzwerk weitergeleitet. Für Internet-Traffic wird der Standard-App Engine-Pfad verwendet.
Stellen Sie die Anwendung mit dem folgenden Befehl in App Engine bereit:
```
gcloud beta app deploy
```

Dienst trennen

So trennen Sie Ihren Dienst vom VPC-Netzwerk:

Entfernen Sie den Abschnitt vpc_access aus der Datei app.yaml.
Stellen Sie den Dienst neu bereit:
```
gcloud beta app deploy
```

Best Practices für die IP-Verwaltung

Sie müssen Ihre IP-Adressen verwalten, da jede Instanz Ihres Dienstes eine IP-Adresse aus Ihrem Subnetz belegt. Verwenden Sie die folgenden Strategien, um Ihre IP-Adressen zu verwalten:

Empfohlener IP-Bereich: Für eine optimale Kompatibilität empfehlen wir, mit dem Bereich RFC 6598 (100.64.0.0/10) zu beginnen.
Alternative IP-Bereiche: Wenn Sie bereits den empfohlenen IP-Bereich 100.64.0.0/10 verwenden, können Sie in Ihrem Subnetz Bereiche außerhalb von RFC 1918 verwenden, z. B. Klasse E (240.0.0.0/4).
Subnetzgröße: Der IPv4-Adressbereich Ihres Subnetzes muss mindestens /26 sein, damit genügend Adressen für die Skalierung verfügbar sind.
IPs überdimensionieren: Wir empfehlen, die Anzahl der verfügbaren IPs in Ihrem Subnetz zu überdimensionieren, um eine Erschöpfung zu vermeiden. Ähnlich wie bei Cloud Run-Diensten sollten Sie in der Regel viermal so viele IPs verwenden (2X für den stabilen Zustand und zusätzlich 2X während der Bereitstellung) wie die Anzahl der ausgeführten Instanzen, um eine reibungslose Skalierung und Updates zu ermöglichen.

Fehlerbehebung

In diesem Abschnitt werden die häufigen Fehler beschrieben, die beim Bereitstellen Ihres App Engine-Dienstes mit ausgehendem VPC-Traffic auftreten können.

Subnetz kann nicht gelöscht werden

Bevor Sie ein Subnetz löschen können, müssen Sie zuerst alle Ressourcen löschen oder neu bereitstellen, die es verwenden. Wenn App Engine ein Subnetz verwendet, trennen Sie die Verbindung zum Dienst von App Engine vom VPC-Netzwerk oder verschieben Sie es vor dem Verschieben in ein anderes Subnetz, bevor Sie das Subnetz löschen.

Nachdem Sie Ihren App Engine-Dienst gelöscht oder verschoben haben, müssen Sie ein bis zwei Stunden warten, bis App Engine die IP-Adressen freigegeben hat und Sie das Subnetz löschen können.

Bereitstellungsfehler

Wenn die Bereitstellung fehlschlägt, werden in der Google Cloud CLI Fehlermeldungen angezeigt, die die Ursache angeben. Zu den häufigsten Problemen zählen folgende:

Falsche VPC-Metadaten, z. B. ein falsch geschriebener Netzwerk- oder Subnetzname in Ihrer app.yaml-Datei. Sehen Sie sich die VPC-Konfiguration in der Datei app.yaml an, um mögliche Fehler zu beheben.
Unzureichende IAM-Berechtigungen. Achten Sie darauf, dass Sie Ihrem Dienstkonto für die Bereitstellung die erforderlichen Berechtigungen erteilen. Wenn während der Bereitstellung Berechtigungsfehler auftreten, weisen Sie dem Dienstkonto die folgenden zusätzlichen Rollen zu:
- Cloud Build-Dienstkonto (roles/cloudbuild.builds.builder)
- Ersteller von Dienstkonto-Token (roles/iam.serviceAccountTokenCreator)

Aufgebrauchte IP-Adressen

Wenn in Ihrem Subnetz keine verfügbaren IP-Adressen mehr vorhanden sind, kann App Engine keine neuen Instanzen starten und protokolliert einen Fehler. Um dieses Problem zu beheben, erweitern Sie den IP-Bereich Ihres Subnetzes oder verschieben Sie Ihren Dienst in ein größeres Subnetz.

Lecks von IP-Adressen

Durch IP-Adresslecks kann es dazu kommen, dass IP-Adressen aufgebraucht werden. IP-Adressen werden bei normalem Betrieb nur selten preisgegeben. Dies kann jedoch aus folgenden Gründen passieren:

Ihr Dienstkonto für die Bereitstellung hat nur Berechtigungen zum Reservieren von Adressen (create, createInternal), aber nicht zum Freigeben von Adressen (delete, deleteInternal).
Ihr Dienstkonto wurde gelöscht, während andere Google Cloud Adressreservierungen aktiv waren.
Das Cloud-Rechnungskonto wurde entfernt und später im Projekt wieder aktiviert, während Serverless-Adressreservierungen aktiv waren.
Ihr Google Cloud -Projekt wurde gelöscht und später wiederhergestellt, während noch Reservierungen für serverlose Adressen vorhanden waren.

Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

Fragen Sie die folgenden Logs im Log-Explorer ab, um die offengelegten Adressen zu ermitteln:

protoPayload.authorizationInfo.permission=~"compute.addresses.delete.*"
protoPayload.authorizationInfo.resourceAttributes.type="compute.addresses"
protoPayload.resourceName=~"projects/.*/regions/.*/addresses/serverless-.*"
severity>=WARNING

Wenn bei dieser Abfrage keine Ergebnisse zurückgegeben werden, gibt es keine IP-Adressenlecks und es sind keine weiteren Maßnahmen erforderlich.

Wenn Ihre Anfrage Ergebnisse zurückgibt, prüfen Sie, ob Ihr bereitstellendes Dienstkonto die Rolle „App Engine Service Agent“ (roles/appengine.serviceAgent) enthält. Wenn Sie diese Rolle nicht verwenden können, gewähren Sie Ihrem bereitstellenden Dienstkonto andere erforderliche Rollen und Berechtigungen.
So löschen Sie geleakte IP-Adressen manuell mit der Google Cloud -Konsole oder der Google Cloud CLI:
Console
1. Rufen Sie in der Google Cloud Console die Seite IP-Adressen auf:
  
  "IP-Adressen" aufrufen
2. Wählen Sie die offengelegten IP-Adressen aus, die Sie im vorherigen Schritt durch Ausführen der Abfrage ermittelt haben.
3. Klicken Sie auf Statische Adresse freigeben, um die offengelegten Adressen zu entfernen.
gcloud
Führen Sie den Befehl gcloud compute addresses delete aus:
gcloud compute addresses delete ADDRESS_NAME --region=REGION
Ersetzen Sie Folgendes:
- ADDRESS_NAME: der Name der offengelegten IP-Adresse.
- REGION: die Region der offengelegten IP-Adresse.