GKE-Netzwerkarchitektur

Autopilot Standard

Das Netzwerk von Google Kubernetes Engine (GKE) nutzt und erweitert die SDN-Infrastruktur (Software-Defined Networking), die von Virtual Private Cloud (VPC) bereitgestellt wird. Mit GKE-Netzwerken können Ihre Komponenten innerhalb eines Kubernetes-Clusters und mit externen Diensten und Netzwerken kommunizieren. Das GKE-Netzwerkmodell basiert auf dem Kubernetes-Netzwerkprinzip, bei dem jeder Pod eine eigene IP-Adresse erhält. Es bietet IP-Adressierung, Lastenausgleich, DNS-Auflösung und die Durchsetzung von Netzwerkrichtlinien. In diesem Dokument wird beschrieben, wie Kernkomponenten wie Knoten, Pods und Dienste im Kontext von GKE-Netzwerken mit der Steuerungsebene interagieren. Dabei werden die folgenden Aspekte behandelt:

• Interaktion dieser Komponenten in Ihrer VPC
• Zuweisung und Verwaltung von IP-Adressen
• Wie Traffic in den Cluster, innerhalb des Clusters und aus dem Cluster fließt

Architektur eines GKE-Netzwerks

Ein GKE-Netzwerk basiert auf der VPC (Virtual Private Cloud) von Google Cloud. Diese Grundlage bietet eine robuste und skalierbare Konnektivität für alle Ihre containerisierten Anwendungen.

VPC-Grundlage und IP-Adressbereiche

In Ihrer VPC definieren Sie Subnetze, die regionale IP-Adressbereiche sind. GKE verwendet verschiedene IP-Adressbereiche in diesen Subnetzen strategisch für verschiedene Clusterkomponenten, wobei häufig VPC-Alias-IP-Adressbereiche verwendet werden:

• Knoten-IP-Adressbereich: Dies ist der primäre IP-Adressbereich des Subnetzes, in dem Ihre Clusterknoten bereitgestellt werden. Alle Ihre GKE-Worker-Knoten, die Compute Engine-VMs sind, erhalten ihre primären IP-Adressen aus diesem Bereich. Diese IP-Adressen werden für die Kommunikation zwischen Knoten und für Systemdiagnosen von Load-Balancern verwendet. Die Knoten-IP-Adresse ist auch die Quelle für Traffic, der auf dem Knoten selbst entsteht. In VPC-nativen Clustern wird für Traffic von Pods die Pod-IP-Adresse als Quelladresse verwendet, sofern die Pod-IP-Adresse nicht durch eine Funktion wie Cloud NAT übersetzt wird.
• Pod-IP-Adressbereich: ein dedizierter sekundärer IP-Adressbereich, oft ein größerer CIDR-Block, der sich in Ihrem Subnetz befindet. Jeder Knoten erhält einen Pool von IP-Adressen aus diesem Bereich. GKE weist diese IP-Adressen Pods zu, die auf diesem Knoten ausgeführt werden. Jeder Pod in Ihrem Cluster erhält seine eindeutige IP-Adresse aus diesem Bereich. Diese Pod-IP-Adressen sind in Ihrer Virtual Private Cloud nativ routingfähig. Standardmäßig erhält jeder Knoten einen /24-Bereich, der 256 IP-Adressen umfasst. GKE begrenzt die maximale Anzahl von Pods pro Knoten jedoch auf 110. Dieser Puffer trägt dazu bei, dass IP-Adressen bei der schnellen Erstellung und Löschung von Pods (auch als Churn bezeichnet) verfügbar sind. Diese IP-Adressen ermöglichen die direkte Kommunikation zwischen Pods auf verschiedenen Knoten, ohne dass eine Network Address Translation (NAT) erforderlich ist.
• Dienst-IP-Adressbereich (ClusterIP): Ein sekundärer IP-Adressbereich für die virtuellen IP-Adressen (ClusterIPs), die Kubernetes-Diensten zugewiesen sind. Diese stabilen IP-Adressen werden nur für die Kommunikation innerhalb des Clusters verwendet.
• IP-Adresse der Steuerungsebene: Jede Steuerungsebene hat basierend auf dem Typ des Clusters, der Version und dem Erstellungsdatum eine öffentliche oder interne IP-Adresse. Diese IP-Adresse wird von Worker-Knoten und externen Clients wie kubectl verwendet, um sicher mit dem Kubernetes API-Server zu kommunizieren. GKE Frontend (GKFE) bietet einen DNS-basierten Endpunkt für jeden Cluster und damit eine sichere und zuverlässige Möglichkeit, auf die Steuerungsebene zuzugreifen, ohne IP-Adressen direkt verwalten zu müssen.

