Gerenciar o NAT de saída padrão do projeto

Esta página descreve a configuração de NAT de saída padrão do projeto, que agora está obsoleta e pode ser usada para permitir que as cargas de trabalho se conectem fora da organização. Esta página também contém instruções sobre como migrar para a solução recomendada, o Cloud NAT.

Visão geral

Esta página descreve as ações de conectividade de saída que você precisa realizar em uma máquina virtual (VM) ou pod em um projeto para permitir que as cargas de trabalho saiam da organização usando a opção de configuração de NAT de saída padrão do projeto (obsoleta).

O NAT de saída padrão do projeto não é compatível com clusters padrão. Use o Cloud NAT se precisar controlar a saída de clusters padrão.

O procedimento mostra como adicionar um rótulo obrigatório às implantações para ativar explicitamente o tráfego de saída e permitir que as cargas de trabalho se comuniquem fora da organização.

Por padrão, o Google Distributed Cloud (GDC) air-gapped bloqueia as cargas de trabalho em um projeto para que não saiam da organização. As cargas de trabalho podem sair da organização se o administrador da plataforma (PA) tiver desativado a proteção contra exfiltração de dados do projeto. Os PAs podem fazer isso anexando o rótulo networking.gdc.goog/enable-default-egress-allow-to-outside-the-org: "true" a o projeto. Além de desativar a proteção contra exfiltração de dados, o operador de aplicativos (AO) precisa adicionar o rótulo egress.networking.gke.io/enabled: true à carga de trabalho do pod para ativar a conectividade de saída desse pod. Quando você aloca e usa um endereço IP conhecido para o projeto, ele executa uma conversão de endereço de rede de origem (NAT) no tráfego de saída da organização.

É possível gerenciar a conectividade de saída das cargas de trabalho em um pod ou uma VM.

Gerenciar o tráfego de saída de cargas de trabalho em um pod

Para configurar cargas de trabalho em um pod para conectividade de saída, primeiro verifique se a proteção contra exfiltração de dados está desativada para o projeto. Em seguida, verifique se o rótulo egress.networking.gke.io/enabled: true foi adicionado ao pod. Se você estiver usando um constructo de nível superior, como Deployment ou Daemonset, para gerenciar conjuntos de pods, configure o rótulo do pod nessas especificações.

O exemplo a seguir mostra como criar uma Deployment no arquivo de manifesto. O arquivo de amostra contém o valor egress.networking.gke.io/enabled: true no campo labels para ativar explicitamente o tráfego de saída do projeto. Esse rótulo é adicionado a cada pod na implantação e permite que as cargas de trabalho nos pods saiam da organização.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: DEPLOYMENT_NAME
spec:
  replicas: NUMBER_OF_REPLICAS
  selector:
    matchLabels:
      run: APP_NAME
  template:
    metadata:
      labels: # The labels given to each pod in the deployment, which are used
              # to manage all pods in the deployment.
        run: APP_NAME
        egress.networking.gke.io/enabled: true
    spec: # The pod specification, which defines how each pod runs in the deployment.
      containers:
      - name: CONTAINER_NAME
        image: CONTAINER_IMAGE
EOF

Substitua:

  • USER_CLUSTER_KUBECONFIG: o arquivo kubeconfig do cluster de usuário em que você está implantando cargas de trabalho de contêiner.

  • DEPLOYMENT_NAME: o arquivo kubeconfig do cluster de usuário em que você está implantando cargas de trabalho de contêiner.

  • APP_NAME: o nome do aplicativo a ser executado na implantação.

  • NUMBER_OF_REPLICAS: o número de objetos Pod replicados que a implantação gerencia.

  • CONTAINER_NAME: o nome do contêiner.

  • CONTAINER_IMAGE: o nome da imagem do contêiner. É necessário incluir o caminho do registro de contêiner e a versão da imagem, como REGISTRY_PATH/hello-app:1.0.

Exemplo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      run: my-app
  template:
    metadata:
      labels:
        run: my-app
        egress.networking.gke.io/enabled: true
    spec:
      containers:
      - name: hello-app
        image: REGISTRY_PATH/hello-app:1.0

Gerenciar o tráfego de saída de cargas de trabalho em uma VM

Para configurar cargas de trabalho em uma VM para conectividade de saída, use o console do GDC para configuração de VM ou crie um recurso VirtualMachineExternalAccess. Para mais informações sobre como ativar uma VM com acesso externo para transferência de dados, consulte Ativar o acesso externo na seção Conectar-se a VMs.

Migrar para o Cloud NAT

Com o Cloud NAT disponível na versão 1.15, a configuração de NAT de saída padrão do projeto por projeto fica obsoleta. Recomendamos que os usuários migrem as configurações de saída da configuração de NAT de saída padrão do projeto para o Cloud NAT.

O NAT de saída padrão do projeto e o Cloud NAT não são compatíveis entre si. Em outras palavras, um determinado endpoint de pod ou VM só pode usar um dos dois. Para migrar endpoints de uma configuração para outra, é necessário desativá-los em uma e ativá-los na outra.

Para iniciar a migração, desative a configuração mais antiga dos endpoints que você quer migrar. Há duas maneiras de fazer isso:

  • Desativar o NAT de saída padrão do projeto para todo o projeto: desative o NAT de saída padrão do projeto para todos os endpoints que estão no projeto atribuindo o rótulo networking.gdc.goog/allocate-egress-ip: "false" ao projeto.
  • Desativar o NAT de saída padrão do projeto por endpoint: desative o NAT de saída padrão do projeto para um determinado endpoint de pod ou VM removendo o rótulo egress.networking.gke.io/enabled:"true" do pod ou da VM.

Para continuar a migração, à medida que cada endpoint é removido do NAT de saída padrão, ele pode ser adicionado a um gateway do Cloud NAT adicionando rótulos ao endpoint que correspondam aos seletores de rótulo do gateway escolhido.

Consulte o Cloud NAT e as páginas a seguir para instruções sobre como configurar o Cloud NAT.

Rastreamento de IP de saída

Com o NAT de saída padrão, os IPs de saída usados para o tráfego de saída NAT são incluídos no status do projeto. Com o Cloud NAT, o objeto do projeto não contém IPs de saída. Em vez disso, o usuário poderá listar os IPs usados pelo gateway do Cloud NAT listando as sub-redes atribuídas ao gateway.