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

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

Cette série comprend les parties suivantes :

Ce tutoriel s'adresse aux architectes réseau qui rencontrent des difficultés pour allouer des adresses IPv4 RFC 1918 aux pods, nœuds et services GKE en raison de l'épuisement ou de la fragmentation de l'espace d'adressage privé. Il présente une solution qui vous permet de procéder à l'installation complète de GKE à l'aide de la fonctionnalité NAT et de la réutilisation stratégique des blocs CIDR RFC 1918 déjà attribués au sein de votre organisation. Cette solution consiste ensuite à automatiser la compilation de l'infrastructure à l'aide de l'outil Terraform et à utiliser le SDK Cloud pour inspecter les composants individuels présentés dans le schéma suivant.

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

En règle générale, il s'agit de configurer un projet hôte, un projet de service, un VPC partagé et une VM Compute Engine, qui constitue la passerelle de VPC isolé. Toutefois, vous pouvez également configurer des routes statiques, des règles de pare-feu et des API appropriées. Pour en savoir plus sur la solution globale et ses composants individuels, consultez la page Fonctionnalité NAT pour tous les blocs CIDR de GKE.

Dans ce tutoriel, nous partons du principe que vous connaissez bien les éléments suivants :

  • Commandes sysadmin Linux
  • GKE
  • Compute Engine
  • VPC partagés
  • NAT
  • Terraform

Objectifs

  • Configurer un projet hôte avec un VPC partagé appelé "VPC de domaine routé".
  • Configurer un projet de service avec un VPC appelé "VPC isolé".
  • Configurer la VM de passerelle VPC isolé.
  • Configurer le routage entre les réseaux VPC via la passerelle de VPC isolé.
  • Configurer la fonctionnalité NAT sur la passerelle de VPC isolé.

Coûts

Ce tutoriel utilise les composants facturables suivants de Google Cloud :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous avez terminé ce tutoriel, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Consultez la page Effectuer un nettoyage pour en savoir plus.

Avant de commencer

Dans cette section, vous allez préparer Cloud Shell, configurer vos variables d'environnement et déployer l'infrastructure de soutien.

Préparer Cloud Shell

  1. Dans Google Cloud Console, ouvrez Cloud Shell.

    Accéder à Cloud Shell

    La majeure partie de ce tutoriel se fait à partir du terminal Cloud Shell, à l'aide de l'outil Terraform de HashiCorp et du SDK Cloud.

  2. Dans Cloud Shell, clonez le dépôt GitHub et accédez au répertoire local :

    git clone https://github.com/GoogleCloudPlatform/terraform-gke-nat-connectivity.git kam
    cd kam/allnat
    

    Le dépôt contient tous les fichiers dont vous avez besoin pour suivre ce tutoriel. Pour obtenir une description complète de chaque fichier, consultez le fichier README.md dans le dépôt.

  3. Rendez tous les scripts shell exécutables :

    sudo chmod 755 *.sh
    
  4. Installez Terraform.

  5. Initialisez Terraform :

    terraform init
    

    Le résultat ressemble à ce qui suit :

    ...
    Initializing provider plugins...
    The following providers do not have any version constraints in configuration, so the latest version was installed.
    
    To prevent automatic upgrades to new major versions that may contain breaking changes, it is recommended to add version = "..." constraints to the corresponding provider blocks in configuration, with the constraint strings suggested below.
    
    ∗ provider.google: version = "~> 2.5"
    
    Terraform has been successfully initialized!
    
    You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure. All Terraform commands should now work.
    
    If you ever set or change modules or backend configuration for Terraform, rerun this command to reinitialize your working directory. If you forget, other commands will detect it and remind you to do so if necessary.
    ...
    

