Gestisci il gateway NAT in uscita predefinito del progetto

Questa pagina descrive la configurazione NAT in uscita predefinita del progetto, ora ritirata, che può essere utilizzata per consentire ai carichi di lavoro di connettersi all'esterno dell'organizzazione. Questa pagina contiene anche istruzioni su come eseguire la migrazione alla soluzione consigliata, Cloud NAT.

Panoramica

Questa pagina descrive le azioni di connettività in uscita che devi intraprendere su una macchina virtuale (VM) o un pod in un progetto per consentire ai carichi di lavoro di uscire dall'organizzazione utilizzando l'opzione di configurazione NAT in uscita predefinita del progetto (ritirata).

La procedura mostra come aggiungere un'etichetta obbligatoria ai deployment per attivare esplicitamente il traffico in uscita e consentire ai workload di comunicare al di fuori dell'organizzazione.

Per impostazione predefinita, Google Distributed Cloud (GDC) con air gap impedisce ai workload di un progetto di uscire dall'organizzazione. I carichi di lavoro possono uscire dall'organizzazione se l'amministratore della piattaforma ha disattivato la protezione dall'esfiltrazione di dati per il progetto. I PA possono farlo allegando l'etichetta networking.gdc.goog/enable-default-egress-allow-to-outside-the-org: "true" al progetto. Oltre a disattivare la protezione dall'esfiltrazione di dati, l'operatore dell'applicazione (AO) deve aggiungere l'etichetta egress.networking.gke.io/enabled: true al carico di lavoro del pod per abilitare la connettività di uscita per quel pod. Quando allochi e utilizzi un indirizzo IP noto per il progetto, esegue una Network Address Translation (NAT) di origine sul traffico in uscita dall'organizzazione.

Puoi gestire la connettività in uscita dai carichi di lavoro in un pod o in una VM.

Gestisci il traffico in uscita dai carichi di lavoro in un pod

Per configurare i carichi di lavoro in un pod per la connettività di uscita, devi prima assicurarti che la protezione dall'esfiltrazione dei dati sia disattivata per il progetto. Poi, assicurati che l'etichetta egress.networking.gke.io/enabled: true sia aggiunta sul pod. Se utilizzi un costrutto di livello superiore come Deployment o Daemonset per gestire i set di pod, devi configurare l'etichetta del pod in queste specifiche.

L'esempio seguente mostra come creare un Deployment dal relativo file manifest. Il file di esempio contiene il valore egress.networking.gke.io/enabled: true nel campo labels per attivare esplicitamente il traffico in uscita dal progetto. Questa etichetta viene aggiunta a ogni pod nel deployment e consente ai workload nei pod di uscire dall'organizzazione.

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

Sostituisci quanto segue:

  • USER_CLUSTER_KUBECONFIG: il file kubeconfig per il cluster utente in cui stai eseguendo il deployment dei workload dei container.

  • DEPLOYMENT_NAME: il file kubeconfig per il cluster utente in cui stai eseguendo il deployment dei carichi di lavoro dei container.

  • APP_NAME: il nome dell'applicazione da eseguire all'interno del deployment.

  • NUMBER_OF_REPLICAS: il numero di oggetti Pod replicati gestiti dal deployment.

  • CONTAINER_NAME: il nome del contenitore.

  • CONTAINER_IMAGE: il nome dell'immagine container. Devi includere il percorso del registro dei container e la versione dell'immagine, ad esempio REGISTRY_PATH/hello-app:1.0.

Ad esempio:

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

Gestisci il traffico in uscita dai carichi di lavoro in una VM

Per configurare i carichi di lavoro in una VM per la connettività in uscita, puoi utilizzare la console GDC per la configurazione della VM o creare una risorsa VirtualMachineExternalAccess. Per informazioni su come attivare una VM con accesso esterno per il trasferimento dei dati, consulta Attivare l'accesso esterno nella sezione Connettersi alle VM.

Migrazione a Cloud NAT

Con la disponibilità di Cloud NAT nella versione 1.15, la configurazione NAT di uscita predefinita per progetto diventa obsoleta. È consigliabile che gli utenti migrino le configurazioni di uscita dalla configurazione NAT in uscita del progetto predefinito a Cloud NAT.

NAT in uscita predefinito del progetto e Cloud NAT non sono compatibili tra loro. In altre parole, un determinato endpoint di pod o VM può utilizzare solo uno dei due. Per eseguire la migrazione degli endpoint da una configurazione all'altra, devi disattivarli in una e attivarli nell'altra.

Per iniziare la migrazione, disattiva la configurazione precedente dagli endpoint che vuoi migrare. Esistono due modi per eseguire questa operazione:

  • Disabilita NAT in uscita predefinito del progetto per l'intero progetto: disabilita NAT in uscita predefinito del progetto per tutti gli endpoint del progetto assegnando l'etichetta networking.gdc.goog/allocate-egress-ip: "false" al progetto.
  • Disattiva NAT in uscita predefinita del progetto per endpoint: disattiva NAT in uscita predefinita del progetto per un determinato endpoint di pod o VM rimuovendo l'etichetta egress.networking.gke.io/enabled:"true" dal pod o dalla VM.

Per continuare la migrazione, man mano che ogni endpoint viene rimosso dalla NAT in uscita predefinita, può essere aggiunto a un gateway Cloud NAT aggiungendo etichette all'endpoint che corrispondono ai selettori di etichette del gateway scelto.

Consulta Cloud NAT e le pagine seguenti per istruzioni su come configurare Cloud NAT.

Monitoraggio IP in uscita

Con NAT in uscita predefinito, gli IP in uscita utilizzati per NAT del traffico in uscita sono inclusi nello stato del progetto. Con Cloud NAT, l'oggetto Project non contiene IP di uscita. L'utente potrà invece elencare gli IP utilizzati dal gateway Cloud NAT elencando le subnet assegnate al gateway.