Die drei Säulen des GKE-Netzwerks

Das GKE-Netzwerk besteht aus drei miteinander verbundenen Säulen, die jeweils eine eigene Kommunikationsebene darstellen. Dieses Framework hilft Ihnen, die Kommunikation Ihrer Anwendungen innerhalb des Clusters und mit externen Netzwerken zu verstehen:

• Pod-Netzwerk: die grundlegende Ebene, die definiert, wie einzelne Container (Pods) innerhalb des Clusters miteinander kommunizieren.
• Service Networking: Diese Ebene basiert auf Pod-Networking und beschreibt, wie Kubernetes-Dienste stabile Endpunkte bereitstellen, um Anwendungen für interne oder externe Clients verfügbar zu machen, einschließlich Load-Balancing und Service Discovery.
• Clusternetzwerk: Die äußerste Ebene, die abdeckt, wie Ihr gesamter GKE-Cluster mit dem breiteren Netzwerkökosystem verbunden ist. Dazu gehört die Verwaltung von Ingress aus dem Internet, Egress zu externen Diensten und die Verbindung zu Google Cloud Diensten und lokalen Systemen.

Diese Schichten bilden zusammen ein umfassendes Kommunikationsmodell, das interne und externe Konnektivität, Sicherheit und Skalierbarkeit unterstützt. In den folgenden Abschnitten werden die einzelnen Säulen genauer betrachtet.

Pod-Netzwerke

Die Pod-Vernetzung ist die Grundlage für die gesamte Kommunikation in einem GKE-Cluster. Sie definiert, wie Anwendungen, die in Pods ausgeführt werden, einander finden und miteinander interagieren können. In Kubernetes ist ein Pod die kleinste und grundlegendste bereitstellbare Einheit. Ein Pod fungiert als logischer Host für Ihre Anwendungen. Er führt einen oder mehrere Container aus, die Netzwerkressourcen gemeinsam nutzen. Wenn ein Pod auf einem Knoten geplant ist, erstellt Kubernetes im Linux-Kernel des Knotens einen dedizierten Netzwerk-Namespace dafür, der sein Netzwerk von anderen Pods auf demselben Knoten isoliert.

Funktionsweise von Pod-Netzwerken

Die Pod-Vernetzung wird durch eine Kombination aus eindeutigen IP-Adressen, virtuellen Netzwerkgeräten und speziellen Plug-ins hergestellt, die die Konnektivität verwalten.

Container Network Interface (CNI): GKE verwendet CNI-Plug-ins, um die Pod-Vernetzung zu implementieren und zu verwalten. Bei VPC-nativen Clustern ist das Google CNI die Standardeinstellung. Weitere Optionen sind kubenet (für nicht VPC-native Cluster), Calico und GKE Dataplane V2 (basierend auf Cilium). Diese Plug-ins sind für die Verbindung von Pods mit dem Netzwerk und die Durchsetzung von Netzwerkrichtlinien verantwortlich.

• IP-Adressenzuweisung: Jeder Knoten erhält einen Pool von IP-Adressen aus dem Pod-IP-Adressbereich, die er Pods zuweisen kann. GKE reserviert einen Teil dieser Adressen, um einen Puffer zu schaffen, der die Verfügbarkeit von IP-Adressen bei schnellen Pod-Churns (Erstellung und Zerstörung) gewährleistet. Aufgrund dieser Reservierung ist die Anzahl der zuweisbaren Pod-IP-Adressen pro Knoten immer kleiner als die Größe des Bereichs.

