Questo documento inizia descrivendo le opzioni per estendere la copertura dei servizi di Agent Platform 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 sia più adatto alle tue esigenze.
Poiché l'accesso privato ai servizi ospita i servizi Agent Platform in una rete gestita in peering con la tua, assicurati di conoscere il materiale in 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 del produttore di raggiungere altre reti per le quali la tua rete dispone di route statiche o dinamiche.
Poiché il peering transitivo non è supportato, le connessioni dalla piattaforma dell'agente non possono raggiungere gli endpoint in altre reti con peering diretto alla tua rete, anche se l'opzione "Esporta route personalizzate" è attivata. 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 di peering n. 2 con la VPN n. 2, come mostrato nel seguente diagramma.
L'attivazione delle route personalizzate nella connessione di peering n. 1 consente ai pacchetti IP della rete di Agent Platform di raggiungere la rete utente n. 2.
Per consentire l'instradamento dei pacchetti di risposta dalla rete utente n. 2 alla rete di Agent Platform, la route di ritorno deve esistere anche nella tabella di routing per la rete utente n. 2. Le route VPN vengono scambiate utilizzando il protocollo BGP (Border Gateway Protocol)
sui router Cloud. Possiamo personalizzare la configurazione BGP
nell'utente 1 per annunciare una route all'intervallo di rete di Agent Platform
di 10.1.0.0/16 alla sua rete peer dell'utente 2.
Tieni presente che puoi modificare entrambi i lati della configurazione BGP della VPN n. 1 per consentire alla rete on-premise e alla rete Agent Platform di apprendere le route reciproche. Poiché non viene tentato di trasmettere pacchetti di percorso in avanti dalla rete di Agent Platform, né i pacchetti di risposta tramite connessioni di peering sequenziali rispetto a una singola rete, nessuno di questi tentativi di inoltro viene bloccato esplicitamente.
Configura la connettività da Agent Platform a internet
Se non viene specificata alcuna rete all'avvio di un workload, questo viene eseguito in un progetto producer gestito da Google separato.
Se viene specificata una rete, il workload viene eseguito in un progetto producer in peering con il progetto consumer.
Per impostazione predefinita, la rete di Agent Platform ha una propria route a internet e la rete producer ha una propria route predefinita a 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 è una configurazione separata dai Controlli di servizio VPC.
L'attivazione dei Controlli di servizio VPC per i peering comporta 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 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 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 norme necessarie al traffico in uscita dalla piattaforma Agent Platform.
Puoi eseguire query sullo stato dei Controlli di servizio VPC per i peering eseguendo il seguente comando:
gcloud services vpc-peerings get-vpc-service-controls \
--network YOUR_NETWORK
Restituirà enabled: true se la configurazione è abilitata e un elenco vuoto ({}) se è disabilitata.
Utilizzo dei Controlli di servizio VPC
Se per il workload viene specificata una rete e sono attivi i Controlli di servizio VPC, il workload viene eseguito in una rete producer in peering con il progetto consumer e soggetta alle stesse norme della rete consumer.
Se queste norme bloccano il traffico in uscita, il carico di lavoro non potrà accedere a internet. In questo caso, devi seguire i passaggi della sezione precedente per forzare il traffico in uscita dal workload a passare attraverso un'istanza NAT nella tua rete VPC.
Configurare la connettività da Agent Platform utilizzando i proxy
Un altro pattern per controllare l'IP in uscita da Agent Platform consiste nel forzare le connessioni in uscita dai workload a passare attraverso un proxy web che controlli. Ciò consente anche l'ispezione delle connessioni in uscita per la conformità.
Tuttavia, l'utilizzo di un proxy di terze parti costringe l'utente a gestire il certificato del proxy per i reclami relativi all'autenticazione. Inoltre, questi proxy potrebbero non proporre un elenco di suite di crittografia che si interseca con ciò che si aspettano gli SDK e le API di Agent Platform.
Google Cloud ora offre un proxy web sicuro per facilitare questo pattern. Ora puoi seguire la guida rapida Deploy di un'istanza di Secure Web Proxy e adattare i tuoi workload per utilizzarlo 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 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 riesci a installare KFP prima di eseguire il codice, devi utilizzare un'immagine con KFP già installato.
Puoi aggiungere KFP a qualsiasi immagine di base e inviarla al tuo repository.
Il seguente esempio di Dockerfile 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 per utilizzare questa immagine:
@component(base_image="$PATH_TO_YOUR_REPOSITORY:YOUR_IMAGE")
Una volta in esecuzione, il componente della pipeline può installare liberamente altri pacchetti passando attraverso 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'])`
Configurare le liste consentite per l'accesso API
Per le transazioni tra i carichi di lavoro di Gemini Enterprise Agent Platform e le API di Google, devi consentire l'accesso dai carichi di lavoro 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 di Agent Platform con l'accesso privato ai servizi presenta diverse limitazioni.
- Potresti dover riservare grandi pool di indirizzi IP privati per workload, evitando al contempo conflitti
con l'indirizzamento VPC.
- L'esecuzione parallela di più workload potrebbe comunque causare un errore RANGES_EXHAUSTED anche dopo la 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 di produzione non è immediatamente ovvio. Poiché non hai accesso al progetto tenant, spesso è difficile determinare quali target può raggiungere effettivamente un workload di Agent Platform senza test approfonditi.
Un pattern alternativo consiste nel deployment di questi servizi in un endpoint Private Service Connect.
- Il servizio utilizza un singolo indirizzo IP all'interno della tua rete VPC, consentendoti di conservare lo spazio di indirizzi privati per il tuo utilizzo.
- Poiché l'IP del servizio Agent Platform si trova nella tua rete, è più semplice creare ed eseguire test di connettività per valutare la sua raggiungibilità da e verso altre posizioni del tuo ambiente.