Gestire il traffico in uscita dai carichi di lavoro
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
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. 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 carichi di lavoro di un progetto di uscire dall'organizzazione. I workload possono uscire dall'organizzazione se l'amministratore della piattaforma ha disattivato la protezione dall'esfiltrazione di dati per il 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 attivare 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. Dopodiché, 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--kubeconfigUSER_CLUSTER_KUBECONFIG\apply-f-<<EOF
apiVersion:apps/v1
kind:Deployment
metadata:
name:DEPLOYMENT_NAME
spec:
replicas:NUMBER_OF_REPLICASselector:
matchLabels:
run:APP_NAMEtemplate:
metadata:
labels:# The labels given to each pod in the deployment, which are used# to manage all pods in the deployment.run:APP_NAMEegress.networking.gke.io/enabled:truespec:# The pod specification, which defines how each pod runs in the deployment.containers:
-name:CONTAINER_NAMEimage:CONTAINER_IMAGE
EOF
Sostituisci quanto segue:
USER_CLUSTER_KUBECONFIG: il file kubeconfig per il cluster utente in cui stai eseguendo il deployment dei carichi di lavoro 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 container.
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.
Gestisci il traffico in uscita dai carichi di lavoro in una VM
Per configurare i workload 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 Attiva l'accesso esterno nella sezione Connettersi alle VM.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 UTC."],[[["\u003cp\u003eGoogle Distributed Cloud (GDC) air-gapped environments block workloads from exiting the organization by default, but this can be overridden by a Platform Administrator (PA) disabling data exfiltration protection for a specific project.\u003c/p\u003e\n"],["\u003cp\u003eTo enable outbound traffic for workloads in a pod, an Application Operator (AO) must add the label \u003ccode\u003eegress.networking.gke.io/enabled: true\u003c/code\u003e to the pod, and this label can also be added to higher-level constructs like \u003ccode\u003eDeployment\u003c/code\u003e or \u003ccode\u003eDaemonset\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eConfiguring egress connectivity for pods also requires ensuring data exfiltration protection is disabled for the project.\u003c/p\u003e\n"],["\u003cp\u003eWorkloads in a VM can also have egress connectivity using the GDC console for VM configuration or create a \u003ccode\u003eVirtualMachineExternalAccess\u003c/code\u003e resource.\u003c/p\u003e\n"]]],[],null,["# Manage outbound traffic from workloads\n\nThis page describes egress connectivity actions you must take on a virtual machine (VM) or pod in a project to let workloads go out of the organization. The procedure shows how to add a required label to deployments to explicitly enable outbound traffic and let workloads communicate outside of the organization.\n\nBy default, Google Distributed Cloud (GDC) air-gapped blocks workloads in a project from going out of the organization. Workloads can exit the organization if your Platform Administrator (PA) has disabled data exfiltration protection for the project. In addition to disabling data exfiltration protection, the Application Operator (AO) must add the label `egress.networking.gke.io/enabled: true` on the pod workload to enable egress connectivity for that pod. When you allocate and use a well-known IP address for the project, it performs a source network address translation (NAT) on the outbound traffic from the organization.\n\nYou can manage egress connectivity from workloads in a [pod](#egress-pod) or a [VM](#egress-vm).\n\nManage outbound traffic from workloads in a pod\n-----------------------------------------------\n\nTo configure workloads in a pod for egress connectivity, first you must ensure [data exfiltration protection is disabled for the project](/distributed-cloud/hosted/docs/latest/gdch/application/ao-user/configure-pnp#disable-data-exfiltration-protection). Then, ensure that the `egress.networking.gke.io/enabled: true` label is added on the pod. If you are using a higher-level construct like `Deployment` or `Daemonset` constructs to manage sets of pods, then you must configure the pod label in those specifications.\n\nThe following example shows how to create a `Deployment` from its manifest file. The sample file contains the value `egress.networking.gke.io/enabled: true` on the `labels` field to explicitly enable outbound traffic from the project. This label is added to each pod in the deployment and allows workloads in the pods to exit the organization. \n\n kubectl --kubeconfig \u003cvar translate=\"no\"\u003eUSER_CLUSTER_KUBECONFIG\u003c/var\u003e \\\n apply -f - \u003c\u003cEOF\n apiVersion: apps/v1\n kind: Deployment\n metadata:\n name: \u003cvar translate=\"no\"\u003eDEPLOYMENT_NAME\u003c/var\u003e\n spec:\n replicas: \u003cvar translate=\"no\"\u003eNUMBER_OF_REPLICAS\u003c/var\u003e\n selector:\n matchLabels:\n run: \u003cvar translate=\"no\"\u003eAPP_NAME\u003c/var\u003e\n template:\n metadata:\n labels: # The labels given to each pod in the deployment, which are used\n # to manage all pods in the deployment.\n run: \u003cvar translate=\"no\"\u003eAPP_NAME\u003c/var\u003e\n egress.networking.gke.io/enabled: true\n spec: # The pod specification, which defines how each pod runs in the deployment.\n containers:\n - name: \u003cvar translate=\"no\"\u003eCONTAINER_NAME\u003c/var\u003e\n image: \u003cvar translate=\"no\"\u003eCONTAINER_IMAGE\u003c/var\u003e\n EOF\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eUSER_CLUSTER_KUBECONFIG\u003c/var\u003e: the kubeconfig file for the\n user cluster to which you're deploying container workloads.\n\n- \u003cvar translate=\"no\"\u003eDEPLOYMENT_NAME\u003c/var\u003e: the kubeconfig file for the user\n cluster to which you're deploying container workloads.\n\n- \u003cvar translate=\"no\"\u003eAPP_NAME\u003c/var\u003e: the name of the application to run within\n the deployment.\n\n- \u003cvar translate=\"no\"\u003eNUMBER_OF_REPLICAS\u003c/var\u003e: the number of replicated `Pod`\n objects that the deployment manages.\n\n- \u003cvar translate=\"no\"\u003eCONTAINER_NAME\u003c/var\u003e: the name of the container.\n\n- \u003cvar translate=\"no\"\u003eCONTAINER_IMAGE\u003c/var\u003e: the name of the container image. You\n must include the container registry path and version of the image, such as\n \u003cvar class=\"readonly\" translate=\"no\"\u003eREGISTRY_PATH\u003c/var\u003e`/hello-app:1.0`.\n\nFor example: \n\n apiVersion: apps/v1\n kind: Deployment\n metadata:\n name: my-app\n spec:\n replicas: 3\n selector:\n matchLabels:\n run: my-app\n template:\n metadata:\n labels:\n run: my-app\n egress.networking.gke.io/enabled: true\n spec:\n containers:\n - name: hello-app\n image: \u003cvar class=\"readonly\" translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-l devsite-syntax-l-Scalar devsite-syntax-l-Scalar-Plain\"\u003eREGISTRY_PATH\u003c/span\u003e\u003c/var\u003e/hello-app:1.0\n\nManage outbound traffic from workloads in a VM\n----------------------------------------------\n\nTo configure workloads in a VM for egress connectivity, you can use the GDC console for VM configuration or create a `VirtualMachineExternalAccess` resource. For information about how to enable a VM with external access for data transfer, see [Enable external access](/distributed-cloud/hosted/docs/latest/gdch/application/ao-user/vms/connect-to-vm/ip-addresses#enable-external-access) on the *Connect to VMs* section."]]