• Netzwerk-Namespaces und virtuelle Ethernet-Paare (veth): Um die Kommunikation zu ermöglichen, verbindet Kubernetes den isolierten Netzwerk-Namespace des Pods mit dem primären oder Root-Netzwerk-Namespace des Knotens. Kubernetes stellt diese Verbindung über ein virtuelles Ethernet-Paar oder veth-Paar her, das wie ein virtuelles Netzwerkkabel funktioniert. Ein Ende des Paares befindet sich im Namespace des Pods und wird als eth0 angezeigt. Das andere Ende ist entweder mit einer Netzwerk-Bridge oder direkt mit dem Netzwerk-Stack des Knotens im Root-Namespace des Knotens verbunden, wodurch der Paketfluss zum und vom Pod ermöglicht wird.

  Die genaue Verbindungsmethode hängt vom CNI-Plug-in ab, das Ihr Cluster verwendet:

  • Google CNI: Dies ist das Standard-CNI für VPC-native Cluster. Das veth-Paar des Pods ist mit dem Root-Netzwerk-Namespace des Knotens verbunden. Da Pod-IP-Adressen Alias-IP-Adressen sind, die dem VPC-Netzwerk bekannt sind, wird der Traffic zum und vom Pod über das standardmäßige Linux-Routing auf dem Knoten weitergeleitet.
  • GKE Dataplane V2: Hier werden eBPF-Programme verwendet, um das Pod-Netzwerk zu verarbeiten. Oft werden herkömmliche Linux-Bridges und veth-Paare umgangen, um Paketflüsse im Kernel direkt zu verwalten und so die Leistung zu steigern.
  • Kubenet: Wird in nicht VPC-nativen Clustern verwendet. Das andere Ende des veth-Paares ist mit einem Linux-Bridge-Gerät namens cbr0 im Root-Namespace des Knotens verbunden. Diese Bridge verwaltet den Traffic zwischen Pods auf demselben Knoten und verwendet NAT für Traffic, der den Knoten verlässt.
  • Calico: Wenn die Netzwerkrichtlinie mit Calico aktiviert ist, wird das andere Ende des veth-Paares mit dem Root-Namespace des Knotens verbunden. Calico programmiert dann Hostrouten, um den Traffic an die richtigen Pods weiterzuleiten.

Maximale Übertragungseinheit (Maximum Transmission Unit, MTU): Hiermit wird die größte Paketgröße festgelegt, die über ein Netzwerk gesendet werden kann, ohne fragmentiert zu werden. In GKE ist die MTU für die Schnittstelle eines Pods eine wichtige Einstellung, die vom GKE-CNI-Plug-in des Clusters und den MTU-Einstellungen des zugrunde liegenden VPC-Netzwerk abhängt. Eine Abweichung bei den MTU-Werten kann zu Paketverlusten oder einer Leistungsverschlechterung führen. Der MTU-Wert der Pod-Schnittstelle ist entweder fest auf 1.460 Byte festgelegt oder wird von der primären Netzwerkschnittstelle des Knotens übernommen, wie in der folgenden Tabelle dargestellt.

CNI	MTU	Nutzung
Google CNI	1460	Standard für VPC-native Cluster, die GKE-Versionen vor 1.26.1 verwenden.
Google CNI	Übernommen	Standardeinstellung für VPC-native Cluster, die GKE-Versionen 1.26.1 und höher verwenden.
Calico	1460	Wird verwendet, wenn die Netzwerkrichtlinie aktiviert ist (--enable-network-policy).
GKE Dataplane V2	Übernommen	Wird verwendet, wenn GKE Dataplane V2 aktiviert ist (--enable-dataplane-v2).
netd	Übernommen	Wird verwendet, wenn Funktionen wie die Sichtbarkeit von „Intranode“, die Workload Identity-Föderation für GKE für GKE oder das IPv4/IPv6-Dual-Stack-Netzwerk aktiviert sind.

Wenn Sie in Clustern, in denen Versionen vor 1.26.1 ausgeführt werden, Funktionen wie „Intranode Visibility“, Workload Identity-Föderation für GKE oder IPv4/IPv6-Dual-Stack-Netzwerke aktivieren, wird die Pod-MTU vom primären Interface des Knotens übernommen.

Kommunikationsablauf zwischen Pods

Kubernetes verwendet ein flaches Netzwerkmodell, bei dem jeder Pod eine eindeutige, routingfähige IP-Adresse hat. Dieses Modell sorgt für eine nahtlose Verbindung zwischen den Pods.

Kommunikation innerhalb desselben Knotens

Wenn ein Pod Traffic an einen anderen Pod auf demselben Knoten sendet, fließt die Anfrage vom Netzwerk-Namespace des ersten Pods über sein veth-Paar in den Root-Netzwerk-Namespace des Knotens. Dieser Traffic verbleibt im Knoten. Abhängig vom verwendeten CNI-Plug-in leitet das CNI-Plug-in den Traffic dann an das veth-Paar des zweiten Pods weiter. Bei kubenet leitet beispielsweise ein Bridge-Gerät den Traffic weiter. Mit GKE Dataplane V2 verwalten eBPF-Programme den Paketfluss direkt.

