Esta página descreve a configuração padrão de NAT de saída do projeto, agora descontinuada, que 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 NAT de saída padrão do projeto (descontinuada).
O procedimento mostra como adicionar um rótulo obrigatório aos implantes 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) com isolamento físico impede que as cargas de trabalho em um projeto saiam da organização. As cargas de trabalho podem sair da organização se o administrador da plataforma (PA, na sigla em inglês) tiver desativado a proteção contra exfiltração de dados do projeto. Para isso, basta anexar o rótulo
networking.gdc.goog/enable-default-egress-allow-to-outside-the-org: "true" ao
projeto. Além de desativar a proteção contra exfiltração de dados, o
operador de aplicativo (AO) precisa adicionar o rótulo egress.networking.gke.io/enabled:
true na 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 realiza uma conversão de endereços de rede (NAT) de origem no tráfego de saída da organização.
É possível gerenciar a conectividade de saída de 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 uma construção 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 um Deployment do arquivo de manifesto dele.
O arquivo 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. 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 objetosPodreplicados que a implantação gerencia.CONTAINER_NAME: o nome do contêiner.CONTAINER_IMAGE: o nome da imagem do contêiner. Inclua o caminho do registro de contêiner e a versão da imagem, comoREGISTRY_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 saber como ativar uma VM com acesso externo para transferência de dados, consulte Ativar acesso externo na seção Conectar a VMs.
Migrar para o Cloud NAT
Com a disponibilidade do Cloud NAT na versão 1.15, a configuração padrão de NAT de saída por projeto foi descontinuada. Recomendamos que os usuários migrem as configurações de saída da configuração padrão de NAT de saída do projeto para o Cloud NAT.
O NAT de saída do projeto padrão 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, desative os endpoints em uma e ative 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 do 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 endpoint de pod ou VM específico 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. Para isso, adicione rótulos ao endpoint que correspondam aos seletores de rótulo do gateway escolhido.
Consulte 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 usados para o tráfego de saída NAT são incluídos no status do projeto. Com o Cloud NAT, o objeto Project 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 a ele.