Como configurar endereços IP públicos usados de maneira particular para o GKE

Autopilot Standard

Neste tutorial, você aprende a aplicar endereços IP públicos de uso particular (PUPIs) aos blocos de endereços de pod do Google Kubernetes Engine (GKE).

Os endereços IP públicos de uso particular (PUPIs) são endereços que podem ser usados particularmente na sua rede de nuvem privada virtual (VPC) do Google Cloud. Esses IPs não pertencem ao Google. Não é preciso ter esses endereços IPs públicos para usá-los particularmente.

Visão geral

Os clusters do GKE exigem intervalos de endereços IP dedicados para nós, pods e serviços. Conforme sua infraestrutura cresce, você pode enfrentar o esgotamento do espaço de endereço IP interno padrão (RFC 1918). Uma forma de reduzir o esgotamento de endereço RFC 1918 particular consiste em usar endereços IP públicos de uso particular (PUPIs) para o bloco do CIDR do pod do GKE. Os PUPIs oferecem uma alternativa para a rede de pods do GKE, reservando endereços IP privados para outros componentes do cluster.

Cluster único: para criar apenas um cluster do GKE, você pode ativar os PUPIs ativando intervalos de endereços IP externos de uso particular.

Vários clusters: se você estiver trabalhando com vários clusters do GKE conectados por peering de VPC (um cenário comum para provedores de serviços), será necessária uma configuração mais complexa. O seguinte diagrama mostra um exemplo de como uma empresa (produtor) oferece um serviço gerenciado usando PUPI com peering de VPC para um cliente (consumidor).

Endereços PUPI para o bloco de CIDR de pod do GKE.

O diagrama anterior envolve as seguintes considerações:

Bloco CIDR primário: um bloco de CIDR não PUPI usado para nós e balanceador de carga interno (ILB) e precisa não se sobrepor entre as VPCs.
Bloco de CIDR secundário do produtor: um bloco de CIDR de PUPI que é usado para pods (por exemplo, 45.45.0.0/16).
Bloco de CIDR secundário do consumidor: qualquer outro bloco de CIDR de PUPI no lado do cliente (por exemplo, 5.5.0.0/16).

Como os PUPIs são usados em um cenário de provedor de serviços

O provedor de serviços (produtor) executa o serviço gerenciado em um cluster do GKE (gke-2) na VPC (vpc-producer). Esse cluster usa o intervalo de PUPI 45.0.0.0/8 para os endereços IP do pod.

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

Essas duas VPCs são conectadas usando peering de VPC, mas cada uma continua usando endereços IP privados padrão (RFC 1918) para nós, serviços e balanceadores de carga internos.

Garantir a comunicação entre VPCs

Do consumidor para o produtor: por padrão, a VPC do consumidor compartilha automaticamente as rotas RFC 1918 (mas não os PUPIs) com o produtor. Isso permite que os recursos na VPC do consumidor acessem serviços na VPC do produtor (normalmente por meio de balanceadores de carga internos).
Produtor para consumidor: para que os pods do produtor alcancem recursos na VPC do consumidor, é necessária uma configuração explícita.
Sem sobreposição: o produtor e o consumidor precisam garantir que o intervalo de PUPI do consumidor não entre em conflito com nenhum endereço IP usado na VPC do produtor.
Exportação/importação: o produtor precisa ativar a exportação das rotas de PUPI. O consumidor precisa ativar a importação dessas rotas pela conexão de peering.

Ativar a comunicação quando os intervalos de PUPI se sobreporem

Se a VPC do consumidor já usa o mesmo intervalo de PUPI do produtor, não é possível a comunicação direta dos pods do produtor. Em vez disso, o produtor pode ativar o mascaramento de endereços IP, em que os endereços IP do pod são escondidos atrás dos endereços IP do nó do produtor.

Na tabela a seguir, mostramos as configurações de importação e exportação padrão para cada VPC. É possível modificar as configurações padrão de peering de VPC usando o comando gcloud compute networks peerings update.