Kommunikation zwischen verschiedenen Knoten

Wenn ein Pod auf einem Knoten Traffic an einen Pod auf einem anderen Knoten sendet, fließt der Traffic zum Root-Netzwerk-Namespace des ersten Knotens. Der Traffic verlässt dann die primäre Netzwerkschnittstelle des ersten Knotens und gelangt in das VPC-Netzwerk. Da Pod-IP-Adressen in einem VPC-nativen GKE-Cluster nativ routingfähig sind, leitet das VPC-Netzwerk den Traffic direkt an den zweiten Knoten weiter. Der zweite Knoten leitet den Traffic dann an den Ziel-Pod weiter.

Hostnetzwerk-Pods

Für bestimmte Anwendungsfälle können Sie einen Pod mit der Einstellung hostNetwork: true konfigurieren. Mit dieser Einstellung wird das isolierte Pod-Netzwerk umgangen und der Pod kann den Netzwerk-Namespace des Knotens direkt verwenden. Bei diesem direkten Zugriff verwendet der Pod die IP-Adresse des Knotens und kann ohne NAT mit allen anderen Pods kommunizieren. In Clustern, die das kubenet-CNI-Plug-in verwenden, unterscheidet sich dieses Verhalten von dem regulärer Pods. Für ausgehenden Traffic von regulären Pods ist NAT erforderlich, da ihre IP-Adressen im VPC-Netzwerk nicht direkt weitergeleitet werden können. Im Gegensatz dazu ist diese Übersetzung bei VPC-nativem Networking in GKE für alle Pods nicht erforderlich. Wenn Sie Pods mit der Einstellung hostNetwork: true konfigurieren, sollten Sie jedoch darauf achten, Portkonflikte mit anderen Prozessen oder Pods zu vermeiden, die auf demselben Knoten ausgeführt werden. In Clustern, die das kubenet-CNI verwenden, wird die virtuelle Netzwerkbrücke cbr0 nur erstellt, wenn der Knoten Pods mit der Einstellung hostNetwork: false hat.

Dienstnetzwerk

Die Pod-Vernetzung bietet zwar die grundlegende Konnektivität zwischen einzelnen Pods, reicht aber nicht aus, um robuste, skalierbare Anwendungen zu erstellen. Pods sind kurzlebig. Sie können jederzeit erstellt, gelöscht und neu geplant werden. Dadurch ändern sich ihre IP-Adressen. Service Networking löst dieses Problem, indem es eine stabile und zuverlässige Möglichkeit bietet, Anwendungen verfügbar zu machen und die Kommunikation innerhalb des Clusters und mit der Außenwelt zu verwalten.

Ein Kubernetes-Dienst ist eine Abstraktion, die ein logisches Set von Pods und eine Richtlinie für den Zugriff auf diese Pods definiert. Services verwenden Labels, um mehrere zusammengehörige Pods in einer einzigen logischen Einheit zu gruppieren. Wenn Sie einen Dienst erstellen, weist Kubernetes ihm eine stabile, virtuelle IP-Adresse zu, die als ClusterIP bezeichnet wird und aus einem Pool von Adressen stammt, die für Dienste reserviert sind. Diese ClusterIP bleibt zusammen mit einem zugehörigen DNS-Namen während des gesamten Lebenszyklus des Dienstes konstant und bietet einen konsistenten Endpunkt, den andere Anwendungen verwenden können, um eine Verbindung zu den Pods herzustellen.

Funktionsweise von Dienstnetzwerken

Das Service-Networking basiert auf zwei wichtigen Mechanismen, um Traffic vom stabilen Endpunkt eines Dienstes zu seinen dynamischen Backend-Pods weiterzuleiten: Diensterkennung und Load-Balancing.

