Netzwerkübersicht

Auf dieser Seite werden die wichtigsten Aspekte des GKE-Netzwerks (Google Kubernetes Engine) erläutert. Diese Informationen sind nicht nur für Kubernetes-Einsteiger nützlich. Auch erfahrene Clusterbetreiber oder Anwendungsentwickler können Kubernetes-Arbeitslasten besser konfigurieren bzw. Anwendungen besser konzipieren, wenn sie mehr über das Kubernetes-Netzwerk wissen.

Mit Kubernetes können Sie deklarativ festlegen, wie Ihre Anwendungen bereitgestellt werden, wie Anwendungen miteinander und mit der Kubernetes-Steuerungsebene kommunizieren und wie Clients Ihre Anwendungen erreichen. Auf dieser Seite erfahren Sie auch, wie GKE Google Cloud-Services konfiguriert, wenn dies in Zusammenhang mit dem Netzwerk relevant ist.

Wenn Sie Kubernetes zum Orchestrieren Ihrer Anwendungen verwenden, müssen Sie beim Netzwerkdesign der Anwendungen und ihrer Hosts umdenken. Bei Kubernetes steht die Kommunikation zwischen Pods, Diensten und externen Clients im Vordergrund, nicht die Art und Weise, wie Ihre Hosts oder virtuelle Maschinen (VMs) miteinander verbunden sind.

Das fortgeschrittene softwarebasierte Netzwerk von Kubernetes ermöglicht das Routing und die Weiterleitung von Paketen mit Pods, Services und Knoten zwischen verschiedenen Zonen im selben regionalen Cluster. Kubernetes und Google Cloud konfigurieren auch IP-Filterregeln, Routingtabellen und Firewallregeln auf jedem Knoten dynamisch. Maßgeblich dafür sind das deklarative Modell Ihrer Kubernetes-Deployments und Ihre Clusterkonfiguration in Google Cloud.

Vorbereitung

Auf dieser Seite werden Begriffe in Zusammenhang mit der Transportschicht, Internetschicht und Anwendungsschicht der Internetprotokollfamilie verwendet, darunter HTTP und DNS. Sie müssen jedoch kein Experte auf diesen Gebieten sein.

Außerdem werden Sie diesen Inhalt vermutlich leichter verstehen, wenn Sie mit den Konzepten und Dienstprogrammen der Linux-Netzwerkverwaltung wie iptables-Regeln und -Routing bereits grundlegend vertraut sind.

Das Netzwerkmodell von Kubernetes stützt sich stark auf IP-Adressen. Services, Pods, Container und Knoten kommunizieren über IP-Adressen und Ports. Kubernetes bietet verschiedene Load-Balancing-Typen, um Anfragen an die richtigen Pods weiterzuleiten. Alle diese Mechanismen werden später ausführlicher beschrieben. Behalten Sie beim Lesen folgende Begriffe im Hinterkopf:

  • ClusterIP: Die IP-Adresse, die einem Dienst zugewiesen ist. In anderen Dokumenten wird diese möglicherweise „Cluster-IP“ genannt. Diese Adresse bleibt über die gesamte Lebensdauer des Service stabil, wie unter Services beschrieben.
  • Pod-IP-Adresse: Die IP-Adresse, die einem bestimmten Pod zugewiesen ist. Diese ist sitzungsspezifisch, wie unter Pods beschrieben.
  • Knoten-IP-Adresse: Die IP-Adresse, die einem bestimmten Knoten zugewiesen ist.

Anforderungen an das Clusternetzwerk

Sowohl öffentliche als auch private Cluster erfordern eine Verbindung zu *.googleapis.com, *.gcr.io und der IP-Adresse der Steuerungsebene. Diese Anforderung wird durch die implizierten Regeln zum Zulassen von ausgehendem Traffic und die von GKE erstellten automatisch erstellten Firewallregeln erfüllt.

Wenn Sie bei öffentlichen Clustern Firewallregeln hinzufügen, die ausgehenden Traffic mit einer höheren Priorität verweigern, müssen Sie Firewallregeln erstellen, um *.googleapis.com, *.gcr.io und die IP-Adresse der Steuerungsebene zuzulassen.

