Gestion des adresses GKE : fonctionnalité NAT pour tous les blocs CIDR de GKE

Ce document fait partie d'une série destinée aux architectes de réseau. Cette série aborde les options de gestion des adresses Google Kubernetes Engine (GKE) disponibles pour les organisations dont l'adressage  IPv4 est limitée.

Cette série comprend les parties suivantes :

Dans ce document, nous partons du principe que vous connaissez bien la fonctionnalité NAT. Vous y découvrirez comment créer un VPC isolé par cluster, où les blocs CIDR RFC 1918 peuvent être réutilisés en toute sécurité pour traduire tous les blocs CIDR de GKE. La solution décrite dans ce document permet de faire face à la demande d'adresses actuelle, tout en anticipant l'évolution à la hausse de cette demande.

Exigences pour les blocs CIDR

Pour en savoir plus sur les méthodes permettant de déterminer les tailles de bloc CIDR et les règles à suivre lors de la sélection des blocs, consultez la page Gestion des adresses GKE : optimisation des adresses IPv4.

Solution

La figure suivante montre une vue d'ensemble de la solution. Chaque composant fonctionnel est abordé séparément dans les sections ci-après.

Fonctionnalité NAT pour tous les blocs CIDR d'un cluster GKE. (Pour obtenir une version PDF lisible, cliquez sur l'image.)
Figure 1. Fonctionnalité NAT pour tous les blocs CIDR d'un cluster GKE. (Pour obtenir une version PDF lisible, cliquez sur l'image.)

VPC partagé

Vous créez un projet et le configurez en tant que projet hôte partageant un VPC. Ce VPC présente les caractéristiques suivantes :

  • Il contient un sous-réseau dans le VPC partagé auquel le VPC isolé peut se connecter via le projet de service associé.
  • Il fournit une connectivité au réseau sur site via Cloud Interconnect ou des connexions VPN.
  • Il contient un sous-réseau qui se connecte à l'interface eth0 de la passerelle de VPC isolé.
  • Il contient une règle de pare-feu qui autorise le trafic provenant des adresses RFC 1918 du domaine routé vers les blocs CIDR d'équilibreur de charge interne du VPC isolé. Cette règle est appliquée à la passerelle de VPC isolé.
  • Il contient une route statique qui achemine le trafic du domaine routé vers les adresses allouées d'équilibreur de charge interne du VPC isolé. La passerelle de VPC isolé doit être spécifiée comme saut suivant pour ce trafic.

Les ressources de ce VPC se voient toujours attribuer des adresses allouées.

VPC isolé

Vous créez un projet de service destiné à contenir le VPC isolé, lequel est un VPC standard et n'a rien d'unique. Le mot isolé n'est utilisé que pour désigner l'objectif fonctionnel du VPC. Ce VPC présente les caractéristiques suivantes :

  • L'API GKE est activée.
  • Il contient le cluster GKE.
  • Il contient la passerelle de VPC isolé.
  • Il contient un sous-réseau connecté à l'interface eth1 de la passerelle de VPC isolé.
  • Il contient une règle de pare-feu qui autorise le trafic provenant des adresses allouées d'équilibreur de charge interne du VPC isolé vers l'espace d'adressage RFC 1918 du domaine routé. Cette règle est appliquée à la passerelle de VPC isolé.
  • Il contient des équilibreurs de charge internes pour l'accès du domaine routé aux adresses IP de service GKE.
  • Il contient une route statique qui achemine le trafic de la passerelle de VPC isolé vers l'espace d'adressage alloué RFC 1918 du domaine routé. La passerelle de VPC isolé doit être spécifiée comme adresse de saut suivant pour ce trafic.

Les ressources de ce VPC se voient attribuer des adresses allouées ou réutilisées.

Passerelle de VPC isolé

