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. Außerdem müssen keine Connectors für Serverloser VPC-Zugriff konfiguriert werden.
Hauptvorteile
- Vereinfachte Verwaltung: Der Betriebsaufwand für die Verwaltung von
Connector-Instanzen, Maschinentypen und Skalierungseinstellungen wird reduziert. App Engine verarbeitet Konfigurationen direkt in der Datei
app.yamlIhres Dienstes. - Kosteneffizienz: Für die Verwendung von ausgehendem Direct VPC-Traffic fallen keine zusätzlichen Kosten an. Sie müssen auch keine monatlichen Festgebühren für Connector-VMs zahlen.
- Verbesserte Leistung und Zuverlässigkeit: Da kein Connector erforderlich ist, bietet ausgehender Direct VPC-Traffic eine schnellere und zuverlässigere Verbindung zu Ihren VPC-Netzwerkressourcen. Die Skalierung erfolgt genauso schnell wie bei Ihrem App Engine-Dienst. Außerdem werden Verbindungsabbrüche vermieden, die bei Connectors während der Wartung auftreten können.
- Detaillierte Sicherheit: Sie können Netzwerk-Tags direkt auf die Versionen Ihres App Engine-Dienstes anwenden und so präzise, dienstspezifische Firewallregeln und Netzwerkrichtlinien erstellen.
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 in Ihrem ausgewählten Subnetz begrenzt.
Wartungsereignisse: Bei Wartungsereignissen an der Netzwerkinfrastruktur kann es zu kurzen Verbindungs unterbrechungen kommen. Wir empfehlen, Clientbibliotheken zu verwenden, 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 können Kaltstarts bis zu einer Minute dauern.
Eingehender Direct VPC-Traffic: App Engine unterstützt keinen eingehenden Direct VPC-Traffic.
Anzahl der Instanzen: Sie können nur bis zu 100 Instanzen pro App Engine-Version für die Verwendung von ausgehendem Direct VPC-Traffic konfigurieren.
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
Für eine schnellere Aufskalierung bei einem Trafficanstieg reserviert App Engine IP-Adressen in Blöcken von 16 (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-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 die Anzahl der Instanzen. Wenn eine Version herunterskaliert wird, behält App Engine seine IP-Adressen bis zu 20 Minuten lang bei. Reservieren Sie insgesamt mindestens die doppelte Anzahl an 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 IP-Adressen von version 1 bis zu 20 Minuten nach dem Herunterskalieren bei. Während des 20-minütigen Aufbewahrungszeitraums müssen Sie mindestens 400 IP-Adressen reservieren ((100 + 100) * 2).
Unterstützte IPv4-Bereiche
App Engine unterstützt die folgenden IPv4-Bereiche für Ihr Subnetz:
Hinweis
Achten Sie darauf, dass Sie in Ihrem Projekt ein VPC-Netzwerk und ein Subnetz haben. Wenn Sie noch kein VPC-Netzwerk haben, folgen Sie der Anleitung unter VPC-Netzwerk erstellen.
Aktivieren Sie die Compute Engine API und die Cloud Build API:
Wenn Sie ausgehenden Direct VPC-Traffic verwenden möchten, muss die aktuelle Version der Google Cloud CLI ausgeführt werden:
gcloud components update
Erforderliche Rollen
Gewähren Sie dem Dienstkonto für die Bereitstellung die folgenden Rollen, damit App Engine auf das VPC-Netzwerk zugreifen kann:
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 detailliertere 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 des App Engine-Dienst-Agents zu. Für Subnetze mit externem IPv6 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.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 die direkte Verbindung eines neuen oder vorhandenen App Engine-Dienstes zu Ihrem VPC-Netzwerk:
Fügen Sie der Datei
app.yamldie folgende Einstellungvpc_accesshinzu: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 Anwendungs instanzen 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 Anwendungs instanzen 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 den Instanzen Ihres App Engine-Dienstes zugewiesen werden sollen und in Firewallregeln und Routingrichtlinien verwendet werden.
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. Internet-Traffic verwendet den Standardpfad von App Engine.
Stellen Sie die Anwendung mit dem folgenden Befehl in 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 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 verwendet. Verwenden Sie die folgenden Strategien zum Verwalten Ihrer IP-Adressen:
Empfohlener IP-Bereich: Für die beste 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 von
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.Überdimensionierung von IP-Adressen: Wir empfehlen, die Anzahl der verfügbaren IP-Adressen in Ihrem Subnetz zu überdimensionieren, um eine Ausschöpfung zu vermeiden. Ähnlich wie bei Cloud Run-Diensten sollten Sie in der Regel viermal so viele IP-Adressen verwenden wie die Anzahl der ausgeführten Instanzen (2X für den stabilen Zustand und weitere 2X während der Bereitstellung), um eine reibungslose Skalierung und Updates zu ermöglichen.
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 alle Ressourcen löschen oder noch einmal bereitstellen, die es verwenden. Wenn App Engine ein Subnetz verwendet, trennen Sie die Verbindung zum App Engine Dienst vom VPC-Netzwerk oder verschieben Sie ihn 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. Beispiele für häufige Probleme:
Falsche VPC-Metadaten, z. B. ein falsch geschriebener Netzwerk- oder Subnetzname in der Datei
app.yaml. Prüfen Sie die VPC-Konfiguration in der Dateiapp.yaml, um potenzielle Fehler zu beheben.Unzureichende IAM-Berechtigungen. Achten Sie darauf, dass Sie die erforderlichen Berechtigungen für Ihr Dienstkonto für die Bereitstellung gewähren. Wenn bei der Bereitstellung Berechtigungsfehler auftreten, gewähren Sie dem Dienstkonto die folgenden zusätzlichen Rollen:
- Cloud Build-Dienstkonto (
roles/cloudbuild.builds.builder) - Ersteller von Dienstkonto-Token (
roles/iam.serviceAccountTokenCreator)
- Cloud Build-Dienstkonto (
IP-Adressbereich 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 zu einer Ausschöpfung der IP-Adressen führen. IP-Adresslecks sind bei Standardvorgängen unwahrscheinlich, können aber aus folgenden Gründen auftreten:
- 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 Adressreservierungen für serverlose Dienste aktiv waren.
- Ihr Google Cloud Projekt wurde gelöscht und später wiederhergestellt, während noch Adressreservierungen für serverlose Dienste 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 durchgesickerten Adressen zu ermitteln:
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 die Abfrage Ergebnisse zurückgibt, prüfen Sie, ob Ihr Dienstkonto für die Bereitstellung die Rolle „App Engine-Dienst-Agent“ (
roles/appengine.serviceAgent) enthält. Wenn Sie diese Rolle nicht verwenden können, stellen Sie sicher, dass Sie Ihrem Dienstkonto für die Bereitstellung andere erforderliche Rollen und Berechtigungen gewähren.Löschen Sie durchgesickerte 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 durchgesickerten IP-Adressen aus, die Sie im vorherigen Schritt durch Ausführen der Abfrage ermittelt haben.
Klicken Sie auf Statische Adresse freigeben , um die durchgesickerten 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 durchgesickerten IP-Adresse.
- REGION: die Region der durchgesickerten IP-Adresse.