Rede VPC	Importar configurações	Exportar configurações	Observações
Produtor	Comportamento padrão (desativado): não importa rotas de sub-rede com endereços IP públicos. Para ativar: --import-subnet-routes-with-public-ip (por peering)	Comportamento padrão (ativado): exporta rotas de sub-rede com endereços IP públicos. Para desativar: --no-export-subnet-routes-with-public-ip (por peering).	Sinalizações controladas pela rede de serviços.
Consumidor	Desativado (padrão)	Ativado (padrão)	Normalmente, gerenciado pelo cliente, não precisa ser modificado pela rede de serviços

Os resultados dessas configurações são os seguintes:

Todas as rotas do cliente ficam visíveis para a VPC do produtor.
As rotas de PUPI configuradas na sub-rede de pod da VPC do produtor não ficam visíveis para a VPC do consumidor.
O tráfego proveniente dos pods do produtor para a rede vpc-consumer precisa ser traduzido por trás dos endereços dos nós do cluster do produtor.

Pré-requisitos

Para estabelecer uma comunicação bem-sucedida entre os pods de VPC e de outra VPC, atenda aos seguintes pré-requisitos e configurações:

Seu cluster do GKE precisa atender aos seguintes requisitos mínimos da versão:
- Clusters do Autopilot: GKE versão 1.22 ou mais recente
- Clusters padrão: GKE versão 1.14 ou posterior.
Selecione um intervalo de PUPI que não seja roteável publicamente ou de propriedade do Google.
Verifique se os endereços IP do nó e o intervalo de endereços IP principal das duas VPCs não se sobrepõem.
Se você precisar de uma comunicação direta entre pods entre a VPC cliente e o serviço gerenciado, siga estas etapas:
- Clusters do Autopilot: configure o SNAT para PUPI para garantir a comunicação entre pods. Você não precisa de configurações adicionais.
- Clusters padrão: traduza os endereços IP do pod para os endereços IP do nó correspondentes usando o SNAT. Ative o SNAT para o tráfego PUPI. Para mais informações, consulte Ativar intervalos de endereços IP externos usados de maneira particular.

Configurar endereços IP públicos usados de maneira particular para clusters do GKE

Para configurar endereços PUPI para clusters do GKE:

Configurar duas redes de nuvem privada virtual.
Configurar uma sub-rede em cada rede de nuvem privada virtual.
Configurar um intervalo de endereços PUPI em um intervalo secundário em cada sub-rede
Estabelecer uma relação de peering entre as duas nuvens privadas virtuais com configurações de importação e exportação adequadas.
Inspecione as rotas em cada nuvem privada virtual.

Custos

Neste documento, você usará 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.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Ativar a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando gcloud components update.
Observação: para instalações atuais da CLI gcloud, defina as propriedades compute/region e compute/zone. Ao definir locais padrão, é possível evitar erros na CLI gcloud, como: One of [--zone, --region] must be supplied: Please specify location.

Use somente clusters nativos de VPC.
Configure as especificações de IPAM necessárias para o peering de VPC.

Configurar redes e clusters

Criar redes VPC:

Crie as duas redes VPC a seguir com RFC-1918 como intervalos principais para nós e intervalos PUPI para pods. Atribua intervalos de endereço IP primário do espaço de endereços particular RFC 1918 (por exemplo, 10.x.x.x, 172.16.x.x ou 192.168.x.x) às duas VPCs. Esses intervalos são normalmente usados para os nós de trabalho nos clusters do GKE. Além dos intervalos de endereços IP internos, designe intervalos de endereços IP públicos de uso privado (PUPIs) para cada VPC. Esses intervalos de PUPI são usados exclusivamente para os endereços IP do pod nos clusters do GKE correspondentes.
- Rede VPC do consumidor: essa VPC hospeda o cluster do GKE em que os aplicativos ou cargas de trabalho do consumidor são executados. Você pode usar uma configuração semelhante a esta:
```
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: essa VPC hospeda o cluster do GKE responsável por fornecer o serviço que o consumidor usa. Você pode usar uma configuração semelhante a esta:
```
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 Criar redes VPC.
Com as redes e sub-redes VPC criadas com intervalos de PUPI na etapa anterior, é possível criar dois clusters do GKE (producer e consumer).

