Gerenciamento de endereços do GKE: como configurar a NAT para todos os blocos CIDR do GKE

Este tutorial faz parte de uma série destinada a arquitetos de rede. A série discute as opções de gerenciamento de endereços do Google Kubernetes Engine (GKE) disponíveis para organizações restritas a endereços IPv4.

A série consiste nas partes a seguir:

Este tutorial destina-se a arquitetos de rede que estejam enfrentando dificuldades para alocar endereços IPv4 RFC 1918 para pods, nós e serviços do GKE devido ao esgotamento ou à fragmentação do espaço de endereço privado. No tutorial, detalhamos uma solução que permite a instalação completa do GKE por meio da NAT e a reutilização estratégica dos blocos CIDR RFC 1918 já atribuídos na sua organização. Em seguida, use o Terraform para automatizar a criação da infraestrutura e utilize o SDK do Cloud para examinar os componentes específicos mostrados no diagrama a seguir.

Reutilização de endereços RFC 1918 com o GKE. Para uma versão em PDF legível em telas, clique na imagem.
Figura 1. Reutilização de endereços RFC 1918 com o GKE. Para uma versão em PDF legível na tela, clique na imagem.

De modo geral, você configura um projeto host, um projeto de serviço, uma VPC compartilhada e uma VM do Compute Engine conhecida como gateway da VPC isolada. Você também define as rotas estáticas, regras de firewall e APIs relevantes. Para uma discussão mais aprofundada sobre a solução geral e os componentes específicos, consulte NAT para todos os blocos CIDR do GKE.

Neste tutorial, presume-se que você tem familiaridade com o seguinte:

  • Comandos sysadmin do Linux
  • GKE
  • Compute Engine
  • VPCs compartilhadas
  • NAT
  • Terraform

Objetivos

  • Configure um projeto host com uma VPC compartilhada chamada VPC de domínio roteado.
  • Defina um projeto de serviço com uma VPC conhecida como VPC isolada.
  • Configure a VM do gateway da VPC isolada.
  • Defina o roteamento nas VPCs por meio do gateway da VPC isolada.
  • Configure a NAT no gateway da VPC isolada.

Custos

Neste tutorial, usamos os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem ser qualificados para uma avaliação gratuita.

Ao concluir este tutorial, exclua os recursos criados para evitar o faturamento contínuo. Para mais informações, consulte Como fazer a limpeza.

Antes de começar

Nesta seção, você prepara o Cloud Shell, configura suas variáveis de ambiente e implanta a infraestrutura de suporte.

Preparar o Cloud Shell

  1. No Console do Google Cloud, abra o Cloud Shell.

    Acessar o Cloud Shell

    Você conclui a maior parte deste tutorial pelo terminal do Cloud Shell usando o Terraform da HashiCorp e o SDK do Cloud.

  2. No Cloud Shell, clone o repositório do GitHub e mude para o diretório local:

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

    O repositório contém todos os arquivos necessários para concluir este tutorial. Para uma descrição completa de cada arquivo, consulte o arquivo README.md no repositório.

  3. Torne executáveis todos os scripts de shell:

    sudo chmod 755 *.sh
    
  4. Instale o Terraform.

  5. Inicialize o Terraform:

    terraform init
    

    A saída será assim:

    ...
    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.
    ...
    

Definir variáveis de ambiente

  1. No Cloud Shell, defina e verifique a variável TF_VAR_org_id, substituindo your-organization-name pelo nome da organização do Google Cloud que você quer usar no tutorial:

    export TF_VAR_org_id=$(gcloud organizations list | \
        awk '/your-organization-name/ {print $2}')
    
  2. Verifique se a variável de ambiente está definida corretamente:

    echo $TF_VAR_org_id
    

    A saída lista o código numérico da organização, que tem um formato semelhante a este:

    ...
    123123123123
    ...
    
  3. Defina as variáveis de ambiente restantes. Para isso, execute o seguinte comando shell do repositório:

    source set_variables.sh
    
  4. Verifique se as variáveis de ambiente estão definidas corretamente:

    env | grep TF_
    

    A resposta será assim:

    ...
    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. Atualize a variável TF_VAR_masquerade se ela não estiver definida.

    Neste documento, a opção de mascaramento do iptables é configurada por padrão, conforme descrito no documento de conceito associado. Se você quiser configurar a opção SNAT do iptables, mude a variável TF_VAR_masquerade para false:

    export TF_VAR_masquerade=false
    
  6. Crie um arquivo de variável de ambiente:

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

    Essa cadeia de comando redireciona as variáveis de ambiente que você criou para um arquivo chamado TF_ENV_VARS. Cada variável é precedida pelo comando export. É possível usar esse arquivo para redefinir as variáveis de ambiente caso a sessão do Cloud Shell seja encerrada. Neste tutorial, essas variáveis são usadas pelos scripts do Terraform, scripts de shell e comandos do SDK.

    Se você precisar reinicializar as variáveis, execute o seguinte comando no diretório em que o arquivo está localizado:

    source TF_ENV_VARS
    

