Configurar endereços IP públicos usados de forma privada para o GKE

Autopilot Padrão

Esta página mostra como aplicar endereços IP públicos usados de forma privada (PUPI) a blocos de endereços de pods do Google Kubernetes Engine (GKE).

Os endereços IP públicos usados de forma privada (PUPIs) são endereços que pode usar de forma privada na sua rede de nuvem virtual privada (VPC). Google Cloud Estes endereços IP não são propriedade da Google. Não tem de ser proprietário destes endereços IP públicos para os usar de forma privada.

Vista geral

Os clusters do GKE requerem intervalos de endereços IP dedicados para nós, pods e serviços. À medida que a sua infraestrutura cresce, pode enfrentar o esgotamento do espaço de endereço IP interno padrão (RFC 1918). Uma forma de mitigar o esgotamento de endereços RFC1918 privados é usar endereços IP públicos usados de forma privada (PUPI) para o bloco CIDR de pods do GKE. Os PUPIs oferecem uma alternativa para a sua rede de pods do GKE, reservando endereços IP privados para outros componentes do cluster.

Cluster único: se estiver a criar apenas um cluster do GKE, pode ativar os PUPIs ativando os intervalos de endereços IP externos usados de forma privada.

Vários clusters: se estiver a trabalhar com vários clusters do GKE ligados através do peering de VPC (um cenário comum para fornecedores de serviços), precisa de uma configuração mais complexa. O diagrama seguinte mostra um exemplo de como uma empresa (produtor) oferece um serviço gerido usando a PUPI com o peering de VPC a um cliente (consumidor).

O diagrama anterior envolve as seguintes considerações:

• Bloco CIDR principal: um bloco CIDR não PUPI usado para nós e o equilibrador de carga interno (ILB) que não pode sobrepor-se nas VPCs.
• Bloco CIDR secundário do produtor: um bloco CIDR PUPI usado para pods (por exemplo, 45.45.0.0/16).
• Bloco CIDR secundário do consumidor: qualquer outro bloco CIDR de PUPI no lado do cliente (por exemplo, 5.5.0.0/16).

Como são usadas as PUPIs num cenário de fornecedor de serviços

O fornecedor de serviços (produtor) executa o respetivo serviço gerido num cluster do GKE (gke-2) na respetiva VPC (vpc-producer). Este cluster usa o intervalo PUPI 45.0.0.0/8 para os respetivos endereços IP de pods.

O cliente (consumidor) também tem um cluster do GKE (gke-1) na respetiva VPC (vpc-consumer), usando um intervalo de PUPI diferente, 5.0.0.0/8, para os respetivos endereços IP de pods.

Estas duas VPCs estão ligadas através do peering de VPCs, mas cada uma continua a usar endereços IP privados padrão (RFC 1918) para nós, serviços e equilibradores de carga internos.

Garanta a comunicação entre VPCs

• Consumidor para produtor: por predefinição, a VPC do consumidor partilha automaticamente as respetivas rotas RFC 1918 (mas não PUPIs) com o produtor. Isto permite que os recursos na VPC do consumidor acedam aos serviços na VPC do produtor (normalmente, através de balanceadores de carga internos).
• Produtor para consumidor: para que os pods do produtor alcancem os recursos na VPC do consumidor, é necessária uma configuração explícita.
• Sem sobreposição: o produtor e o consumidor têm de garantir que o intervalo de PUPI do consumidor não entra em conflito com nenhum endereço IP usado na VPC do produtor.
• Exportação/importação: o produtor tem de ativar a exportação das respetivas rotas PUPI e o consumidor tem de ativar a importação dessas rotas através da ligação de peering.

Ative a comunicação quando os intervalos de PUPI se sobrepõem

Se a VPC do consumidor já usar o mesmo intervalo de PUPIs que o produtor, a comunicação direta dos pods do produtor não é possível. Em alternativa, o produtor pode ativar a ocultação de endereços IP, em que os endereços IP dos pods são ocultados atrás dos endereços IP dos nós do produtor.

Nota: os PUPIs não suportam a rede de serviços.

