이 페이지에서는 워크로드가 조직 외부로 나갈 수 있도록 프로젝트의 가상 머신 (VM) 또는 포드에서 취해야 하는 이그레스 연결 작업을 설명합니다. 이 절차에서는 아웃바운드 트래픽을 명시적으로 사용 설정하고 워크로드가 조직 외부와 통신할 수 있도록 배포에 필수 라벨을 추가하는 방법을 보여줍니다.
기본적으로 Google Distributed Cloud (GDC)는 조직 외부로 나가는 프로젝트의 워크로드를 에어 갭으로 차단합니다. 플랫폼 관리자 (PA)가 프로젝트의 데이터 무단 반출 보호를 사용 중지한 경우 워크로드가 조직을 종료할 수 있습니다. 데이터 유출 방지 기능을 사용 중지하는 것 외에도 애플리케이션 운영자 (AO)는 포드의 워크로드에 라벨 egress.networking.gke.io/enabled: true를 추가하여 해당 포드의 이그레스 연결을 사용 설정해야 합니다. 프로젝트에 잘 알려진 IP 주소를 할당하고 사용하면 조직에서 나가는 트래픽에 소스 네트워크 주소 변환 (NAT)이 실행됩니다.
이그레스 연결을 위해 포드에서 워크로드를 구성하려면 먼저 프로젝트에 데이터 유출 방지가 사용 중지되어 있는지 확인해야 합니다. 그런 다음 egress.networking.gke.io/enabled: true 라벨이 포드에 추가되었는지 확인합니다. Deployment 또는 Daemonset 구조와 같은 상위 수준 구조를 사용하여 포드 집합을 관리하는 경우 해당 사양에서 포드 라벨을 구성해야 합니다.
다음 예에서는 매니페스트 파일에서 Deployment를 만드는 방법을 보여줍니다. 샘플 파일의 labels 필드에는 프로젝트의 아웃바운드 트래픽을 명시적으로 사용 설정하는 egress.networking.gke.io/enabled: true 값이 포함되어 있습니다. 이 라벨은 배포의 각 포드에 추가되며 포드의 워크로드가 조직을 종료할 수 있도록 합니다.
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
다음을 바꿉니다.
USER_CLUSTER_KUBECONFIG: 컨테이너 워크로드를 배포할 사용자 클러스터의 kubeconfig 파일입니다.
DEPLOYMENT_NAME: 컨테이너 워크로드를 배포할 사용자 클러스터의 kubeconfig 파일입니다.
APP_NAME: 배포 내에서 실행할 애플리케이션의 이름입니다.
NUMBER_OF_REPLICAS: 배포에서 관리하는 복제된 Pod 객체 수입니다.
CONTAINER_NAME: 컨테이너의 이름입니다.
CONTAINER_IMAGE: 컨테이너 이미지의 이름입니다. REGISTRY_PATH/hello-app:1.0와 같은 컨테이너 레지스트리 경로와 이미지 버전을 포함해야 합니다.
이그레스 연결을 위해 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."]]