Observação: os intervalos de PUPI só são aceitos como intervalos de endereços IP secundários para a rede de pod no GKE e não podem ser usados para o intervalo de endereço IP primário (usado por nós e Serviços).
1. Crie clusters producer com a rede e a sub-rede do produtor da seguinte maneira:
```
gcloud container clusters create PRODUCER_CLUSTER_NAME \
    --enable-ip-alias \
    --network=NETWORK_NAME \
    --subnetwork=SUBNETWORK_NAME \
    --cluster-secondary-range-name=PRODUCER_PODS \
    --services-secondary-range-name=PRODUCER_SERVICES \
    --num-nodes=1 \
    --zone=PRODUCER_ZONE_NAME \
    --project=PRODUCER_PROJECT_NAME
```
  Substitua:
  - PRODUCER_CLUSTER_NAME: o nome do cluster do produtor do GKE.
  - COMPUTE_LOCATION: a região do Compute Engine para o cluster.
  - PRODUCER_SUBNET_NAME: o nome de uma sub-rede atual. O intervalo de endereços IP primário da sub-rede é usado para os nós. A sub-rede precisa estar na mesma região do cluster. Se omitido, o GKE tentará usar uma sub-rede na rede VPC default na região do cluster.
  - Se o método de atribuição do intervalo secundário for gerenciado pelo GKE:
    - POD_IP_RANGE: um intervalo de endereços IP na notação CIDR, como 10.0.0.0/14, ou o tamanho da máscara de sub-rede de um bloco CIDR, como /14. Isso é usado para criar o intervalo de endereços IP secundário da sub-rede para pods. Se você omitir a opção --cluster-ipv4-cidr, o GKE escolherá um intervalo de /14 (2¹⁸ endereços) automaticamente. 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 da máscara de sub-rede de um bloco CIDR (por exemplo, /19). Isso é usado para criar o intervalo de endereços IP secundário da sub-rede para Serviços.
  - Se o método de atribuição do intervalo secundário for gerenciado pelo usuário:
    - SECONDARY_RANGE_PODS: o nome de um intervalo atual de endereços IP secundário no SUBNET_NAME especificado. O GKE usa todo o intervalo de endereços IP secundário da sub-rede para os pods do cluster.
    - SECONDARY_RANGE_SERVICES: o nome de um intervalo atual de endereços IP secundário especificado.
2. Crie clusters consumer com a rede do consumidor e a sub-rede da seguinte maneira:
```
gcloud container clusters create CONSUMER_CLUSTER_NAME \
    --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 \
    --zone=CONSUMER_ZONE \
    --project=CONSUMER_PROJECT
```
  Substitua:
  - CONSUMER_CLUSTER_NAME: o nome do cluster do consumidor do GKE.
  - COMPUTE_LOCATION: a região do Compute Engine para o cluster.
  - CONSUMER_SUBNET_NAME: o nome de uma sub-rede atual. O intervalo de endereços IP primário da sub-rede é usado para os nós. A sub-rede precisa estar na mesma região do cluster. Se omitido, o GKE tentará usar uma sub-rede na rede VPC default na região do cluster.
  - Se o método de atribuição do intervalo secundário for gerenciado pelo GKE:
    - POD_IP_RANGE: um intervalo de endereços IP na notação CIDR, como 10.0.0.0/14, ou o tamanho da máscara de sub-rede de um bloco CIDR, como /14. Isso é usado para criar o intervalo de endereços IP secundário da sub-rede para pods. Se você omitir a opção --cluster-ipv4-cidr, o GKE escolherá um intervalo de /14 (endereços 2¹⁸) automaticamente. O intervalo escolhido automaticamente é selecionado aleatoriamente de 10.0.0.0/8 (um intervalo de 2²⁴ endereços) e não incluirá intervalos de endereços IP alocados para VMs, rotas existentes ou intervalos alocados a outros clusters. O intervalo escolhido automaticamente pode entrar em conflito com endereços IP reservados, rotas dinâmicas ou rotas em VPCs que fazem peering com esse cluster. Se você usar qualquer um deles, especifique --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 da máscara de sub-rede de um bloco CIDR (por exemplo, /19). Isso é usado para criar o intervalo de endereços IP secundário da sub-rede para Serviços.
  - Se o método de atribuição do intervalo secundário for gerenciado pelo usuário:
    - SECONDARY_RANGE_PODS: o nome de um intervalo atual de endereços IP secundário no SUBNET_NAME especificado. O GKE usa todo o intervalo de endereços IP secundário da sub-rede para os pods do cluster.
    - SECONDARY_RANGE_SERVICES: o nome de um intervalo atual de endereços IP secundário especificado.
