Nesta página, explicamos como controlar o fluxo de tráfego de rede entre pods e
serviços que usam regras de firewall no nível do pod.
Políticas de rede para
aplicativos ajudam a definir
regras de tráfego de comunicação entre pods. Elas controlam como os pods se comunicam
entre si nos aplicativos e com endpoints externos. É possível ativar
uma política de rede em redes de pods nos clusters da edição Enterprise do Google Kubernetes Engine (GKE)
com multirrede ativada. Você pode aplicar políticas de rede em interfaces de Pod adicionais que correspondam a redes de Pod especificadas pelo usuário.
Por que usar políticas de rede de várias redes
Talvez você queira usar políticas de rede multirrede nos seguintes cenários:
Segurança de rede aprimorada: você quer isolar e proteger
cargas de trabalho ou dados confidenciais definindo políticas de rede para redes de Pod específicas. As políticas de rede para várias redes limitam a exposição e reduzem
a superfície de ataque.
Controle de tráfego refinado: tenha um controle preciso
pelo fluxo de tráfego entre pods e serviços em diferentes redes de pods
permitindo topologias de rede e requisitos de segurança complexos.
Ambientes multilocatários: crie redes isoladas
para diferentes locatários ou aplicativos, garantindo que eles não interfiram na
comunicação uns dos outros, mantendo o controle sobre o acesso à rede
em cada rede de pod.
Otimizar a utilização de recursos: implemente
políticas de redes de pods específicas para alocar recursos e
priorizar o tráfego com base nos requisitos do aplicativo, melhorando o desempenho
e confiabilidade.
Segurança para funções de rede conteinerizadas (CNFs, na sigla em inglês): segregue o tráfego de gerenciamento do tráfego do Dataplane dentro do mesmo pod,
para evitar possíveis violações de segurança e acessos não autorizados.
Como as políticas de rede de várias redes funcionam com as redes de pods
O diagrama abaixo ilustra como as políticas de rede, aplicadas a determinados
redes de pods usando anotações, controlam o fluxo de tráfego entre pods em um
do cluster do GKE.
O diagrama anterior mostra vários nós de trabalho executando pods (aplicativos conteinerizados) e como eles se comunicam dentro do mesmo nó ou entre nós diferentes usando a infraestrutura de rede. Ele também ilustra o uso de políticas de rede para controlar o fluxo de tráfego e a segmentação das VPCs e sub-redes da rede para maior segurança e organização.
Isolamento do tráfego com políticas de rede segmentadas: as políticas de rede afetam apenas o tráfego na rede de pod "azul" devido à anotação
networking.gke.io/network: blue-Pod-network O tráfego na rede de pods padrão permanece irrestrito.
Aplica o tráfego unidirecional com políticas de rede de pods: no diagrama anterior, as políticas de rede permitem que o Pod1 envie tráfego para o Pod2 na rede Pod "azul". O Pod2 não consegue enviar o tráfego de volta para o Pod1 na mesma rede. A
política de rede para pods com o rótulo "test-app-2" funciona como um canal unidirecional.
Ela permite especificamente o tráfego de saída apenas para pods rotulados como
"test-app-3", impedindo a comunicação com outros pods, como "test-app-1".
Permite tráfego de saída por padrão: se nenhuma política de saída for definida para um
pod (neste exemplo, Pod1), todo o tráfego de saída é permitido
por padrão no modo "azul", de uma interface de rede VPC.
Garante a compatibilidade dos recursos atuais: todas as opções padrão de política de rede do GKE, como seletores de rótulos e blocos de endereços IP, funcionam com políticas de rede multirredes.
Controla o escopo da política de rede com anotações:
Se você criar uma política de rede sem anotação, o GKE aplicará políticas de rede multirredes a todas as interfaces de rede nos pods no namespace selecionado, independentemente das redes de pods às quais elas estão conectadas.
Se você incluir a anotação e especificar o nome de uma rede de pod válida (por exemplo, networking.gke.io/network: blue-Pod-network),
o GKE aplica a política aos pods conectados a essa rede de pods específica.
Se a anotação fizer referência à rede de pods que não existe realmente no seu cluster, o GKE não aplicará a política de rede a nenhum pod. Isso ocorre porque nenhum pod está conectado à rede inexistente especificada.
Mantém a comunicação de várias redes para pods com várias interfaces de redes
do aplicativo: se você aplicar uma política de rede para restringir o tráfego em uma rede de pod específica dentro de um pod, isso não afetará o tráfego em outras redes de pod conectadas ao mesmo pod.
Vantagens
Veja a seguir os benefícios de usar políticas de rede de várias redes:
Segurança reforçada: você pode reduzir os riscos associados ao acesso não autorizado e à movimentação lateral no cluster do GKE aplicando políticas de rede em nível granular.
Flexibilidade e personalização: você pode personalizar políticas de rede para atender às suas necessidades específicas de segurança e gerenciamento de tráfego para diferentes redes de Pod, acomodando diversas cargas de trabalho e aplicativos.
Gerenciamento de rede simplificado: você pode evitar a criação excessiva de redes Pod e ter controle refinado sobre a comunicação usando políticas de rede, simplificando o gerenciamento da rede e reduzindo a complexidade.
Otimização de custos: ao evitar a necessidade de criar inúmeras redes Pod, você pode otimizar a utilização de recursos e reduzir custos associados à infraestrutura de rede.
Proteção reforçada para CNFs: você pode garantir a segurança e a integridade das implantações CNF isolando o gerenciamento e o tráfego do plano de dados e aplicando políticas de rede específicas a cada implantação.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)"]]