Définir des variables d'environnement

  1. Dans Cloud Shell, définissez et vérifiez la variable TF_VAR_org_id, en remplaçant your-organization-name par le nom de l'organisation Google Cloud que vous souhaitez utiliser dans ce tutoriel :

    export TF_VAR_org_id=$(gcloud organizations list | \
        awk '/your-organization-name/ {print $2}')
    
  2. Validez la définition de la variable d'environnement :

    echo $TF_VAR_org_id
    

    Le résultat affiche l'ID numérique de votre organisation et se présente comme suit :

    ...
    123123123123
    ...
    
  3. Définissez les variables d'environnement restantes en exécutant la commande shell suivante depuis le dépôt :

    source set_variables.sh
    
  4. Validez la définition des variables d'environnement :

    env | grep TF_
    

    Le résultat ressemble à ce qui suit :

    ...
    TF_VAR_isolated_net_name=isolated-vpc
    TF_VAR_isolated_pname=isolated-vpc-project
    TF_VAR_isolated_pid=isolated-vpc-project-id
    TF_VAR_shared_net_name=routed-domain-vpc
    TF_VAR_shared_pname=routed-domain-project
    TF_VAR_shared_pid=routed-domain-project-id
    TF_VAR_isolated_vpc_gw_host_nic_ip=10.97.0.2
    TF_VAR_isolated_vpc_gw_service_nic_ip=10.32.0.2
    TF_VAR_isolated_vpc_gw_service_dgw_ip=10.32.0.1
    TF_VAR_org_id=123123123123
    TF_VAR_region=us-west1
    TF_VAR_zone=us-west1-b
    TF_VAR_user_account=user@example.com
    TF_VAR_node_cidr=10.32.0.0/19
    TF_VAR_pod_cidr=10.0.0.0/11
    TF_VAR_service_cidr=10.224.0.0/20
    TF_VAR_shared_cidr=10.97.0.0/24
    TF_VAR_test1_cidr=10.0.0.0/11
    TF_VAR_test2_cidr=10.160.0.0/11
    TF_VAR_test3_cidr=10.64.0.0/19
    TF_VAR_ilb_cidr=10.32.31.0/24
    TF_VAR_masquerade=true
    ...
    
  5. Mettez à jour la variable TF_VAR_masquerade si elle n'est pas définie.

    Par défaut, ce document configure l'option de masquage d'adresses IP iptables, comme décrit dans le document conceptuel associé à ce tutoriel. Si vous souhaitez configurer l'option SNAT iptables, vous devez remplacer la variable TF_VAR_masquerade par false :

    export TF_VAR_masquerade=false
    
  6. Créez un fichier de variables d'environnement :

    env | grep TF_ | sed 's/^/export /' > TF_ENV_VARS
    

    Cette chaîne de commande redirige les variables d'environnement que vous avez créées dans un fichier appelé TF_ENV_VARS. Chaque variable est précédée de la commande export. Vous pouvez utiliser ce fichier pour réinitialiser les variables d'environnement au cas où votre session Cloud Shell prendrait fin. Ces variables sont utilisées par les scripts Terraform, les scripts d'interface système et les commandes du SDK de ce tutoriel.

    Si vous avez besoin de réinitialiser les variables, vous pouvez exécuter la commande suivante à partir du répertoire dans lequel se trouve le fichier :

    source TF_ENV_VARS
    

Déployer l'infrastructure de soutien

  • Déployez l'infrastructure Terraform dans Cloud Shell :

    terraform apply
    

    Terraform vous invite à confirmer l'opération avant de procéder à des modifications. Répondez yes pour appliquer l'une des deux configurations.

    La commande terraform apply demande à Terraform de déployer tous les composants de la solution. Pour mieux comprendre comment l'infrastructure est définie de manière déclarative, vous pouvez parcourir les fichiers manifestes Terraform, c'est-à-dire les fichiers avec l'extension .tf.

Inspecter l'infrastructure de soutien

Vous utilisez maintenant les outils de ligne de commande gcloud pour afficher et valider l'infrastructure créée par Terraform. La validation consiste à exécuter une commande pour voir si la ressource répond et a été créée correctement.