Weitere Informationen zu den Anforderungen für private Cluster finden Sie unter Anforderungen, Beschränkungen und Einschränkungen.

Netzwerk innerhalb des Clusters

In diesem Abschnitt werden Netzwerkvorgänge eines Kubernetes-Clusters in Verbindung mit der IP-Zuweisung, Pods, Services, DNS und der Steuerungsebene beschrieben.

IP-Adresszuweisung

Kubernetes verwendet verschiedene IP-Bereiche, um Knoten, Pods und Services IP-Adressen zuzuweisen.

  • Jedem Knoten wird eine IP-Adresse aus dem VPC-Netzwerk (Virtual Private Cloud) des Clusters zugewiesen. Diese Knoten-IP ermöglicht die Verbindung von Steuerungskomponenten wie kube-proxy und kubelet und dem Kubernetes-API-Server. Diese IP-Adresse ist die Verbindung des Knotens mit dem Rest des Clusters.
  • Jeder Knoten verfügt über einen Pool von IP-Adressen, der den Pods auf diesem Knoten durch GKE zugewiesen wird (standardmäßig ein /24-CIDR-Block ). Optional können Sie den Bereich von IP-Adressen beim Erstellen des Clusters angeben. Mit der flexiblen CIDR-Bereichsfunktion für Pods können Sie die Größe des Bereichs für Pod-IP-Adressen für Knoten in einem Knotenpool verringern.
  • Jedem Pod wird eine einzelne IP-Adresse aus dem Pod-CIDR-Bereich seines Knotens zugewiesen. Diese IP-Adresse wird von allen Containern geteilt, die innerhalb des Pods ausgeführt werden, und sie verbindet sie mit anderen Pods, die im Cluster ausgeführt werden.
  • Jeder Dienst hat eine IP-Adresse, die ClusterIP genannt und aus dem VPC-Netzwerk des Clusters zugewiesen wird. Sie können das VPC-Netzwerk optional anpassen, wenn Sie den Cluster erstellen.
  • Jede Steuerungsebene hat basierend auf dem Typ des Clusters, der Version und dem Erstellungsdatum eine öffentliche oder interne IP-Adresse. Weitere Informationen finden Sie in der Beschreibung der Steuerungsebene.

Das GKE-Netzwerkmodell lässt nicht zu, dass IP-Adressen im gesamten Netzwerk wiederverwendet werden. Wenn Sie zu GKE migrieren, müssen Sie die Zuweisung von IP-Adressen planen, um die Nutzung interner IP-Adressen in GKE zu reduzieren.

MTU

Die für eine Pod-Schnittstelle ausgewählte MTU hängt von der von den Clusterknoten verwendeten Container Network Interface (CNI) und der zugrunde liegenden VPC-MTU-Einstellung ab. Weitere Informationen finden Sie unter Pods.

Der MTU-Wert der Pod-Schnittstelle ist entweder 1460 oder wird von der primären Schnittstelle des Knotens übernommen.

CNI MTU GKE Standard
kubenet 1460 Standard
kubenet
(GKE-Version 1.26.1 und höher) 		Übernommen Standard
Calico 1460

Aktiviert mit --enable-network-policy.

Weitere Informationen finden Sie unter Kommunikation zwischen Pods und Services mithilfe von Netzwerkrichtlinien steuern.
netd Übernommen Aktiviert durch Verwendung einer der folgenden Optionen:
GKE Dataplane V2 Übernommen

Aktiviert mit --enable-dataplane-v2.

Weitere Informationen finden Sie unter GKE Dataplane V2 verwenden.

Weitere Informationen finden Sie unter VPC-native Cluster.

Pods

In Kubernetes ist ein Pod die einfachste Einheit, die in einem Kubernetes-Cluster bereitgestellt werden kann. Ein Pod führt mindestens einen Container aus. Auf einem Knoten können null oder mehr Pods ausgeführt werden. Jeder Knoten im Cluster gehört zu einem Knotenpool.

In GKE sind diese Knoten virtuelle Maschinen, die jeweils als Instanz in Compute Engine ausgeführt werden.

Pods können auch mit externen Speicher-Volumes und anderen benutzerdefinierten Ressourcen verknüpft werden. Dieses Diagramm zeigt einen einzelnen Knoten mit zwei Pods, die jeweils mit zwei Volumes verknüpft sind.

