Sortie VPC directe avec un réseau VPC

Vous pouvez activer votre job ou votre service Cloud Run pour envoyer du trafic vers un réseau VPC à l'aide de la sortie VPC directe sans connecteur d'accès au VPC sans serveur.

Avant de commencer

Si vous n'avez pas encore de réseau VPC dans votre projet, créez-en un.
Si vous utilisez un VPC partagé, consultez la section Se connecter à un réseau VPC partagé.
Si vous utilisez un sous-réseau VPC, celui-ci doit être /24 ou supérieur.
Pour vous assurer que vous disposez de suffisamment d'adresses IP à utiliser dans Cloud Run, tenez compte des conditions suivantes :
- Le sous-réseau dans lequel vous prévoyez de déployer des services ou des révisions Cloud Run doit disposer d'au moins quelques centaines d'adresses IP disponibles.
- À l'état stable, si le nombre total d'instances Cloud Run utilisant le sous-réseau est de 100 ou plus, réservez suffisamment d'adresses IP pour au moins quatre fois (x 4) le nombre d'instances. Lorsqu'une révision effectue un scaling à la baisse, sachez que Cloud Run conserve ses adresses IP pendant 20 minutes au maximum. Par exemple, si vous mettez à niveau des révisions de sorte que revision 1 passe de 100 instances à zéro tandis que revision 2 passe de zéro à 100, Cloud Run conserve l'adresse IP revision 1 jusqu'à 20 minutes après le scaling à la baisse. Au cours de cet intervalle de 20 minutes, vous devez réserver au moins 800 adresses IP ((100 + 100) * 4).

Limites

Les limites suivantes s'appliquent aux services et aux jobs Cloud Run :

Cloud Run accepte un débit pouvant atteindre 1 Gbit/s par instance individuelle. Au-delà de ce nombre, les performances sont limitées.
Un quota d'utilisation de Cloud Run limite le nombre maximal d'instances que vous pouvez configurer pour utiliser la sortie VPC directe. Le nombre maximal est configuré par révision ou exécution de job Cloud Run. Pour augmenter les limites par défaut, consultez la section Augmenter les quotas. Vous pouvez vérifier votre quota à l'aide de la console Google Cloud.
Les services et jobs Cloud Run peuvent rencontrer des interruptions de connexion lors d'événements de maintenance de l'infrastructure de mise en réseau. Nous vous recommandons d'utiliser des bibliothèques clientes pouvant gérer les réinitialisations occasionnelles des connexions.
L'activation de la sortie VPC directe sur l'environnement d'exécution de deuxième génération peut augmenter les temps de démarrage à froid des conteneurs.

Les limites suivantes s'appliquent uniquement aux jobs Cloud Run, et non aux services :

La sortie VPC directe pour les jobs Cloud Run n'est disponible qu'en version preview.
Pour garantir la bonne exécution des jobs, n'utilisez la sortie VPC directe que pour les jobs qui ne nécessitent pas plus de huit instances simultanées, et veillez à réserver un minimum de 1 024 adresses IP.

Les éléments suivants ne sont pas compatibles avec la sortie VPC directe :

Les journaux de flux VPC et la journalisation des règles de pare-feu ne fournissent pas le nom du service ou de la révision Cloud Run.
Mise en miroir de paquets
Network Intelligence Center
Trafic IPv6
Utilisation de tags réseau dans les règles de pare-feu d'entrée appliquées à la ressource de destination.
Utilisation de l'identité du service en tant que compte de service source dans les règles de pare-feu d'entrée appliquées à la ressource de destination.
Les règles de pare-feu ne peuvent pas utiliser de tags Resource Manager associés à des charges de travail Cloud Run.
Les jobs Cloud Run exécutés pendant plus d'une heure peuvent subir des interruptions de connexion. Cela peut se produire lors d'événements de maintenance liés à la migration du job d'une machine à une autre. Le conteneur reçoit un signal SIGTSTP 10 secondes avant l'événement et un signal SIGCONT après l'événement. Une fois que le conteneur a reçu le signal SIGCONT, réessayez la connexion.

Attribution d'adresses IP

Pour placer votre job ou service Cloud Run sur un réseau VPC, vous devez spécifier un réseau et un sous-réseau. Cloud Run alloue les adresses IP de votre sous-réseau.

