Bonnes pratiques pour la mise en réseau Cloud Run

Cette page décrit les bonnes pratiques à suivre pour configurer les options de mise en réseau pour les ressources Cloud Run. Avant de créer vos ressources, nous vous recommandons de consulter toutes les sections de cette page pour comprendre les options de mise en réseau compatibles avec Cloud Run et leurs implications.

Surveiller l'utilisation des adresses IP

Si vous utilisez la sortie VPC directe, assurez-vous de disposer de suffisamment d'adresses IP pour votre sous-réseau. Le nombre d'adresses IP que vous utilisez dépend du nombre d'instances de conteneur exécutées par vos charges de travail. Nous vous recommandons donc de surveiller l'utilisation de vos adresses IP. Assurez-vous que votre utilisation des adresses IP au fil du temps reste dans les limites acceptées par le sous-réseau.

Pour estimer votre utilisation des adresses IP :

  1. Dans la console Google Cloud , accédez à la page "Explorateur de métriques" de Cloud Monitoring :

    Accéder à l'explorateur de métriques Cloud Monitoring

  2. Recherchez le nombre d'instances de conteneur dans votre projet à l'aide du type de métrique run.googleapis.com/container/instance_count. Cloud Monitoring vous permet d'afficher la valeur de cette métrique au fil du temps.

  3. Multipliez la valeur de la métrique du nombre d'instances par 2 pour obtenir une estimation du nombre d'adresses IP utilisées.

Stratégies d'épuisement des adresses IP

Un grand nombre de charges de travail Cloud Run peut entraîner des problèmes d'épuisement des adresses IP lorsque vous utilisez l'espace d'adresses IP privées RFC 1918 avec la sortie VPC directe. Les stratégies suivantes peuvent vous aider à gérer l'épuisement des adresses IP en utilisant d'autres plages d'adresses IP.

Utiliser des adresses IPv4 non-RFC 1918

Outre les plages d'adresses IPv4 RFC 1918, Cloud Run est également compatible avec les plages RFC 6598 et Classe E/RFC 5735. Tous les services et fonctionnalitésGoogle Cloud fonctionnent avec ces plages non-RFC 1918, y compris les réseaux VPC, Cloud Load Balancing et Private Service Connect.

Pour une compatibilité optimale, nous vous recommandons de commencer par la plage RFC 6598 (100.64.0.0/10). Si vous utilisez déjà cette plage ailleurs, envisagez d'utiliser la classe E/RFC 5735 (240.0.0.0/4). La classe E est un espace immense qui compte plus de 268 millions d'adresses IP disponibles. Elle pourra donc soutenir votre croissance pendant longtemps. Toutefois, la classe E présente certaines limites. Par exemple, elle n'est pas compatible avec Windows ni avec certains matériels sur site. Découvrez comment exploiter l'espace d'adressage IPv4 de classe E pour atténuer les problèmes d'épuisement des adresses IPv4 dans GKE.

Utiliser Cloud NAT ou Private Service Connect

Si votre charge de travail Cloud Run utilisant une plage non-RFC 1918 doit atteindre une destination sur site qui n'accepte que la norme RFC 1918, utilisez l'une des solutions suivantes :

  • Utilisez Hybrid NAT pour effectuer la traduction d'adresses et la sortie à l'aide d'une petite plage RFC 1918.
  • Exposez le service sur site en tant que service hybride Private Service Connect.

Utiliser des sous-réseaux IPv4 et IPv6 (double pile)

Bien que cela ne réduise pas l'épuisement des adresses IPv4, migrer vos applications vers IPv6 est une bonne première étape. Configurez des ressources à double pile pour éviter les problèmes d'épuisement des adresses IPv4 à l'avenir.

Stratégies de réduction de l'épuisement des ports

La section suivante décrit les stratégies permettant de réduire l'épuisement des ports avec Cloud Run.

Utiliser le regroupement de connexions et réutiliser les connexions

Lorsque vous envoyez un grand nombre de requêtes à une seule adresse IP de destination, utilisez le regroupement de connexions pour maintenir et réutiliser les connexions à la destination. Des taux de connexion élevés à une seule adresse IP peuvent épuiser les ports sortants et provoquer des erreurs de connexion refusée.

Isoler le trafic Internet sortant

Par défaut, Cloud Run envoie le trafic Internet sortant via un pool régional d'adresses IP dynamiques partagées entre les charges de travail sans serveur. N'utilisez pas ce pool partagé par défaut pour les charges de travail qui dépendent de la réputation des adresses IP ou qui génèrent un trafic de sondage volumineux.

