Questo documento inizia illustrando le opzioni per estendere la portata dei servizi della piattaforma agente di cui è stato eseguito il deployment con l'accesso privato ai servizi.
Segue una breve discussione sulle motivazioni per il deployment dei servizi in un endpoint Private Service Connect, nel caso in cui questa sia una soluzione più adatta alle tue esigenze.
Poiché l'accesso privato ai servizi ospita i servizi della piattaforma agente in una rete gestita in peering con la tua, assicurati di avere familiarità con il materiale relativo ai peering VPC prima di leggere il resto di questo documento.
Per impostazione predefinita, la configurazione del peering consente solo alla rete Agent Platform in peering di raggiungere gli endpoint nelle subnet locali. L'esportazione di route personalizzate consente alla rete producer di raggiungere altre reti verso le quali la tua rete ha route statiche o dinamiche.
Poiché il peering transitivo non è supportato, le connessioni dalla piattaforma dell'agente non possono raggiungere gli endpoint in altre reti in peering diretto con la tua rete, anche se l'opzione "Esporta route personalizzate" è abilitata. Nell'esempio mostrato nel seguente diagramma, i pacchetti possono attraversare la connessione di peering n. 1, ma non la connessione di peering n. 2.
Per consentire ad Agent Platform di raggiungere la rete utente n. 2, sostituisci la connessione in peering n. 2 con la VPN n. 2, come mostrato nel seguente diagramma.
L'abilitazione delle route personalizzate nella connessione in peering n. 1 consente ai pacchetti IP della rete della piattaforma dell'agente di raggiungere la rete utente n. 2.
Per consentire l'instradamento dei pacchetti di risposta dalla rete utente n. 2 alla rete della piattaforma dell'agente, la route di ritorno deve esistere anche nella tabella di routing della rete utente n. 2. Le route VPN vengono scambiate utilizzando il protocollo BGP (Border Gateway Protocol) sui router Cloud. Possiamo personalizzare la configurazione BGP in Utente n. 1 per annunciare una route all'intervallo di rete della piattaforma agente di 10.1.0.0/16 alla rete utente n. 2 peer.
Tieni presente che puoi modificare entrambi i lati della configurazione BGP della VPN n. 1 per consentire alla rete on-premise e alla rete della piattaforma agente di apprendere le route l'una dell'altra. Poiché non viene effettuato alcun tentativo di trasmettere pacchetti del percorso di andata dalla rete della piattaforma dell'agente, né i pacchetti di risposta su connessioni di peering sequenziali rispetto a una singola rete, nessuno di questi tentativi di forwarding viene bloccato esplicitamente.
Configura la connettività da Agent Platform a internet
Se non viene specificata alcuna rete quando si avvia un workload, questo viene eseguito in un progetto producer separato gestito da Google.
Se viene specificata una rete, il workload viene eseguito in un progetto producer in peering con il progetto consumer.
Per impostazione predefinita, la rete della piattaforma dell'agente ha la propria route verso internet e la rete producer ha la propria route predefinita verso internet.
Per forzare il routing delle connessioni in uscita dalla rete producer attraverso la tua rete, puoi attivare i Controlli di servizio VPC per i peering. Tieni presente che questa configurazione è separata dai Controlli di servizio VPC.
L'attivazione dei Controlli di servizio VPC per i peering causa le seguenti modifiche nella rete della piattaforma dell'agente:
- Elimina la route internet predefinita.
- Crea una route per la destinazione
199.36.153.4/30con l'hop successivo del gateway internet predefinito. - Crea una zona Cloud DNS privata gestita per
*.googleapis.comcon record appropriati per mappare i nomi host a uno di questi quattro indirizzi. - Autorizza la zona per l'utilizzo da parte della rete VPC
servicenetworking.
Con questa modifica, puoi esportare la route predefinita dalla tua rete per assicurarti che le connessioni in uscita a internet vengano instradate tramite la tua rete VPC. Questa modifica ti consente anche di applicare le policy necessarie al traffico in uscita dalla piattaforma degli agenti.
Puoi eseguire una query sullo stato dei Controlli di servizio VPC per i peering eseguendo questo comando:
gcloud services vpc-peerings get-vpc-service-controls \
--network YOUR_NETWORK
Verrà restituito enabled: true se la configurazione è abilitata e un elenco vuoto ({}) se è disabilitata.
Utilizzo dei Controlli di servizio VPC
Se per il workload è specificata una rete e i Controlli di servizio VPC sono abilitati, il workload viene eseguito in una rete producer in peering con il progetto consumer e soggetta alle stesse policy della rete consumer.
Se queste policy bloccano il traffico in uscita, il workload non sarà in grado di raggiungere internet. In questo caso, devi seguire i passaggi della sezione precedente per forzare il traffico in uscita dal workload ad attraversare un'istanza NAT nella tua rete VPC.
Configura la connettività da Agent Platform utilizzando i proxy
Un altro pattern per controllare l'IP in uscita da Agent Platform è forzare le connessioni in uscita dai workload ad attraversare un proxy web che controlli. In questo modo è anche possibile ispezionare le connessioni in uscita per verificarne la conformità.
Tuttavia, l'utilizzo di un proxy di terze parti costringe l'utente a gestire il certificato del proxy per i reclami di autenticazione. Inoltre, questi proxy potrebbero non proporre un elenco di suite di crittografia che si interseca con quello previsto dagli SDK e dalle API di Agent Platform.
Google Cloud ora offre un Secure Web Proxy per facilitare questo pattern. Ora puoi seguire la guida rapida Esegui il deployment di un'istanza di Secure Web Proxy e adattare i tuoi workload in modo che utilizzino l'istanza per le connessioni in uscita. Queste connessioni sembreranno provenire dall'indirizzo IP di origine del proxy.
Se la libreria KFP non è già installata nell'immagine del componente, la pipeline tenta di installarla prima di eseguire qualsiasi codice in cui potresti aver specificato un proxy.
Se la pipeline dipende dal proxy per installare i pacchetti da internet, questo tentativo non andrà a buon fine e potresti visualizzare un errore simile al seguente:
Could not find a version that satisfies the requirement kfp==2.7.0
In casi come questo, quando non puoi installare KFP prima di eseguire il codice, devi utilizzare un'immagine con KFP già installato.
Puoi aggiungere KFP a qualsiasi immagine di base ed eseguirne il push nel tuo repository.
L'esempio di Dockerfile seguente aggiunge KFP all'immagine di base python:3.8.
FROM python:3.8
RUN pip install kfp==2.7.0
Puoi quindi configurare la pipeline @component in modo che utilizzi questa immagine:
@component(base_image="$PATH_TO_YOUR_REPOSITORY:YOUR_IMAGE")
Una volta che il componente della pipeline è in esecuzione, il codice può installare liberamente altri pacchetti tramite il proxy. L'esempio seguente installa numpy utilizzando un proxy all'indirizzo https://10.10.10.10:443.
import subprocess
subprocess.call(['pip', 'install', '--proxy', 'https://10.10.10.10:443', 'numpy'])`
Configura le liste consentite per l'accesso alle API
Per le transazioni tra i workload di Gemini Enterprise Agent Platform e le API di Google, devi consentire l'accesso dai workload agli intervalli IP utilizzati dalle API di Google. A questo scopo, puoi eseguire lo script fornito per restituire gli indirizzi IP per i domini predefiniti.
Fornire connettività ibrida con Private Service Connect
Il deployment dei servizi della piattaforma agente con accesso privato ai servizi presenta diverse limitazioni.
- Potresti dover prenotare grandi pool di indirizzi IP privati per workload, evitando al contempo conflitti con l'indirizzamento VPC.
- L'esecuzione di più workload in parallelo potrebbe comunque causare un errore RANGES_EXHAUSTED anche dopo una configurazione iniziale corretta.
- Complessità di deployment e risoluzione dei problemi di networking:
- Poiché il peering transitivo non è supportato, devi implementare soluzioni alternative complesse per concedere la connettività tra reti diverse in peering con la tua rete VPC.
- Lo stato della tabella di routing nell'ambiente producer non è immediatamente evidente. Poiché non hai accesso al progetto tenant, spesso è difficile determinare quali target può effettivamente raggiungere un workload di Agent Platform senza test approfonditi.
Un pattern alternativo consiste nell'eseguire il deployment di questi servizi in un endpoint Private Service Connect.
- Il servizio utilizza un singolo indirizzo IP all'interno della rete VPC, consentendoti di conservare lo spazio di indirizzi privati per uso personale.
- Poiché l'IP del servizio Agent Platform si trova nella tua rete, è più semplice creare ed eseguire Connectivity Tests per valutarne la raggiungibilità da e verso altre parti del tuo ambiente.