Les adresses IP étant éphémères, ne créez pas de règles basées sur des adresses IP individuelles. Si vous devez créer une règle basée sur les adresses IP, par exemple dans les règles de pare-feu, vous devez utiliser la plage d'adresses IP de l'ensemble du sous-réseau.

Pour modifier le réseau ou le sous-réseau utilisé par votre service ou votre job, déployez une nouvelle révision de service ou exécutez une nouvelle tâche de job utilisant les nouvelles valeurs de réseau et de sous-réseau.

Effectuer un scaling à la hausse

Pour permettre un scaling rapide à la hausse en cas de surcharge du trafic, Cloud Run alloue les adresses IP avant qu'elles ne soient nécessaires.

À un moment donné, le nombre d'adresses IP allouées est probablement supérieur au nombre d'instances qui existent. Pour vous assurer que Cloud Run peut obtenir suffisamment d'adresses IP, assurez-vous que votre sous-réseau dispose d'au moins quelques centaines d'adresses IP disponibles. Si le nombre total d'instances du sous-réseau pour tous les services et jobs Cloud Run dépasse 100, nous vous recommandons d'avoir au moins quatre fois (4 fois) le nombre total disponible. Si Cloud Run ne peut pas allouer plus d'adresses IP, il ne peut pas démarrer d'autres instances de service ni tâches de jobs tant que davantage d'adresses IP ne sont pas disponibles. Si votre espace d'adresses IP est limité, consultez la section Plages d'adresses IP compatibles pour plus d'options. Pour optimiser l'attribution d'adresses IP et simplifier la gestion, placez plusieurs services ou jobs sur le même sous-réseau.

Scaling à la baisse

Même après le scaling à zéro instance de tous les services ou jobs, Cloud Run réserve certaines adresses IP du sous-réseau au cas où des services ou jobs devraient évoluer à nouveau rapidement.

Pour supprimer le sous-réseau, vous devez d'abord supprimer ou redéployer vos services ou jobs Cloud Run afin de cesser d'utiliser le sous-réseau, puis attendre une à deux heures.

Plages d'adresses IP compatibles

Cloud Run accepte les plages IPv4 suivantes pour votre sous-réseau :

RFC 1918 (recommandé)
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
RFC 6598
- 100.64.0.0/10
Classe E (non recommandé avec les configurations sur site)
- 240.0.0.0/4

Configurer les autorisations IAM

Assurez-vous que Cloud Run a accès au réseau VPC à l'aide de l'une des méthodes suivantes :

Rôle d'agent de service Cloud Run : par défaut, l'agent de service Cloud Run dispose du rôle Agent de service Cloud Run (roles/run.serviceAgent) contenant les autorisations nécessaires.
Autorisations personnalisées : pour un contrôle plus précis, accordez à l'agent de service Cloud Run les autorisations supplémentaires suivantes sur le projet :
- compute.networks.get
- compute.subnetworks.get
- compute.subnetworks.use sur le projet ou le sous-réseau spécifique
- compute.addresses.get
- compute.addresses.list
- compute.addresses.createInternal
- compute.addresses.deleteInternal
Rôle d'utilisateur de réseau Compute : si vous n'utilisez pas le rôle d'agent de service Cloud Run par défaut ou les autorisations personnalisées, attribuez le rôle d'utilisateur de réseau Compute (roles/compute.networkUser) sur le compte de service de l'agent de service Cloud Run en exécutant la commande suivante :
```
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com" \
--role "roles/compute.networkUser"
```
Remplacez les éléments suivants :
- PROJECT_ID : par l'ID du projet.
- PROJECT_NUMBER : numéro du projet dans lequel vous déployez votre service ou votre job Cloud Run.

Déployer un service

La sortie directe VPC permet à votre service Cloud Run d'envoyer du trafic vers un réseau VPC sans connecteur d'accès au VPC sans serveur. Les coûts réseau sont réduits à zéro comme le service lui-même. Vous pouvez également utiliser les tags réseau directement sur les révisions du service Cloud Run pour une sécurité réseau plus précise.

Vous pouvez configurer la sortie directe du VPC avec un service à l'aide de la console Google Cloud, de Google Cloud CLI ou de YAML.

Console

