Ce document commence par présenter les options permettant d'étendre la portée des services Agent Platform déployés avec l'accès aux services privés.
Nous aborderons ensuite brièvement les raisons pour lesquelles vous pourriez déployer les services sur un point de terminaison Private Service Connect si cela correspond mieux à vos besoins.
Étant donné que l'accès aux services privés héberge les services Agent Platform dans un réseau géré appairé au vôtre, assurez-vous de bien connaître le contenu de la page Appairage de réseaux VPC avant de lire le reste de ce document.
Par défaut, la configuration d'appairage permet seulement au réseau de l'Agent Platform appairé d'atteindre les points de terminaison de vos sous-réseaux locaux. L'exportation de routes personnalisées permet au réseau du producteur d'atteindre d'autres réseaux pour lesquels votre réseau dispose de routes statiques ou dynamiques.
Comme l'appairage transitif n'est pas accepté, les connexions de la plate-forme d'agents ne peuvent pas atteindre les points de terminaison d'autres réseaux directement appairés à votre réseau, même si l'option "Exporter des routes personnalisées" est activée. Dans l'exemple présenté dans le schéma suivant, les paquets peuvent traverser la connexion d'appairage 1, mais pas la connexion d'appairage 2.
Pour permettre à la plate-forme d'agents d'atteindre le réseau utilisateur 2, remplacez la connexion d'appairage 2 par le VPN 2, comme illustré dans le schéma suivant.
L'activation des routes personnalisées dans la connexion d'appairage 1 permet aux paquets IP du réseau de l'Agent Platform d'atteindre le réseau utilisateur 2.
Pour autoriser la redirection des paquets de réponse du réseau utilisateur 2 vers le réseau de la plate-forme d'agent, la route de retour doit également figurer dans la table de routage du réseau utilisateur 2. Les routes VPN sont échangées à l'aide du protocole BGP (Border Gateway Protocol) sur des routeurs Cloud Router. Nous pouvons personnaliser la configuration BGP du réseau utilisateur 1 pour annoncer une route vers la plage 10.1.0.0/16 du réseau de la plate-forme Agent Platform à son réseau utilisateur 2 appairé.
Notez que vous pouvez modifier les deux côtés de la configuration BGP du VPN 1 pour permettre au réseau sur site et au réseau Agent Platform d'apprendre les routes qui les relient. Étant donné qu'il n'y a pas de tentative de transmission de paquets de chemin de transfert à partir du réseau de l'Agent Platform, ni de paquets de réponse via des connexions d'appairage séquentielles associées à un réseau unique, aucune de ces tentatives de transfert n'est explicitement bloquée.
Configurer la connectivité d'Agent Platform à Internet
Si aucun réseau n'est spécifié lors du lancement d'une charge de travail, celle-ci s'exécute dans un projet producteur distinct géré par Google.
Si un réseau est spécifié, la charge de travail s'exécute dans un projet producteur qui est appairé au projet client.
Par défaut, le réseau Agent Platform dispose de sa propre route vers Internet et le réseau du producteur dispose de sa propre route par défaut vers Internet.
Pour forcer le routage des connexions sortantes du réseau producteur via votre réseau, vous pouvez activer VPC Service Controls pour les appairages. Notez qu'il s'agit d'une configuration distincte de VPC Service Controls.
L'activation de VPC Service Controls pour les appairages entraîne les modifications suivantes dans le réseau Agent Platform :
- Suppression de la route Internet par défaut
- Création d'une route pour l'adresse
199.36.153.4/30de destination avec un saut suivant de la passerelle Internet par défaut - Création d'une zone gérée privée de Cloud DNS pour
*.googleapis.comavec les enregistrements appropriés pour mapper les noms d'hôte à l'une de ces quatre adresses - Autorisation d'utiliser cette zone pour le réseau VPC
servicenetworking
Cette modification vous permet d'exporter la route par défaut de votre réseau afin de vous assurer que les connexions sortantes vers Internet sont acheminées via votre réseau VPC. Cette modification vous permet également d'appliquer les règles nécessaires au trafic sortant de l'Agent Platform.
Vous pouvez interroger l'état de VPC Service Controls pour les peerings en exécutant la commande suivante :
gcloud services vpc-peerings get-vpc-service-controls \
--network YOUR_NETWORK
enabled: true est renvoyé si la configuration est activée, et une liste vide ({}) si elle est désactivée.
Utiliser VPC Service Controls
Si un réseau est spécifié pour la charge de travail et que VPC Service Controls est activé, la charge de travail s'exécute dans un réseau producteur qui est appairé au projet client et soumis aux mêmes règles que le réseau consommateur.
Si ces règles bloquent le trafic sortant, la charge de travail ne pourra pas non plus accéder à Internet. Dans ce cas, vous devez suivre les étapes de la section précédente pour forcer le trafic sortant de la charge de travail à transiter par une instance NAT de votre réseau VPC.
Configurer la connectivité depuis Agent Platform à l'aide de proxys
Un autre modèle de contrôle des adresses IP sortantes d'Agent Platform consiste à forcer les connexions sortantes des charges de travail à passer par un proxy Web que vous contrôlez. Cela permet également d'inspecter la conformité des connexions sortantes.
Toutefois, l'utilisation d'un proxy tiers oblige l'utilisateur à gérer le certificat du proxy pour les réclamations portant sur l'authentification. En outre, ces proxys peuvent ne pas proposer de liste de suites de chiffrement qui s'entrecroise avec celle attendue par les SDK et les API Agent Platform.
Google Cloud propose désormais un proxy Web sécurisé pour faciliter ce processus. Vous pouvez maintenant suivre le guide de démarrage rapide Déployer une instance de Secure Web Proxy et adapter vos charges de travail afin qu'elles l'utilisent pour les connexions sortantes. Ces connexions semblent provenir de l'adresse IP source du proxy.
Si la bibliothèque KFP n'est pas déjà installée dans l'image du composant, le pipeline tente de l'installer avant d'exécuter du code dans lequel vous avez peut-être spécifié un proxy.
Si le pipeline dépend du proxy pour installer les packages à partir d'Internet, cette tentative échoue et une erreur semblable à celle-ci peut s'afficher :
Could not find a version that satisfies the requirement kfp==2.7.0
Dans ce cas, lorsque vous ne parvenez pas à installer KFP avant d'exécuter le code, vous devez utiliser une image sur laquelle KFP est déjà installé.
Vous pouvez ajouter KFP à n'importe quelle image de base et la "push" vers votre dépôt.
L'exemple Dockerfile suivant ajoute KFP à l'image de base python:3.8.
FROM python:3.8
RUN pip install kfp==2.7.0
Vous pouvez ensuite configurer le pipeline @component pour utiliser cette image :
@component(base_image="$PATH_TO_YOUR_REPOSITORY:YOUR_IMAGE")
Une fois le composant de pipeline en cours d'exécution, votre code peut installer librement d'autres packages en passant par le proxy. L'exemple suivant installe numpy à l'aide d'un proxy à l'adresse https://10.10.10.10:443.
import subprocess
subprocess.call(['pip', 'install', '--proxy', 'https://10.10.10.10:443', 'numpy'])`
Configurer des listes d'autorisation pour l'accès aux API
Pour les transactions entre les charges de travail Gemini Enterprise Agent Platform et les API Google, vous devez autoriser l'accès des charges de travail aux plages d'adresses IP utilisées par les API Google. Pour ce faire, vous pouvez exécuter le script fourni pour renvoyer les adresses IP des domaines par défaut.
Fournir une connectivité hybride avec Private Service Connect
Le déploiement des services Agent Platform avec l'accès aux services privés présente plusieurs limites.
- Vous devrez peut-être réserver de grands pools d'adresses IP privées par charge de travail tout en évitant les conflits avec l'adressage de votre VPC.
- L'exécution de plusieurs charges de travail en parallèle peut toujours entraîner une erreur RANGES_EXHAUSTED, même après une configuration initiale correcte.
- Complexité du déploiement et du dépannage du Mise en réseau :
- L'appairage transitif n'étant pas compatible, vous devez déployer des solutions de contournement complexes pour accorder la connectivité entre différents réseaux appairés à votre réseau VPC.
- L'état de la table de routage dans l'environnement du producteur n'est pas immédiatement évident. Comme vous n'avez pas accès au projet locataire, il est souvent difficile de déterminer les cibles qu'une charge de travail Agent Platform peut réellement atteindre sans tests approfondis.
Vous pouvez également déployer ces services sur un point de terminaison Private Service Connect.
- Le service consomme une seule adresse IP dans votre réseau VPC, ce qui vous permet de préserver l'espace d'adressage privé pour votre propre usage.
- Comme l'adresse IP du service Agent Platform se trouve sur votre propre réseau, il est plus simple de créer et d'exécuter des tests de connectivité pour évaluer son accessibilité depuis et vers d'autres points de votre environnement.