このページでは、ワークロードが組織外に出るようにするために、プロジェクト内の仮想マシン(VM)または Pod で実行する必要がある下り(外向き)接続アクションについて説明します。この手順では、アウトバウンド トラフィックを明示的に有効にして、ワークロードが組織外で通信できるようにするために、デプロイに必須ラベルを追加する方法について説明します。
下り(外向き)接続用に Pod のワークロードを構成するには、まずプロジェクトでデータ漏洩保護が無効になっていることを確認する必要があります。次に、Pod に egress.networking.gke.io/enabled: true ラベルが追加されていることを確認します。Deployment などの上位レベルのコンストラクトまたは Daemonset コンストラクトを使用して 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
下り(外向き)接続用に VM のワークロードを構成するには、VM 構成に GDC コンソールを使用するか、VirtualMachineExternalAccess リソースを作成します。データ転送用に外部アクセスで VM を有効にする方法については、VM に接続するセクションの外部アクセスを有効にするをご覧ください。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 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."]]