Valider les projets

  1. Dans Cloud Shell, répertoriez les deux projets :

    gcloud projects list | grep pid
    

    Le résultat ressemble à ce qui suit :

    ...
    isolated-vpc-pid       isolated-vpc-pname        777999333962
    routed-domain-pid      routed-domain-pname       777852333528
    ...
    
  2. Indiquez l'état de l'API :

    1. Pour le projet de VPC isolé :

      gcloud services list --project=$TF_VAR_isolated_vpc_pid | grep -E "compute|container"
      

      Le résultat ressemble à ce qui suit :

      ...
      compute.googleapis.com            Compute Engine API
      container.googleapis.com          Google Kubernetes Engine API
      ...
      
    2. Pour le projet de domaine routé :

      gcloud services list --project=$TF_VAR_shared_vpc_pid | grep -E "compute"
      

      Le résultat ressemble à ce qui suit :

      ...
      compute.googleapis.com            Compute Engine API
      ...
      
  3. Répertoriez l'état du VPC partagé :

    gcloud compute shared-vpc organizations list-host-projects $TF_VAR_org_id
    gcloud compute shared-vpc get-host-project $TF_VAR_isolated_vpc_pid
    gcloud compute shared-vpc list-associated-resources $TF_VAR_shared_vpc_pid
    

    Le résultat ressemble à ce qui suit :

    ...
    NAME                 CREATION_TIMESTAMP  XPN_PROJECT_STATUS
    svpc-pid--210756488
    ...
    kind: compute#project
    name: svpc-pid--210756488
    ...
    RESOURCE_ID          RESOURCE_TYPE
    ivpc-pid--695116665  PROJECT
    ...
    

Valider les réseaux et les sous-réseaux

  1. Dans Cloud Shell, validez les réseaux et les sous-réseaux du VPC isolé :

    gcloud compute networks describe $TF_VAR_isolated_net_name \
      --project=$TF_VAR_isolated_vpc_pid
    
    gcloud compute networks subnets describe node-cidr \
      --project=$TF_VAR_isolated_vpc_pid \
      --region=$TF_VAR_region
    

    Le résultat ressemble à ce qui suit :

    ...
    kind: compute#network
    name: isolated-vpc-net
    routingConfig:
      routingMode: GLOBAL
    ...
    subnetworks:
    ‐ https://www.googleapis.com/compute/v1/projects/ivpc-pid--695116665/regions/us-west1/subnetworks/node-cidr
    x_gcloud_bgp_routing_mode: GLOBAL
    ...
    gatewayAddress: 10.32.0.1
    ipCidrRange: 10.32.0.0/19
    kind: compute#subnetwork
    name: node-cidr
    ...
    secondaryIpRanges:
    ‐ ipCidrRange: 10.0.0.0/11
      rangeName: pod-cidr
    ...
    
  2. Vérifiez les réseaux et les sous-réseaux du VPC de domaine routé :

    gcloud compute networks describe $TF_VAR_shared_net_name \
        --project=$TF_VAR_shared_vpc_pid
    
    gcloud compute networks subnets describe shared-cidr \
        --project=$TF_VAR_shared_vpc_pid \
        --region=$TF_VAR_region
    
    gcloud compute networks subnets list $TF_VAR_shared_net_name \
        --project=$TF_VAR_shared_vpc_pid
    

    Le résultat ressemble à ce qui suit :

    ...
    kind: compute#network
    name: routed-domain-vpc-net
    routingConfig:
      routingMode: GLOBAL
    ...
    subnetworks:
    ‐ https://www.googleapis.com/compute/v1/projects/svpc-pid--210756488/regions/us-west1/subnetworks/shared-cidr
    x_gcloud_bgp_routing_mode: GLOBAL
    ...
    gatewayAddress: 10.97.0.1
    ...
    ipCidrRange: 10.97.0.0/24
    kind: compute#subnetwork
    name: shared-cidr
    ...
    region: https://www.googleapis.com/compute/v1/projects/svpc-pid--210756488/regions/us-west1
    ...
    NAME            REGION         NETWORK                RANGE
    ...
    test-10-11      us-west1       routed-domain-vpc-net  10.0.0.0/11
    test-10-160-11  us-west1       routed-domain-vpc-net  10.160.0.0/11
    test-10-64-19   us-west1       routed-domain-vpc-net  10.64.0.0/19
    ...
    

Vérifier les règles de pare-feu

  • Dans Cloud Shell, vérifiez les règles de pare-feu dans les deux VPC :

    gcloud compute firewall-rules list --project=$TF_VAR_isolated_vpc_pid
    gcloud compute firewall-rules list --project=$TF_VAR_shared_vpc_pid
    

    Le résultat ressemble à ce qui suit :

    ...
    NAME                  NETWORK           DIRECTION  PRIORITY  ALLOW  DENY  DISABLED
    allow-rfc1918-in-fwr  isolated-vpc-net  INGRESS    1000      all          False
    allow-ssh-in-fwr      isolated-vpc-net  INGRESS    1000      22           False
    ...
    NAME                  NETWORK           DIRECTION  PRIORITY  ALLOW  DENY  DISABLED
    allow-rfc1918-in-fwr  routed-domain-vpc-net  INGRESS 1000    all          False
    allow-ssh-in-fwr      routed-domain-vpc-net  INGRESS 1000    22           False
    ...
    