Image

Wenn Kubernetes die Ausführung eines Pods auf einem Knoten plant, wird im Linux-Kernel des Knotens ein Netzwerk-Namespace für den Pod erstellt. Dieser Netzwerk-Namespace verbindet die physische Netzwerkschnittstelle des Knotens, beispielsweise eth0, über eine virtuelle Netzwerkschnittstelle mit dem Pod, sodass Pakete zum und vom Pod übertragen werden können. Die zugehörige virtuelle Netzwerkschnittstelle im Root-Netzwerk-Namespace des Knotens ist mit einer Linux-Bridge verbunden, die die Kommunikation zwischen Pods auf demselben Knoten ermöglicht. Über diese virtuelle Schnittstelle kann ein Pod auch Pakete außerhalb des Knotens senden.

Kubernetes weist der virtuellen Netzwerkschnittstelle eine IP-Adresse (die Pod-IP-Adresse) aus einem für Pods auf dem Knoten reservierten Adressbereich im Netzwerk-Namespace des Pods zu. Dieser Adressbereich ist eine Teilmenge des IP-Adressbereichs, der dem Cluster für Pods zugewiesen ist und den Sie beim Erstellen eines Clusters konfigurieren können.

Ein Container, der in einem Pod ausgeführt wird, verwendet den Netzwerk-Namespace des Pods. Aus der Sicht des Containers scheint der Pod eine physische Maschine mit einer einzigen Netzwerkschnittstelle zu sein. Alle Container im Pod sehen diese eine Netzwerkschnittstelle. Der localhost jedes Containers ist über den Pod mit der physischen Netzwerkschnittstelle des Knotens wie eth0 verbunden.

Diese Verbindung unterscheidet sich stark, je nachdem, ob Sie das Container Network Interface (CNI) von GKE oder die Implementierung von Calico verwenden und beim Erstellen des Clusters die Netzwerkrichtlinie aktivieren.

  • Bei Verwendung des CNI von GKE ist ein Ende des veth-Paares (Virtual Ethernet Device) mit dem Pod in dessen Namespace verbunden und das andere mit dem Linux-Bridge-Gerät cbr0.1 In diesem Fall zeigt der folgende Befehl die MAC-Adressen der verschiedenen Pods an, die an cbr0 angehängt sind:

    arp -n

    Wenn Sie folgenden Befehl im Toolbox-Container ausführen, wird das Ende des Stamm-Namespaces jedes mit cbr0 verbundenen veth-Paares angezeigt:

    brctl show cbr0

  • Bei aktivierter Netzwerkrichtlinie ist ein Ende des veth-Paares mit dem Pod und das andere mit eth0 verbunden. In diesem Fall zeigt der folgende Befehl die MAC-Adressen der verschiedenen Pods an, die mit verschiedenen veth-Geräten verbunden sind:

    arp -n

    Der folgende Befehl im Toolbox-Container zeigt, dass es kein Linux-Bridge-Gerät namens cbr0 gibt:

    brctl show

Die iptables-Regeln, die die Weiterleitung innerhalb des Clusters ermöglichen, unterscheiden sich von Szenario zu Szenario. Behalten Sie diese Unterscheidung im Hinterkopf, wenn Sie beim Beheben von Verbindungsfehlern ins Detail gehen.

Standardmäßig hat jeder Pod ungefilterten Zugriff auf alle anderen Pods, die auf allen Knoten des Clusters ausgeführt werden. Sie können jedoch den Zugriff unter Pods beschränken. Kubernetes fährt Pods regelmäßig herunter und erstellt sie neu. Dies geschieht, wenn ein Upgrade für einen Knotenpool ausgeführt wird, wenn sich die deklarative Konfiguration des Pods oder das Image eines Containers ändert oder wenn ein Knoten nicht mehr verfügbar ist. Daher ist die IP-Adresse eines Pods ein Implementierungsdetail, auf das Sie sich nicht verlassen sollten. Stabile IP-Adressen stellt Kubernetes mithilfe von Services bereit.

  1. Die virtuelle Netzwerkbrücke cbr0 wird nur erstellt, wenn Pods vorhanden sind, die hostNetwork: false festlegen.↩