Une passerelle de VPC isolé est une VM Compute Engine qui sert de passerelle entre le VPC isolé et le domaine routé de votre organisation. Elle présente les caractéristiques suivantes :

  • Elle réside dans le VPC isolé.
  • Elle dispose d'une configuration à cartes d'interface réseau multiples avec eth0 dans le VPC partagé et eth1 dans le VPC isolé.
  • Elle est configurée pour le transfert d'adresses IP.
  • Elle est configurée pour exécuter la traduction NAT source telle que définie dans la section sur les conditions requises pour la NAT.

Étant donné que chaque application et réseau présentent des exigences différentes, nous ne pouvons pas recommander un type de machine pour la passerelle de VPC isolé. Pour vous aider à choisir un type de machine, nous vous recommandons d'effectuer une analyse comparative des besoins en bande passante de votre cluster et de la charge du processeur et de la mémoire générée par la NAT.

Routage

Vous devez configurer les routes en fonction de vos applications et de votre infrastructure réseau.

Au sein du VPC partagé

La route statique suivante doit être configurée dans le VPC partagé :

  • Une route qui dirige le trafic vers l'adresse allouée du VPC isolé du bloc CIDR d'équilibreur de charge interne. La passerelle de VPC isolé doit être définie comme saut suivant pour ce trafic.

Si les blocs CIDR alloués du VPC isolé doivent être accessibles à partir du réseau sur site, ils doivent respecter l'une des conditions suivantes :

  • Ils doivent être annoncés sur le réseau sur site via l'interconnexion ou la liaison VPN.
  • Ils doivent être configurés en tant que route statique pointant vers le VPC partagé, puis redistribués dans le protocole IGP sur le réseau sur site.

Sur la passerelle de VPC isolé

Les routes statiques suivantes doivent être configurées sur la passerelle de VPC isolé :

  • Une route statique qui dirige le trafic vers le bloc CIDR 10/8.
  • Une route statique qui dirige le trafic vers le bloc CIDR 172.16/12.
  • Une route statique qui dirige le trafic vers le bloc CIDR 192.168/16.

Ces routes dirigent le trafic vers le VPC partagé et le réseau sur site. Le saut suivant pour ces routes doit être l'adresse IPv4 du routeur réseau du VPC partagé, par exemple 10.97.0.1.

Au sein du VPC isolé

Les routes statiques suivantes doivent être configurées dans le VPC isolé :

  • Une route statique qui dirige le trafic vers le bloc CIDR 10/8.
  • Une route statique qui dirige le trafic vers le bloc CIDR 172.16/12.
  • Une route statique qui dirige le trafic vers le bloc CIDR 192.168/16.

Ces routes dirigent le trafic vers le VPC partagé et le réseau sur site. Le saut suivant pour ces routes doit être l'adresse IPv4 de la passerelle de VPC isolé, par exemple 10.32.0.2.

Terminologie liée à la fonctionnalité NAT pour le VPC isolé

Les colonnes Adresses allouées du VPC isolé et Adresses réutilisées du VPC isolé dans le tableau ci-après récapitulent les exemples de plages CIDR utilisées dans cette solution.

Adresses allouées
du domaine routé
Adresses réutilisées
du domaine routé
Description
du VPC isolé
Adresses allouées
du VPC isolé
Adresses réutilisées
du VPC isolé
10.0.0.0/11 10.160.0.0/11 Pod - 10.0.0.0/11
10.32.0.0/19 10.64.0.0/19 Nœuds - 10.32.0.0/19
10.224.0.0/20 10.224.224.0/20 Services - 10.224.0.0/20
- - Équilibrage de
charge interne
Sous-réseau dans le bloc CIDR
réutilisé de nœud du VPC isolé
-

Tableau 1. Exemples de plages CIDR.

