Gateways NAT do Cloud para clusters padrão

O Google Distributed Cloud (GDC) com isolamento físico é compatível com clusters padrão, um cluster do Kubernetes de projeto único e autoatendimento gerenciado pelo grupo de operadores de aplicativos que oferece mais flexibilidade para cargas de trabalho personalizadas. Esta página mostra como configurar o Cloud NAT para clusters padrão e descreve algumas restrições e limitações nas configurações de NAT para esse tipo de cluster.

Antes de começar

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.

Visão geral

Diagrama mostrando uma configuração de gateway do Cloud NAT para um cluster padrão

Os gateways do Cloud NAT podem ser configurados para processar o tráfego de saída das cargas de trabalho executadas em clusters padrão de duas maneiras:

  • Gateway no escopo do projeto:um gateway que se aplica a todo o tráfego de carga de trabalho em clusters dentro de um projeto, incluindo todos os clusters compartilhados e padrão. Essa é a configuração descrita em Criar um gateway do Cloud NAT.
  • Gateway no escopo do cluster:um gateway que se aplica apenas a cargas de trabalho em um único cluster padrão especificado. Este é o tipo de gateway demonstrado nesta página.

Esses dois métodos são exclusivos para cargas de trabalho e não se aplicam aos nós que compõem um cluster padrão. Para ativar o Cloud NAT nos nós que formam um cluster padrão, adicione o rótulo cluster.gdc.goog/enable-node-egress-to-outside-the-org: "true" ao objeto do cluster padrão.

Criar o gateway do Cloud NAT

O processo de criação de um gateway para um cluster padrão continua o mesmo que a criação de qualquer gateway do Cloud NAT no escopo do projeto.

Neste caso, vamos nos concentrar na capacidade de filtragem de cluster para o Cloud NAT de cluster padrão e criar uma configuração semelhante ao primeiro cenário, mas especificando o nome do cluster padrão user-vc-1 em que os endpoints que vão rotear o tráfego pelo gateway estão localizados. Como resultado, esse gateway será limitado a esse cluster específico.

apiVersion: networking.gdc.goog/v1
kind: CloudNATGateway
metadata:
  namespace: project-1
  name: gateway-1
spec:
  workloadSelector:    # Immutable
    labelSelector:
      workloads:
        matchLabels:
          app: aa
      clusters:
        matchLabels:
          kubernetes.io/metadata.name: user-vc-1
  subnetRefs:           # Mutable
  - subnet-1
  - subnet-2

Essa configuração vai selecionar todas as cargas de trabalho com os rótulos app: aa em todos os namespaces no cluster padrão user-vc-1.

Verificar o status do gateway

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:       # Immutable
    labelSelector:
      workloads:
        matchLabels:
          app: aa
      clusters:
        matchLabels:
          kubernetes.io/metadata.name: user-vc-1
  subnetRefs:       # Mutable
  - 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

Tráfego de teste

Teste o tráfego emitindo um comando curl de um dos pods ou VMs atribuídos ao gateway no cluster padrão para um endpoint externo. O endpoint de recebimento vai receber um pacote de um dos IPs de saída associados ao gateway. Endpoints em clusters compartilhados com os mesmos rótulos NÃO PODEM fazer saída de tráfego usando esse gateway.

Restrições nas configurações de gateway específicas do cluster

Os operadores de correspondência de rótulos de cargas de trabalho (workloadSelector.labelSelector.workloads.matchLabels) de gateways no escopo do cluster NÃO PODEM SE SOBREPOR aos operadores de correspondência de rótulos de cargas de trabalho de outros gateways no escopo do projeto. Conforme discutido em Restrições na configuração do Cloud NAT, o workloadSelector.labelSelector.workloads.matchLabels não pode se sobrepor entre gateways no mesmo projeto e zona.

As outras restrições listadas em Restrições na configuração do Cloud NAT também se aplicam às configurações de gateway no escopo do cluster.