Dienste

In Kubernetes können Sie allen Kubernetes-Ressourcen beliebige Schlüssel/Wert-Paare zuweisen, die Labels genannt werden. Mithilfe von Labels fasst Kubernetes mehrere zusammengehörige Pods zu einer logischen Einheit zusammen, die als Dienst bezeichnet wird. Ein Service hat eine stabile IP-Adresse und Ports. Außerdem bietet er Load-Balancing unter mehreren Pods, deren Labels mit den Labels übereinstimmen, die Sie beim Erstellen des Service im Labelselektor festlegen.

Das folgende Diagramm zeigt zwei separate Services, die jeweils aus mehreren Pods bestehen. Jeder der Pods im Diagramm hat das Label app=demo, die anderen Labels unterscheiden sich jedoch. Der Service „frontend“ entspricht allen Pods mit app=demo und component=frontend, während der Service „users“ allen Pods mit app=demo und component=users entspricht. Der Client-Pod stimmt mit keinem der Serviceselektoren exakt überein, sodass er zu keinem dieser Services gehört. Allerdings kann der Client-Pod mit beiden Diensten kommunizieren, da er im selben Cluster ausgeführt wird.

Image

Kubernetes weist jedem neu erstellten Service eine stabile, zuverlässige IP-Adresse (die ClusterIP) aus dem Pool der verfügbaren Service-IP-Adressen des Clusters zu. Außerdem weist Kubernetes der ClusterIP einen Hostnamen zu. Hierfür wird ein DNS-Eintrag hinzugefügt. Die ClusterIP und der Hostname kommen innerhalb des Clusters nur einmal vor und bleiben über den gesamten Lebenszyklus des Service gleich. Kubernetes gibt die ClusterIP und den Hostnamen nur frei, wenn der Service aus der Clusterkonfiguration gelöscht wird. Ein fehlerfreier Pod, der eine Anwendung ausführt, ist über die ClusterIP oder den Hostnamen des Service erreichbar.

Auf den ersten Blick sieht ein Service wie ein Single Point of Failure für eine Anwendung aus. Allerdings verteilt Kubernetes Traffic so gleichmäßig wie möglich über den gesamten Satz von Pods, die auf vielen Knoten ausgeführt werden. So kann ein Cluster einem Ausfall standhalten, der einen oder mehrere (aber nicht alle) Knoten betrifft.

Kube-Proxy

Kubernetes verwaltet Verbindungen zwischen Pods und Services mit der Komponente kube-proxy, die normalerweise als statischer Pod auf jedem Knoten ausgeführt wird.

kube-proxy ist kein Inline-Proxy, sondern ein auf ausgehenden Traffic ausgelegter Load-Balancing-Controller, der den Kubernetes API-Server beobachtet und die ClusterIP kontinuierlich fehlerfreien Pods zuweist. Zu diesem Zweck werden DNAT-Regeln (Ziel-NAT) in das Subsystem iptables des Knotens aufgenommen und aus diesem entfernt. Wenn ein im Pod ausgeführter Container Traffic an die ClusterIP eines Service sendet, wählt der Knoten einen Pod nach dem Zufallsprinzip aus und leitet den Traffic an diesen Pod weiter.

Wenn Sie einen Service konfigurieren, können Sie optional seinen Überwachungsport neu zuordnen. Dafür legen Sie Werte für port und targetPort fest.

  • Über den port erreichen Clients die Anwendung.
  • Der targetPort ist der Port, den die Anwendung tatsächlich auf Traffic innerhalb des Pods überwacht.

kube-proxy verwaltet diese Neuzuordnung des Ports durch Hinzufügen und Entfernen von iptables-Regeln für den Knoten.

Dieses Diagramm veranschaulicht den Fluss des Traffics von einem Client-Pod zu einem Server-Pod auf einem anderen Knoten. Der Client stellt über 172.16.12.100:80 eine Verbindung zum Service her. Der Kubernetes API-Server verwaltet eine Liste der Pods, auf denen die Anwendung ausgeführt wird. Diese Liste wird vom Prozess kube-proxy auf den einzelnen Knoten verwendet, um eine iptables-Regel zur Weiterleitung des Traffics an einen geeigneten Pod wie 10.255.255.202:8080 zu erstellen. Der Client-Pod muss weder die Topologie des Clusters noch Einzelheiten über die darin enthaltenen Pods oder Container kennen.