A tabela seguinte mostra as predefinições de importação e exportação para cada VPC. Pode modificar as predefinições da interligação de VPCs através do comando gcloud compute networks peerings update.

Rede da VPC	Importar definições	Exportar definições	Notas
Produtor	Comportamento predefinido (desativado): não importa encaminhamentos de sub-rede com endereços IP públicos Para ativar: --import-subnet-routes-with-public-ip (através do peering)	Comportamento predefinido (ativado): exporta encaminhamentos de sub-rede com endereços IP públicos Para desativar: --no-export-subnet-routes-with-public-ip (através da interligação)	Flags controladas através da rede de serviços.
Consumidor	Desativado (predefinição)	Ativada (predefinição)	Normalmente, gerido pelo cliente, não é necessário modificar através da rede de serviços

Estas definições resultam no seguinte:

• A VPC do produtor vê todas as rotas do cliente.
• A VPC do consumidor não vê os trajetos PUPI configurados na sub-rede do pod na VPC do produtor.
• O tráfego originado dos pods do produtor para a rede vpc-consumer tem de ser traduzido atrás dos endereços dos nós no cluster do produtor.

Pré-requisitos

Para estabelecer uma comunicação bem-sucedida entre os pods da VPC e outra VPC, certifique-se de que os seguintes pré-requisitos e configurações são cumpridos:

• O seu cluster do GKE tem de cumprir os seguintes requisitos de versão mínima:
  • Clusters do Autopilot: versão 1.22 ou posterior do GKE
  • Clusters padrão: versão 1.14 ou posterior do GKE
• Selecione um intervalo de PUPI que não seja encaminhável publicamente nem pertença à Google.
• Certifique-se de que os endereços IP dos nós e o intervalo de endereços IP principal de ambas as VPCs não se sobrepõem.
• Se precisar de comunicação direta de pod para pod entre a VPC do cliente e o serviço gerido, siga estes passos:
  • Clusters do Autopilot: configure o SNAT para o PUPI para garantir a comunicação entre pods. Não precisa de configuração adicional.
  • Clusters padrão: traduzem os endereços IP dos pods para os respetivos endereços IP dos nós através do SNAT. Ative o SNAT para tráfego PUPI. Para mais informações, consulte o artigo Ative intervalos de endereços IP externos usados de forma privada.

Configure endereços IP públicos usados de forma privada para clusters do GKE

Para configurar endereços PUPI para clusters do GKE:

1. Configurar duas redes de nuvem privada virtual.
2. Configure uma sub-rede em cada rede de nuvem privada virtual.
3. Configure um intervalo de endereços PUPI num intervalo de endereços secundário em cada sub-rede.
4. Estabeleça uma relação de intercâmbio da nuvem privada virtual entre as duas redes da nuvem privada virtual com as definições de importação e exportação adequadas.
5. Inspecione as rotas em cada nuvem privada virtual.

Custos

Neste documento, usa os seguintes componentes faturáveis do Google Cloud:

• GKE

Para gerar uma estimativa de custos com base na sua utilização projetada, use a calculadora de preços.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

• Ative a API Google Kubernetes Engine.
Ative a API Google Kubernetes Engine
• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.
  Nota: para instalações existentes da CLI gcloud, certifique-se de que define a compute/region propriedade. Se usar principalmente clusters zonais, defina o compute/zone. Ao definir uma localização predefinida, pode evitar erros na CLI gcloud, como os seguintes: One of [--zone, --region] must be supplied: Please specify location. Pode ter de especificar a localização em determinados comandos se a localização do seu cluster for diferente da predefinição que definiu.

• Use apenas clusters nativos de VPC.

• Configure as especificações de IPAM necessárias para o VPC peering.

Configure redes e clusters

