本页面介绍了您必须在项目中的虚拟机 (VM) 或 pod 上执行的出站连接操作,以允许工作负载离开组织。此过程演示了如何向部署添加必需的标签,以明确启用出站流量并允许工作负载在组织外部进行通信。
默认情况下,经过网闸隔离的 Google Distributed Cloud (GDC) 会阻止项目中的工作负载离开组织。如果平台管理员 (PA) 已针对项目停用数据渗漏保护功能,工作负载可能会退出组织。除了停用数据渗漏防护功能之外,应用操作员 (AO) 还必须在 pod 工作负载上添加标签 egress.networking.gke.io/enabled: true,以启用该 pod 的出站连接。当您为项目分配并使用知名 IP 地址时,系统会对组织的出站流量执行源网络地址转换 (NAT)。
如需配置 pod 中的工作负载以实现出站连接,您必须先确保为项目停用数据渗漏防护功能。然后,确保在 pod 上添加了 egress.networking.gke.io/enabled: true 标签。如果您使用 Deployment 或 Daemonset 等更高级别的构造来管理一组 Pod,则必须在这些规范中配置 Pod 标签。
以下示例展示了如何从清单文件创建 Deployment。示例文件中的 labels 字段包含值 egress.networking.gke.io/enabled: true,用于明确启用来自项目的出站流量。此标签会添加到部署中的每个 pod,并允许 pod 中的工作负载退出组织。
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
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-04。"],[[["\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."]]