Image

Wie kube-proxy bereitgestellt wird, hängt von der GKE-Version des Clusters ab:

  • Für die GKE-Versionen 1.16.0 und 1.16.8-gke.13 wird kube-proxy als DaemonSet bereitgestellt.
  • Für GKE-Versionen ab 1.16.8-gke.13 wird kube-proxy als statischer Pod für Knoten bereitgestellt.

DNS

GKE bietet die folgenden Cluster-DNS-Optionen, um Dienstnamen und externe Namen aufzulösen:

  • kube-dns: Ein Cluster-Add-on, das standardmäßig in allen GKE-Clustern bereitgestellt wird. Weitere Informationen finden Sie unter kube-dns verwenden.

  • Cloud DNS: Eine in der Cloud verwaltete DNS-Infrastruktur, die kube-dns im Cluster ersetzt. Weitere Informationen finden Sie unter Cloud DNS für die GKE verwenden.

GKE bietet auch NodeLocal DNSCache als optionales Add-on mit kube-dns oder Cloud DNS, um die Leistung des Cluster-DNS zu verbessern.

Weitere Informationen dazu, wie GKE DNS bereitstellt, finden Sie unter Service Discovery und DNS.

Steuerungsebene

In Kubernetes verwaltet die Steuerungsebene die Prozesse der Steuerungsebene, einschließlich des Kubernetes API-Servers. Wie Sie auf die Steuerungsebene zugreifen, hängt von der Version Ihres GKE Autopilot- oder Standardclusters ab.

Cluster mit Private Service Connect

Private oder öffentliche Cluster, die eine der folgenden Bedingungen erfüllen, verwenden Private Service Connect, um Knoten und die Steuerungsebene privat zu verbinden:

  • Neue öffentliche Cluster in Version 1.23 am oder nach dem 15. März 2022.
  • Neue private Cluster in Version 1.29 nach dem 28. Januar 2024.

Vorhandene öffentliche Cluster, die die vorherigen Bedingungen nicht erfüllen, werden zu Private Service Connect migriert. Daher verwenden diese Cluster möglicherweise bereits Private Service Connect. Führen Sie den Befehl gcloud container clusters describe aus, um zu prüfen, ob der Cluster Private Service Connect verwendet. Wenn Ihr öffentlicher Cluster Private Service Connect verwendet, hat die Ressource privateClusterConfig die folgenden Werte:

  • Das Feld peeringName ist leer oder nicht vorhanden.
  • Dem Feld privateEndpoint ist ein Wert zugewiesen.

Vorhandene private Cluster, die die vorherigen Bedingungen nicht erfüllen, werden jedoch noch nicht migriert.

Sie können Cluster erstellen, die Private Service Connect verwenden, und die Clusterisolierung ändern.

Verwenden Sie autorisierte Netzwerke, um den Zugriff auf die Steuerungsebene des Clusters zu beschränken. Dazu definieren Sie die Ursprünge, die die Steuerungsebene erreichen können.

Private Service Connect-Ressourcen, die für GKE-Cluster verwendet werden, werden ausgeblendet.

Netzwerk außerhalb des Clusters

In diesem Abschnitt wird erläutert, wie Traffic von außerhalb des Clusters Anwendungen erreicht, die in einem Kubernetes-Cluster ausgeführt werden. Diese Informationen sind wichtig, wenn Sie die Anwendungen und Arbeitslasten Ihres Clusters entwerfen.

Sie wissen bereits, dass Kubernetes mithilfe von Services stabile IP-Adressen für Anwendungen bereitstellt, die in Pods ausgeführt werden. Standardmäßig stellen Pods keine externe IP-Adresse zur Verfügung, da kube-proxy den gesamten Traffic auf jedem Knoten verwaltet. Pods und ihre Container können frei miteinander kommunizieren, Verbindungen außerhalb des Clusters können jedoch nicht auf den Dienst zugreifen. In der vorherigen Abbildung können Clients außerhalb des Clusters beispielsweise nicht auf den Service „frontend“ über dessen ClusterIP zugreifen.

