Visão geral
Neste caso de uso, vamos criar um gateway do Cloud NAT com vários IPs de saída atribuídos. Esses gateways vão fazer o tráfego sair dos pods e das VMs que correspondem aos rótulos configurados no gateway. O gateway atribui automaticamente um IP de saída a cada endpoint que pode sair do tráfego por ele.

Pré-requisitos
Antes de configurar um gateway, você precisa receber as permissões adequadas do Identity and Access Management (IAM), garantir que seu projeto tenha uma política de rede adequada e ativar a saída.
Consulte Antes de começar a usar o Cloud NAT para mais detalhes.
O gateway do Cloud NAT usa sub-redes externas leaf como entradas. Para mais informações sobre como configurar sub-redes externas para o Cloud NAT, consulte Criar sub-redes externas para o Cloud NAT.
Garantir uma configuração de VM ou pod compatível
Conforme mencionado na Visão geral do NAT, o Cloud NAT não é compatível
com a configuração de saída padrão do projeto. Verifique se nenhum pod ou VM
que você quer usar com o Cloud NAT tem o rótulo
egress.networking.gke.io/enabled:true.
Por padrão, uma configuração de acesso externo à máquina virtual (VMEA, na sigla em inglês) configura uma VM para saída de
tráfego usando a configuração de saída padrão do projeto. Em outras palavras, ele adiciona automaticamente o rótulo egress.networking.gke.io/enabled:"true" à VM. Se essa VM também estiver configurada para saída de tráfego usando um gateway do Cloud NAT, isso resultará em uma colisão entre as configurações de NAT. Para evitar essa colisão, em cada VMEA associada a uma VM configurada para saída de tráfego por um gateway do Cloud NAT, verifique se a VMEA associada a essa VM tem a anotação egress.networking.gke.io/use-cloud-nat:"true".
A VM associada vai fazer a saída do tráfego exclusivamente pelo gateway do Cloud NAT.
Criar os gateways do Cloud NAT
O exemplo a seguir define um gateway do Cloud NAT com duas sub-redes externas de folha (subnet-1 e subnet-2). O gateway usa todos os IPs dessas sub-redes, um de subnet-1 e quatro de subnet-2, e os atribui automaticamente aos endpoints de cada VM ou pod com os rótulos especificados. Vários pods ou VMs podem receber o mesmo IP de saída atribuído.
apiVersion: networking.gdc.goog/v1
kind: CloudNATGateway
metadata:
namespace: project-1
name: gateway-1
spec:
workloadSelector: # Immutable
labelSelector:
workloads:
matchLabels:
app: aa
subnetRefs: # Mutable
- subnet-1
- subnet-2
Verificar o status dos gateways
Verifique o status dos gateways executando o seguinte comando kubectl.
export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
kubectl get cloudnatgateways gateway-1 -n project-1 --kubeconfig "${MGMT_KUBECONFIG:?}"
Se configurado corretamente, o campo de condição de status do gateway do Cloud NAT
vai mostrar a condição do tipo Ready definida como true e as sub-redes
marcadas como OK, conforme mostrado no exemplo de saída a seguir.
apiVersion: networking.gdc.goog/v1
kind: CloudNATGateway
metadata:
namespace: project-1
name: gateway-1
spec:
workloadSelector:
labelSelector:
workloads:
matchLabels:
app: aa
subnetRefs:
- subnet-1
- subnet-2
status:
conditions:
- lastTransitionTime: "2025-08-20T21:31:36Z"
message: ""
observedGeneration: 1
reason: Ready
status: "True"
type: Ready
- lastTransitionTime: "2025-08-20T21:31:36Z"
message: ""
observedGeneration: 1
reason: Ready
status: "True"
type: SubnetsReady
- lastTransitionTime: "2025-08-20T21:31:36Z"
message: ""
observedGeneration: 1
reason: Ready
status: "True"
type: PerimeterConfigurationReady
- lastTransitionTime: "2025-08-20T21:31:36Z"
message: ""
observedGeneration: 1
reason: Ready
status: "True"
type: EgressRoutesReady
subnets:
- name: subnet-1
status: OK
- name: subnet-2
status: OK
O status do gateway do Cloud NAT contém quatro condições dos seguintes tipos:
Ready: essa condição resume o status do gateway do Cloud NAT. Essa condição será definida como "true" se o gateway estiver totalmente configurado.SubnetsReady: essa condição indica se as sub-redes atribuídas ao gateway são válidas.PerimeterConfigurationReady: essa condição indica se a configuração do perímetro já foi feita (por exemplo, IPs externos atribuídos a nós voltados para o exterior etc.).EgressRoutesReady: essa condição indica se as rotas para o tráfego de saída dos endpoints de origem já foram configuradas.
Tráfego de teste
Podemos testar o tráfego emitindo um comando curl de um dos pods ou VMs
atribuídos ao gateway para um endpoint externo. O endpoint de recebimento
vai ver um dos IPs de saída associados ao gateway.