Accédez à Cloud Run
Cliquez sur Créer un service si vous configurez un nouveau service sur lequel effectuer un déploiement. Si vous configurez et déployez un service existant, cliquez sur ce service, puis sur Modifier et déployer la nouvelle révision.
Si vous configurez un nouveau service, remplissez la page initiale des paramètres du service selon vos besoins, puis cliquez sur Conteneur(s), volumes, mise en réseau et sécurité pour développer la page de configuration du service.
Cliquez sur l'onglet Réseau.
Cliquez sur Se connecter à un VPC pour le trafic sortant.
Cliquez sur Envoyer le trafic directement à un VPC.
Dans le champ Réseau, sélectionnez le réseau VPC vers lequel vous souhaitez envoyer du trafic.
Dans le champ Sous-réseau, sélectionnez le sous-réseau à partir duquel votre service reçoit des adresses IP. Vous pouvez déployer plusieurs services sur le même sous-réseau.
Facultatif : saisissez les noms des tags réseau que vous souhaitez associer à votre ou vos services. Les tags réseau sont spécifiés au niveau de la révision. Chaque révision de service peut avoir des tags réseau différents, tels que network-tag-2.
Dans le champ Routage du trafic, sélectionnez l'une des options suivantes :
- N'acheminez que les requêtes adressées à des adresses IP privées vers le VPC pour envoyer uniquement le trafic vers des adresses internes via le réseau VPC.
- Acheminez tout le trafic vers le VPC pour envoyer tout le trafic sortant via le réseau VPC.
Cliquez sur Créer ou Déployer.
Pour vérifier que votre service se trouve sur votre réseau VPC, cliquez sur le service, puis sur l'onglet Mise en réseau. Le réseau et le sous-réseau sont répertoriés dans la fiche VPC.

Vous pouvez désormais envoyer des requêtes à partir de votre service Cloud Run vers n'importe quelle ressource du réseau VPC, conformément à vos règles de pare-feu.

gcloud

Pour déployer un service Cloud Run sans connecteur à partir de Google Cloud CLI, procédez comme suit :

Assurez-vous que l'API Compute Engine est activée pour votre projet :
```
gcloud services enable compute.googleapis.com
```
Déployez votre service Cloud Run à l'aide de la commande suivante :
```
gcloud run deploy SERVICE_NAME \
--image=IMAGE_URL \
--network=NETWORK \
--subnet=SUBNET \
--network-tags=NETWORK_TAG_NAMES \
--vpc-egress=EGRESS_SETTING \
--region=REGION
```
Remplacez :
- SERVICE_NAME par le nom de votre service Cloud Run.
- IMAGE_URL par une référence à l'image de conteneur, par exemple us-docker.pkg.dev/cloudrun/container/hello:latest. Si vous utilisez Artifact Registry, le dépôt REPO_NAME doit déjà être créé. L'URL se présente sous la forme suivante : LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
- NETWORK par le nom de votre réseau VPC ;
- SUBNET par le nom de votre sous-réseau. Vous pouvez déployer ou exécuter plusieurs services ou jobs sur le même sous-réseau.
- Facultatif : NETWORK_TAG_NAMES par les noms des tags réseau séparés par une virgule que vous souhaitez associer à un service. Pour les services, les tags réseau sont spécifiés au niveau de la révision. Chaque révision de service peut avoir des tags réseau différents, tels que network-tag-2.
- EGRESS_SETTING par une valeur de paramètre de sortie :
  - all-traffic : achemine tout le trafic sortant via le réseau VPC.
  - private-ranges-only : achemine uniquement le trafic destiné à des adresses internes via le réseau VPC.
- REGION par une région pour votre service.
Pour vérifier que votre service se trouve sur votre réseau VPC, exécutez la commande suivante :
```
gcloud run services describe SERVICE_NAME \
--region=REGION
```
Remplacez :
- SERVICE_NAME par le nom de votre service.
- REGION par la région du service que vous avez spécifiée à l'étape précédente.
La sortie doit contenir le nom du réseau, du sous-réseau et du trafic sortant, par exemple :
```
VPC access:
  Network:       default
  Subnet:        subnet
  Egress:        private-ranges-only
```

Vous pouvez désormais envoyer des requêtes à partir de votre service Cloud Run vers n'importe quelle ressource du réseau VPC, conformément à vos règles de pare-feu.

YAML

Vous pouvez stocker votre spécification de service dans un fichier YAML, puis la déployer à l'aide de gcloud CLI.

Créez un fichier service.yaml avec le contenu suivant :
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE_NAME
  labels:
    cloud.googleapis.com/location: REGION
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'
        run.googleapis.com/vpc-access-egress: EGRESS_SETTING
    spec:
      containers:
      - image: IMAGE