GKE stellt drei verschiedene Arten von Load-Balancern bereit, mit denen der Zugriff gesteuert und eingehender Traffic so gleichmäßig wie möglich auf den Cluster verteilt werden kann. Sie können einen Service so konfigurieren, dass er mehrere Arten von Load-Balancern gleichzeitig verwendet.

  • Externe Load-Balancer verwalten Traffic, der von außerhalb des Clusters und des Google Cloud-VPC-Netzwerks eingeht. Sie verwenden Weiterleitungsregeln, die dem Google Cloud-Netzwerk zugeordnet sind, um Traffic an einen Kubernetes-Knoten weiterzuleiten.
  • Interne Load-Balancer verwalten Traffic, der aus demselben VPC-Netzwerk kommt. Wie externe Load-Balancer verwenden sie Weiterleitungsregeln, die dem Google Cloud-Netzwerk zugeordnet sind, um Traffic an einen Kubernetes-Knoten weiterzuleiten.
  • Application Load Balancer sind spezialisierte externe Load Balancer, die für HTTP(S)-Traffic verwendet werden. Sie nutzen statt einer Weiterleitungsregel eine Ingress-Ressource, um Traffic an einen Kubernetes-Knoten weiterzuleiten.

Wenn Traffic einen Kubernetes-Knoten erreicht, wird er unabhängig von der Art des Load-Balancers auf dieselbe Weise verarbeitet. Der Load-Balancer weiß nicht, welche Knoten im Cluster Pods für dessen Service ausführen. Er verteilt vielmehr den Traffic gleichmäßig auf alle Knoten im Cluster, auch auf diejenigen, die keinen relevanten Pod ausführen. In einem regionalen Cluster wird die Last auf alle Knoten in allen Zonen der Clusterregion verteilt. Wenn Traffic bei einem Knoten eingeht, leitet er diesen an einen Pod weiter, der auf demselben oder einem anderen Knoten ausgeführt werden kann. Der Knoten leitet den Traffic an einen zufällig ausgewählten Pod weiter. Dazu werden die iptables-Regeln angewendet, die kube-proxy auf dem Knoten verwaltet.

Im folgenden Diagramm leitet der externe Passthrough-Network-Load-Balancer Traffic an den mittleren Knoten weiter und der Traffic wird an einen Pod auf dem ersten Knoten umgeleitet.

Image

Wenn ein Load-Balancer Traffic an einen Knoten sendet, wird der Datenverkehr möglicherweise an einen Pod auf einem anderen Knoten weitergeleitet. Das erfordert zusätzliche Netzwerk-Hops. Wenn Sie diese zusätzlichen Hops vermeiden möchten, können Sie angeben, dass der Traffic an einen Pod geleitet werden muss, der sich auf demselben Knoten befindet, auf dem der Traffic ursprünglich empfangen wurde.

Damit der Traffic an einen Pod auf demselben Knoten geleitet wird, geben Sie in Ihrem Servicemanifest für externalTrafficPolicy den Wert Local an:

apiVersion: v1
kind: Service
metadata:
  name: my-lb-service
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  selector:
    app: demo
    component: users
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Wenn Sie externalTrafficPolicy auf Local setzen, sendet der Load-Balancer Traffic nur an Knoten mit einem fehlerfreien Pod, der zum Service gehört. Über eine Systemdiagnose ermittelt der Load-Balancer, welche Knoten über entsprechende Pods verfügen.

Externer Load-Balancer

Wenn Ihr Service von außerhalb des Clusters und des VPC-Netzwerks erreichbar sein muss, können Sie ihn LoadBalancer. Dafür setzen Sie das Feld type beim Definieren des Service auf Loadbalancer. GKE stellt dann vor dem Service einen externen Passthrough-Network-Load-Balancer bereit. Der externe Passthrough-Network-Load-Balancer kennt alle Knoten im Cluster und konfiguriert die Firewallregeln des VPC-Netzwerks so, dass Verbindungen zum Service von außerhalb des Netzwerks möglich sind. Diese werden über die externe IP-Adresse des Service hergestellt. Sie können dem Dienst auch eine statische externe IP-Adresse zuweisen.

Weitere Informationen finden Sie unter Domainnamen mit statischen IP-Adressen konfigurieren.