Vérifier les machines de test

  • Dans Cloud Shell, vérifiez les machines de test :

    gcloud compute instances list --project=$TF_VAR_shared_vpc_pid
    

    Le résultat ressemble à ce qui suit :

    ...
    NAME               ZONE        MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP     STATUS
    test-10-11-vm      us-west1-b  n1-standard-1               10.0.0.2     192.0.2.1       RUNNING
    test-10-160-11-vm  us-west1-b  n1-standard-1               10.160.0.2   192.0.2.2       RUNNING
    test-10-64-19-vm   us-west1-b  n1-standard-1               10.64.0.2    192.0.2.3       RUNNING
    ...
    

Vérifier la passerelle VPC isolée

  1. Dans Cloud Shell, vérifiez l'instance :

    gcloud compute instances describe isolated-vpc-gw \
        --project=$TF_VAR_isolated_vpc_pid \
        --zone $TF_VAR_zone
    

    Le résultat ressemble à ce qui suit :

    ...
    metadata:
      fingerprint: e_P00DAAAAA=
      items:
      ‐ key: startup-script
        value: |+
          #! /bin/bash
          #Enable packet forwarding
          sudo sysctl -w net.ipv4.ip_forward=1
    ...
    name: isolated-vpc-gw
    networkInterfaces:
    ‐ accessConfigs:
      ‐ kind: compute#accessConfig
        name: external-nat
        natIP: 192.0.2.76
    ...
      networkIP: 10.97.0.12
    ...
      networkIP: 10.32.0.15
    ...
    tags:
      fingerprint: FOrvKltVVVV=
      items:
      ‐ allow-rfc1918-in-fwr
      ‐ allow-ssh-in-fwr
      ‐ isolated-vpc-allocated-ilb-route
    ...
    
  2. Connectez-vous à la passerelle de VPC isolé à l'aide de SSH :

    gcloud compute ssh isolated-vpc-gw \
        --project=$TF_VAR_isolated_vpc_pid \
        --zone $TF_VAR_zone
    
  3. Dans l'instance, vérifiez l'existence des éléments suivants :

    • La table de routage du domaine routé
    • Les règles de sécurité qui dirigent le trafic lié au domaine routé vers la table de routage qui lui est associée
    • Les routes statiques de la table de routage qui dirigent le trafic vers le domaine routé
    sudo sysctl net.ipv4.ip_forward
    cat /etc/iproute2/rt_tables | grep routed-domain
    ip rule show
    ip route show table routed-domain
    

    Le résultat ressemble à ce qui suit :

    ....
    net.ipv4.ip_forward = 1
    ....
    routed-domain
    100 routed-domain
    ....
    0:      from all lookup local
    32763:  from all to 192.168.0.0/16 lookup routed-domain
    32764:  from all to 172.16.0.0/12 lookup routed-domain
    32765:  from all to 10.0.0.0/8 lookup routed-domain
    32766:  from all lookup main
    32767:  from all lookup default
    ....
    10.0.0.0/8 via 10.97.0.1 dev eth0
    10.32.31.0/24 via 10.32.0.1 dev eth1
    172.16.0.0/12 via 10.97.0.1 dev eth0
    192.168.0.0/16 via 10.97.0.1 dev eth0
    ....
    
  4. Vérifiez la configuration NAT iptables :

    sudo iptables -t nat -L -v
    

    En ce qui concerne la configuration de masquage d'adresses IP iptables, le résultat ressemble à ce qui suit :

    ...
    Chain PREROUTING (policy ACCEPT 1 packets, 60 bytes)
     pkts bytes target     prot opt in     out     source               destination
    
    Chain INPUT (policy ACCEPT 1 packets, 60 bytes)
     pkts bytes target     prot opt in     out     source               destination
    
    Chain OUTPUT (policy ACCEPT 24 packets, 1525 bytes)
     pkts bytes target     prot opt in     out     source               destination
    
    Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
       24  1525 MASQUERADE  all  --  any    eth0    anywhere             anywhere
        0     0 MASQUERADE  all  --  any    eth1    anywhere             anywhere
    ...
    

    En ce qui concerne l'option SNAT iptables, le résultat ressemble à ce qui suit :

    ...
    Chain PREROUTING (policy ACCEPT 1 packets, 60 bytes)
     pkts bytes target     prot opt in     out     source               destination
    
    Chain INPUT (policy ACCEPT 1 packets, 60 bytes)
     pkts bytes target     prot opt in     out     source               destination
    
    Chain OUTPUT (policy ACCEPT 21 packets, 1345 bytes)
     pkts bytes target     prot opt in     out     source               destination
    
    Chain POSTROUTING (policy ACCEPT 21 packets, 1345 bytes)
     pkts bytes target     prot opt in     out     source               destination
        0     0 SNAT       tcp  --  any    eth1    10.160.0.0/11        anywhere             to:10.160.0.0-10.191.255.255:1024-33279
        0     0 SNAT       tcp  --  any    eth1    10.0.0.0/11          anywhere             to:10.160.0.0-10.191.255.255:33280-65535
        0     0 SNAT       tcp  --  any    eth1    10.64.0.0/19         anywhere             to:10.64.0.0-10.64.31.255:1024-33279
        0     0 SNAT       tcp  --  any    eth1    10.32.0.0/19         anywhere             to:10.64.0.0-10.64.31.255:33280-65535
        0     0 SNAT       udp  --  any    eth1    10.160.0.0/11        anywhere             to:10.160.0.0-10.191.255.255:1024-33279
        0     0 SNAT       udp  --  any    eth1    10.0.0.0/11          anywhere             to:10.160.0.0-10.191.255.255:33280-65535
        0     0 SNAT       udp  --  any    eth1    10.64.0.0/19         anywhere             to:10.64.0.0-10.64.31.255:1024-33279
        0     0 SNAT       udp  --  any    eth1    10.32.0.0/19         anywhere             to:10.64.0.0-10.64.31.255:33280-65535
        0     0 SNAT       icmp --  any    eth1    10.160.0.0/11        anywhere             to:10.160.0.0-10.191.255.255
        0     0 SNAT       icmp --  any    eth1    10.0.0.0/11          anywhere             to:10.160.0.0-10.191.255.255
        0     0 SNAT       icmp --  any    eth1    10.64.0.0/19         anywhere             to:10.64.0.0-10.64.31.255
        0     0 SNAT       icmp --  any    eth1    10.32.0.0/19         anywhere             to:10.64.0.0-10.64.31.255
    ...
    