```
Remplacez :
- SERVICE_NAME par le nom de votre service Cloud Run. Les noms de service doivent comporter un maximum de 49 caractères et être uniques par région et par projet.
- REGION par la région de votre service Cloud Run, qui doit correspondre à la région de votre sous-réseau.
- NETWORK par le nom de votre réseau VPC ;
- SUBNET par le nom de votre sous-réseau. Vous pouvez déployer ou exécuter plusieurs services ou jobs sur le même sous-réseau.
- Facultatif : NETWORK_TAG_NAMES par les noms des tags réseau que vous souhaitez associer à un service. Pour les services, les tags réseau sont spécifiés au niveau de la révision. Chaque révision de service peut avoir des tags réseau différents, tels que network-tag-2.
- EGRESS_SETTING par une valeur de paramètre de sortie :
  - all-traffic : achemine tout le trafic sortant via le réseau VPC.
  - private-ranges-only : achemine uniquement le trafic destiné à des adresses internes via le réseau VPC.
- IMAGE par l'URL de votre image de conteneur de service.
Vous pouvez également spécifier d'autres éléments de configuration, tels que des variables d'environnement ou des limites de mémoire.
Déployez le nouveau service en exécutant la commande suivante :
```
gcloud run services replace service.yaml
```
Vous pouvez éventuellement rendre votre service public si vous souhaitez autoriser un accès non authentifié à celui-ci.

Si vous devez télécharger ou consulter la configuration d'un service existant, exécutez la commande suivante pour enregistrer les résultats dans un fichier YAML :

gcloud run services describe SERVICE --format export > service.yaml

Dans un fichier YAML de configuration de service, modifiez les attributs enfants spec.template en fonction de vos besoins pour mettre à jour les paramètres de révision, puis déployez la nouvelle révision :

gcloud run services replace service.yaml

Créer un job

La sortie directe de VPC permet à votre job Cloud Run d'envoyer du trafic vers un réseau VPC sans connecteur d'accès au VPC sans serveur.

Vous pouvez configurer une sortie VPC directe avec un job à l'aide de la console Google Cloud, de Google Cloud CLI ou de YAML.

Console

Accédez à Cloud Run
Si vous configurez un nouveau job, cliquez sur l'onglet Jobs et remplissez la page des paramètres initiaux du job selon vos besoins. Si vous configurez une tâche existante, cliquez sur celle-ci, puis sur Modifier.
Cliquez sur Conteneur, variables et secrets, connexions, sécurité pour développer la page des propriétés du job.
Cliquez sur l'onglet Connexions.
Cliquez sur Se connecter à un VPC pour le trafic sortant.
Cliquez sur Envoyer le trafic directement à un VPC.
Dans le champ Réseau, sélectionnez le réseau VPC auquel vous souhaitez envoyer du trafic.
Dans le champ Sous-réseau, sélectionnez le sous-réseau à partir duquel votre job reçoit des adresses IP. Vous pouvez exécuter plusieurs tâches sur le même sous-réseau.
Dans le champ Routage du trafic, sélectionnez l'une des options suivantes :
- N'acheminez que les requêtes adressées à des adresses IP privées vers le VPC pour envoyer uniquement le trafic vers des adresses internes via le réseau VPC.
- Acheminez tout le trafic vers le VPC pour envoyer tout le trafic sortant via le réseau VPC.
Facultatif : saisissez les noms des tags réseau que vous souhaitez associer à votre ou vos services. Les tags réseau sont spécifiés au niveau de la révision. Chaque révision de service peut avoir des tags réseau différents, tels que network-tag-2.
Facultatif : saisissez les noms des tags réseau que vous souhaitez associer à votre ou vos jobs. Pour les jobs, les tags réseau sont spécifiés au niveau de l'exécution. Chaque exécution de job peut avoir des tags réseau différents, tels que network-tag-2.
Cliquez sur Créer ou Mettre à jour.
Pour vérifier que votre job se trouve sur votre réseau VPC, cliquez sur le job, puis sur l'onglet Configuration. Le réseau et le sous-réseau sont répertoriés dans la fiche VPC.

Vous pouvez maintenant exécuter votre job Cloud Run et envoyer des requêtes à partir du job vers n'importe quelle ressource du réseau VPC, conformément à vos règles de pare-feu.

gcloud

Pour créer un job Cloud Run sans connecteur à partir de Google Cloud CLI, procédez comme suit :

Assurez-vous que l'API Compute Engine est activée pour votre projet :
```
gcloud services enable compute.googleapis.com
```
Créez un job Cloud Run à l'aide de la commande suivante :
```
gcloud run jobs create JOB_NAME \
--image=IMAGE_URL \
--network=NETWORK \
--subnet=SUBNET \
--network-tags=NETWORK_TAG_NAMES \
--vpc-egress=EGRESS_SETTING \
--region=REGION
```
Remplacez :
- JOB_NAME par le nom de votre job Cloud Run
- IMAGE_URL par une référence à l'image du conteneur, par exemple us-docker.pkg.dev/cloudrun/container/job:latest ;
- NETWORK par le nom de votre réseau VPC ;
- SUBNET par le nom de votre sous-réseau. Vous pouvez déployer ou exécuter plusieurs services ou jobs sur le même sous-réseau.
- Facultatif : NETWORK_TAG_NAMES par les noms des tags réseau que vous souhaitez associer à un job. Pour les jobs, les tags réseau sont spécifiés au niveau de l'exécution. Chaque exécution de job peut avoir des tags réseau différents, tels que network-tag-2.
- EGRESS_SETTING par une valeur de paramètre de sortie :
  - all-traffic : achemine tout le trafic sortant via le réseau VPC.
  - private-ranges-only : achemine uniquement le trafic destiné à des adresses internes via le réseau VPC.
- REGION par une région pour votre job.
Pour vérifier que le job se trouve sur votre réseau VPC, exécutez la commande suivante :
```
gcloud run jobs describe JOB_NAME \
  --region=REGION
  