Weitere Informationen zu Firewallregeln finden Sie unter Automatisch erstellte Firewallregeln.

Technische Details

Bei Verwendung des externen Load-Balancers wird eingehender Traffic zuerst mithilfe einer Weiterleitungsregel, die dem Google Cloud-Netzwerk zugeordnet ist, an einen Knoten weitergeleitet. Nachdem der Traffic den Knoten erreicht hat, wählt dieser anhand seiner NAT-Tabelle iptables einen Pod aus. Dabei verwaltet kube-proxy die iptables-Regeln auf dem Knoten.

Internes Load-Balancing-Modul

Für Traffic, der den Cluster aus demselben VPC-Netzwerk erreichen muss, können Sie den Dienst so konfigurieren, dass ein interner Passthrough-Network-Load-Balancer bereitgestellt wird. Der interne Passthrough-Network-Load-Balancer wählt statt einer externen IP-Adresse eine IP-Adresse aus dem VPC-Subnetz des Clusters aus. Anwendungen oder Dienste im VPC-Netzwerk können über diese IP-Adresse mit Diensten im Cluster kommunizieren.

Technische Details

Das interne Load Balancing wird von Google Cloud bereitgestellt. Wenn der Traffic einen bestimmten Knoten erreicht, wählt dieser Knoten anhand seiner NAT-Tabelle iptables einen Pod aus, selbst wenn sich der Pod auf einem anderen Knoten befindet. Dabei verwaltet kube-proxy die iptables-Regeln auf dem Knoten.

Weitere Informationen zu internen Load-Balancern finden Sie unter Internen Passthrough-Network-Load-Balancer verwenden.

Application Load Balancer

Viele Anwendungen wie RESTful-Webdienst-APIs kommunizieren über HTTP(S). Sie können Clients außerhalb Ihres VPC-Netzwerks Zugriff auf diese Art von Anwendungen mithilfe einem Ingress von Kubernetes gewähren.

Mit Ingress können Sie Hostnamen und URL-Pfade Services in Ihrem Cluster zuordnen. Beim Einsatz eines Application Load Balancers müssen Sie den Service so konfigurieren, dass er sowohl einen NodePort als auch eine ClusterIP verwendet. Wenn Traffic über die IP-Adresse am NodePort eines Knotens auf den Service zugreift, leitet GKE den Traffic an einen fehlerfreien Pod für den Service weiter. Sie können einen NodePort angeben oder zulassen, dass GKE einen nicht verwendeten Port nach dem Zufallsprinzip zuweist.

Wenn Sie die Ingress-Ressource erstellen, stellt GKE im Google Cloud-Projekt einen externen Application Load Balancer bereit. Der Load-Balancer sendet eine Anfrage an die IP-Adresse am NodePort eines Knotens. Nachdem die Anfrage den Knoten erreicht hat, wählt dieser anhand seiner NAT-Tabelle iptables einen Pod aus. Dabei verwaltet kube-proxy die iptables-Regeln auf dem Knoten.

Diese Ingress-Definition leitet Traffic für demo.example.com an einen Service namens frontend an Port 80 und Traffic für demo-backend.example.com an einen Service namens users an Port 8080 weiter.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
spec:
  rules:
  - host: demo.example.com
    http:
      paths:
      - backend:
          service:
            name: frontend
            port:
              number: 80
  - host: demo-backend.example.com
    http:
      paths:
      - backend:
          service:
            name: users
            port:
              number: 8080

Weitere Informationen finden Sie unter GKE Ingress für Application Load Balancer.

Technische Details

Wenn Sie ein Ingress-Objekt erstellen, konfiguriert der GKE-Ingress-Controller einen Application Load Balancer gemäß den Regeln im Ingress-Manifest und in den zugehörigen Servicemanifesten. Der Client sendet eine Anfrage an den Application Load Balancer. Der Load-Balancer ist tatsächlich ein Proxy. Er wählt einen Knoten aus und leitet die Anfrage an die NodeIP:NodePort-Kombination dieses Knotens weiter. Der Knoten wählt anhand seiner NAT-Tabelle iptables einen Pod aus. Dabei verwaltet kube-proxy die iptables-Regeln auf dem Knoten.