Vérifier le cluster GKE

  • Dans Cloud Shell, vérifiez le cluster GKE :

    gcloud container clusters list \
        --project=$TF_VAR_isolated_vpc_pid \
        --zone=$TF_VAR_zone
    

    Le résultat ressemble à ce qui suit :

    ...
    NAME     LOCATION    MASTER_VERSION MASTER_IP   MACHINE_TYPE   NODE_VERSION  NUM_NODES  STATUS
    cluster1 us-west1-b  1.11.8-gke.6   192.0.2.58  n1-standard-1  1.11.8-gke.6  3          RUNNING
    ...
    

Vérifier le routage entre les réseaux VPC

  1. Dans Cloud Shell, vérifiez le routage inter-VPC pour le VPC partagé :

    gcloud compute routes list \
        --filter=name="('ivpc-allocated-ilb-route')" \
        --project=$TF_VAR_shared_vpc_pid
    

    Le résultat ressemble à ce qui suit :

    NAME                      NETWORK                DEST_RANGE     NEXT_HOP   PRIORITY
    ivpc-allocated-ilb-route  routed-domain-vpc-net  10.32.31.0/24  10.97.0.2  1000
    
  2. Vérifiez le routage inter-VPC pour le VPC isolé :

    gcloud compute routes list --project=$TF_VAR_isolated_vpc_pid
    

    Le résultat ressemble à ce qui suit :

    ...
    NAME                            NETWORK           DEST_RANGE      NEXT_HOP  PRIORITY
    ivpc-to-10net                   isolated-vpc-net  10.0.0.0/8      10.32.0.2 1000
    ivpc-to-172-16net               isolated-vpc-net  172.16.0.0/12   10.32.0.2 1000
    ivpc-to-192-168net              isolated-vpc-net  192.168.0.0/16  10.32.0.2 1000
    ...
    