Service Discovery: Damit Anwendungen sich gegenseitig finden und miteinander kommunizieren können, stellt GKE einen internen DNS-Dienst bereit (entweder kube-dns oder Cloud DNS). Wenn Sie einen Dienst erstellen, wird vom DNS-Dienst automatisch ein entsprechender DNS-Eintrag erstellt. Mit diesem Eintrag können Anwendungen über den DNS-Namen (z. B. my-app-service) eine Verbindung zum Dienst herstellen, ohne die ClusterIP zu kennen. Obwohl kube-dns die Standardeinstellung für Standardcluster ist, ist Cloud DNS for GKE die empfohlene Lösung für die meisten Produktionsumgebungen. Sie ist auch die einzige unterstützte Lösung für GKE Autopilot-Cluster. Dieser Dienst ist vollständig verwaltet, skalierbar und hochverfügbar. Der Dienst lässt sich in VPC-Netzwerke und Cloud Logging einbinden und bietet eine verbesserte Leistung und Beobachtbarkeit, ohne dass Sie die kube-dns-Pods verwalten müssen.

Load-Balancing-Mechanismen: Die Implementierung von Load-Balancing für Dienste hängt vom Netzwerkmodus Ihres GKE-Cluster ab.

• GKE Dataplane V2: Cluster, die GKE Dataplane V2 (basierend auf Cilium) verwenden, nutzen kube-proxy nicht für das Load-Balancing von Diensten. Stattdessen verwendet GKE Dataplane V2 eBPF-Programme, die im Linux-Kernel ausgeführt werden. Diese eBPF-Programme sind sehr effizient beim Abfangen von Traffic zu Service-ClusterIPs und beim direkten Load-Balancing von Traffic zu den entsprechenden Backend-Pods. Dieser Ansatz führt zu einer besseren Leistung und ist eng in die Funktionen zur Durchsetzung von Netzwerkrichtlinien von GKE Dataplane V2 integriert.

• kube-proxy (für Cluster ohne GKE Dataplane V2): Auf jedem Knoten in einem GKE-Cluster, der GKE Dataplane V2 nicht verwendet, implementiert eine Komponente namens kube-proxy den Mechanismus für virtuelle IP-Adressen für Dienste. kube-proxy überwacht den Kubernetes API-Server auf Änderungen an Diensten und Endpunkten und programmiert dann Netzwerkregeln auf dem Knoten, um Traffic abzufangen, der für die ClusterIP eines Dienstes bestimmt ist.

  kube-proxy kann in verschiedenen Modi ausgeführt werden, z. B.:

  • iptables-Modus: Dies ist der Standardmodus. kube-proxy fügt DNAT-Regeln (Destination NAT) im iptables-Subsystem des Knotens hinzu und entfernt sie. Wenn Traffic für die ClusterIP eines Dienstes eingeht, führen diese Regeln eine NAT-Übersetzung durch und ändern die Ziel-IP-Adresse in eine der fehlerfreien Backend-Pods. Das Load-Balancing über Backend-Pods erfolgt in der Regel zufällig oder im Round-Robin-Verfahren.
  • ipvs-Modus: In diesem Modus wird der Linux IP Virtual Server (IPVS) für das leistungsstarke Load-Balancing verwendet. Mit kube-proxy werden IPVS-Regeln konfiguriert, die eine große Anzahl von Diensten verarbeiten und komplexere Load-Balancing-Algorithmen bereitstellen können.

Beispiel für einen internen Kommunikationsablauf

In der folgenden Liste wird beschrieben, wie eine Anfrage von einem Client-Pod zu einem Server-Pod über einen Dienst in einem Cluster weitergeleitet wird, in dem GKE Dataplane V2 nicht verwendet wird:

1. Die Clientanwendung stellt eine DNS-Anfrage für my-server-service.
2. Der interne DNS-Dienst des Clusters löst diesen Namen in die stabile ClusterIP des Dienstes auf (z. B. 10.0.32.8).
3. Der Client-Pod sendet eine Anfrage an die ClusterIP des Service.
4. Die iptables-Regeln auf dem Knoten des Clients, die von kube-proxy verwaltet werden, fangen diese Anfrage ab.
5. Diese iptables-Regeln führen DNAT aus und wählen einen der fehlerfreien Backend-Pods für my-server-service aus (z. B. Pod 2 mit der IP-Adresse 10.4.0.3). Außerdem wird die Ziel-IP-Adresse des Pakets in die IP-Adresse des Pods umgeschrieben.
6. Das Paket wird über das flache Pod-Netzwerk an Pod 2 weitergeleitet, der die Anfrage verarbeitet.