Verbindungen zwischen Knoten beschränken

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 Features wie NodePort und kubectl exec beeinträchtigt werden.

Verbindungen zu Pods und Services beschränken

Standardmäßig können alle Pods, die innerhalb desselben Clusters ausgeführt werden, frei miteinander kommunizieren. Allerdings haben Sie die Möglichkeit, die Verbindungen innerhalb eines Clusters je nach Bedarf auf verschiedene Arten zu beschränken.

Zugriff unter Pods beschränken

Sie können den Zugriff unter Pods mithilfe einer Netzwerkrichtlinie beschränken. Durch die Definition von Netzwerkrichtlinien lässt sich der eingehende und ausgehende Traffic von Pods mithilfe einer beliebigen Kombination aus Labels, IP-Bereichen und Portnummern beschränken.

Standardmäßig gibt es keine Netzwerkrichtlinie, sodass der gesamte Traffic unter Pods im Cluster zulässig ist. Sobald Sie die erste Netzwerkrichtlinie in einem Namespace erstellen, wird der gesamte Traffic abgelehnt, der ihr nicht entspricht.

Nachdem Sie eine Netzwerkrichtlinie erstellt haben, müssen Sie sie explizit für den Cluster aktivieren. Weitere Informationen finden Sie unter Netzwerkrichtlinien für Anwendungen konfigurieren.

Zugriff auf einen externen Load-Balancer beschränken

Wenn Ihr Service einen externen Load-Balancer verwendet, kann Traffic von jeder externen IP-Adresse standardmäßig auf Ihren Service zugreifen. Sie können aber die IP-Adressbereiche einschränken, die Zugriff auf die Endpunkte im Cluster haben. Dazu legen Sie beim Konfigurieren des Service die Option loadBalancerSourceRanges fest. Sie können mehrere Bereiche angeben und die Konfiguration eines laufenden Service jederzeit aktualisieren. Die auf jedem Knoten ausgeführte Instanz kube-proxy konfiguriert die iptables-Regeln dieses Knotens so, dass jeglicher Traffic abgelehnt wird, der nicht mit den angegebenen loadBalancerSourceRanges übereinstimmt. Es wird keine VPC-Firewallregel erstellt.

Zugriff auf einen Application Load Balancer beschränken

Wenn Ihr Service einen Application Load Balancer verwendet, können Sie eine Google Cloud Armor-Sicherheitsrichtlinie verwenden, um einzuschränken, welche externen IP-Adressen auf Ihren Service zugreifen können und welche Antworten zurückgegeben werden sollen, wenn der Zugriff aufgrund der Sicherheitsrichtlinie verweigert wird. Sie können Cloud Logging so konfigurieren, dass Informationen zu diesen Interaktionen geloggt werden.

Wenn eine Google Cloud Armor-Sicherheitsrichtlinie nicht engmaschig genug ist, können Sie den Identity-Aware Proxy auf Ihren Endpunkten aktivieren, um eine nutzerbasierte Authentifizierung und Autorisierung für Ihre Anwendung zu implementieren. Weitere Informationen finden Sie in der ausführlichen Anleitung zum Konfigurieren des IAP.

Bekannte Probleme

In diesem Abschnitt werden die bekannten Probleme beschrieben.

Knoten, bei dem Container aktiviert ist, kann keine Verbindung zum Bereich 172.17/16 herstellen

Eine Knoten-VM mit aktiviertem Containerd kann keine Verbindung zu einem Host herstellen, der eine IP-Adresse innerhalb von 172.17/16 hat. Weitere Informationen finden Sie unter Konflikt mit dem IP-Adressbereich 172.17/16.

Gehackte Ressourcen aus gelöschten GKE-Clustern mit Private Service Connect

Wenn Sie vor dem 7. Mai 2024 GKE-Cluster mit Private Service Connect erstellt und gelöscht haben und das Projekt, das den Cluster enthält, vor dem Cluster selbst gelöscht haben, wurden möglicherweise zugehörige Private Service Connect-Ressourcen offengelegt. Diese Ressourcen bleiben ausgeblendet und Sie können die zugehörigen Subnetze nicht löschen. Wenden Sie sich ansonsten an den Google Cloud-Support.

Nächste Schritte