Para mais informações sobre a criação de clusters, consulte Como criar clusters.
Estabeleça a relação de peering de VPC entre a rede VPC do consumidor e a rede VPC do produtor da seguinte maneira:
- Para conectar a rede consumer ao produtor, execute o seguinte comando:
```
gcloud compute networks peerings create PEERING_NAME \
    --project=consumer_project \
    --network=consumer \
    --peer-network=producer
```
- Para conectar a rede producer ao consumidor, execute o seguinte comando:
```
gcloud compute networks peerings create PEERING_NAME \
    --project=producer_project \
    --network=producer \
    --peer-network=consumer \
    --no-export-subnet-routes-with-public-ip \
    --import-subnet-routes-with-public-ip
```
Substitua:
- PEERING_NAME: o nome do cluster do consumidor do GKE.
- CONSUMER_CLUSTER_NAME: o nome do cluster do consumidor do GKE.
Por padrão, a VPC do consumidor exporta os endereços PUPI. Ao criar a VPC do produtor, você usa os seguintes argumentos para configurar a VPC para importar, mas não exportar, endereços PUPI:
```
--no-export-subnet-routes-with-public-ip
--import-subnet-routes-with-public-ip
```

Verificar as redes e sub-redes

Verificar a rede do produtor:

gcloud compute networks describe producer \
    --project=producer_project

O resultado será assim:

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

Verificar a sub-rede do produtor:

gcloud compute networks subnets describe producer-subnet \
    --project=producer_project\
    --region=producer_region

O resultado será assim:

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

Verificar a rede do consumidor:

gcloud compute networks subnets describe consumer-subnet \
    --project=consumer_project \
    --region=consumer_region

O resultado será assim:

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

Verificar a sub-rede do consumidor:

gcloud compute networks describe consumer \
--project=consumer_project

O resultado será assim:

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

Verificar o cluster do GKE e os recursos dele

Receber as credenciais do cluster do consumidor:

gcloud container clusters get-credentials consumer-cluster \
    --project=consumer_project \
    --zone=consumer_zone

O resultado será assim:

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

Instale e verifique o helloapp.

Como alternativa, salve o manifesto abaixo 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

Aplique o deployment.yaml:
```
kubectl apply -f
```

Verificar a implantação helloweb:

kubectl get deployment helloweb

O resultado será assim:

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

Como verificar a solução

Valide se você criou o peering da VPC:

gcloud compute networks peerings list

A saída é semelhante à seguinte, que mostra peerings com os nomes consumidor e produtor:

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.

Valide se a VPC do consumidor exporta rotas de PUPI:

gcloud compute networks peerings list-routes consumer-peer-producer \
    --direction=OUTGOING \
    --network=consumer \
    --region=<consumer_region>

A saída é semelhante à seguinte, que mostra os três CIDRs de blocos do 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

Valide as rotas de PUPI que a VPC do produtor importou:

gcloud compute networks peerings list-routes producer-peer-consumer \
    --direction=INCOMING \
    --network=producer \
    --region=<producer_region>

A saída é semelhante à seguinte, que mostra os três CIDRs de blocos do 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

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

kubectl get pod -o wide

A saída é semelhante à 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>

A seguir

Leia o guia Como configurar o acesso privado a serviços.
Leia o guia Primeiros passos com a API Service Networking.
Confira arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Confira o Centro de arquitetura do Cloud.