Netzwerkübersicht

Auf dieser Seite erhalten Sie eine Übersicht über die wichtigsten Aspekte des Google Kubernetes Engine-Netzwerks. 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, Services und externen Clients im Vordergrund, nicht die Art und Weise, wie Ihre Hosts oder 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.

Voraussetzungen

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. Diese Mechanismen werden alle in diesem Thema noch ausführlicher beschrieben. Behalten Sie beim Lesen folgende Begriffe im Hinterkopf:

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

Netzwerk innerhalb des Clusters

In diesem Abschnitt werden Netzwerkvorgänge eines Kubernetes-Clusters in Verbindung mit der IP-Zuweisung, Pods und Services erörtert.

IP-Zuweisung

Kubernetes verwendet verschiedene IP-Bereiche, um Knoten, Pods und Diensten 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 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 dieses Bereichs der Pod-IP-Adressen für Knoten in einem bestimmten 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 Service 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.

Weitere Informationen finden Sie unter VPC-native Cluster mithilfe von Alias-IP-Adressen erstellen.

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.

Diagramm mit einem einzigen Knoten, auf dem zwei Pods ausgeführt werden, wie im Abschnitt darüber beschrieben

Wenn Kubernetes einen Pod zur Ausführung auf einem Knoten einplant, wird ein Netzwerk-Namespace für den Pod im Linux-Kernel des Knotens 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) 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 native 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 mit dem Pod in dessen Namespace verbunden und das andere mit dem Linux-Bridge-Gerät cbr0. In diesem Fall zeigt der folgende Befehl die MAC-Adressen der verschiedenen Pods an, die mit cbr0 verbunden sind:

    arp -n
    

    Wenn Sie Folgendes im Toolbox-Container aufrufen, wird außerdem 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
    

    Wenn Sie Folgendes im Toolbox-Container aufrufen, sehen Sie außerdem, 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.

Services

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 Service 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 Services kommunizieren, da er im selben Cluster ausgeführt wird.

Diagramm mit zwei separaten Services, wie im vorherigen Abschnitt beschrieben

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 die Verbindungen zwischen Pods und Services mithilfe der Komponente kube-proxy. Diese wird standardmäßig als statischer Pod auf jedem Knoten bereitgestellt. Jeder GKE-Cluster mit 1.16 oder höher hat ein kube-proxy-DaemonSet. Dadurch werden nur Knoten ausgewählt, auf denen eine GKE-Version zwischen 1.16.0 und 1.16.8-gke.13 ausgeführt wird. Wenn der Cluster keine Knoten hat, auf denen diese Versionen ausgeführt werden, wird erwartet, dass dieses DaemonSet 0 Pods anzeigt.

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.

Diagramm mit einem Client, der eine Verbindung zu einem Service herstellt und an einen Pod weitergeleitet wird, wie im vorherigen Abschnitt beschrieben

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 Service 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, um den Zugriff zu steuern und eingehenden Traffic so gleichmäßig wie möglich auf den Cluster zu verteilen. Sie können einen Dienst 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 kommt. 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.
  • HTTP(S)-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 Netzwerk-Load-Balancer Traffic an den mittleren Knoten weiter und der Traffic wird an einen Pod auf dem ersten Knoten umgeleitet.

Diagramm mit Traffic, der von einem Knoten auf einen Pod eines anderen Knoten weitergeleitet wird, wie im vorherigen Abschnitt beschrieben

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 entsprechende Pods haben.

Externer Load-Balancer

Wenn Ihr Service von außerhalb des Clusters und des VPC-Netzwerks erreichbar sein muss, können Sie ihn als LoadBalancer konfigurieren. Dafür setzen Sie das Feld type beim Definieren des Service auf LoadBalancer. GKE stellt dann vor dem Service einen Netzwerk-Load-Balancer bereit. Der Netzwerk-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. Dies erfolgt über die externe IP-Adresse des Service. Sie können dem Serviced auch eine statische externe IP-Adresse zuweisen. Weitere Informationen finden Sie unter Domainnamen mit statischen IP-Adressen konfigurieren.

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.

Interner Load-Balancer

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

Technische Details

Die Funktion für den internen Load-Balancer 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 in der Dokumentation zum internen Load-Balancer.

HTTP(S)-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 einer Ingress-Ressource von Kubernetes gewähren. Eine Ingress-Ressource ermöglicht die Zuordnung von Hostnamen und URL-Pfaden zu Services im Cluster. Beim Einsatz eines HTTP(S)-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 HTTP(S)-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/v1beta1
kind: Ingress
metadata:
  name: demo
spec:
  rules:
  - host: demo.example.com
    http:
      paths:
      - backend:
          serviceName: frontend
          servicePort: 80
  - host: demo-backend.example.com
    http:
      paths:
      - backend:
          serviceName: users
          servicePort: 8080

Weitere Informationen finden Sie unter Ingress in Google Cloud.

Technische Details

Wenn Sie ein Ingress-Objekt erstellen, konfiguriert der GKE-Ingress-Controller einen Google Cloud-HTTP(S)-Load-Balancer gemäß den Regeln im Ingress-Manifest und in den zugehörigen Servicemanifesten. Der Client sendet eine Anfrage an den HTTP(S)-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 einschrä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 ausgehenden Traffic auf Knoten in Ihrem Cluster anwenden, können Funktionen 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.

Weitere Einzelheiten zum Angeben der Richtlinie selbst finden Sie unter Netzwerkrichtlinien.

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 HTTP(S)-Load-Balancer beschränken

Wenn Ihr Service den HTTP(S)-Load-Balancer verwendet, können Sie mithilfe einer Cloud Armor-Sicherheitsrichtlinie die externen IP-Adressen beschränken, die auf den Service zugreifen können. Außerdem lässt sich damit festlegen, welche Antworten zurückgegeben werden, 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.

Weitere Informationen