1. Criar redes VPC:

   Crie as duas seguintes redes VPC com RFC-1918 como intervalos principais para nós e intervalos PUPI para pods. Atribua intervalos de endereços IP primários do espaço de endereços privados RFC 1918 (por exemplo, 10.x.x.x, 172.16.x.x ou 192.168.x.x) a ambas as VPCs. Normalmente, estes intervalos são usados para os nós de trabalho nos seus clusters do GKE. Além dos intervalos de endereços IP internos, designe intervalos separados de endereços IP públicos usados de forma privada (PUPIs) para cada VPC. Estes intervalos de PUPI são usados exclusivamente para os endereços IP dos pods nos respetivos clusters do GKE.

   • Rede da VPC do consumidor: esta VPC aloja o cluster do GKE onde as aplicações ou as cargas de trabalho do consumidor são executadas. Pode usar uma configuração semelhante à seguinte:

     Network: consumer
     Subnetwork: consumer-subnet
     Primary range: 10.129.0.0/24
     Service range name and cidr: consumer-services, 172.16.5.0/24
     Pod range name and cidr: consumer-pods, 5.5.5.0/24
     Cluster name: consumer-cluster
     

   • Rede VPC do produtor: esta VPC aloja o cluster do GKE responsável por fornecer o serviço que o consumidor usa. Pode usar uma configuração semelhante à seguinte:

     Network: producer
     Subnetwork: producer-subnet
     Primary range: 10.128.0.0/24
     Service range name and cidr: producer-services, 172.16.45.0/24
     Pod range name and cidr: producer-pods, 45.45.45.0/24
     Cluster name: producer-cluster
     

   Para mais informações sobre como criar redes VPC, consulte o artigo Crie redes VPC.

