In diesem Dokument werden zunächst Optionen zum Erweitern der Reichweite von Agent Platform-Diensten beschrieben, die mit Zugriff auf private Dienste bereitgestellt werden.
Anschließend werden kurz die Gründe für die Bereitstellung der Dienste an einem Private Service Connect-Endpunkt erläutert, falls dies besser zu Ihren Anforderungen passt.
Da Agent Platform-Dienste über den Zugriff auf private Dienste in einem verwalteten Netzwerk gehostet werden, das per Peering mit Ihrem Netzwerk verbunden ist, sollten Sie sich mit dem Material unter VPC-Peerings vertraut machen, bevor Sie den Rest dieses Dokuments lesen.
Standardmäßig lässt die Peering-Konfiguration nur zu, dass das Peering-Agent Platform-Netzwerk Endpunkte in Ihren lokalen Subnetzen erreicht. Durch den Export benutzerdefinierter Routen kann das Produzentennetzwerk andere Netzwerke erreichen, zu denen Ihr Netzwerk statische oder dynamische Routen hat.
Da transitives Peering nicht unterstützt wird, können Verbindungen von Agent Platform keine Endpunkte in anderen Netzwerken erreichen, die direkt mit Ihrem Netzwerk verbunden sind, selbst wenn "Benutzerdefinierte Routen exportieren" aktiviert ist. Im folgenden Diagramm können Pakete die Peering-Verbindung 1 durchqueren, jedoch nicht die Peering-Verbindung 2.
Damit Agent Platform Nutzernetzwerk 2 erreichen kann, ersetzen Sie die Peering-Verbindung 2 durch VPN 2, wie im folgenden Diagramm gezeigt.
Wenn Sie benutzerdefinierte Routen in Peering-Verbindung 1 aktivieren, können IP-Pakete aus dem Agent Platform-Netzwerk Nutzernetzwerk 2 erreichen.
Damit Antwortpakete von Nutzernetzwerk 2 zurück zum Agent Platform-Netzwerk weitergeleitet werden können, muss die Rückgaberoute auch in der Routingtabelle für Nutzernetzwerk 2 vorhanden sein. VPN-Routen werden mit dem Border Gateway Protocol (BGP)
auf Cloud Routern ausgetauscht. Wir können die BGP-Konfiguration
in Nutzer 1 anpassen, um eine Route zum Agent Platform-Netzwerkbereich
von 10.1.0.0/16 zum Peering-Netzwerk 2 zu bewerben.
Sie können beide Seiten der VPN-1-BGP-Konfiguration bearbeiten, damit das lokale Netzwerk und das Agent Platform-Netzwerk Routen zueinander lernen können. Da nicht versucht wird, Weiterleitungspfadpakete aus dem Agent Platform-Netzwerk oder die Antwortpakete über sequenzielle Peering-Verbindungen in Bezug auf ein einzelnes Netzwerk zu übertragen, wird keiner dieser Weiterleitungsversuche explizit blockiert.
Verbindung von Agent Platform zum Internet einrichten
Wenn beim Starten einer Arbeitslast kein Netzwerk angegeben wird, wird die Arbeitslast in einem separaten von Google verwalteten Produzentenprojekt ausgeführt.
Wenn ein Netzwerk angegeben ist, wird die Arbeitslast in einem Erstellerprojekt ausgeführt, das per Peering mit dem Nutzerprojekt verbunden ist.
Standardmäßig hat das Agent Platform-Netzwerk eine eigene Route zum Internet und das Produzentennetzwerk hat eine eigene Standardroute zum Internet.
Wenn Sie erzwingen möchten, dass ausgehende Verbindungen vom Produzentennetzwerk über Ihr Netzwerk weitergeleitet werden, können Sie VPC Service Controls für Peerings aktivieren. Beachten Sie, dass dies eine separate Konfiguration von VPC Service Controls ist.
Wenn Sie VPC Service Controls für Peerings aktivieren, ändert sich Folgendes im Agent Platform-Netzwerk:
- Löscht die Standard-Internetroute.
- Erstellt eine Route für das Ziel
199.36.153.4/30mit dem Standard-Internetgateway als nächsten Hop. - Erstellt eine von Cloud DNS verwaltete private Zone für
*.googleapis.commit den entsprechenden Einträgen, um Hostnamen einer dieser vier Adressen zuzuordnen. - Autorisiert diese Zone für das zu verwendende
servicenetworking-VPC-Netzwerk.
Mit dieser Änderung können Sie die Standardroute aus Ihrem Netzwerk exportieren, damit ausgehende Verbindungen zum Internet sicher über Ihr VPC-Netzwerk geleitet werden. Mit dieser Änderung können Sie auch alle erforderlichen Richtlinien auf den von Agent Platform ausgehenden Traffic anwenden.
Sie können den Status von VPC Service Controls für Peerings mit dem folgenden Befehl abfragen:
gcloud services vpc-peerings get-vpc-service-controls \
--network YOUR_NETWORK
Wenn die Konfiguration aktiviert ist, wird enabled: true zurückgegeben. Wenn sie deaktiviert ist, wird eine leere Liste ({}) zurückgegeben.
Mit VPC Service Controls arbeiten
Wenn ein Netzwerk für die Arbeitslast angegeben ist und VPC Service Controls aktiviert ist, wird die Arbeitslast in einem Erstellernetzwerk ausgeführt, das per Peering mit dem Nutzerprojekt verbunden ist und den gleichen Richtlinien unterliegt. als Nutzernetzwerk.
Wenn diese Richtlinien ausgehenden Traffic blockieren, kann die Arbeitslast ebenfalls nicht auf das Internet zugreifen. In diesem Fall müssen Sie die Schritte im vorherigen Abschnitt ausführen, um ausgehenden Traffic von der Arbeitslast über eine NAT-Instanz in Ihrem VPC-Netzwerk zu leiten.
Verbindung von Agent Platform über Proxys einrichten
Ein weiteres Muster zur Steuerung der ausgehenden IP von Agent Platform besteht darin, ausgehende Verbindungen von Arbeitslasten über einen von Ihnen verwalteten Webproxy zu zwingen. Außerdem können ausgehende Verbindungen auf Einhaltung der Compliance-Anforderungen geprüft werden.
Bei der Verwendung eines Proxys von Drittanbietern muss der Nutzer jedoch das Zertifikat des Proxys verwalten, um Beschwerden bei der Authentifizierung zu vermeiden. Darüber hinaus schlagen diese Proxys möglicherweise keine Liste von Chiffresammlungen vor, die sich mit den Anforderungen von Agent Platform SDKs und APIs überschneiden.
Google Cloud bietet jetzt einen Sicheren Web-Proxy, um dieses Muster zu ermöglichen. Sie können jetzt der Kurzanleitung Secure Web Proxy-Instanz bereitstellen folgen und Ihre Arbeitslasten so anpassen, dass sie diese für ausgehende Verbindungen verwenden. Es scheint, als ob diese Verbindungen von der Quell-IP-Adresse des Proxys stammen.
Wenn die KFP-Bibliothek noch nicht im Komponenten-Image installiert ist, versucht die Pipeline, sie zu installieren, bevor Sie Code ausführen, in dem Sie möglicherweise einen Proxy angegeben haben.
Wenn die Pipeline den Proxy benötigt, um Pakete aus dem Internet zu installieren, schlägt dieser Versuch fehl und Sie erhalten möglicherweise einen Fehler wie den folgenden:
Could not find a version that satisfies the requirement kfp==2.7.0
Wenn Sie KFP nicht installieren können, bevor Sie Ihren Code ausführen, müssen Sie ein Image verwenden, auf dem KFP bereits installiert ist.
Sie können KFP zu jedem Basis-Image hinzufügen und es in Ihr Repository übertragen.
Im folgenden Dockerfile-Beispiel wird KFP zum Basis-Image python:3.8 hinzugefügt.
FROM python:3.8
RUN pip install kfp==2.7.0
Sie können dann die Pipeline @component so konfigurieren, dass dieses Image verwendet wird:
@component(base_image="$PATH_TO_YOUR_REPOSITORY:YOUR_IMAGE")
Sobald die Pipelinekomponente ausgeführt wird, kann Ihr Code andere Pakete über den Proxy installieren. Im folgenden Beispiel wird numpy mithilfe eines Proxys unter https://10.10.10.10:443 installiert.
import subprocess
subprocess.call(['pip', 'install', '--proxy', 'https://10.10.10.10:443', 'numpy'])`
Zulassungslisten für den API-Zugriff einrichten
Für Transaktionen zwischen Gemini Enterprise Agent Platform-Arbeitslasten und Google APIs müssen Sie den Zugriff der Arbeitslasten auf die von Google APIs verwendeten IP-Bereiche zulassen. Dazu können Sie das bereitgestellte Script zum Zurückgeben von IP-Adressen für Standarddomains ausführen.
Hybride Konnektivität mit Private Service Connect bereitstellen
Die Bereitstellung von Agent Platform-Diensten mit Zugriff auf private Dienste hat mehrere Einschränkungen.
- Möglicherweise müssen Sie große Pools privater IP-Adressen pro Arbeitslast reservieren und gleichzeitig Konflikte mit Ihrer VPC-Adressierung vermeiden.
- Auch nach der korrekten Erstkonfiguration kann es bei der parallelen Ausführung mehrerer Arbeitslasten zu einem RANGES_EXHAUSTED-Fehler kommen.
- Komplexität bei der Bereitstellung und Fehlerbehebung von Netzwerken:
- Da transitives Peering nicht unterstützt wird, müssen Sie komplexe Problemumgehungen bereitstellen, um die Konnektivität zwischen verschiedenen Netzwerken zu ermöglichen, die per Peering mit Ihrem VPC-Netzwerk verbunden sind.
- Der Status der Routingtabelle in der Produzentenumgebung ist nicht sofort ersichtlich. Da Sie keinen Zugriff auf das Mandantenprojekt haben, ist es oft schwierig, ohne umfangreiche Tests zu ermitteln, welche Ziele eine Agent Platform-Arbeitslast tatsächlich erreichen kann.
Eine alternative Methode besteht darin, diese Dienste an einem Private Service Connect-Endpunkt bereitzustellen.
- Der Dienst verwendet eine einzelne IP-Adresse in Ihrem VPC-Netzwerk, sodass Sie privaten Adressraum für Ihre eigene Verwendung reservieren können.
- Da sich die IP-Adresse des Agent Platform-Dienstes in Ihrem eigenen Netzwerk befindet, ist es einfacher, Konnektivitätstests zu erstellen und auszuführen, um die Erreichbarkeit von und zu anderen Stellen in Ihrer Umgebung zu bewerten.