In Clustern, die GKE Dataplane V2 verwenden, übernehmen eBPF-Programme das Abfangen und Load-Balancing von Traffic zur ClusterIP des Dienstes. Dabei werden kube-proxy und iptables umgangen.

Beispiel für ein Dienstmanifest

Das folgende Beispiel zeigt ein Dienstmanifest. Im Feld selector wird angegeben, welche Pods basierend auf ihren Labels Traffic empfangen.

apiVersion: v1
kind: Service
metadata:
  name: my-server-service
spec:
  selector:
    app: my-server # This should match the labels on your server Pods
  ports:
  - protocol: TCP
    port: 80 # The port the Service exposes
    targetPort: 8080 # The port the containers in the Pods are listening on

Funktionen des Dienstnetzwerks

GKE-Dienstnetzwerke bieten verschiedene Funktionen zum Verwalten des Trafficflusses und zum Bereitstellen von Anwendungen, sowohl intern als auch extern.

• Internes und externes Load-Balancing: Für Dienste, auf die nur innerhalb des Clusters zugegriffen werden muss, übernimmt kube-proxy (oder GKE Dataplane V2) das Load-Balancing intern. Für Dienste, die im Internet verfügbar sein müssen, stellt GKE automatisch einen Cloud-Load-Balancer bereit, um externen Traffic auf die Knoten im Cluster zu verteilen.
• Application Load Balancer für HTTP(S)-Routing: Für HTTP(S)-Traffic verwendet GKE einen speziellen Layer-7-Load-Balancer, den Application Load Balancer. Sie konfigurieren diesen Load-Balancer mit der Kubernetes Gateway API, die für alle neuen Anwendungen empfohlen wird. Der GKE Gateway-Controller ist die Google-Implementierung der Gateway API und soll ein ausdrucksstärkerer, flexiblerer und erweiterbarer Nachfolger der Ingress-Ressource sein. In der Gateway API werden die folgenden Ressourcen verwendet, um den Load Balancer zu konfigurieren:
  • Gateway:Definiert Listener-Konfigurationen wie Ports, Protokolle und Hostnamen. Sie dient als Einstiegspunkt für Traffic.
  • HTTPRoute:Gibt an, wie Traffic, der von einem Gateway empfangen wird, an Dienste weitergeleitet wird. Es unterstützt erweiterte Funktionen wie wegebasiertes Routing, Header-Abgleich und Trafficaufteilung.
  • Richtlinie:Definiert, wie die zugrunde liegende Google Cloud Infrastruktur funktionieren soll, indem sie an ein Gateway, eine Route oder einen Dienst angehängt wird.
• Service Mesh-Integration: GKE unterstützt Service Mesh-Technologien für komplexe Mikrodienstarchitekturen. Ein Service Mesh ist eine optionale Infrastrukturebene, die erweiterte Funktionen für Traffic-Verwaltung, Beobachtbarkeit und Sicherheit bietet. Für eine vollständig verwaltete und unterstützte Lösung bietet GKE Cloud Service Mesh an, das auf Istio basiert.

Clusternetzwerk

Das Clusternetzwerk ist die äußerste Ebene des GKE-Netzwerks. Dabei geht es darum, wie Ihr gesamter Kubernetes-Cluster mit externen Ressourcen und Netzwerken interagiert, einschließlich der Frage, wie Internetclients Ihre Anwendungen erreichen, wie Ihre Pods auf externe APIs zugreifen und wie Ihr Cluster mit lokalen Rechenzentren verbunden ist. Die Clustervernetzung basiert auf der VPC-Infrastruktur von Google Cloud.

Eingehenden Traffic verwalten

Ingress ist Traffic, der von außerhalb in Ihren Cluster gelangt. GKE verwendet mehrere integrierte Google Cloud Funktionen, um diesen Traffic zu verwalten und zu schützen.

Datenfluss für externen Zugriff: Wenn ein Client aus dem Internet eine Anfrage an Ihre Anwendung sendet (in der Regel über einen Dienst vom Typ LoadBalancer oder eine Ingress- oder Gateway-Ressource), erreicht sie zuerst einen Google Cloud -Load-Balancer. Der Load Balancer leitet die Anfrage an einen fehlerfreien Knoten in Ihrem Cluster weiter. Der Knoten leitet den Traffic an den entsprechenden Pod weiter. kube-proxy übernimmt diese Weiterleitung in Clustern, die GKE Dataplane V2 nicht verwenden. In Clustern, die GKE Dataplane V2 verwenden, wird sie von eBPF-Programmen übernommen. Der Ziel-Pod kann sich auf demselben oder einem anderen Knoten befinden.