```
Remplacez :
- JOB_NAME par le nom de votre tâche.
- REGION par la région de votre job que vous avez spécifié à l'étape précédente.
Le résultat doit contenir le nom de votre réseau et de votre sous-réseau, par exemple :
```
VPC network:
  Network:       default
  Subnet:        default
```

Vous pouvez maintenant exécuter votre job Cloud Run et envoyer des requêtes à partir du job vers n'importe quelle ressource du réseau VPC, conformément à vos règles de pare-feu.

YAML

Vous pouvez stocker votre spécification de job dans un fichier YAML, puis la déployer à l'aide de gcloud CLI.

Créez un fichier job.yaml avec le contenu suivant :
```
apiVersion: run.googleapis.com/v1
kind: Job
metadata:
  name: JOB_NAME
  annotations:
    run.googleapis.com/launch-stage: BETA
  labels:
    cloud.googleapis.com/location: REGION
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'
        run.googleapis.com/vpc-access-egress: EGRESS_SETTING
    spec:
      containers:
      - image: IMAGE
```
Remplacez :
- JOB_NAME par le nom de votre job Cloud Run Les noms de job doivent comporter un maximum de 49 caractères et être uniques par région et par projet.
- REGION par la région de votre job Cloud Run, qui doit correspondre à la région de votre sous-réseau.
- NETWORK par le nom de votre réseau VPC ;
- SUBNET par le nom de votre sous-réseau. Vous pouvez déployer ou exécuter plusieurs services ou jobs sur le même sous-réseau.
- Facultatif : NETWORK_TAG_NAMES par les noms des tags réseau que vous souhaitez associer à un job. Pour les jobs, les tags réseau sont spécifiés au niveau de l'exécution. Chaque exécution de job peut avoir des tags réseau différents, tels que network-tag-2.
- EGRESS_SETTING par une valeur de paramètre de sortie :
  - all-traffic : achemine tout le trafic sortant via le réseau VPC.
  - private-ranges-only : achemine uniquement le trafic destiné à des adresses internes via le réseau VPC.
- IMAGE par l'URL de votre image de conteneur de job.
Déployez le nouveau job en exécutant la commande suivante :
```
gcloud run jobs replace job.yaml
```

Si vous devez télécharger ou consulter la configuration d'un job existant, exécutez la commande suivante pour enregistrer les résultats dans un fichier YAML :

gcloud run jobs describe JOB --format export > job.yaml

Dans un fichier YAML de configuration de job, modifiez les attributs enfants spec.template en fonction de vos besoins pour mettre à jour les paramètres de révision, puis redéployez votre application :

gcloud run jobs replace job.yaml

Restreindre l'accès avec des règles de pare-feu

Limitez l'accès aux ressources d'un réseau VPC à l'aide de règles de pare-feu VPC. Ajoutez ces restrictions en utilisant l'une des stratégies suivantes :

Créez une règle de pare-feu d'entrée qui fait référence à votre service ou à votre job à l'aide de la plage d'adresses IP du sous-réseau.
Créez une règle de pare-feu de sortie qui fait référence à votre service ou à votre job.

Dans la règle de pare-feu de sortie, faites référence à votre service ou à votre job en utilisant l'identité de service du compte de service associé, la plage d'adresses IP du sous-réseau ou les tags réseau associés.

Tags réseau pour la sortie

Ajoutez une couche de sécurité réseau supplémentaire en utilisant des tags réseau dans les règles de pare-feu de sortie.

Console

Pour associer des tags réseau à un service ou à un job, procédez comme suit :

Dans Google Cloud Console, accédez à la page Cloud Run.

Accédez à Cloud Run
Cliquez sur le service ou le job auquel vous souhaitez associer des tags réseau, puis sur Modifier et déployer la nouvelle révision pour les services ou sur Modifier pour les jobs.
Cliquez sur l'onglet Mise en réseau pour les services ou sur l'onglet Connexions pour les jobs.
Assurez-vous d'avoir sélectionné Se connecter à un VPC pour le trafic sortant et Envoyer le trafic directement vers un VPC.
Dans le champ Sous-réseau, sélectionnez le sous-réseau à partir duquel votre service reçoit des adresses IP. Vous pouvez déployer ou exécuter plusieurs services ou jobs sur le même sous-réseau.
Dans le champ Tags réseau, saisissez les noms des tags réseau que vous souhaitez associer à votre service ou à votre job.
Cliquez sur Déployer ou Mettre à jour.

Pour les services, chaque révision peut avoir un ensemble différent de tags réseau, car ceux-ci sont spécifiés au niveau de la révision. Pour un job, une exécution possède les mêmes tags réseau que le job avait lors de la création de l'exécution.

gcloud

Pour associer des tags réseau à un service ou à un job, exécutez la commande gcloud run deploy :

gcloud run deploy SERVICE_JOB_NAME \
    --image=IMAGE_URL \
    --network=NETWORK \
    --subnet=SUBNET \
    --network-tags=NETWORK_TAG_NAMES \
    --region=REGION

Remplacez les éléments suivants :

SERVICE_JOB_NAME par le nom de votre service ou de votre job.
IMAGE_URL par l'URL de l'image du service ou du job.
NETWORK par le nom de votre réseau VPC ;
SUBNET par le nom de votre sous-réseau. Vous pouvez déployer ou exécuter plusieurs services ou jobs sur le même sous-réseau.
NETWORK_TAG_NAMES par le nom de votre tag réseau ou liste de tags réseau séparés par une virgule.
REGION par le nom de votre région.

Déconnecter un service

Console

Pour supprimer votre service du réseau VPC, procédez comme suit :
1. Accédez à Cloud Run
2. Cliquez sur le service à supprimer, puis sur Modifier et déployer la nouvelle révision.
3. Cliquez sur l'onglet Réseau.
4. Désactivez l'option Se connecter à un VPC pour le trafic sortant.
5. Cliquez sur Déployer.
6. Pour vérifier que votre service ne se trouve plus sur votre réseau VPC, cliquez sur l'onglet Réseau. Le réseau et le sous-réseau ne sont plus répertoriés dans la fiche VPC.
Pour ne supprimer que les tags réseau tout en maintenant le service connecté au réseau VPC, procédez comme suit :
1. Cliquez sur le service contenant les tags réseau à supprimer, puis sur Modifier et déployer la nouvelle révision.
2. Cliquez sur l'onglet Réseau.
3. Effacez les noms des tags réseau que vous ne souhaitez plus associer à votre service.
4. Cliquez sur Déployer.

gcloud

Pour supprimer votre service du réseau VPC, exécutez la commande suivante :

gcloud run services update SERVICE_NAME --region=REGION \
--clear-network

Pour ne supprimer que les tags réseau tout en maintenant le service connecté au réseau VPC, exécutez la commande suivante :
```
gcloud run services update SERVICE_NAME --region=REGION \
--clear-network-tags
```
Remplacez les éléments suivants :
- SERVICE_NAME : nom de votre service Cloud Run.
- REGION : région de votre service Cloud Run.

YAML

Pour supprimer votre service du réseau VPC, procédez comme suit :
1. Supprimez le contenu suivant de votre fichier service.yaml :
```
run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'
```
  Où
  - NETWORK : nom de votre réseau VPC.
  - SUBNET : nom de votre sous-réseau
  - Facultatif : NETWORK_TAG_NAMES : noms des tags réseau si vous les avez associés à un service.
2. Déployez la révision du service en exécutant la commande suivante :
```
gcloud run services replace service.yaml
```
Pour ne supprimer que les tags réseau tout en maintenant le service connecté au réseau VPC, procédez comme suit :
1. Supprimez la variable tags du contenu de votre fichier service.yaml, en laissant les variables network et subnetwork en place, comme indiqué dans l'exemple suivant :
```
run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET"}]'
```
  Où
  - NETWORK : nom de votre réseau VPC.
  - SUBNET : nom de votre sous-réseau
2. Déployez la révision du service en exécutant la commande suivante :
```
gcloud run services replace service.yaml
```

Déconnecter un job

Console

Pour supprimer votre job du réseau VPC, procédez comme suit :
1. Accédez à Cloud Run
2. Cliquez sur le job à supprimer, puis sur Modifier et déployer la nouvelle révision.
3. Cliquez sur l'onglet Connexions.
4. Désactivez l'option Se connecter à un VPC pour le trafic sortant.
5. Cliquez sur Update (Mettre à jour).
6. Pour vérifier que votre job ne se trouve plus sur votre réseau VPC, cliquez sur l'onglet Configuration. Le réseau et le sous-réseau ne sont plus répertoriés dans la fiche VPC.
Pour supprimer uniquement les tags réseau tout en maintenant le job connecté au réseau VPC :
1. Cliquez sur le job contenant les tags réseau à supprimer, puis sur Modifier et déployer la nouvelle révision.
2. Cliquez sur l'onglet Connexions.
3. Effacez les noms des tags réseau que vous ne souhaitez plus associer à votre job.
4. Cliquez sur Update (Mettre à jour).

gcloud

Pour supprimer votre job du réseau VPC, exécutez la commande suivante :

gcloud run jobs update JOB_NAME --region=REGION \
  --clear-network

Pour ne supprimer que les tags réseau tout en maintenant le job connecté au réseau VPC, exécutez la commande suivante :
```
gcloud run jobs update JOB_NAME --region=REGION \
  --clear-network-tags
  
