이 페이지에서는 포드 수준에서 방화벽 규칙을 사용하여 포드와 서비스 간 네트워크 트래픽 흐름을 제어하는 방법을 설명합니다.
애플리케이션에 대한 네트워크 정책은 포드 간 통신 트래픽 규칙을 정의하는 데 도움이 됩니다. 여기서는 포드가 애플리케이션 내에서 서로 그리고 외부 엔드포인트와 통신하는 방법을 제어합니다. 멀티 네트워크가 사용 설정된 Google Kubernetes Engine(GKE) Enterprise 버전 클러스터의 포드 네트워크에서 네트워크 정책을 사용 설정할 수 있습니다. 사용자 지정 포드 네트워크에 해당하는 추가 포드 인터페이스에 네트워크 정책을 적용할 수 있습니다.
멀티 네트워크 네트워크 정책을 사용하는 이유
다음과 같은 시나리오에서 멀티 네트워크 네트워크 정책을 사용해야 할 수 있습니다.
향상된 네트워크 보안: 특정 포드 네트워크에 대한 네트워크 정책을 정의하여 민감한 워크로드 또는 데이터를 격리하고 보호하려고 합니다. 멀티 네트워킹 네트워크 정책은 노출을 제한하고 공격 표면을 줄입니다.
세밀한 트래픽 제어: 서로 다른 포드 네트워크에서 포드와 서비스 간의 트래픽 흐름을 정밀하게 제어하여 복잡한 네트워크 토폴로지 및 보안 요구사항을 허용하려 합니다.
멀티 테넌트 환경: 서로 다른 테넌트 또는 애플리케이션에 대해 격리된 네트워크를 생성하여 각 포드 네트워크 내에서 네트워크 액세스에 대한 제어를 유지하면서 서로의 커뮤니케이션을 방해하지 않도록 합니다.
리소스 사용률 최적화: 특정 포드 네트워크에서 네트워크 정책을 구현하여 리소스를 효율적으로 할당하고 애플리케이션 요구사항에 따라 트래픽의 우선순위를 지정하여 성능과 안정성을 향상시키려 합니다.
컨테이너화된 네트워크 기능(CNF)을 위한 보안: 동일한 포드 내의 데이터 영역 트래픽에서 관리 트래픽을 분리하여 잠재적인 보안 침해 및 무단 액세스를 방지하려 합니다.
멀티 네트워크 네트워크 정책이 포드 네트워크에서 작동하는 방식
다음 다이어그램은 주석을 사용하여 특정 포드 네트워크에 적용된 네트워크 정책이 GKE 클러스터 내 포드 간의 트래픽 흐름을 제어하는 방법을 보여줍니다.
앞의 다이어그램은 포드(컨테이너화된 애플리케이션)를 실행하는 여러 워커 노드와 네트워크 인프라를 사용하여 동일한 노드 내에서 또는 다른 노드 간에 커뮤니케이션하는 방법을 보여줍니다. 또한 네트워크 정책을 사용하여 트래픽 흐름을 제어하는 방법과 보안 향상 및 조직 강화를 위해 VPC와 서브넷을 사용하여 네트워크를 세분화하는 방법도 설명합니다.
대상 네트워크 정책으로 트래픽 격리: 네트워크 정책은 networking.gke.io/network: blue-Pod-network 주석으로 인해 '파란색' 포드 네트워크의 트래픽에만 영향을 미칩니다. 기본 포드 네트워크의 트래픽은 제한되지 않은 상태로 유지됩니다.
포드 네트워크 정책으로 단방향 트래픽 적용: 이전 다이어그램에서 네트워크 정책은 포드1이 '파란색' 포드 네트워크에서 포드2로 트래픽을 전송하도록 허용합니다. 포드2는 동일한 네트워크에서 포드1로 트래픽을 다시 보낼 수 없습니다. 'test-app-2'로 라벨이 지정된 포드의 네트워크 정책은 단방향 채널로 작동합니다.
특히 'test-app-3'으로 라벨이 지정된 포드로 나가는 트래픽만 허용하여 'test-app-1'과 같은 다른 포드와의 통신을 방지합니다.
기본적으로 나가는 트래픽 허용: 포드(이 예시에서는 포드1)에 이그레스 정책이 정의되어 있지 않으면 모든 나가는 트래픽이 '파란색' 네트워크 인터페이스에서 기본적으로 허용됩니다.
기존 기능 호환성 보장: 라벨 선택기 및 IP 주소 블록과 같은 모든 표준 GKE 네트워크 정책 옵션은 멀티 네트워크 네트워크 정책과 함께 작동합니다.
주석으로 네트워크 정책 범위 제어:
주석 없이 네트워크 정책을 만들 경우 GKE는 연결된 포드 네트워크에 관계없이 선택된 네임스페이스의 포드에 대한 모든 네트워크 인터페이스에 멀티 네트워크 네트워크 정책을 적용합니다.
주석을 포함하고 유효한 포드 네트워크의 이름을 지정하면(예: networking.gke.io/network: blue-Pod-network) GKE에서 특정 포드 네트워크에 연결된 포드에 정책을 적용합니다.
주석이 클러스터에 실제로 없는 포드 네트워크를 참조하는 경우 GKE는 네트워크 정책을 어떤 포드에도 적용하지 않습니다. 이는 지정된 존재하지 않는 네트워크에 연결된 포드가 없기 때문입니다.
멀티 네트워크 인터페이스가 있는 포드의 네트워크 간 커뮤니케이션 유지: 네트워크 정책을 적용하여 포드 내의 특정 포드 네트워크 트래픽을 제한하는 경우, 동일한 포드에 연결된 다른 포드 네트워크의 트래픽에는 영향을 미치지 않습니다.
이점
멀티 네트워크 네트워크 정책을 사용할 때의 이점은 다음과 같습니다.
보안 강화: 세부적인 수준으로 네트워크 정책을 적용하여 GKE 클러스터 내에서 무단 액세스 및 측면 이동과 관련된 위험을 완화할 수 있습니다.
유연성 및 맞춤설정: 다양한 워크로드와 애플리케이션을 수용함으로써 여러 포드 네트워크에 대한 특정 보안 및 트래픽 관리 요구사항을 충족하도록 네트워크 정책을 조정할 수 있습니다.
간소화된 네트워크 관리: 네트워크 정책을 사용하여 네트워크 관리를 간소화하고 복잡성을 줄임으로써 과도한 포드 네트워크 생성을 방지하고 커뮤니케이션을 세밀하게 제어할 수 있습니다.
비용 최적화: 여러 포드 네트워크를 만들 필요가 없으므로 리소스 사용률을 최적화하고 네트워크 인프라와 관련된 비용을 줄일 수 있습니다.
CNF를 위한 향상된 보호 모드: 관리 및 데이터 영역 트래픽을 격리하고 각 배포에 특정 네트워크 정책을 적용하여 CNF 배포의 보안과 무결성을 보장할 수 있습니다.
[[["이해하기 쉬움","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-08(UTC)"],[],[],null,["# About multi-network network policies\n\n[Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\n|\n| **Preview**\n|\n|\n| This feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\nThis page explains how to control the network traffic flow between Pods and\nServices using firewall rules at the Pod level.\n\n[Network policies for\napplications](/kubernetes-engine/docs/tutorials/network-policy) help you define\ncommunication traffic rules between Pods. It controls how Pods communicate with\neach other within their applications and with external endpoints. You can enable\nnetwork policy on Pod-networks in Google Kubernetes Engine (GKE) Enterprise edition clusters that have\nmulti-network enabled. You can enforce network policies on additional Pod\ninterfaces that correspond to user-specified Pod-networks.\n\nWhy use multi-network network policies\n--------------------------------------\n\nYou might want to use multi-network network policies in the following\nscenarios:\n\n- **Enhanced network security**: You want to isolate and protect\n sensitive workloads or data by defining network policies for specific\n Pod-networks. Multi-networking network policies limit exposure and reduce\n the attack surface.\n\n- **Fine-grained traffic control**: You want to achieve precise control\n over traffic flow between Pods and Services on different Pod-networks,\n allowing for complex network topologies and security requirements.\n\n- **Multi-tenant environments**: You want to create isolated networks\n for different tenants or applications, ensuring they can't interfere with\n each other's communication, while maintaining control over network access\n within each Pod-network.\n\n- **Optimize resource utilization**: You want to implement network\n policies on specific Pod-networks to efficiently allocate resources and\n prioritize traffic based on application requirements, improving performance\n and reliability.\n\n- **Security for Containerized Network Functions (CNFs)**: You want to\n segregate management traffic from dataplane traffic within the same Pod,\n preventing potential security breaches and unauthorized access.\n\nHow multi-network network policies work with Pod-networks\n---------------------------------------------------------\n\nThe following diagram illustrates how network policies, applied to specific\nPod-networks using annotations, control traffic flow between Pods within a\nGKE cluster.\n\nThe preceding diagram shows multiple worker nodes running Pods (containerized\napplications) and how they communicate within the same node or across different\nnodes using the network infrastructure. It also illustrates the use of network\npolicies to control traffic flow and the segmentation of the network using\nVPCs and subnets for enhanced security and organization.\n\n1. **Isolates traffic with targeted Network Policies** : The network policies only affect traffic on the \"blue\" Pod-network because of the annotation `networking.gke.io/network: blue-Pod-network`. Traffic on the default Pod-network remains unrestricted.\n2. **Enforces one-way traffic with Pod-network policies**: In the preceding diagram, network policies allow Pod1 to send traffic to Pod2 on the \"blue\" Pod-network. Pod2 can't send traffic back to Pod1 on the same network. The network policy for Pods labeled 'test-app-2' functions as a one-way channel. It specifically allows outgoing traffic only towards Pods labeled 'test-app-3', preventing communication with other Pods like 'test-app-1'.\n3. **Allows outgoing traffic by default**: If no egress policy is defined for a Pod (Pod1 in this example), all outgoing traffic is allowed by default on the \"blue\" network interface.\n4. **Ensures existing features compatibility**: All standard GKE network policy options like label selectors and IP address blocks work with multi-network network policies.\n5. **Controls network policy scope with annotations** :\n 1. If you create a network policy without annotation, GKE applies multi-network network policies to all network interfaces on the Pods in the selected namespace, regardless of which Pod-networks they are connected to.\n 2. If you include the annotation and specify the name of a valid Pod-network (for example, `networking.gke.io/network: blue-Pod-network`), GKE applies the policy to Pods connected to that specific Pod-network.\n 3. If the annotation references the Pod-network that doesn't actually exist in your cluster, GKE doesn't apply the network policy to any Pods at all. This is because no Pods are connected to the specified non-existent network.\n6. **Maintains cross-network communication for Pods with multiple network\n interfaces**: If you apply a network policy to restrict traffic on a specific Pod-network within a Pod, it won't affect the traffic on other Pod-networks connected to the same Pod.\n\nBenefits\n--------\n\nFollowing are the benefits in using multi-network network policies:\n\n- **Improved Security**: You can mitigate risks associated with unauthorized\n access and lateral movement within the GKE cluster by\n applying network policies at a granular level.\n\n- **Flexibility and Customization**: You can tailor network policies to meet\n your specific security and traffic management needs for different\n Pod-networks by accommodating diverse workloads and applications.\n\n- **Simplified Network Management**: You can avoid creating excessive\n Pod-networks and have fine-grained control over communication by using\n network policies, simplifying network management, and reducing complexity.\n\n- **Cost Optimization**: By avoiding the need to create numerous Pod-networks,\n you can optimize resource utilization and reduce costs associated with\n network infrastructure.\n\n- **Enhanced Protection for CNFs**: You can ensure the security and integrity\n of CNF deployments by isolating management and dataplane traffic, and by\n applying specific network policies to each deployment.\n\nWhat's next\n-----------\n\n[Control traffic flow between Pods and Services at Pod level](/kubernetes-engine/docs/how-to/control-traffic-between-Pods-Services)"]]