2. Com as redes VPC e sub-redes criadas com intervalos PUPI no passo anterior, pode criar dois clusters do GKE (producer e consumer).

   Nota: os intervalos PUPI só são suportados como intervalos de endereços IP secundários para a rede de pods no GKE e não podem ser usados para o intervalo de endereços IP principal (usado por nós e serviços).

   1. Crie producer clusters com a rede e a sub-rede do produtor da seguinte forma:

      gcloud container clusters create PRODUCER_CLUSTER_NAME \
          --location=PRODUCER_CONTROL_PLANE_LOCATION \
          --enable-ip-alias \
          --network=PRODUCER_NETWORK_NAME \
          --subnetwork=PRODUCER_SUBNETWORK_NAME \
          --cluster-secondary-range-name=PRODUCER_PODS \
          --services-secondary-range-name=PRODUCER_SERVICES \
          --num-nodes=1 \
          --project=PRODUCER_PROJECT_ID
      

      Substitua o seguinte:

      • PRODUCER_CLUSTER_NAME: o nome do cluster de produção do GKE.
      • PRODUCER_CONTROL_PLANE_LOCATION: a localização do Compute Engine do painel de controlo do seu cluster de produção. Indique uma região para clusters regionais ou uma zona para clusters zonais.
      • PRODUCER_NETWORK_NAME: o nome de uma rede VPC do produtor existente.
      • PRODUCER_SUBNETWORK_NAME: o nome de uma sub-rede existente. O intervalo de endereços IP principal da sub-rede é usado para nós. A sub-rede tem de existir na mesma região que a usada pelo cluster. Se for omitido, o GKE tenta usar uma sub-rede na rede defaultVPC na região do cluster.
      • Se o método de atribuição de intervalo secundário for gerido pelo GKE:
        • POD_IP_RANGE: um intervalo de endereços IP na notação CIDR, como 10.0.0.0/14, ou o tamanho de uma máscara de sub-rede de bloco CIDR, como /14. Isto é usado para criar o intervalo de endereços IP secundário da sub-rede para pods. Se omitir a opção --cluster-ipv4-cidr, o GKE escolhe automaticamente um intervalo de /14 (2¹⁸ endereços). O intervalo escolhido automaticamente é selecionado aleatoriamente a partir de 10.0.0.0/8 (um intervalo de 2²⁴ endereços).
        • SERVICES_IP_RANGE: um intervalo de endereços IP na notação CIDR (por exemplo, 10.4.0.0/19) ou o tamanho de uma máscara de sub-rede de bloco CIDR (por exemplo, /19). Isto é usado para criar o intervalo de endereços IP secundário da sub-rede para Serviços.
      • Se o método de atribuição de intervalo secundário for gerido pelo utilizador:
        • SECONDARY_RANGE_PODS: o nome de um intervalo de endereços IP secundários existente no SUBNET_NAME especificado. O GKE usa todo o intervalo de endereços IP secundários da sub-rede para os pods do cluster.
        • SECONDARY_RANGE_SERVICES: o nome de um intervalo de endereços IP secundários existente no especificado.
      • PRODUCER_PROJECT_ID: o ID do projeto produtor.

   2. Crie consumerclusters com a rede de consumidor e a sub-rede da seguinte forma:

      gcloud container clusters create CONSUMER_CLUSTER_NAME \
          --location=CONSUMER_CONTROL_PLANE_LOCATION \
          --enable-ip-alias \
          --network=CONSUMER_NETWORK_NAME \
          --subnetwork=CONSUMER_SUBNETWORK_NAME \
          --cluster-secondary-range-name=CONSUMER_PODS \
          --services-secondary-range-name=CONSUMER_SERVICES \
          --num-nodes=1 \
          --project=CONSUMER_PROJECT_ID
      

      Substitua o seguinte:

      • CONSUMER_CLUSTER_NAME: o nome do cluster de consumidor do GKE.
      • CONSUMER_CONTROL_PLANE_LOCATION: a localização do Compute Engine do painel de controlo do seu cluster de consumo. Indique uma região para clusters regionais ou uma zona para clusters zonais.
      • PRODUCER_NETWORK_NAME: o nome de uma rede VPC do consumidor existente.
      • CONSUMER_SUBNETWORK_NAME: o nome de uma sub-rede existente. O intervalo de endereços IP principal da sub-rede é usado para nós. A sub-rede tem de existir na mesma região que a usada pelo cluster. Se for omitido, o GKE tenta usar uma sub-rede na rede defaultVPC na região do cluster.
      • Se o método de atribuição de intervalo secundário for gerido pelo GKE:
        • POD_IP_RANGE: um intervalo de endereços IP na notação CIDR, como 10.0.0.0/14, ou o tamanho de uma máscara de sub-rede de bloco CIDR, como /14. Isto é usado para criar o intervalo de endereços IP secundário da sub-rede para pods. Se omitir a opção --cluster-ipv4-cidr, o GKE escolhe automaticamente um intervalo de /14 (2¹⁸ endereços). O intervalo escolhido automaticamente é selecionado aleatoriamente a partir de 10.0.0.0/8 (um intervalo de 2²⁴ endereços) e não inclui intervalos de endereços IP atribuídos a VMs, rotas existentes nem intervalos atribuídos a outros clusters. O intervalo escolhido automaticamente pode entrar em conflito com endereços IP reservados, rotas dinâmicas ou rotas em VPCs que estabelecem peering com este cluster. Se usar qualquer uma destas opções, deve especificar --cluster-ipv4-cidr para evitar conflitos.
        • SERVICES_IP_RANGE: um intervalo de endereços IP na notação CIDR (por exemplo, 10.4.0.0/19) ou o tamanho de uma máscara de sub-rede de bloco CIDR (por exemplo, /19). Isto é usado para criar o intervalo de endereços IP secundário da sub-rede para Serviços.
      • Se o método de atribuição de intervalo secundário for gerido pelo utilizador:
        • SECONDARY_RANGE_PODS: o nome de um intervalo de endereços IP secundários existente no SUBNET_NAME especificado. O GKE usa todo o intervalo de endereços IP secundários da sub-rede para os pods do cluster.
        • SECONDARY_RANGE_SERVICES: o nome de um intervalo de endereços IP secundários existente no especificado.
      • CONSUMER_PROJECT_ID: o ID do projeto de consumidor.

   Para mais informações sobre a criação de clusters, consulte o artigo Criar clusters.