Configurez plutôt la sortie VPC directe avec --vpc-egress=all-traffic et acheminez le trafic via Cloud NAT avec des adresses IP sortantes statiques dédiées dans les cas suivants :

  • Votre charge de travail se connecte à des points de terminaison externes sensibles à la réputation, tels que des passerelles de paiement, des bases de données hébergées ou des API partenaires derrière des pare-feu d'application Web (WAF) tiers. Les adresses IP statiques dédiées empêchent le trafic bruyant d'autres locataires du pool partagé de déclencher des blocages WAF externes ou des erreurs HTTP 403.
  • Votre charge de travail exécute une analyse réseau autorisée, une énumération de ports, une empreinte d'hôte, une détection de failles, un scraping Web ou un test de charge. L'exécution de ces charges de travail sur le pool d'adresses IP partagées par défaut dégrade la réputation des adresses IP, peut perturber le service pour d'autres clients en violation du Règlement sur l'utilisation acceptable deGoogle Cloud et peut amener Google à limiter ou suspendre votre charge de travail.

Lorsque vous exécutez des charges de travail d'analyse autorisée ou à connexion élevée via Cloud NAT, allouez suffisamment d'adresses IP statiques et configurez la réservation de ports pour éviter l'épuisement des ports.

Stratégies de performances et de débit

Cette section présente les options évolutives permettant d'améliorer les performances et le débit du réseau vers Internet et les services Google.

Utiliser l'environnement d'exécution de deuxième génération

Pour obtenir les meilleures performances réseau pour les services Cloud Run, utilisez l'environnement d'exécution de deuxième génération lors de l'acheminement du trafic avec la sortie VPC directe. L'environnement de deuxième génération offre des performances réseau plus rapides, en particulier en cas de perte de paquets.

Vous pouvez sélectionner l'environnement d'exécution à l'aide de la console Google Cloud , de la gcloud CLI, de YAML ou de Terraform.

Utiliser la sortie VPC directe pour un débit de sortie réseau plus rapide

Pour accélérer le débit des connexions de sortie réseau, utilisez la sortie VPC directe pour acheminer le trafic via votre réseau VPC. Nous vous recommandons de l'utiliser conjointement avec l'environnement d'exécution de deuxième génération, comme indiqué précédemment.

Exemple 1 : Trafic externe vers Internet

Si vous envoyez du trafic externe vers l'Internet public, acheminez tout le trafic via le réseau VPC en définissant --vpc-egress=all-traffic. Avec cette approche, vous devez configurer Cloud NAT pour accéder à l'Internet public.

Pour permettre à Cloud Run d'utiliser une passerelle Cloud NAT pour Public NAT ou Private NAT, consultez Interactions entre Cloud NAT et la sortie VPC directe.

Exemple 2 : Trafic interne vers une API Google

Si vous utilisez la sortie VPC directe pour envoyer du trafic vers une API Google, telle que Cloud Storage, choisissez l'une des options suivantes :

Utiliser le paramètre de MTU par défaut pour Cloud Run

Ne modifiez pas le paramètre d'unité de transmission maximale (MTU) d'un réseau VPC lorsque vous l'utilisez avec Cloud Run. Utilisez plutôt la MTU par défaut de 1 460 octets.

Considérations liées au coût

Lorsque vous configurez les options de mise en réseau de vos ressources, tenez compte des points suivants :

  • Colocalisez vos ressources : essayez de déployer vos ressources Cloud Run dans la même région que vos bases de données de backend (comme Cloud SQL ou Firestore) et vos buckets Cloud Storage. Le transfert de données entre les ressources Google Cloud au sein d'une même région est sans frais.
  • Passer à la sortie VPC directe : si vous acheminez de manière sécurisée le trafic vers des ressources de réseau VPC internes, envisagez de passer à la sortie VPC directe à partir des connecteurs d'accès au VPC sans serveur. La sortie VPC directe effectue un scaling à la baisse jusqu'à zéro, ce qui élimine les coûts de calcul de base et les coûts d'inactivité associés aux instances de connecteur.
  • Utilisez Cloud CDN : déchargez les éléments statiques et le contenu pouvant être mis en cache en plaçant Cloud CDN devant vos ressources Cloud Run. La diffusion de données à partir de la périphérie est nettement moins coûteuse que le paiement d'une sortie Internet standard directement depuis Cloud Run.
  • Surveiller le trafic de sortie Internet : le trafic entrant est toujours sans frais, et vous bénéficiez de 1 Gio de transfert de données Internet sortant sans frais par mois en Amérique du Nord. Concentrez vos efforts de surveillance sur le trafic sortant qui dépasse les limites de la région ou le niveau sans frais.

Pour en savoir plus, consultez les tarifs de Cloud Run ou estimez les coûts à l'aide du simulateur de coût.

Étapes suivantes