Firewallregeln: In GKE-Clustern werden VPC-Firewallregeln verwendet, um eingehenden Traffic zu steuern. Obwohl GKE automatisch einige Standard-Firewallregeln für wichtige Clusteroperationen erstellt, z. B. um der Steuerungsebene den Zugriff auf die Knoten zu ermöglichen, können Sie benutzerdefinierte Regeln definieren, um Ihre spezifischen Sicherheitsanforderungen zu erfüllen. Diese VPC-Firewallregeln funktionieren mit Kubernetes-Netzwerkrichtlinien, um durch die Steuerung des Traffics sowohl auf Knoten- als auch auf Pod-Ebene eine umfassende Sicherheit zu bieten.

Externen Trafficfluss optimieren: Wenn ein Load-Balancer Traffic an einen Knoten sendet, muss der Knoten diesen Traffic möglicherweise an einen Pod auf einem anderen Knoten weiterleiten, was zusätzliche Netzwerk-Hops erfordert. Um dies zu vermeiden, setzen Sie das Feld externalTrafficPolicy in Ihrem Dienstmanifest auf Local. Wenn diese Richtlinie aktiv ist, verwendet der Load-Balancer eine Systemdiagnose, um zu ermitteln, welche Knoten fehlerfreie Pods für den Ziel-Service haben. Der Load Balancer sendet Traffic nur an die fehlerfreien Pods, wodurch der zusätzliche Netzwerk-Hop vermieden wird. Der Nachteil dieser Richtlinie besteht darin, dass sie zu einer ungleichmäßigen Traffic-Verteilung führen kann, wenn Ihre Backend-Pods nicht gleichmäßig auf die Knoten in Ihrem Cluster verteilt sind.

Ausgehenden Traffic verwalten

Ausgehender Traffic ist Traffic, der Ihren Cluster verlässt. Damit ein GKE-Cluster funktioniert und Ihre Anwendungen externe Dienste erreichen können, müssen Sie mehrere Verbindungspfade verwalten.

Grundlegende Anforderungen an die Verbindung: Alle GKE-Cluster benötigen ausgehende Verbindungen zu den Domains *.googleapis.com, *.gcr.io und *.pkg.dev. Auch die ausgehende Verbindung zur IP-Adresse der Steuerungsebene muss ordnungsgemäß funktionieren. Internetzugriff für Pods über Cloud NAT: In privaten Clustern, in denen Pods keine öffentlichen IP-Adressen haben, können Sie mit Cloud NAT ausgehenden Internetzugriff ermöglichen. Cloud NAT ist ein verwalteter Dienst, mit dem Pods eine Verbindung zum Internet herstellen können, um beispielsweise Updates herunterzuladen oder auf externe APIs zuzugreifen, ohne eingehenden Verbindungen ausgesetzt zu sein.

Verbindung zu Google Cloud -Diensten: Wenn Sie Ihrem Cluster die sichere Kommunikation mit anderen Google Cloud -Diensten wie Cloud Storage oder Cloud SQL ermöglichen möchten, ohne das öffentliche Internet zu durchlaufen, verwenden Sie privater Google-Zugriff. Dies ist ein wichtiger Egress-Mechanismus für private Cluster, die mit Google APIs interagieren.

Hybrid- und Multi-Cluster-Konnektivität

Wenn Sie Ihre GKE-Cluster mit der lokalen Infrastruktur verbinden möchten, verwenden Sie Cloud VPN für verschlüsselte Tunnel oder Cloud Interconnect für dedizierte Verbindungen mit hoher Bandbreite. Um die Kommunikation zwischen mehreren GKE-Clustern zu ermöglichen, verwenden Sie Multi-Cluster-Services, die die Service Discovery und den Trafficfluss über verschiedene Cluster, Regionen oder Projekte hinweg erleichtern.

Netzwerksicherheitsfunktionen

Zum Schutz Ihres Clusters und der darin ausgeführten Anwendungen bietet GKE mehrere Sicherheitsebenen für internen (Ost-West-) und externen (Nord-Süd-) Traffic.

Internen Traffic (Ost-West) mit Netzwerkrichtlinien sichern