Valider l'application Hello World

Dans cette section, vous obtenez les identifiants du cluster et vous validez le service hello-server.

  1. Dans Cloud Shell, obtenez les identifiants du cluster :

    gcloud container clusters get-credentials cluster1 \
       --project=$TF_VAR_isolated_vpc_pid \
       --zone $TF_VAR_zone
    

    Le résultat ressemble à ce qui suit :

    ...
    Fetching cluster endpoint and auth data.
    kubeconfig entry generated for cluster1.
    ...
    
  2. Vérifiez le service hello-server :

    kubectl get service hello-server
    

    Le résultat ressemble à ce qui suit :

    ...
    NAME           TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
    hello-server   LoadBalancer   10.224.7.87   <pending>     8080:30635/TCP   3m
    ...
    

Valider la solution

Dans cette section, vous configurez la surveillance sur la passerelle de VPC isolé et vous testez l'application.

Configurer la surveillance sur la passerelle de VPC isolé

  1. Dans Cloud Shell, connectez-vous à la passerelle de VPC isolé à l'aide de SSH :

    gcloud compute ssh isolated-vpc-gw \
        --project=$TF_VAR_isolated_vpc_pid \
        --zone=$TF_VAR_zone
    
  2. Dans l'instance, exécutez l'utilitaire tcpdump :

    sudo tcpdump -n -i eth1 host 10.32.31.1
    

    Le résultat ressemble à ce qui suit :

    ...
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
    ...
    

    Cette commande démarre l'utilitaire tcpdump pour capturer les paquets qui traversent la passerelle de VPC isolé. L'utilitaire ne capture que les paquets qui contiennent l'adresse IP de l'équilibreur de charge interne créé par le service GKE.

Tester l'application

  1. Ouvrez une nouvelle instance de Cloud Shell.

    Ouvrir Cloud Shell

  2. Connectez-vous via ssh à l'instance Compute Engine test-10-11-vm. Ensuite, dans la nouvelle instance, accédez au répertoire du dépôt Git :

    source TF_ENV_VARS
    gcloud compute ssh test-10-11-vm \
       --project=$TF_VAR_shared_vpc_pid \
       --zone=$TF_VAR_zone
    
  3. Dans la nouvelle instance, connectez-vous à la nouvelle application via la commande curl :

    curl http://10.32.31.1:8080/
    

    Cette commande récupère la page Web à partir de l'application exécutée sur le cluster GKE. Le résultat ressemble à ce qui suit :

    ...
    Hello, world!
    Version: 1.0.0
    Hostname: my-app-6597cdc789-d6phf
    ...
    

    Dans le terminal Cloud Shell d'origine, lorsque vous validez la passerelle de VPC isolé, le résultat ressemble à ce qui suit :

    ...
    17:45:32.674129 IP 10.32.0.2.56698 > 10.32.31.1.8080: Flags [S], seq 2205959832, win 28400, options [mss 1420,sackOK,TS val 296564 ecr 0,nop,wscale 7], length 0
    17:45:32.678253 IP 10.32.31.1.8080 > 10.32.0.2.56698: Flags [S.], seq 4243326926, ack 2205959833, win 28160, options [mss 1420,sackOK,TS val 632036963 ecr 296564,nop,wscale 7], length 0
    17:45:32.678982 IP 10.32.0.2.56698 > 10.32.31.1.8080: Flags [.], ack 1, win 222, options [nop,nop,TS val 296565 ecr 632036963], length 0
    17:45:32.678995 IP 10.32.0.2.56698 > 10.32.31.1.8080: Flags [P.], seq 1:80, ack 1, win 222, options [nop,nop,TS val 296565 ecr 632036963], length 79: HTTP: GET / HTTP/1.1
    17:45:32.679411 IP 10.32.31.1.8080 > 10.32.0.2.56698: Flags [.], ack 80, win 220, options [nop,nop,TS val 632036965 ecr 296565], length 0
    17:45:32.679904 IP 10.32.31.1.8080 > 10.32.0.2.56698: Flags [P.], seq 1:181, ack 80, win 220, options [nop,nop,TS val 632036965 ecr 296565], length 180: HTTP: HTTP/1.1 200 OK
    17:45:32.680032 IP 10.32.0.2.56698 > 10.32.31.1.8080: Flags [.], ack 181, win 231, options [nop,nop,TS val 296565 ecr 632036965], length 0
    ...
    

    Il s'agit d'une capture de paquets renvoyée par la commande curl que vous venez d'exécuter.

  4. Dans la première instance Cloud Shell, appuyez sur Control+C pour arrêter l'affichage de tcpdump.

  5. Dans cette même instance, inspectez la table de connexion sur la passerelle de VPC isolé :

    sudo conntrack -L | grep 10.32.31.49
    

    En ce qui concerne l'option de masquage d'adresses IP iptables, le résultat ressemble à ce qui suit :

    ...
    tcp      6 118 TIME_WAIT src=10.0.0.2 dst=10.32.31.1 sport=56760 dport=8080 src=10.32.31.1 dst=10.32.0.2 sport=8080 dport=56760 [ASSURED] mark=0 use=1
    ...
    

    Cette commande affiche les entrées NAT sources créées dans la table de connexion à partir de la capture de paquets renvoyée à l'étape précédente. src=10.0.0.2 a été traduit par dst=10.32.0.2. L'option SNAT iptables renverra un résultat semblable.

  6. Réexécutez l'intégralité de cette section de test en remplaçant test-10-160-11-vm et test-10-64-19-vm par test-10-11-vm.