```
Remplacez les éléments suivants :
- JOB_NAME par le nom de votre job Cloud Run
- REGION : région de votre job Cloud Run.

YAML

Pour supprimer votre job du réseau VPC, procédez comme suit :
1. Supprimez le contenu suivant de votre fichier job.yaml :
```
run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'
```
  Remplacez les éléments suivants :
  - NETWORK : nom de votre réseau VPC.
  - SUBNET : nom de votre sous-réseau
  - Facultatif : NETWORK_TAG_NAMES par les noms des tags réseau si vous les avez associés à un job.
2. Redéployez le job en exécutant la commande suivante :
```
gcloud run jobs replace job.yaml
```
Pour supprimer uniquement les tags réseau tout en maintenant le job connecté au réseau VPC :
1. Supprimez la variable tags du contenu de votre fichier job.yaml, en laissant les variables network et subnetwork en place, comme indiqué dans l'exemple suivant :
```
run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET"}]'
```
  Remplacez les éléments suivants :
  - NETWORK : nom de votre réseau VPC.
  - SUBNET : nom de votre sous-réseau
2. Redéployez le job en exécutant la commande suivante :
```
gcloud run jobs replace job.yaml
```

Dépannage

Impossible de supprimer le sous-réseau

Pour supprimer un sous-réseau, vous devez d'abord supprimer ou redéployer toutes les ressources qui l'utilisent. Si Cloud Run utilise un sous-réseau, déconnectez le service ou la tâche Cloud Run du réseau VPC ou déplacez-le vers un autre sous-réseau avant de supprimer le sous-réseau.

Le sous-réseau VPC direct manque d'adresses IP

Si le sous-réseau du réseau VPC manque d'adresses IP, cela est consigné par Cloud Logging. Lorsque cela se produit, Cloud Run ne peut pas démarrer d'autres instances de service ou tâches de job tant que davantage d'adresses IP ne sont pas disponibles.

Afficher les adresses IP allouées

Pour afficher les adresses IP allouées par Cloud Run, accédez à la page Adresses IP dans la console Google Cloud ou exécutez la commande suivante à partir de Google Cloud CLI :

gcloud compute addresses list