Standardmäßig können alle Pods in einem GKE-Cluster frei miteinander kommunizieren. Um internen Traffic zu sichern und das Prinzip der geringsten Berechtigung zu erzwingen, können Sie NetworkPolicy verwenden. Eine NetworkPolicy ist eine Kubernetes-Ressource, die als Firewall für Ihre Pods fungiert, indem sie den Netzwerkverkehr zwischen ihnen steuert. Mit NetworkPolicy-Ressourcen können Sie Regeln definieren, um den eingehenden und ausgehenden Traffic für eine ausgewählte Gruppe von Pods basierend auf einer Kombination aus Labels, IP-Adressbereichen und Portnummern einzuschränken. Wenn Sie die erste NetworkPolicy in einem Namespace erstellen, wird der gesamte Traffic abgelehnt, der nicht explizit durch diese Richtlinie zugelassen wird. Die Durchsetzung dieser Richtlinien ist direkt in GKE Dataplane V2 integriert oder wird vom CNI-Plug-in des Clusters, z. B. Calico, übernommen.

Beispiel für ein NetworkPolicy-Manifest

Das folgende Beispiel zeigt ein NetworkPolicy-Manifest. Diese Richtlinie gilt für Pods mit dem Label app: backend und lässt Ingress-Traffic nur von Pods mit dem Label app: frontend über den TCP-Port 6379 zu.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 6379

Externen Zugriff auf den Cluster sichern

Es ist wichtig, den Traffic zu steuern, der in Ihren Cluster gelangt und ihn verlässt, um Ihre Anwendungen vor externen Bedrohungen zu schützen.

VPC-Firewallregeln

GKE-Cluster befinden sich in einem Google Cloud VPC-Netzwerk und sind durch VPC-Firewallregeln geschützt, die den Traffic zu und von den Clusterknoten steuern. VPC-Firewallregeln und Netzwerkrichtlinien arbeiten zusammen, um eine umfassende Sicherheitsstrategie zu bieten. VPC-Firewalls werden auf Knotenebene (Ebene 3 oder Ebene 4) ausgeführt und steuern den Traffic zu den VMs. Netzwerkrichtlinien werden auf Pod-Ebene (Layer 3 oder Layer 4) ausgeführt und ermöglichen eine detailliertere Steuerung des Traffics zwischen Anwendungen im Cluster.

Das Erstellen von Firewallregeln für eingehenden oder ausgehenden Traffic, die auf Knoten in Ihrem Cluster ausgerichtet sind, kann sich nachteilig auswirken. Wenn Sie beispielsweise Regeln für abzulehnenden ausgehenden Traffic auf Knoten in Ihrem Cluster anwenden, können Funktionen wie NodePort und kubectl exec beeinträchtigt werden.

Zugriff auf Load-Balancer beschränken

Wenn Sie Anwendungen über einen Kubernetes-Dienst oder einen Ingress verfügbar machen, können Sie zusätzliche Sicherheitskontrollen auf Load-Balancer-Ebene anwenden. Für externe Load Balancer haben Sie folgende Möglichkeiten:

• Wenn Sie einen Dienst über das Feld type: LoadBalancer freigeben, können Sie das Feld loadBalancerSourceRanges in Ihrem Servicemanifest angeben. Mit diesem Feld wird der Zugriff auf den Dienst auf die von Ihnen definierten IP-Adressbereiche beschränkt.

• Für Application Load Balancer (Ingress) können Sie beim Bereitstellen von HTTP(S)-Anwendungen erweiterte Sicherheitsdienste verwenden:

  • Google Cloud Armor: Dieser Dienst ist eine Web-Application Firewall (WAF), die Ihre Anwendungen vor DDoS-Angriffen und anderen webbasierten Bedrohungen schützt.
  • Identity-Aware Proxy (IAP): Für eine detaillierte Zugriffssteuerung können Sie IAP für Ihre Endpunkte aktivieren. IAP überprüft die Identität eines Nutzers und bestimmt anhand dieser, ob der Nutzer auf die Anwendung zugreifen darf.

Nächste Schritte

• VPC-nativen Cluster erstellen
• Weitere Informationen zu GKE Dataplane V2
• Netzwerkrichtlinien implementieren, um die Pod-zu-Pod-Kommunikation zu schützen.
• Anwendungen über Dienste bereitstellen und Ingress mit der Gateway API konfigurieren