Effectuer un nettoyage

Détruire l'infrastructure

  1. À partir du premier terminal Cloud Shell, fermez la session SSH sur la passerelle de VPC isolé :

    exit
    
  2. Détruisez la configuration Terraform :

    terraform destroy
    

    Terraform vous invite à confirmer l'opération avant de procéder à la modification. Répondez yes pour détruire la configuration et tous les composants du tutoriel.

    Vous constatez peut-être l'affichage de l'erreur Terraform suivante :

    ...
    ∗ google_compute_shared_vpc_host_project.host (destroy): 1 error(s) occurred:
    ∗ google_compute_shared_vpc_host_project.host: Error disabling Shared VPC Host "svpc-pid--23156887": googleapi: Error 400: Cannot disable project as a shared VPC host because it has active service projects., badRequest
    ...
    

    Cette erreur se produit si vous tentez de détruire le VPC partagé avant de détruire la passerelle de VPC isolé.

  3. Poursuivez le nettoyage :

    gcloud compute shared-vpc associated-projects remove $TF_VAR_isolated_vpc_pid \
        --host-project=$TF_VAR_shared_vpc_pid
    
    gcloud compute shared-vpc disable $TF_VAR_shared_vpc_pid
    

    Vous constatez peut-être l'affichage de l'erreur Terraform suivante :

    ...
    ∗ google_compute_network.ivpc (destroy): 1 error(s) occurred:
    ∗ google_compute_network.ivpc: Error waiting for Deleting Network: The network resource 'projects/ivpc-pid--1058675427/global/networks/isolated-vpc-net' is already being used by 'projects/ivpc-pid--1058675427/global/firewalls/k8s-05693142c93de80e-node-hc'
    ...
    

    Cette erreur se produit si vous tentez de détruire le réseau VPC isolé avant de supprimer les règles de pare-feu GKE.

  4. Terminez le nettoyage en supprimant les règles de pare-feu du VPC isolé autres que celles par défaut :

    ./k8-fwr.sh
    

    Le résultat indique les règles de pare-feu à supprimer.

  5. Vérifiez les règles et, lorsque vous y êtes invité, saisissez yes.

  6. Depuis le premier terminal Cloud Shell, renvoyez la commande suivante :

    terraform destroy
    

    Terraform vous invite à confirmer l'opération avant de procéder à la modification. Répondez yes pour détruire la configuration.

  7. Supprimez les fichiers créés au cours de ce tutoriel :

    rm -rf .git
    rm -rf .terr*
    rm*
    cd ..
    rm -rf kam
    

Étape suivante