Implantar a infraestrutura de suporte

  • No Cloud Shell, implante a infraestrutura de suporte do Terraform:

    terraform apply
    

    O Terraform solicita a confirmação antes de fazer qualquer alteração. Responda yes para aplicar qualquer configuração.

    O comando terraform apply instrui o Terraform a implantar todos os componentes da solução. Para entender melhor como a infraestrutura é declarativamente definida, leia os manifestos do Terraform, ou seja, os arquivos com a extensão .tf.

Como inspecionar a infraestrutura de suporte

Agora, use as ferramentas de linha de comando gcloud para visualizar e verificar a infraestrutura que o Terraform criou. A verificação envolve a execução de um comando para ver se o recurso responde e foi criado corretamente.

Verificar os projetos

  1. No Cloud Shell, liste os dois projetos:

    gcloud projects list | grep pid
    

    A resposta será assim:

    ...
    isolated-vpc-pid       isolated-vpc-pname        777999333962
    routed-domain-pid      routed-domain-pname       777852333528
    ...
    
  2. Listar o status da API:

    1. Para o projeto da VPC isolada:

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

      A resposta será assim:

      ...
      compute.googleapis.com            Compute Engine API
      container.googleapis.com          Google Kubernetes Engine API
      ...
      
    2. Para o projeto de domínio roteado:

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

      A resposta será assim:

      ...
      compute.googleapis.com            Compute Engine API
      ...
      
  3. Liste o status da VPC compartilhada:

    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
    

    A resposta será assim:

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

Verificar as redes e sub-redes

  1. No Cloud Shell, verifique as redes e sub-redes da VPC isolada:

    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
    

    A saída será assim:

    ...
    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. Verifique as redes e sub-redes da VPC de domínio roteado:

    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
    

    A resposta será assim:

    ...
    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
    ...
    

Verificar regras de firewall

  • No Cloud Shell, confira as regras de firewall nas duas VPCs:

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

    A resposta será assim:

    ...
    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
    ...
    

Verificar máquinas de teste

  • No Cloud Shell, confira as máquinas de teste:

    gcloud compute instances list --project=$TF_VAR_shared_vpc_pid
    

    A resposta será assim:

    ...
    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
    ...
    

Verificar o gateway da VPC isolada

  1. No Cloud Shell, confira a instância:

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

    A resposta será assim:

    ...
    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. Conecte-se ao gateway da VPC isolada usando SSH:

    gcloud compute ssh isolated-vpc-gw \
        --project=$TF_VAR_isolated_vpc_pid \
        --zone $TF_VAR_zone
    
  3. Na instância, verifique a existência do seguinte:

    • A tabela de rotas de domínio roteado
    • As regras de política que direcionam o tráfego vinculado ao domínio roteado para a tabela de roteamento de domínio roteado
    • As rotas estáticas na tabela de roteamento de domínio roteado que direcionam o tráfego para o domínio roteado
    sudo sysctl net.ipv4.ip_forward
    cat /etc/iproute2/rt_tables | grep routed-domain
    ip rule show
    ip route show table routed-domain
    

    A saída será assim:

    ....
    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. Verifique a configuração de iptables da NAT:

    sudo iptables -t nat -L -v
    

    Para a configuração de mascaramento do iptables, a saída é semelhante a esta:

    ...
    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
    ...
    

    Para a opção SNAT do iptables, a saída é semelhante à seguinte:

    ...
    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
    ...
    

Verificar o cluster do GKE

  • No Cloud Shell, confira o cluster do GKE:

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

    A resposta será assim:

    ...
    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
    ...
    

Verificar o roteamento entre VPCs

  1. No Cloud Shell, confira o roteamento entre VPCs para a VPC compartilhada:

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

    A resposta será assim:

    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. Verifique o roteamento entre VPCs para a VPC isolada:

    gcloud compute routes list --project=$TF_VAR_isolated_vpc_pid
    

    A resposta será assim:

    ...
    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
    ...
    