3. Estabeleça a relação de intercâmbio da VPC entre a rede da VPC do consumidor e a rede da VPC do produtor da seguinte forma:

   • Para associar a rede consumer ao produtor, execute o seguinte comando:

     gcloud compute networks peerings create CONSUMER_PEERING_NAME \
         --project=CONSUMER_PROJECT_ID \
         --network=CONSUMER_NETWORK_NAME \
         --peer-network=PRODUCER_NETWORK_NAME
     

     Substitua CONSUMER_PEERING_NAME pelo nome da interligação a adicionar à rede do consumidor.

   • Para associar a rede producer ao consumidor, execute o seguinte comando:

     gcloud compute networks peerings create PRODUCER_PEERING_NAME \
         --project=PRODUCER_PROJECT_ID \
         --network=PRODUCER_NETWORK_NAME \
         --peer-network=CONSUMER_NETWORK_NAME \
         --no-export-subnet-routes-with-public-ip \
         --import-subnet-routes-with-public-ip
     

     Substitua PRODUCER_PEERING_NAME pelo nome da interligação a adicionar à rede de produção.

   Por predefinição, a VPC do consumidor exporta os endereços PUPI. Quando cria a VPC do produtor, usa os seguintes argumentos para configurar a VPC de modo a importar endereços PUPI, mas não os exportar:

   --no-export-subnet-routes-with-public-ip
   --import-subnet-routes-with-public-ip
   

Valide as redes e as sub-redes

1. Valide a rede de produtores:

   gcloud compute networks describe PRODUCER_NETWORK_NAME \
       --project=PRODUCER_PROJECT_ID
   

   O resultado é semelhante ao seguinte:

   ...
   kind: compute#network
   name: producer
   peerings:
   - autoCreateRoutes: true
     exchangeSubnetRoutes: true
     exportCustomRoutes: false
     exportSubnetRoutesWithPublicIp: false
     importCustomRoutes: false
     importSubnetRoutesWithPublicIp: true
     name: producer-peer-consumer
   …
   

2. Valide a sub-rede do produtor:

   gcloud compute networks subnets describe PRODUCER_SUBNETWORK_NAME \
       --project=PRODUCER_PROJECT_ID\
       --region=PRODUCER_CONTROL_PLANE_LOCATION
   

   O resultado é semelhante ao seguinte:

   ...
   ipCidrRange: 10.128.0.0/24
   kind: compute#subnetwork
   name: producer-subnet
   …
   secondaryIpRanges:
   - ipCidrRange: 172.16.45.0/24
     rangeName: producer-services
   - ipCidrRange: 45.45.45.0/24
     rangeName: producer-pods
   …
   

3. Valide a rede de consumidores:

   gcloud compute networks describe CONSUMER_NETWORK_NAME \
       --project=CONSUMER_PROJECT_ID
   

   O resultado é semelhante ao seguinte:

   ...
   kind: compute#network
   name: consumer
   peerings:
   - autoCreateRoutes: true
     exchangeSubnetRoutes: true
     exportCustomRoutes: false
     exportSubnetRoutesWithPublicIp: true
     importCustomRoutes: false
     importSubnetRoutesWithPublicIp: false
     name: consumer-peer-producer
   ...
   

4. Valide a sub-rede do consumidor:

   gcloud compute networks subnets describe CONSUMER_SUBNETWORK_NAME \
       --project=CONSUMER_PROJECT_ID\
       --region=CONSUMER_CONTROL_PLANE_LOCATION
   

   O resultado é semelhante ao seguinte:

   ...
   ipCidrRange: 10.129.0.0/24
   kind: compute#subnetwork
   name: consumer-subnet
   ...
   secondaryIpRanges:
   - ipCidrRange: 172.16.5.0/24
     rangeName: consumer-services
   - ipCidrRange: 5.5.5.0/24
     rangeName: consumer-pods
   ...
   

Valide o cluster do GKE e os respetivos recursos

1. Obtenha as credenciais do cluster de consumidores:

   gcloud container clusters get-credentials CONSUMER_CLUSTER_NAME \
       --project=CONSUMER_PROJECT_ID \
       --location=CONSUMER_CONTROL_PLANE_LOCATION
   

   O resultado é semelhante ao seguinte:

   ...
   Fetching cluster endpoint and auth data.
   kubeconfig entry generated for consumer-cluster.
   ...
   

