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. Mit ausgehendem Direct VPC-Traffic können Arbeitslasten nahtlos auf VPC-Netzwerkressourcen zugreifen. Connectors für Serverloser VPC-Zugriff müssen nicht mehr konfiguriert werden.
Hauptvorteile
- Vereinfachte Verwaltung: Der operative Aufwand für die Verwaltung von Connector-Instanzen, Maschinentypen und Skalierungseinstellungen entfällt. App Engine verarbeitet Konfigurationen direkt in der
app.yaml-Datei Ihres Dienstes. - 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 zahlen.
- Verbesserte 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. Er wird so schnell wie Ihr App Engine-Dienst skaliert und verhindert Verbindungsabbrüche, die bei Connectors während der Wartung auftreten können.
Detaillierte Sicherheit: Sie können Netzwerk-Tags direkt auf Ihre App Engine-Dienstversionen anwenden, um präzise, dienstspezifische Firewallregeln und Netzwerkrichtlinien zu ermöglichen.
Unterstützt VPC-Flusslogs: Sie können VPC-Flusslogs für Ihr Subnetz aktivieren, um ausgehenden Traffic von Ihrem App Engine-Dienst zu protokollieren.
Beschränkungen
IP-Adressverbrauch: Die IP-Adressnutzung Ihres Dienstes skaliert direkt mit der Anzahl der ausgeführten Instanzen. Ihre Skalierungsfähigkeit ist durch die Anzahl der verfügbaren IP-Adressen im ausgewählten Subnetz begrenzt.
Wartungsereignisse: Bei Wartungsereignissen der Netzwerkinfrastruktur kann es 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 spezifischen Anwendungsfall ab. In seltenen Fällen können Kaltstarts bis zu einer Minute dauern.
Direct VPC-Ingress: App Engine unterstützt Direct VPC-Ingress nicht.
Anzahl der Instanzen: Sie können pro App Engine-Version nur bis zu 100 Instanzen für die Verwendung von ausgehendem Direct VPC-Traffic konfigurieren.
VPC-Flusslogs: Die Version Ihres App Engine-Dienstes wird in den Logeinträgen nicht angezeigt. Der Dienstname wird im Feld
AppEngineServiceDetailsangezeigt.
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 jeweils 16 (Subnetzmaske 28).
Damit Sie genügend IPv4-Adressen für die Verwendung in App Engine zur Verfügung haben, muss der IPv4-Adressbereich Ihres Subnetzes /26 oder größer sein.
Für eine effiziente IP-Zuordnung 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 Instanzen. Wenn eine Version herunterskaliert wird, behält App Engine ihre IP-Adressen bis zu 20 Minuten lang bei. Reservieren Sie insgesamt mindestens das Zweifache der Anzahl der IP-Adressen sowie 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 Aufbewahrungsfensters 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:
Hinweis
Prüfen Sie, ob in Ihrem Projekt ein VPC-Netzwerk und ein Subnetz vorhanden sind. Wenn Sie noch keine VPC haben, folgen Sie der Anleitung unter VPC-Netzwerk erstellen, um eine zu erstellen.
Aktivieren Sie die Compute Engine API und die Cloud Build API:
Wenn Sie ausgehenden Direct VPC-Traffic verwenden möchten, müssen Sie die neueste Version der Google Cloud CLI ausführen:
gcloud components update
Erforderliche Rollen
Sorgen Sie dafür, dass App Engine Zugriff auf das VPC-Netzwerk hat, indem Sie dem bereitstellenden Dienstkonto 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.getcompute.subnetworks.getcompute.subnetworks.usefür das Projekt oder das spezifische Subnetzcompute.addresses.getcompute.addresses.listcompute.addresses.createcompute.addresses.deletecompute.addresses.createInternalcompute.addresses.deleteInternalcompute.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 externer IPv6-Adresse ist außerdem die Rolle Compute Public IP Admin (roles/compute.publicIpAdmin) erforderlich.Führen Sie beispielsweise den folgenden Befehl aus, um die Rolle „Compute-Netzwerknutzer“ zuzuweisen:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:service-PROJECT_NUMBER@gcp-gae-service." \ --role "roles/compute.networkUser"
Ersetzen Sie Folgendes:
- PROJECT_ID: die Projekt-ID.
- PROJECT_NUMBER: die Projektnummer, unter der Sie Ihren App Engine-Dienst bereitstellen.
App Engine-Dienst mit Direct VPC-Ausgang konfigurieren
So ermöglichen Sie einem neuen oder vorhandenen App Engine-Dienst, eine direkte Verbindung zu Ihrem VPC-Netzwerk herzustellen:
Fügen Sie der Datei
app.yamldie folgendevpc_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 Ihre Anwendungsinstanzen verbunden sind, 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 Ihre Anwendungsinstanzen verbunden sind, 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 mit den Instanzen Ihres App Engine-Dienstes verknüpft werden sollen, um sie in Firewallregeln und Routingrichtlinien zu verwenden.
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. Internettraffic verwendet den Standard-App Engine-Pfad.
Stellen Sie die Anwendung mit dem folgenden Befehl in der App Engine bereit:
gcloud beta app deploy
Dienst trennen
So trennen Sie die Verbindung Ihres Dienstes zum VPC-Netzwerk:
Entfernen Sie den Abschnitt
vpc_accessaus der Dateiapp.yaml.Stellen Sie den Dienst noch einmal 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 die beste Kompatibilität empfehlen wir, mit dem RFC 6598-Bereich (
100.64.0.0/10) zu beginnen.Alternative IP-Bereiche: Wenn Sie bereits den empfohlenen IP-Bereich
100.64.0.0/10verwenden, 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
/26oder größer sein, damit genügend Adressen für die Skalierung vorhanden sind.IP-Adressen überdimensionieren: Wir empfehlen, die Anzahl der verfügbaren IP-Adressen 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 IP-Adressen verwenden (zweimal für den stabilen Zustand und zweimal während der Bereitstellung) wie die Anzahl der ausgeführten Instanzen, um eine reibungslose Skalierung und Aktualisierung zu ermöglichen.
Ausgehenden Internettraffic isolieren
Wenn vpc_egress auf private-ranges-only gesetzt ist, sendet App Engine standardmäßig ausgehenden Internettraffic über einen regionalen Pool dynamischer IP-Adressen, die von serverlosen Arbeitslasten gemeinsam genutzt werden. Verwenden Sie diesen standardmäßigen freigegebenen Pool nicht für Arbeitslasten, die von der IP-Reputation abhängen oder ein hohes Volumen an Prüf-Traffic generieren.
Legen Sie stattdessen vpc_egress: all-traffic fest und leiten Sie ausgehenden Traffic in den folgenden Fällen über Cloud NAT mit dedizierten statischen ausgehenden IP-Adressen weiter:
- Ihr Dienst stellt eine Verbindung zu reputationsempfindlichen externen Endpunkten her, z. B. Zahlungs-Gateways, gehostete Datenbanken oder Partner-APIs hinter Web Application Firewalls (WAFs) von Drittanbietern. Dedizierte statische IP-Adressen verhindern, dass störender Traffic von anderen Mandanten im freigegebenen Pool externe WAF-Blöcke oder
HTTP 403-Fehler auslöst. - Ihr Dienst führt autorisierte Netzwerkscans, Portaufzählungen, Host-Fingerprinting, Sicherheitslückenprüfungen, Web-Scraping oder Lasttests durch. Wenn Sie diese Arbeitslasten über den standardmäßigen freigegebenen IP-Pool ausführen, wird die IP-Reputation beeinträchtigt. Außerdem kann der Dienst für andere Kunden unterbrochen werden, was gegen die Google Cloud -Richtlinien zur zulässigen Verwendung verstößt. Dies kann dazu führen, dass Google Ihre Arbeitslast drosselt oder sperrt.
Wenn Sie autorisierte Scans oder Arbeitslasten mit vielen Verbindungen über Cloud NAT ausführen, weisen Sie genügend statische IP-Adressen zu und konfigurieren Sie die Portreservierung, um eine Port-Erschöpfung zu verhindern.
Fehlerbehebung
In diesem Abschnitt werden die häufigsten Fehler beschrieben, die bei der Bereitstellung Ihres App Engine-Dienstes mit ausgehendem Direct 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. Prüfen Sie die VPC-Konfiguration in der Dateiapp.yaml, um potenzielle Fehler zu beheben.Unzureichende IAM-Berechtigungen. Achten Sie darauf, dass Sie dem Dienstkonto für die Bereitstellung die erforderlichen Berechtigungen gewähren. 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-Tokens (
roles/iam.serviceAccountTokenCreator)
- Cloud Build-Dienstkonto (
IP-Adressen aufgebraucht
Wenn in Ihrem Subnetz keine IP-Adressen mehr verfügbar sind, kann App Engine keine neuen Instanzen starten und protokolliert einen Fehler. Erweitern Sie den IP-Bereich Ihres Subnetzes oder verschieben Sie Ihren Dienst in ein größeres Subnetz, um dieses Problem zu beheben.
IP-Adresslecks
IP-Adresslecks können dazu führen, dass IP-Adressen aufgebraucht werden. IP-Adresslecks sind im Standardbetrieb unwahrscheinlich, können aber aus folgenden Gründen auftreten:
- Ihr Bereitstellungsdienstkonto hat nur Berechtigungen zum Reservieren von Adressen (
create,createInternal) und keine Berechtigungen 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 serverlose Adressreservierungen aktiv waren.
- Ihr Google Cloud -Projekt wurde gelöscht und später wiederhergestellt, während noch serverlose Adressreservierungen vorhanden waren.
Führen Sie die folgenden Schritte aus, um das Problem zu beheben:
Suchen Sie im Log-Explorer nach den folgenden Logs, um die geleakten Adressen zu identifizieren:
protoPayload.authorizationInfo.permission=~"compute.addresses.delete.*" protoPayload.authorizationInfo.resourceAttributes.type="compute.addresses" protoPayload.resourceName=~"projects/.*/regions/.*/addresses/serverless-.*" severity>=WARNINGWenn diese Abfrage keine Ergebnisse zurückgibt, gibt es keine IP-Adresslecks und es sind keine weiteren Maßnahmen erforderlich.
Wenn Ihre Abfrage Ergebnisse zurückgibt, prüfen Sie, ob Ihr Bereitstellungsdienstkonto die Rolle „App Engine-Dienst-Agent“ (
roles/appengine.serviceAgent) enthält. Wenn Sie diese Rolle nicht verwenden können, müssen Sie Ihrem Bereitstellungsdienstkonto andere erforderliche Rollen und Berechtigungen zuweisen.Löschen Sie geleakte IP-Adressen manuell über die Google Cloud Console oder die Google Cloud CLI:
Console
Rufen Sie in der Google Cloud Console die Seite IP-Adressen auf:
Wählen Sie die geleakten IP-Adressen aus, die Sie im vorherigen Schritt durch Ausführen der Abfrage identifiziert haben.
Klicken Sie auf Statische Adresse freigeben, um die geleakten Adressen zu entfernen.
gcloud
Führen Sie den Befehl
gcloud compute addresses deleteaus:gcloud compute addresses delete ADDRESS_NAME --region=REGION
Ersetzen Sie Folgendes:
- ADDRESS_NAME: der Name der geleakten IP-Adresse.
- REGION: die Region der geleakten IP-Adresse.