Adresses réutilisées

  • Pod : cet espace d'adressage sera déjà utilisé sur site ou dans le cloud. Étant donné que les adresses IPv4 de pod sont éphémères et utilisées pour la communication au sein des pods, cela ne pose aucun problème. Cet espace d'adressage est classé dans les adresses réutilisées du VPC isolé, car les pods résident dans le VPC isolé et font appel à des adresses IPv4 réutilisées.

    Ce bloc d'adresses ne doit pas être utilisé dans une route statique du VPC partagé qui dirige le trafic vers le VPC isolé.

  • Nœud : cet espace d'adressage sera déjà utilisé sur site ou dans le cloud. La réutilisation de cet espace d'adressage est acceptable, car les applications de cluster sont exposées en dehors du cluster via une adresse d'équilibreur de charge interne. Cet espace d'adressage est classé dans les adresses réutilisées du VPC isolé, car les nœuds résident dans le VPC isolé et font appel à des adresses IPv4 réutilisées.

    Ce bloc d'adresses ne doit pas être utilisé dans une route statique du VPC partagé qui dirige le trafic vers le VPC isolé.

  • Service : il est possible que cet espace d'adressage soit déjà utilisé sur site ou dans le cloud. Étant donné que l'espace d'adressage de service est utilisé pour la communication au sein des pods et l'équilibrage de charge, cela ne pose aucun problème. Cet espace d'adressage est classé dans les adresses réutilisées du VPC isolé, car les adresses résident dans le VPC isolé et sont des adresses IPv4 réutilisées.

    Ce bloc d'adresses ne doit pas être utilisé dans une route statique du VPC partagé qui dirige le trafic vers le VPC isolé.

Adresses allouées

  • Équilibrage de charge interne : GKE exige que les adresses IPv4 des équilibreurs de charge internes soient attribuées à partir du bloc CIDR IPv4 de nœud. Par conséquent, l'organisation doit allouer un sous-réseau de l'espace réutilisé pour la plage CIDR IPv4 de nœud. Ces adresses IPv4 doivent être réservées dans le VPC isolé et sont spécifiées en tant que valeur loadBalancerIP dans le fichier manifeste de service GKE.

    L'espace d'adressage alloué du VPC isolé des équilibreurs de charge internes ne doit pas nécessairement être contigu dans la plage CIDR IPv4 de nœud. Le masque de réseau de cet espace peut s'étendre jusqu'à la plage CIDR IPv4 de service, ou se limiter à une adresse hôte avec un masque de réseau /32, ou bien il peut s'agir d'un ensemble de blocs CIDR. Lorsque vous utilisez un espace d'adressage non contigu, veillez à respecter les limites de quota pour les routes statiques.

    Cet espace d'adressage est classé dans les adresses allouées du VPC isolé, car les adresses résident dans le VPC isolé et sont des adresses IPv4 allouées par l'organisation. Ces blocs d'adresses apparaissent dans la table de routage globale du domaine routé.

Configuration NAT

L'objectif des configurations NAT fournies dans ce document est d'offrir un juste équilibre entre la simplicité et la flexibilité nécessaire pour résoudre des problèmes techniques catastrophiques ou intermittents. La figure 2 présente un schéma général de la conception NAT globale.

