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, através da opção de configuração de NAT de saída predefinida do projeto (descontinuada).

A NAT de saída predefinida do projeto não é compatível com clusters padrão. Use NAT na nuvem se precisar de controlar a saída para clusters padrão.

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 bloqueia as cargas de trabalho num 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 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" a o projeto. Além de desativar a proteção contra a exfiltração de dados, o operador de aplicações (AO) tem de adicionar a etiqueta egress.networking.gke.io/enabled: true à carga de trabalho do pod para ativar a conetividade de saída para esse pod. Quando aloca e usa um endereço IP conhecido para o projeto, este realiza uma tradução de endereço de rede de origem (NAT) no tráfego de saída da organização.

Pode gerir a conetividade de saída a partir de 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 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 ao pod. Se estiver a usar uma construção de nível superior, como as 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 uma 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 do cluster do utilizador para o qual está a implementar cargas de trabalho de contentores.

  • DEPLOYMENT_NAME: o ficheiro kubeconfig do cluster do utilizador para o 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 Pod replicados que a implementação gere.

  • 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 da VM ou criar um recurso VirtualMachineExternalAccess. Para saber 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 a NAT na nuvem

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

A NAT de saída predefinida do projeto e a NAT na nuvem não são compatíveis entre si. Por outras palavras, um determinado ponto final de pod ou VM só pode usar uma das duas. Para migrar pontos finais de uma configuração para a 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:

  • Desative a NAT de saída predefinida do projeto para todo o projeto: desative a NAT de saída predefinida 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 a NAT de saída predefinida do projeto por ponto final: desative a NAT de saída predefinida do projeto para um determinado ponto final de pod ou VM 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 da NAT de saída predefinida, pode ser adicionado a uma gateway da NAT na nuvem adicionando etiquetas ao ponto final que correspondam aos seletores de etiquetas da gateway escolhida.

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

Acompanhamento do IP de saída

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