Gateways Cloud NAT para clusters padrão

O Google Distributed Cloud (GDC) air-gapped oferece suporte a clusters padrão, um cluster do Kubernetes de projeto único e self-service gerenciado pelo grupo de operadores de aplicativos que oferece maior flexibilidade para cargas de trabalho personalizadas. Esta página aborda 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 o 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 leaf externas 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 em execução em clusters padrão de duas maneiras:

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

Esses dois métodos são exclusivamente para cargas de trabalho e não se aplicam aos nós que compõem um cluster padrão. Para ativar o Cloud NAT para os 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 de cluster padrão.

Criar o gateway do Cloud NAT

O processo de criação de um gateway para um cluster padrão permanece o mesmo da criação de qualquer gateway do Cloud NAT com escopo de projeto.

Nesse caso, vamos nos concentrar na capacidade de filtragem de clusters 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 terá escopo para 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

Testar o tráfego

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 mostrar um pacote de um dos IPs de saída associados ao gateway. Os endpoints em clusters compartilhados com os mesmos rótulos NÃO PODEM sair do tráfego usando esse gateway.

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

Os correspondentes de rótulo de cargas de trabalho (workloadSelector.labelSelector.workloads.matchLabels) de gateways com escopo de cluster NÃO PODEM SE SOBREPOR aos correspondentes de rótulo de cargas de trabalho de outros gateways com escopo de 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 a configurações de gateway com escopo de cluster .