Réutilisation des blocs CIDR RFC 1918 avec GKE. (Pour obtenir une version PDF lisible, cliquez sur l'image.)
Figure 2. Réutilisation des blocs CIDR RFC 1918 avec GKE. (Pour obtenir une version PDF lisible, cliquez sur l'image.)

Étant donné que le bloc d'adresses allouées du VPC isolé utilisé pour les équilibreurs de charge internes figure dans la table de routage globale de l'organisation, il n'est pas nécessaire d'effectuer une traduction NAT basée sur la destination. De plus, comme vous réutilisez des adresses IPv4 déjà attribuées aux ressources du domaine routé qui ont besoin d'accéder aux applications du VPC isolé, vous avez besoin d'une configuration SNAT dans la passerelle de VPC isolé.

Trafic provenant du VPC isolé acheminé vers le domaine routé

Le trafic provenant des adresses réutilisées du VPC isolé de nœud, de pod ou de service ne peut pas entrer en communication avec des blocs CIDR identiques utilisés comme adresses allouées du domaine routé. Les adresses sont dites partagées avec le VPC isolé, car ces sous-réseaux sont toujours considérés comme directement connectés. Ce trafic ne peut pas être acheminé vers la passerelle de VPC isolé. Il s'agit d'un problème de routage, pas d'un problème de NAT.

Le trafic provenant de l'espace d'adressage réutilisé du VPC isolé de nœud, de pod ou de service peut entrer en communication avec tous les autres espaces d'adressage alloués RFC 1918 du domaine routé. Une configuration avec masquage d'adresses IP iptables est appliquée sur l'interface eth0 de la passerelle de VPC isolé pour ce trafic. Étant donné que le masquage d'adresses IP utilise la NAT basée sur le port, la limite maximale est de 64 512 connexions de cluster sortantes simultanées, depuis le VPC isolé vers le domaine routé.

Ces points PEUVENT jouer un rôle dans la sélection des adresses réutilisées d'une organisation. Bien que cette solution permette le chevauchement de l'espace d'adresses IP entre les clusters GKE et l'environnement sur site, notez que les pods du cluster GKE ne pourront jamais établir de connexions sortantes vers cet espace d'adresses IP présentant un chevauchement sur site sans mettre en œuvre de solution DNS. Par conséquent, l'une des solutions suivantes est recommandée pour l'espace d'adressage IP de pod des clusters GKE :

  • Choisissez un espace d'adressage IP qui n'est pas utilisé sur site pour la taille maximale d'un seul cluster. Bien souvent, il ne doit pas nécessairement s'agir d'un espace /11, mais d'un espace /16-/19, en fonction de votre taille de cluster standard et maximale. Vous pouvez réutiliser cette adresse IP dans différents VPC isolés de différents clusters GKE.

  • Choisissez un espace d'adressage IP auquel vous savez qu'aucun cluster GKE ne devra se connecter. Comme aucune connexion à ce bloc CIDR n'est nécessaire, l'échec du routage n'a pas d'importance.

Trafic provenant du domaine routé acheminé vers le VPC isolé

Option 1 : configuration avec masquage d'adresses IP iptables

La configuration SNAT la plus simple pour ce flux de trafic consiste à utiliser le masquage d'adresses IP sur l'interface eth1 de la passerelle de VPC isolé. Étant donné que le masquage d'adresses IP utilise la NAT basée sur le port, la limite maximale est de 64 512 connexions de cluster simultanées. Cette option est recommandée.

Option 2 : configuration SNAT iptables

Si le cluster GKE du VPC isolé doit comporter plus de 64 512 connexions simultanées, vous devez disposer d'une configuration SNAT détaillée. Cette configuration doit effectuer les opérations suivantes :

  1. Traduire les flux de trafic TCP, UDP et ICMP
  2. Éviter les scénarios de partage d'adresses du VPC isolé

    Pour éviter les problèmes de partage d'adresses, les plages CIDR allouées du domaine routé qui sont également des adresses réutilisées du VPC isolé doivent être traduites au niveau de la source en adresses réutilisées du domaine routé. La figure 3 est une représentation graphique de la façon dont se produit le partage d'adresses.

    Adresse réutilisée du domaine routé. (Pour obtenir une version PDF lisible, cliquez sur l'image.)
    Figure 3. Adresse réutilisée du domaine routé. (Pour obtenir une version PDF lisible, cliquez sur l'image.)

    Le problème réside dans le fait que l'adresse du domaine routé 10.0.0.2 est considérée comme appartenant à l'espace d'adressage de pod 10.0.0.0/11 dans le VPC isolé.

    1. Dans la figure 3, le trafic quitte le nœud Host1 destiné au nœud Host2 avec l'adresse source 10.0.0.2.
    2. Le paquet entre dans le nœud Host2 dans le VPC isolé comme prévu et est traité, mais il fait ensuite l'objet d'un processus de black-holing, soit l'envoi dans un trou noir, et est partagé avec le VPC isolé.
    3. Le paquet en réponse avec l'adresse de destination 10.0.0.2 est acheminé à tort vers une adresse de pod sur le nœud Host3, car la décision de routage sur le nœud Host2 considère le réseau comme local. Pour éviter ce problème, les adresses allouées du domaine routé doivent toutes être traduites en un autre bloc CIDR : un bloc d'adresses réutilisées du domaine routé.

      Cette exigence s'applique pour les blocs CIDR de nœud, de pod et de service. La colonne Adresses réutilisées du domaine routé dans le tableau 1 répertorie les blocs CIDR à utiliser dans la configuration iptables.

  3. Éviter les scénarios de reflet du port source

    Dans le domaine routé, le reflet du port source se produit lorsque deux machines sources avec la même adresse IP génèrent le même numéro de port source. Ce problème peut survenir lorsque deux machines présentent des blocs CIDR qui se chevauchent en raison de blocs d'adresses réutilisées et allouées du domaine routé. Dans ce scénario, si des machines avec des adresses associées choisissent le même port source, une seule de ces machines reçoit le trafic de réponse. Le reflet du port source se produit rarement et de manière occasionnelle. Aux étapes 1 et 2 de la figure 4, les paquets initiaux présentent deux adresses IP sources différentes, mais le même numéro de port source.

    Requête avec reflet du port source. (Pour obtenir une version PDF lisible, cliquez sur l'image.)
    Figure 4. Requête avec reflet du port source. (Pour obtenir une version PDF lisible, cliquez sur l'image.)

    Comme prévu, lorsque les hôtes du domaine routé 10.160.0.2 et 10.0.0.2 initialisent le trafic TCP ou UDP, les données sont acheminées vers la même adresse d'équilibreur de charge interne dans le VPC isolé. Si les deux hôtes sélectionnent le même port source, par exemple 2005, une cascade d'échecs commence :

    1. Dans la figure 4, l'adresse 10.160.0.2 n'est pas traduite au niveau de la source, car elle est acheminée via la passerelle.
    2. Si l'adresse 10.0.0.2 est traduite au niveau de la source en adresse réutilisée du domaine routé 10.160.0.2, une entrée de table de connexion est créée sur la passerelle de VPC isolé en utilisant le numéro de protocole, l'adresse source, le port source, l'adresse de destination et le port de destination.
    3. À l'étape 3, le premier aspect problématique survient. Les deux flux de paquets semblent maintenant provenir de la même machine du domaine routé, interrompant ainsi les flux de trafic TCP et UDP.

      La figure 5 est une représentation graphique des paquets renvoyés.

      Requête avec reflet du port source. (Pour obtenir une version PDF lisible, cliquez sur l'image.)
      Figure 5. Réponse avec reflet du port source. (Pour obtenir une version PDF lisible, cliquez sur l'image.)

    À l'étape 1 de la figure 5, le trafic de destination renvoyé, avec des numéros de protocole, des adresses sources, des ports sources, des adresses de destination et des ports de destination identiques, est maintenant haché dans la même entrée de connexion et traduit au niveau de la destination en adresse 10.0.0.2. À l'étape 2, vous pouvez voir comment le trafic destiné à 10.160.0.2 est placé dans un trou noir.

    La solution à ce problème consiste à verrouiller différentes plages de ports sources en plages CIDR sources dans la configuration SNAT. En d'autres termes, vous traduisez les ports sources pour les espaces 10.0.0.0/11 et 10.160.0.0/11. Le tableau 2 récapitule les blocs CIDR traduits en plages de ports sources à utiliser.

    Adresses allouées du domaine routé Type d'adresse Plage de ports sources
    10.160.0.0/11 Adresses réutilisées du domaine routé (10.160.0.2) 1024-33,279
    10.0.0.0/11 Adresses réutilisées du VPC isolé (10.0.0.2) 33280-65535

    Tableau 2. Blocs CIDR SNAT.

Pour l'essentiel, les blocs CIDR utilisés comme adresses réutilisées du domaine routé sont traduits en plage de ports 1024-33,279. Les blocs CIDR utilisés comme adresses réutilisées du VPC isolé sont traduits en plage 33280-65535.

Le trafic ICMP n'est pas sujet au reflet du port source. La valeur d'en-tête d'ID ICMP est utilisée dans le hachage de la table de connexion et crée donc une entrée de table de connexion pour chaque échange ICMP.

Équilibrage de charge

Par l'intermédiaire du fichier de configuration de service GKE, vous rendez vos adresses IP de service disponibles pour le domaine routé via des adresses IPv4 d'équilibreur de charge interne.

Les adresses d'équilibrage de charge interne sont sélectionnées dans la plage CIDR IPv4 de nœud attribuée au sous-réseau principal du VPC isolé. Un bloc d'adresses compris dans la plage d'adresses principale du sous-réseau doit être alloué pour les adresses d'équilibreur de charge interne. Ces adresses peuvent être contiguës ou bien constituer un ensemble de blocs CIDR alloués plus petits. Dans ce dernier cas, vous devez configurer une route statique correspondante dans le VPC partagé qui dirige le trafic vers le VPC isolé. La passerelle de VPC isolé doit être spécifiée comme adresse de saut suivant pour cette route.

Dans le VPC partagé, vous ne devez pas configurer de sous-réseaux avec un bloc CIDR contenant la plage d'adresses allouées du VPC isolé d'équilibreur de charge interne. Par exemple, si le sous-réseau 10.32.0.0/19 existe dans le VPC partagé, la création de la route statique 10.32.224.0/20 échoue, car cette route est un sous-réseau plus petit de 10.32.0.0/19. Cette configuration constitue une violation des règles de création de sous-réseaux dans le VPC.

Autres problèmes

Effectuer le scaling de la bande passante et des ressources grâce au routage multi-chemins à coût égal (ECMP, Equal-Cost Multi-Path)

Lorsque l'application du cluster GKE commence à épuiser la bande passante, le processeur ou la mémoire des passerelles de VPC isolé, vous pouvez ajouter d'autres passerelles en tenant compte des points suivants.

VPC partagé

  • Pour chaque bloc d'adresses d'équilibreur de charge interne alloué du VPC isolé ayant une adresse de saut suivant de l'interface eth0 sur la nouvelle passerelle, vous devez ajouter une route statique supplémentaire.
  • La priorité des nouvelles routes doit être égale à celle des routes d'origine pour que la stratégie ECMP s'applique.
  • Les nouvelles routes statiques restent dans la table de routage tant que la passerelle de VPC associée est opérationnelle. En cas de problème avec la configuration NAT, tout le trafic envoyé à la VM problématique est supprimé. Vous pouvez ajouter une vérification de l'état pour vous assurer que la NAT fonctionne correctement.

Passerelle de VPC isolé

  • Réservez une nouvelle adresse IPv4 dans le sous-réseau du VPC partagé pour l'interface eth0.
  • Réservez une nouvelle adresse IPv4 dans le sous-réseau du VPC isolé pour l'interface eth1.
  • Si vous choisissez l'option de masquage d'adresses IP iptables pour la configuration SNAT, aucune étape supplémentaire n'est nécessaire.
  • Si vous choisissez l'option SNAT iptables, vous devez modifier la configuration SNAT sur la passerelle de VPC isolé d'origine. La configuration SNAT de toutes les passerelles doit garantir que ces passerelles n'effectuent pas de traduction dans les mêmes combinaisons "adresse:port". Par exemple, cela peut se produire si une passerelle de VPC isolé traduit au niveau de la source 10.0.0.0/11 en 10.160.0.0/11, et qu'une nouvelle passerelle est ajoutée à la conception. Avec la nouvelle configuration, la première passerelle traduirait 10.0.0.0/11 en 10.160.0.0/12, et la seconde passerelle traduirait 10.0.0.0/11 en 10.176.0.0/12.

VPC isolé

  • Vous devez ajouter trois routes aux adresses RFC 1918 allouées du domaine routé. L'adresse de saut suivant doit être définie sur l'interface eth1 de la nouvelle passerelle.
  • La priorité des nouvelles routes doit être égale à celle des routes d'origine pour que la stratégie ECMP s'applique.

Lorsqu'un nouveau cluster est requis pour l'organisation, vous pouvez ajouter soit un projet de service, soit un hôte et un projet de service. Vous pouvez mettre en œuvre la solution de manière systématique en réutilisant toutes les adresses du VPC isolé. Veillez simplement à attribuer des blocs CIDR qui ne se chevauchent pas pour les différentes adresses allouées d'équilibreur de charge interne du VPC isolé.

Informations complémentaires

Lorsque vous configurez votre projet, tenez compte des points abordés dans les sections suivantes.

IAM

Passez en revue les procédures et rôles IAM suivants, et attribuez-les de manière appropriée au sein de votre organisation :

Coût

Une fois que vous avez activé la facturation pour le projet, la solution entraîne les coûts ci-après, dont le montant exact dépend de la mise en œuvre :

Vous pouvez utiliser le Simulateur de coût pour vous aider à estimer les coûts.

Quotas et limites

Tenez compte des limites et quotas suivants :

API

Mettez en œuvre les API et les paramètres suivants pour cette solution :

Sécurité

Nous vous recommandons de discuter des points de sécurité suivants avec votre équipe chargée du réseau et de la sécurité :

  • Étant donné qu'une mauvaise configuration des scénarios de réutilisation des adresses peut occasionner des pannes de réseau, configurez l'automatisation et des alias d'adresse e-mail tels que ipv4addrspaceviolation@example.com et ipv4routingviolation@example.com pour être averti en cas de problème.
  • Assurez-vous que les configurations IAM de VPC partagé appropriées sont en place.
  • Assurez-vous que les configurations IAM d'administrateur de réseaux appropriées pour les routes et les règles de pare-feu sont mises en œuvre. Pour en savoir plus, consultez la documentation sur le VPC.
  • Vérifiez qu'aucune connexion VPN ou Cloud Interconnect depuis les emplacements sur site n'est établie vers le VPC isolé.
  • Effectuez le suivi des traductions NAT pour toute analyse de données ultérieure.
  • Examinez toute connexion externe à Internet depuis le VPC isolé afin de vous assurer que les règles de pare-feu respectent les normes établies.
  • Examinez les règles de pare-feu de cette solution avant de les appliquer en production.

Surveillance

Nous vous recommandons de discuter des points de surveillance suivants avec votre équipe chargée de la gestion de réseau :

  • Surveillez le débit de la passerelle de VPC isolé afin de pouvoir détecter l'épuisement de la bande passante et procéder à une analyse comparative des coûts.
  • Surveillez l'utilisation de la mémoire et du processeur pour la ou les passerelles de VPC isolé.
  • Surveillez l'utilisation de la fonctionnalité NAT sur les passerelles de VPC isolé afin de pouvoir détecter l'épuisement de l'espace et procéder au suivi des requêtes des utilisateurs finaux.
  • Créez un tableau de bord de suivi des quotas dans Cloud Monitoring.
  • Créez un tableau de bord Cloud Monitoring qui effectue le suivi des variables importantes pour votre entreprise et votre application.
  • Installez les outils conntrack et tcpdump sur la passerelle de VPC isolé à des fins de dépannage et de diagnostic.

Étapes suivantes