Como verificar o aplicativo hello-world

Nesta seção, será possível encontrar as credenciais do cluster e verificar o serviço hello-server.

  1. No Cloud Shell, consiga as credenciais do cluster:

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

    A resposta será assim:

    ...
    Fetching cluster endpoint and auth data.
    kubeconfig entry generated for cluster1.
    ...
    
  2. Confira o serviço hello-server:

    kubectl get service hello-server
    

    A resposta será assim:

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

Como verificar a solução

Nesta seção, você configura o monitoramento no gateway da VPC isolada e testa o aplicativo.

Configurar o monitoramento no gateway da VPC isolada

  1. No Cloud Shell, use o SSH para se conectar ao gateway da VPC isolada:

    gcloud compute ssh isolated-vpc-gw \
        --project=$TF_VAR_isolated_vpc_pid \
        --zone=$TF_VAR_zone
    
  2. Na instância, execute o utilitário tcpdump:

    sudo tcpdump -n -i eth1 host 10.32.31.1
    

    A saída será assim:

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

    Esse comando inicia tcpdump para capturar os pacotes que transferem o gateway da VPC isolada. O utilitário só captura pacotes que contêm o endereço IP do balanceador de carga interno criado pelo serviço do GKE.

Testar o app

  1. Abra uma nova instância do Cloud Shell.

    ABRIR o Cloud Shell

  2. Use ssh para se conectar à instância test-10-11-vm do Compute Engine. Em seguida, na nova instância, mude para o diretório do repositório Git:

    source TF_ENV_VARS
    gcloud compute ssh test-10-11-vm \
       --project=$TF_VAR_shared_vpc_pid \
       --zone=$TF_VAR_zone
    
  3. Na nova instância, use curl para se conectar ao aplicativo:

    curl http://10.32.31.1:8080/
    

    O comando anterior recupera a página da Web do aplicativo em execução no cluster do GKE. A saída será assim:

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

    No terminal original do Cloud Shell, quando você verifica o gateway da VPC isolada, a saída é semelhante a esta:

    ...
    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
    ...
    

    Essa saída é uma captura de pacote do comando curl que você acabou de executar.

  4. Na primeira instância do Cloud Shell, pressione Control+C para interromper a listagem tcpdump.

  5. Nessa mesma instância, examine a tabela de conexão no gateway da VPC isolada:

    sudo conntrack -L | grep 10.32.31.49
    

    Para a opção de mascaramento do iptables, a saída tem um formato semelhante a este:

    ...
    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
    ...
    

    Esse comando exibe entradas de NAT de origem criadas na tabela de conexão com base na captura de pacotes na etapa anterior, e src=10.0.0.2 foi convertido em dst=10.32.0.2. A saída para a opção SNAT do iptables será semelhante.

  6. Execute novamente esta seção completa de testes, substituindo test-10-11-vm por test-10-160-11-vm e test-10-64-19-vm.

Limpeza

Destruir a infraestrutura

  1. No primeiro terminal do Cloud Shell, feche a sessão SSH para o gateway da VPC isolada:

    exit
    
  2. Destrua a configuração do Terraform:

    terraform destroy
    

    O Terraform solicita a confirmação antes de fazer a alteração. Responda yes para destruir a configuração e todos os componentes do tutorial.

    É possível ver o seguinte erro do Terraform:

    ...
    ∗ 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
    ...
    

    Este erro ocorre quando você tenta destruir a VPC compartilhada antes de destruir o gateway da VPC isolada.

  3. Continue o processo de limpeza:

    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
    

    É possível ver o seguinte erro do Terraform:

    ...
    ∗ 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'
    ...
    

    Esse erro ocorre quando você tenta destruir a rede da VPC isolada antes das regras de firewall do GKE.

  4. Faça a limpeza removendo as regras de firewall não padrão da VPC isolada:

    ./k8-fwr.sh
    

    A resposta mostra quais regras de firewall serão removidas.

  5. Revise as regras e, quando solicitado, digite yes.

  6. No primeiro terminal do Cloud Shell, emita novamente o seguinte comando:

    terraform destroy
    

    O Terraform solicita a confirmação antes de fazer a alteração. Responda yes para destruir a configuração.

  7. Remova os arquivos criados durante este tutorial:

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

A seguir