Faça a gestão da NAT de saída predefinida do projeto

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

Vista geral

Esta página descreve as ações de conetividade de saída que tem de realizar numa máquina virtual (VM) ou num pod num projeto para permitir que as cargas de trabalho saiam da organização, usando a opção de configuração de NAT de saída predefinida do projeto (descontinuada).

O procedimento mostra como adicionar uma etiqueta obrigatória às implementações para ativar explicitamente o tráfego de saída e permitir que as cargas de trabalho comuniquem fora da organização.

Por predefinição, o Google Distributed Cloud (GDC) isolado impede que as cargas de trabalho num projeto 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 a exfiltração de dados para o projeto. Os PAs podem fazê-lo anexando a etiqueta networking.gdc.goog/enable-default-egress-allow-to-outside-the-org: "true" ao projeto. Além de desativar a proteção contra a exfiltração de dados, o operador da aplicação (AO) tem de adicionar a etiqueta egress.networking.gke.io/enabled: true na carga de trabalho do pod para ativar a conetividade de saída para esse pod. Quando atribui e usa um endereço IP conhecido para o projeto, este executa uma tradução de endereço de rede (NAT) de origem no tráfego de saída da organização.

Pode gerir a conetividade de saída das cargas de trabalho num pod ou numa VM.

Faça a gestão do tráfego de saída de cargas de trabalho num pod

Para configurar cargas de trabalho num pod para a conetividade de saída, primeiro tem de garantir que a proteção contra a exfiltração de dados está desativada para o projeto. Em seguida, certifique-se de que a etiqueta egress.networking.gke.io/enabled: true é adicionada no pod. Se estiver a usar uma construção de nível superior, como construções Deployment ou Daemonset, para gerir conjuntos de pods, tem de configurar a etiqueta do pod nessas especificações.

O exemplo seguinte mostra como criar um Deployment a partir do respetivo ficheiro de manifesto. O ficheiro de exemplo contém o valor egress.networking.gke.io/enabled: true no campo labels para ativar explicitamente o tráfego de saída do projeto. Esta etiqueta é adicionada a cada pod na implementaçã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 o seguinte:

  • USER_CLUSTER_KUBECONFIG: o ficheiro kubeconfig para o cluster de utilizador no qual está a implementar cargas de trabalho de contentores.

  • DEPLOYMENT_NAME: o ficheiro kubeconfig para o cluster do utilizador no qual está a implementar cargas de trabalho de contentores.

  • APP_NAME: o nome da aplicação a executar na implementação.

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

  • CONTAINER_NAME: o nome do contentor.

  • CONTAINER_IMAGE: o nome da imagem do contentor. Tem de incluir o caminho do registo de contentores e a versão da imagem, como REGISTRY_PATH/hello-app:1.0.

Por 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

Faça a gestão do tráfego de saída de cargas de trabalho numa VM

Para configurar cargas de trabalho numa VM para conetividade de saída, pode usar a consola do GDC para a configuração de VMs ou criar um recurso VirtualMachineExternalAccess. Para obter informações sobre como ativar uma VM com acesso externo para transferência de dados, consulte o artigo Ative o acesso externo na secção Ligue-se a VMs.

Migre para o Cloud NAT

Com a disponibilização do Cloud NAT na versão 1.15, a configuração de NAT de saída do projeto predefinida por projeto fica descontinuada. Recomendamos que os utilizadores migrem as respetivas configurações de saída da configuração de NAT de saída do projeto predefinido para o Cloud NAT.

O NAT de saída do projeto predefinido e o Cloud NAT não são compatíveis entre si. Por outras palavras, um determinado ponto final de VM ou pod só pode usar um dos dois. Para migrar os pontos finais de uma configuração para outra, tem de os desativar numa e, em seguida, ativá-los na outra.

Para iniciar a migração, desative a configuração mais antiga nos pontos finais que quer migrar. Existem duas formas de o fazer:

  • Desativar o NAT de saída predefinido do projeto para todo o projeto: desative o NAT de saída predefinido do projeto para todos os pontos finais que estão no projeto atribuindo a etiqueta networking.gdc.goog/allocate-egress-ip: "false" ao projeto.
  • Desative o NAT de saída predefinido do projeto por ponto final: desative o NAT de saída predefinido do projeto para um pod ou um ponto final de VM específico removendo a etiqueta egress.networking.gke.io/enabled:"true" do pod ou da VM.

Para continuar a migração, à medida que cada ponto final é removido do NAT de saída predefinido, pode ser adicionado a um gateway NAT da nuvem adicionando etiquetas ao ponto final que correspondam aos seletores de etiquetas do gateway escolhido.

Consulte o artigo NAT na nuvem e as páginas seguintes para obter instruções sobre como configurar a NAT na nuvem.

Acompanhamento de IP de saída

Com a NAT de saída predefinida, os IPs de saída usados para o tráfego de saída da NAT estão incluídos no estado do projeto. Com o Cloud NAT, o objeto Project não contém IPs de saída. Em alternativa, o utilizador pode listar os IPs usados pelo gateway Cloud NAT listando as sub-redes atribuídas ao gateway.