2. Instale e valide a helloapp.

   Em alternativa, pode guardar o seguinte manifesto como deployment.yaml:

   kubectl apply -f - <<'EOF'
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: helloweb
     labels:
       app: hello
   spec:
     selector:
       matchLabels:
         app: hello
         tier: web
     template:
       metadata:
         labels:
           app: hello
           tier: web
       spec:
         containers:
         - name: hello-app
           image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
           ports:
           - containerPort: 8080
           resources:
             requests:
               cpu: 200m
   EOF
   

3. Aplique o ficheiro deployment.yaml:

   kubectl apply -f
   

4. Valide a implementação do helloweb:

   kubectl get deployment helloweb
   

   O resultado é semelhante ao seguinte:

   ...
   NAME       READY   UP-TO-DATE   AVAILABLE   AGE
   helloweb   1/1     1            1           10s
   ...
   

Validar a solução

1. Valide se criou com êxito a interligação de VPCs:

   gcloud compute networks peerings list
   

   O resultado é semelhante ao seguinte, que mostra as interligações com os nomes consumer e producer:

   NAME                                     NETWORK    PEER_PROJECT                PEER_NETWORK                            STACK_TYPE  PEER_MTU  IMPORT_CUSTOM_ROUTES  EXPORT_CUSTOM_ROUTES  STATE   STATE_DETAILS
   consumer-peer-producer                   consumer   <project_name>             producer                                IPV4_ONLY   1460      False                 False                 ACTIVE  [2023-08-07T13:14:57.178-07:00]: Connected.
   producer-peer-consumer                   producer   <project_name>             consumer                                IPV4_ONLY   1460      False                 False                 ACTIVE  [2023-08-07T13:14:57.178-07:00]: Connected.
   

2. Valide se a VPC do consumidor exporta encaminhamentos PUPI:

   gcloud compute networks peerings list-routes CONSUMER_PEERING_NAME \
       --direction=OUTGOING \
       --network=CONSUMER_NETWORK_NAME \
       --region=CONSUMER_CONTROL_PLANE_LOCATION
   

   O resultado é semelhante ao seguinte, que mostra todos os três blocos CIDR de consumidor:

   DEST_RANGE     TYPE                  NEXT_HOP_REGION  PRIORITY  STATUS
   10.129.0.0/24  SUBNET_PEERING_ROUTE  us-central1      0         accepted by peer
   172.16.5.0/24  SUBNET_PEERING_ROUTE  us-central1      0         accepted by peer
   5.5.5.0/24     SUBNET_PEERING_ROUTE  us-central1      0         accepted by peer
   

3. Valide os encaminhamentos PUPI que a VPC do produtor importou:

   gcloud compute networks peerings list-routes PRODUCER_PEERING_NAME \
       --direction=INCOMING \
       --network=PRODUCER_NETWORK_NAME \
       --region=PRODUCER_CONTROL_PLANE_LOCATION
   

   O resultado é semelhante ao seguinte, que mostra todos os três blocos CIDR de consumidor:

   DEST_RANGE     TYPE                  NEXT_HOP_REGION  PRIORITY  STATUS
   10.129.0.0/24  SUBNET_PEERING_ROUTE  us-central1      0         accepted
   172.16.5.0/24  SUBNET_PEERING_ROUTE  us-central1      0         accepted
   5.5.5.0/24     SUBNET_PEERING_ROUTE  us-central1      0         accepted
   

4. Valide se os pods do GKE têm um endereço PUPI:

   kubectl get pod -o wide
   

   O resultado é semelhante ao seguinte, que mostra que os endereços IP dos pods estão no intervalo 5.5.5/24.

   NAME                        READY   STATUS    RESTARTS   AGE   IP         NODE                                              NOMINATED NODE   READINESS GATES
   helloweb-575d78464d-xfklj   1/1     Running   0          28m   5.5.5.16   gke-consumer-cluster-default-pool-e62b6542-dp5f   <none>           <none>
   

O que se segue?

• Leia o guia Configurar o acesso privado ao serviço.
• Leia o guia Introdução à API Service Networking.
• Explore arquiteturas de referência, diagramas e práticas recomendadas sobre Google Cloud. Consulte o nosso Centro de Arquitetura na nuvem.