Auf dieser Seite wird erläutert, wie Sie den Netzwerktraffic zwischen Pods und Services mithilfe von Firewallregeln auf Pod-Ebene steuern.
Mit Netzwerkrichtlinien für Anwendungen können Sie Regeln für den Kommunikationstraffic zwischen Pods definieren. Er steuert, wie Pods innerhalb ihrer Anwendungen und mit externen Endpunkten miteinander kommunizieren. Sie können Netzwerkrichtlinien für Pod-Netzwerke in GKE Enterprise-Clustern (Google Kubernetes Engine) aktivieren, für die Multi-Netzwerke aktiviert sind. Sie können Netzwerkrichtlinien für zusätzliche Pod-Schnittstellen erzwingen, die benutzerdefinierten Pod-Netzwerken entsprechen.
Vorteile von Multi-Netzwerk-Netzwerkrichtlinien
In folgenden Fällen können Sie Netzwerkrichtlinien für mehrere Netzwerke verwenden:
Erhöhte Netzwerksicherheit: Sie möchten vertrauliche Arbeitslasten oder Daten isolieren und schützen, indem Sie Netzwerkrichtlinien für bestimmte Pod-Netzwerke definieren. Durch Netzwerkrichtlinien mit mehreren Netzwerken wird das Risiko begrenzt und die Angriffsfläche reduziert.
Detailgenaue Trafficsteuerung: Sie möchten den Trafficfluss zwischen Pods und Services in verschiedenen Pod-Netzwerken genau steuern und damit komplexe Netzwerktopologien und Sicherheitsanforderungen ermöglichen.
Mehrmandantenfähige Umgebungen: Sie möchten isolierte Netzwerke für verschiedene Mandanten oder Anwendungen erstellen, damit sie die Kommunikation des jeweils anderen nicht beeinträchtigen können, während Sie die Kontrolle über den Netzwerkzugriff in jedem Pod-Netzwerk behalten.
Ressourcennutzung optimieren: Sie möchten Netzwerkrichtlinien in bestimmten Pod-Netzwerken implementieren, um Ressourcen effizient zuzuweisen und den Traffic anhand der Anwendungsanforderungen zu priorisieren und so die Leistung und Zuverlässigkeit zu verbessern.
Sicherheit für containerisierte Netzwerkfunktionen (CNFs): Sie möchten den Verwaltungs-Traffic vom Traffic der Datenebene innerhalb desselben Pods trennen, um potenzielle Sicherheitsverstöße und nicht autorisierten Zugriff zu verhindern.
Funktionsweise von Netzwerkrichtlinien für mehrere Netzwerke mit Pod-Netzwerken
Das folgende Diagramm zeigt, wie Netzwerkrichtlinien, die mithilfe von Annotationen auf bestimmte Pod-Netzwerke angewendet werden, den Trafficfluss zwischen Pods innerhalb eines GKE-Clusters steuern.
Das obige Diagramm zeigt mehrere Worker-Knoten, auf denen Pods (Containeranwendungen) ausgeführt werden, und wie sie innerhalb desselben Knotens oder über verschiedene Knoten mithilfe der Netzwerkinfrastruktur kommunizieren. Außerdem wird der Einsatz von Netzwerkrichtlinien zur Steuerung des Trafficflusses und die Segmentierung des Netzwerks mithilfe von VPCs und Subnetzen veranschaulicht, um die Sicherheit und Organisation zu verbessern.
Traffic mit gezielten Netzwerkrichtlinien isolieren: Die Netzwerkrichtlinien wirken sich aufgrund der Annotation networking.gke.io/network: blue-Pod-network nur auf den Traffic im "blauen" Pod-Netzwerk aus. Der Traffic im Standard-Pod-Netzwerk bleibt uneingeschränkt.
Erzwingt Einweg-Traffic mit Pod-Netzwerkrichtlinien: Im vorherigen Diagramm erlauben Netzwerkrichtlinien Pod1, Traffic an Pod2 ins "blaue" Pod-Netzwerk zu senden. Pod2 kann im selben Netzwerk keinen Traffic zurück an Pod1 senden. Die Netzwerkrichtlinie für Pods mit dem Label "test-app-2" funktioniert als unidirektionaler Kanal.
Insbesondere wird ausgehender Traffic nur zu Pods mit dem Label "test-app-3" zugelassen und die Kommunikation mit anderen Pods wie "test-app-1" verhindert.
Lässt ausgehenden Traffic standardmäßig zu: Wenn für einen Pod (in diesem Beispiel Pod1) keine Richtlinie für ausgehenden Traffic definiert ist, wird der gesamte ausgehende Traffic standardmäßig auf der "blauen" Netzwerkschnittstelle zugelassen.
Sicherstellen der Kompatibilität vorhandener Features: Alle standardmäßigen Optionen für GKE-Netzwerkrichtlinien wie Labelselektoren und IP-Adressblöcke funktionieren mit Netzwerkrichtlinien für mehrere Netzwerke.
Steuert den Bereich der Netzwerkrichtlinien mit Annotationen:
Wenn Sie eine Netzwerkrichtlinie ohne Annotation erstellen, wendet GKE Netzwerkrichtlinien für mehrere Netzwerke auf alle Netzwerkschnittstellen auf den Pods im ausgewählten Namespace an, unabhängig davon, mit welchen Pod-Netzwerken sie verbunden sind.
Wenn Sie die Annotation einfügen und den Namen eines gültigen Pod-Netzwerks angeben (z. B. networking.gke.io/network: blue-Pod-network), wendet GKE die Richtlinie auf Pods an, die mit diesem bestimmten Pod-Netzwerk verbunden sind.
Wenn die Annotation auf das Pod-Netzwerk verweist, das in Ihrem Cluster nicht vorhanden ist, wendet GKE die Netzwerkrichtlinie überhaupt auf kein Pod-Netzwerk an. Das liegt daran, dass keine Pods mit dem angegebenen nicht vorhandenen Netzwerk verbunden sind.
Hält die netzwerkübergreifende Kommunikation für Pods mit mehreren Netzwerkschnittstellen aufrecht: Wenn Sie eine Netzwerkrichtlinie anwenden, um den Traffic auf ein bestimmtes Pod-Netzwerk innerhalb eines Pods einzuschränken, wirkt sich diese nicht auf den Traffic in anderen Pod-Netzwerken aus, die mit demselben Pod verbunden sind.
Vorteile
Die Verwendung von Richtlinien für mehrere Netzwerke bietet folgende Vorteile:
Verbesserte Sicherheit: Sie können Risiken im Zusammenhang mit nicht autorisiertem Zugriff und seitlichen Bewegungen innerhalb des GKE-Clusters minimieren, indem Sie Netzwerkrichtlinien detailliert anwenden.
Flexibilität und Anpassung: Sie können Netzwerkrichtlinien an Ihre spezifischen Sicherheits- und Trafficverwaltungsanforderungen für verschiedene Pod-Netzwerke anpassen, indem Sie verschiedene Arbeitslasten und Anwendungen berücksichtigen.
Vereinfachte Netzwerkverwaltung: Sie können verhindern, dass übermäßig viele Pod-Netzwerke erstellt werden, und die Kommunikation mithilfe von Netzwerkrichtlinien genau steuern, um eine einfachere Netzwerkverwaltung und geringere Komplexität zu erzielen.
Kostenoptimierung: Wenn Sie keine zahlreiche Pod-Netzwerke erstellen müssen, können Sie die Ressourcennutzung optimieren und die mit der Netzwerkinfrastruktur verbundenen Kosten senken.
Erweiterter Schutz für CNFs: Sie können die Sicherheit und Integrität von CNF-Bereitstellungen gewährleisten, indem Sie den Traffic der Verwaltung und der Datenebene isolieren und auf jede Bereitstellung spezifische Netzwerkrichtlinien anwenden.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-28 (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)"]]
