Kommunikation zwischen Pods und Services mithilfe von Netzwerkrichtlinien steuern

Autopilot Standard

Auf dieser Seite wird erläutert, wie Sie die Kommunikation zwischen den Pods und Services des Clusters mithilfe der Netzwerkrichtlinienerzwingung von GKE steuern.

Sie können auch den ausgehenden Traffic von Pods zu jedem Endpunkt oder Dienst außerhalb des Clusters mithilfe von FQDN-Netzwerkrichtlinien (voll qualifizierter Domainname) steuern. Weitere Informationen finden Sie unter Kommunikation zwischen Pods und Diensten mithilfe von FQDNs steuern.

Erzwingung von GKE-Netzwerkrichtlinien

Mit der Erzwingung von Netzwerkrichtlinien können Sie in Ihrem Cluster Netzwerkrichtlinien für Kubernetes erstellen. Standardmäßig können alle Pods in einem Cluster frei miteinander kommunizieren. Netzwerkrichtlinien erstellen Firewallregeln auf Pod-Ebene, die festlegen, welche Pods und Services in einem Cluster aufeinander zugreifen können.

Mithilfe von Netzwerkrichtlinien können Sie unter anderem gestaffelte Sicherheitsebenen aktivieren, wenn auf dem Cluster eine Anwendung mit mehreren Ebenen bereitgestellt wird. Sie können z. B. eine Netzwerkrichtlinie erstellen, um zu verhindern, dass ein manipulierter Front-End-Dienst in einer Anwendung direkt mit einem mehrere Ebenen tieferen Abrechnungs- oder Buchhaltungsdienst kommuniziert.

Netzwerkrichtlinien können außerdem das gleichzeitige Hosten von Daten mehrerer Nutzer in einer Anwendung vereinfachen. Sie können beispielsweise eine sichere Mehrmandantenfähigkeit bereitstellen, indem Sie ein Mandanten-pro-Namespace-Modell festlegen. In diesem Modell können Regeln von Netzwerkrichtlinien dafür sorgen, dass Pods und Dienste in einem bestimmten Namespace nicht auf andere Pods oder Dienste in einem anderen Namespace zugreifen können.

Hinweis: Damit die Durchsetzung von Netzwerkrichtlinien ordnungsgemäß funktioniert, stellt GKE Pods auf Ihren Knoten bereit, die erhöhte RBAC-Berechtigungen haben, z. B. die Möglichkeit, alle Deployments zu patchen und den Status von Knoten zu aktualisieren. Diese Berechtigungen sind erforderlich, damit GKE Ihre Netzwerkrichtlinien anhand Ihrer Konfiguration erzwingen kann.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

• Aktivieren Sie die Google Kubernetes Engine API.
Google Kubernetes Engine API aktivieren
• Wenn Sie die Google Cloud CLI für diesen Task verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
  Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das compute/region-Attribut fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Wenn Sie einen standardmäßigen Speicherort festlegen, können Sie in der gcloud CLI Fehler wie diesen vermeiden: One of [--zone, --region] must be supplied: Please specify location. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

* Sie benötigen einen vorhandenen Autopilot- oder Standardcluster. Erstellen Sie einen Autopilot-Cluster, falls erforderlich.

Anforderungen und Einschränkungen

Die folgenden Anforderungen und Einschränkungen gelten sowohl für Autopilot- als auch für Standard-Cluster:

• Sie müssen ausgehenden Traffic zum Metadatenserver zulassen.
• Wenn Sie ein endPort-Feld in einer Netzwerkrichtlinie für einen Cluster angeben, für den GKE Dataplane V2 aktiviert ist, wird dies ab GKE-Version 1.22 möglicherweise nicht wirksam. Weitere Informationen finden Sie unter Portbereiche für Netzwerkrichtlinien werden nicht wirksam. Für Autopilot-Cluster ist GKE Dataplane V2 immer aktiviert.

Die folgenden Anforderungen und Einschränkungen gelten nur für Standard-Cluster:

• Sie müssen ausgehenden Traffic zum Metadatenserver zulassen, wenn Sie Netzwerkrichtlinien mit der Identitätsföderation von Arbeitslasten für GKE verwenden.
• Durch Aktivieren der Erzwingung von Netzwerkrichtlinien wird der Arbeitsspeicherbedarf des kube-system-Prozesses um etwa 128 MB erhöht und es werden etwa 300 Millicore von der CPU benötigt. Wenn Sie also Netzwerkrichtlinien für einen vorhandenen Cluster aktivieren, muss unter Umständen die Clustergröße erhöht werden, um geplante Arbeitslasten weiterhin ausführen zu können.
• Zur Durchsetzung von Netzwerkrichtlinien müssen Ihre Knoten neu erstellt werden. Wenn es für den Cluster ein aktives Wartungsfenster gibt, werden die Knoten erst innerhalb des nächsten Wartungsfensters automatisch neu erstellt. Sie können den Cluster jedoch jederzeit manuell aktualisieren.
• Die erforderliche Mindestclustergröße zum Ausführen der Durchsetzung von Netzwerkrichtlinien besteht aus drei Instanzen vom Typ e2-medium oder einer Instanz eines Maschinentyps mit mehr als einer zuweisbaren vCPU. Weitere Informationen finden Sie unter Bekannte GKE-Probleme.
• Die Netzwerkrichtlinie wird für Cluster, deren Knoten f1-micro- oder g1-small-Instanzen sind, nicht unterstützt, da die Ressourcenanforderungen zu hoch sind.
• Cilium oder Calico verwalten keine Pods, für die hostNetwork: true festgelegt ist, und Netzwerkrichtlinien können diese Pods nicht steuern.

Weitere Informationen zu Knotenmaschinentypen und zuweisbaren Ressourcen finden Sie unter Standardclusterarchitektur – Knoten.

Erzwingung von Netzwerkrichtlinien aktivieren

Die Erzwingung von Netzwerkrichtlinien ist für Autopilot-Cluster standardmäßig aktiviert, sodass Sie mit Netzwerkrichtlinie erstellen fortfahren können.

Sie können die Erzwingung von Netzwerkrichtlinien in GKE Standard mit der gcloud CLI, mit der Google Cloud -Konsole oder mit der GKE API aktivieren.

Die Durchsetzung von Netzwerkrichtlinien ist in GKE Dataplane V2 integriert. Sie müssen die Durchsetzung von Netzwerkrichtlinien in Clustern, die GKE Dataplane V2 verwenden, nicht aktivieren.

Für diese Änderung müssen die Knoten neu erstellt werden, was zu Unterbrechungen Ihrer laufenden Arbeitslasten führen kann. Details zu dieser spezifischen Änderung finden Sie in der entsprechenden Zeile in der Tabelle Manuelle Änderungen, die die Knoten mithilfe einer Knotenupgrade-Strategie neu erstellen und Wartungsrichtlinien berücksichtigen. Weitere Informationen zu Knotenupdates finden Sie unter Unterbrechungen durch Knotenupdates planen.

Wichtig :GKE berücksichtigt Wartungsrichtlinien, wenn die Knoten für diese Änderung mit der Knoten-Upgrade-Strategie neu erstellt werden, und hängt von der Ressourcenverfügbarkeit ab. Das Deaktivieren von automatischen Knotenupgrades verhindert diese Änderung nicht. Wenn Sie die Änderungen manuell auf die Knoten anwenden möchten, verwenden Sie die gcloud CLI, um den Befehl gcloud container clusters upgrade aufzurufen und das Flag --cluster-version mit derselben GKE-Version zu übergeben, die der Knotenpool bereits ausführt.

gcloud

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Führen Sie die folgenden Aufgaben aus, um die Durchsetzung von Netzwerkrichtlinien in Ihrem Cluster zu aktivieren:

   Achtung: Wenn Sie die Erzwingung von Netzwerkrichtlinien für den Cluster aktivieren, wird sie standardmäßig auch für die Knoten des Clusters aktiviert und kann zu Unterbrechungen bei manuell bereitgestellten Pods führen. Weitere Informationen finden Sie unter Nicht geplante manuell bereitgestellte Pods.

   1. Um das Add-on zu aktivieren, führen Sie folgenden Befehl aus:

      gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=ENABLED
      

      Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters.

   2. Mit dem unten aufgeführten Befehl aktivieren Sie die Durchsetzung von Netzwerkrichtlinien für Ihren Cluster. Dadurch werden die Knotenpools Ihres Clusters bei aktivierter Durchsetzung der Netzwerkrichtlinien neu erstellt.

      gcloud container clusters update CLUSTER_NAME --enable-network-policy
      

Console

So aktivieren Sie die Durchsetzung von Netzwerkrichtlinien in Ihrem Cluster:

Achtung: Wenn Sie die Erzwingung von Netzwerkrichtlinien für den Cluster aktivieren, wird sie standardmäßig auch für die Knoten des Clusters aktiviert und kann zu Unterbrechungen bei manuell bereitgestellten Pods führen. Weitere Informationen finden Sie unter Nicht geplante manuell bereitgestellte Pods.

1. Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

   Zur Seite "Google Kubernetes Engine"

2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.

3. Klicken Sie unter Cluster Networking (Clusternetzwerk) im Feld Calico Kubernetes Network Policy (Calico-Kubernetes-Netzwerkrichtlinie) auf Edit network policy (Netzwerkrichtlinie bearbeiten).

4. Klicken Sie im Dialogfeld Netzwerkrichtlinie bearbeiten das Kästchen Calico-Kubernetes-Netzwerkrichtlinie für Steuerungsebene aktivieren an und klicken Sie auf Änderungen speichern.

5. Warten Sie, bis die Änderungen übernommen wurden. Klicken Sie oben rechts in der Konsole auf  Benachrichtigungen, um den Fortschritt zu verfolgen.

6. Klicken Sie im Feld Calico-Kubernetes-Netzwerkrichtlinie noch einmal auf Netzwerkrichtlinie bearbeiten.

7. Klicken Sie im Dialogfeld Netzwerkrichtlinie bearbeiten das Kästchen Calico-Kubernetes-Netzwerkrichtlinie für Knoten aktivieren an.

8. Klicken Sie auf Änderungen speichern.

API

So aktivieren Sie die Durchsetzung von Netzwerkrichtlinien:

Achtung: Wenn Sie die Erzwingung von Netzwerkrichtlinien für den Cluster aktivieren, wird sie standardmäßig auch für die Knoten des Clusters aktiviert und kann zu Unterbrechungen bei manuell bereitgestellten Pods führen. Weitere Informationen finden Sie unter Nicht geplante manuell bereitgestellte Pods.

1. Geben Sie das networkPolicy-Objekt im cluster-Objekt an, das Sie für projects.zones.clusters.create oder projects.zones.clusters.update bereitstellen.

2. Das networkPolicy-Objekt erfordert ein Enum, in dem angegeben ist, welcher Netzwerkrichtlinienanbieter verwendet werden soll, sowie einen booleschen Wert, der festlegt, ob die Netzwerkrichtlinie aktiviert werden soll. Wenn Sie die Netzwerkrichtlinie aktivieren, aber keinen Anbieter festlegen, geben die Befehle create und update einen Fehler zurück.

Erzwingung von Netzwerkrichtlinien in einem Standard-Cluster deaktivieren

Sie können die Durchsetzung von Netzwerkrichtlinien mit der gcloud CLI, mit der Google Cloud -Konsole oder mit der GKE API deaktivieren. Sie können die Erzwingung von Netzwerkrichtlinien in Autopilot-Clustern oder Clustern, die GKE Dataplane V2 verwenden, nicht deaktivieren.

Für diese Änderung müssen die Knoten neu erstellt werden, was zu Unterbrechungen Ihrer laufenden Arbeitslasten führen kann. Details zu dieser spezifischen Änderung finden Sie in der entsprechenden Zeile in der Tabelle Manuelle Änderungen, die die Knoten mithilfe einer Knotenupgrade-Strategie neu erstellen und Wartungsrichtlinien berücksichtigen. Weitere Informationen zu Knotenupdates finden Sie unter Unterbrechungen durch Knotenupdates planen.

Wichtig :GKE berücksichtigt Wartungsrichtlinien, wenn die Knoten für diese Änderung mit der Knoten-Upgrade-Strategie neu erstellt werden, und hängt von der Ressourcenverfügbarkeit ab. Das Deaktivieren von automatischen Knotenupgrades verhindert diese Änderung nicht. Wenn Sie die Änderungen manuell auf die Knoten anwenden möchten, verwenden Sie die gcloud CLI, um den Befehl gcloud container clusters upgrade aufzurufen und das Flag --cluster-version mit derselben GKE-Version zu übergeben, die der Knotenpool bereits ausführt.

gcloud

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Führen Sie die folgenden Aufgaben aus, um die Durchsetzung von Netzwerkrichtlinien zu deaktivieren:

   1. Deaktivieren Sie die Durchsetzung von Netzwerkrichtlinien in Ihrem Cluster:

   gcloud container clusters update CLUSTER_NAME --no-enable-network-policy
   

   Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters.

   Nachdem Sie diesen Befehl ausgeführt haben, erstellt GKE Ihre Clusterknotenpools neu, wobei die Netzwerkrichtlinien erzwungen werden.

3. Prüfen Sie, ob alle Knoten neu erstellt wurden:

   kubectl get nodes -l projectcalico.org/ds-ready=true
   

   Wenn der Vorgang erfolgreich ist, sieht die Ausgabe in etwa so aus:

   No resources found
   

   Wenn die Ausgabe in etwa so aussieht, müssen Sie warten, bis GKE die Aktualisierung der Knotenpools abgeschlossen hat:

   NAME                                             STATUS                     ROLES    AGE     VERSION
   gke-calico-cluster2-default-pool-bd997d68-pgqn   Ready,SchedulingDisabled   <none>   15m     v1.22.10-gke.600
   gke-calico-cluster2-np2-c4331149-2mmz            Ready                      <none>   6m58s   v1.22.10-gke.600
   

   Wenn Sie die Durchsetzung von Netzwerkrichtlinien deaktivieren, aktualisiert GKE möglicherweise die Knoten nicht sofort, wenn Ihr Cluster ein konfiguriertes Wartungsfenster oder einen konfigurierten Ausschluss hat. Weitere Informationen finden Sie unter Cluster wird nur langsam aktualisiert.

4. Nachdem alle Knoten neu erstellt wurden, deaktivieren Sie das Add-on:

   gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=DISABLED
   

Console

So deaktivieren Sie die Durchsetzung von Netzwerkrichtlinien für einen vorhandenen Cluster:

1. Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

   Zur Seite "Google Kubernetes Engine"

2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.

3. Klicken Sie unter Netzwerk im Feld Netzwerkrichtlinie auf Netzwerkrichtlinie bearbeiten.

4. Entfernen Sie das Häkchen aus dem Kästchen Netzwerkrichtlinie für Knoten aktivieren und klicken Sie auf Änderungen speichern.

5. Warten Sie, bis Ihre Änderungen übernommen wurden, und klicken Sie dann noch einmal auf Netzwerkrichtlinie bearbeiten.

6. Entfernen Sie das Häkchen aus dem Kästchen Netzwerkrichtlinie für Master aktivieren.

7. Klicken Sie auf Änderungen speichern.

API

So deaktivieren Sie die Durchsetzung von Netzwerkrichtlinien für einen vorhandenen Cluster:

1. Aktualisieren Sie Ihren Cluster für die Verwendung von networkPolicy.enabled: false mit der setNetworkPolicy API.

2. Überprüfen Sie, ob alle Knoten mit der gcloud CLI neu erstellt wurden:

   kubectl get nodes -l projectcalico.org/ds-ready=true
   

   Wenn der Vorgang erfolgreich ist, sieht die Ausgabe in etwa so aus:

   No resources found
   

   Wenn die Ausgabe in etwa so aussieht, müssen Sie warten, bis GKE die Aktualisierung der Knotenpools abgeschlossen hat:

   NAME                                             STATUS                     ROLES    AGE     VERSION
   gke-calico-cluster2-default-pool-bd997d68-pgqn   Ready,SchedulingDisabled   <none>   15m     v1.22.10-gke.600
   gke-calico-cluster2-np2-c4331149-2mmz            Ready                      <none>   6m58s   v1.22.10-gke.600
   

   Wenn Sie die Durchsetzung von Netzwerkrichtlinien deaktivieren, aktualisiert GKE möglicherweise die Knoten nicht sofort, wenn Ihr Cluster ein konfiguriertes Wartungsfenster oder einen konfigurierten Ausschluss hat. Weitere Informationen finden Sie unter Cluster wird nur langsam aktualisiert.

3. Aktualisieren Sie Ihren Cluster für die Verwendung von update.desiredAddonsConfig.NetworkPolicyConfig.disabled: true mit der updateCluster API.

Netzwerkrichtlinie erstellen

Sie können eine Netzwerkrichtlinie mit der Kubernetes Network Policy API erstellen.

Weitere Informationen zum Erstellen einer Netzwerkrichtlinie finden Sie in den folgenden Themen in der Kubernetes-Dokumentation:

• Netzwerkrichtlinien
• Netzwerkrichtlinien deklarieren

Netzwerkrichtlinie und Identitätsföderation von Arbeitslasten für GKE

Wenn Sie Netzwerkrichtlinien mit der Identitätsföderation von Arbeitslasten für GKE verwenden, müssen Sie ausgehenden Traffic zu den folgenden IP-Adressen zulassen, damit die Pods mit dem GKE-Metadatenserver kommunizieren können.

• Lassen Sie für Cluster mit GKE-Version 1.21.0-gke.1000 und höher den ausgehenden Traffic zu 169.254.169.252/32 an Port 988 zu.
• Bei Clustern, auf denen GKE-Versionen vor 1.21.0-gke.1000 ausgeführt werden, müssen Sie ausgehenden Traffic zu 127.0.0.1/32 an Port 988 zulassen.
• Lassen Sie für Cluster mit GKE Dataplane V2 ausgehenden Traffic zu 169.254.169.254/32 an Port 80 zu.

Wenn Sie ausgehenden Traffic zu diesen IP-Adressen und Ports nicht zulassen, können bei automatischen Upgrades Unterbrechungen auftreten.

Von Calico zu GKE Dataplane V2 migrieren

Beachten Sie die folgenden Einschränkungen, wenn Sie Ihre Netzwerkrichtlinien von Calico zu GKE Dataplane V2 migrieren:

• Sie können keine Pod- oder Dienst-IP-Adresse im Feld ipBlock.cidr eines NetworkPolicy-Manifests verwenden. Sie müssen Arbeitslasten mithilfe von Labels referenzieren. Die folgende Konfiguration ist beispielsweise ungültig:

  - ipBlock:
      cidr: 10.8.0.6/32
  

• Sie können in einem NetworkPolicy-Manifest kein leeres ports.port-Feld angeben. Wenn Sie ein Protokoll angeben, müssen Sie auch einen Port angeben. Die folgende Konfiguration ist beispielsweise ungültig:

  ingress:
  - ports:
    - protocol: TCP
  

Mit Application Load Balancern arbeiten

Wenn ein Ingress auf einen Dienst angewendet wird, um einen HTTP(S)-Load-Balancer zu erstellen, müssen Sie dafür sorgen, dass Ihre Netzwerkrichtlinie Traffic aus den IP-Bereichen der Systemdiagnose des HTTP(S)-Application Load Balancers zulässt.

Hinweis :In GKE Dataplane V2-Umgebungen können Sie ipBlock.cidr nicht verwenden, um Pod- oder Dienst-IP-Adressen in Ihrer Netzwerkrichtlinie anzugeben. Sie können jedoch mit ipBlock.cidr andere CIDR-Blöcke definieren, z. B. die für Load-Balancer-Systemdiagnosen erforderlich sind.

Wenn Sie kein containernatives Load-Balancing mit Netzwerk-Endpunktgruppen verwenden, leiten die Knotenports für einen Dienst möglicherweise Verbindungen zu Pods auf anderen Knoten weiter, sofern dies nicht durch Festlegen von externalTrafficPolicy auf Local in der Definition des Dienstes unterbunden wird. Wenn externalTrafficPolicy nicht auf Local gesetzt ist, muss die Netzwerkrichtlinie auch Verbindungen von anderen Knoten-IP-Adressen im Cluster zulassen.

Aufnahme von Pod-IP-Bereichen in die ipBlock-Regeln

Wenn Sie Traffic für bestimmte Pods steuern möchten, wählen Sie Pods immer nach ihrem Namespace oder Pod-Labels aus. Verwenden Sie dazu in den NetworkPolicy-Regeln für ein- oder ausgehenden Traffic die Felder namespaceSelector und podSelector. Verwenden Sie das Feld ipBlock.cidr nicht, um absichtlich Pod-IP-Adressbereiche auszuwählen, die standardmäßig sitzungsspezifisch sind. Das Kubernetes-Projekt definiert das Verhalten des Felds ipBlock.cidr nicht explizit, wenn es Pod-IP-Adressbereiche enthält. Die Angabe von breiten CIDR-Bereichen in diesem Feld, z. B. 0.0.0.0/0 (einschließlich der Pod-IP-Adressbereiche), kann zu unerwarteten Ergebnissen in verschiedenen Implementierungen von NetworkPolicy führen.

In den folgenden Abschnitten wird beschrieben, wie die verschiedenen Implementierungen von NetworkPolicy in GKE die IP-Adressbereiche auswerten, die Sie im Feld ipBlock.cidr angeben, und wie sich dies auf die Pod-IP-Adressbereiche auswirken kann, die standardmäßig in breiten CIDR-Bereichen enthalten sind. Wenn Sie das Verhalten zwischen Implementierungen verstehen, können Sie sich auf die Ergebnisse vorbereiten, wenn Sie zu einer anderen Implementierung migrieren.

ipBlock-Verhalten in GKE Dataplane V2

Bei der GKE Dataplane V2-Implementierung von NetworkPolicy wird der Pod-Traffic nie von einer ipBlock-Regel abgedeckt. Selbst wenn Sie eine allgemeine Regel wie cidr: '0.0.0.0/0' definieren, umfasst sie keinen Pod-Traffic. Das ist nützlich, da Sie beispielsweise Pods in einem Namespace erlauben können, Traffic aus dem Internet zu empfangen, ohne auch Traffic von Pods zuzulassen. Wenn Sie auch Pod-Traffic einschließen möchten, wählen Sie Pods explizit mit einem zusätzlichen Pod oder Namespace-Selektor in den Definitionen für eingehenden oder ausgehenden Traffic von NetworkPolicy aus.

ipBlock-Verhalten in Calico

Für die Calico-Implementierung von NetworkPolicy beziehen sich die ipBlock-Regeln auf Pod-Traffic. Wenn Sie mit dieser Implementierung einen breiten CIDR-Bereich konfigurieren möchten, ohne Pod-Traffic zuzulassen, schließen Sie den Pod-CIDR-Bereich des Clusters explizit aus, wie im folgenden Beispiel:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-non-pod-traffic
spec:
  ingress:
  - from:
    - ipBlock:
      cidr: '0.0.0.0/0'
      except: ['POD_IP_RANGE']

In diesem Beispiel ist POD_IP_RANGE der IPv4-Adressbereich für Pods Ihres Clusters, z. B. 10.95.0.0/17. Wenn Sie mehrere IP-Bereiche haben, können diese einzeln in das Array aufgenommen werden, z. B. ['10.95.0.0/17', '10.108.128.0/17'].

Verhalten von Netzwerkrichtlinien mit externalTrafficPolicy steuern

Die Einstellung externalTrafficPolicy für Ihren Dienst beeinflusst, wie Kubernetes Netzwerkrichtlinien anwendet. Diese Einstellung bestimmt die Quell-IP-Adresse, die Ihre Pods für eingehenden Traffic sehen. Das kann sich darauf auswirken, wie Kubernetes NetworkPolicy-Regeln auswertet.

externalTrafficPolicyhat zwei mögliche Werte:

• Cluster:Wenn externalTrafficPolicy auf Cluster festgelegt ist, wird die Quell-IP-Adresse für den Ziel-Pod als IP-Adresse des Knotens angezeigt, auf dem der Traffic ursprünglich empfangen wurde. Wenn Sie eine NetworkPolicy haben, die Traffic basierend auf Client-IP-Adressen ablehnt, aber die Remote-Knoten-IP-Adressen nicht enthält, kann es sein, dass externer Traffic von den in den Richtlinienregeln angegebenen externen Clients unbeabsichtigt blockiert wird. Um dies zu vermeiden, erstellen Sie eine Richtlinie, die Traffic von allen Knoten im Cluster zulässt. Diese Richtlinie lässt jedoch Traffic von jedem externen Client zu.

• Local:Wenn externalTrafficPolicy auf Local festgelegt ist, wird die Quell-IP-Adresse im Pod als ursprüngliche Client-IP-Adresse angezeigt. Dies ermöglicht eine detailliertere Steuerung mit Netzwerkrichtlinien, da Sie Regeln basierend auf den tatsächlichen Client-IP-Adressen definieren können.

Fehlerbehebung

Pods können nicht mit der Steuerungsebene in Clustern kommunizieren, die Private Service Connect verwenden

Bei Pods in GKE-Clustern, die Private Service Connect verwenden, kann ein Kommunikationsproblem mit der Steuerungsebene auftreten, wenn der ausgehende Traffic des Pods an die interne IP-Adresse der Steuerungsebene in ausgehenden Netzwerk-Richtlinien eingeschränkt ist.

So beheben Sie das Problem:

1. Prüfen Sie, ob Ihr Cluster Private Service Connect verwendet. Wenn Sie in Clustern, die Private Service Connect verwenden, das Flag master-ipv4-cidr beim Erstellen des Subnetzes verwenden, weist GKE jeder Steuerungsebene eine interne IP-Adresse aus den Werten zu, die Sie in master-ipv4-cidr definiert haben. Andernfalls verwendet GKE das Clusterknoten-Subnetz, um jeder Steuerungsebene eine interne IP-Adresse zuzuweisen.

2. Konfigurieren Sie die Egress-Richtlinie Ihres Clusters so, dass Traffic zur internen IP-Adresse der Steuerungsebene zugelassen wird.

   So finden Sie die interne IP-Adresse der Steuerungsebene:

   gcloud

   Führen Sie den folgenden Befehl aus, um nach privateEndpoint zu suchen:

   gcloud container clusters describe CLUSTER_NAME
   

   Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters.

   Mit diesem Befehl wird die privateEndpoint des angegebenen Clusters abgerufen.

   Console

   1. Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

      Zur Seite "Google Kubernetes Engine"

   2. Klicken Sie im Navigationsbereich unter Cluster auf den Cluster, dessen interne IP-Adresse Sie suchen.

   3. Rufen Sie unter Clustergrundlagen Internal endpoint auf. Dort wird die interne IP-Adresse aufgeführt.

   Sobald Sie privateEndpoint oder Internal endpoint gefunden haben, konfigurieren Sie die Richtlinie für ausgehenden Traffic Ihres Clusters so, dass Traffic zur internen IP-Adresse der Steuerungsebene zugelassen wird. Weitere Informationen finden Sie unter Netzwerkrichtlinie erstellen.

Cluster wird langsam aktualisiert

Wenn Sie die Durchsetzung von Netzwerkrichtlinien in einem vorhandenen Cluster aktivieren oder deaktivieren, aktualisiert GKE die Knoten möglicherweise nicht sofort, wenn für den Cluster ein Wartungsfenster oder ein Ausschluss konfiguriert ist.

Sie können einen Knotenpool manuell aktualisieren. Setzen Sie dazu das Flag --cluster-version auf dieselbe GKE-Version, die auf der Steuerungsebene ausgeführt wird. Für diesen Vorgang müssen Sie die Google Cloud-Befehlszeile verwenden. Weitere Informationen finden Sie unter Hinweise für Wartungsfenster.

Nicht geplante manuell bereitgestellte Pods

Wenn Sie die Durchsetzung von Netzwerkrichtlinien auf der Steuerungsebene eines vorhandenen Clusters aktivieren, plant GKE alle ip-masquerade-agent- oder calico-Knoten-Pods, die Sie manuell bereitgestellt haben.

GKE plant diese Pods erst neu, wenn die Durchsetzung von Netzwerkrichtlinien auf den Clusterknoten aktiviert ist und die Knoten neu erstellt werden.

Wenn Sie ein Wartungsfenster oder einen Wartungsausschluss konfiguriert haben, kann es zu einer längeren Unterbrechung kommen.

Um die Dauer dieser Unterbrechung zu minimieren, können Sie den Clusterknoten manuell die folgenden Labels zuweisen:

• node.kubernetes.io/masq-agent-ds-ready=true
• projectcalico.org/ds-ready=true

Netzwerkrichtlinie wird nicht wirksam

Wenn eine NetworkPolicy nicht wirksam wird, können Sie das Problem mit den folgenden Schritten beheben:

1. Prüfen Sie, ob die Durchsetzung von Netzwerkrichtlinien aktiviert ist. Der dabei verwendete Befehl hängt davon ab, ob in Ihrem Cluster GKE Dataplane V2 aktiviert ist.

   Wenn in Ihrem Cluster GKE Dataplane V2 aktiviert ist, führen Sie den folgenden Befehl aus:

   kubectl -n kube-system get pods -l k8s-app=cilium
   

   Wenn die Ausgabe leer ist, ist die Durchsetzung von Netzwerkrichtlinien nicht aktiviert.

   Wenn in Ihrem Cluster GKE Dataplane V2 nicht aktiviert ist, führen Sie den folgenden Befehl aus:

   kubectl get nodes -l projectcalico.org/ds-ready=true
   

   Wenn die Ausgabe leer ist, ist die Durchsetzung von Netzwerkrichtlinien nicht aktiviert.

2. Prüfen Sie die Pod-Labels:

   kubectl describe pod POD_NAME
   

   Ersetzen Sie POD_NAME durch den Namen des Pods.

   Die Ausgabe sieht in etwa so aus:

   Labels:        app=store
                  pod-template-hash=64d9d4f554
                  version=v1
   

3. Prüfen Sie, ob die Labels in der Richtlinie mit den Labels im Pod übereinstimmen:

   kubectl describe networkpolicy
   

   Die Ausgabe sieht in etwa so aus:

   PodSelector: app=store
   

   In dieser Ausgabe entsprechen die app=store-Labels den app=store-Labels aus dem vorherigen Schritt.

4. Prüfen Sie, ob Ihre Arbeitslasten von Netzwerkrichtlinien ausgewählt werden:

   kubectl get networkpolicy
   

   Wenn die Ausgabe leer ist, wurde im Namespace keine NetworkPolicy erstellt und Ihre Arbeitslasten werden nicht ausgewählt. Wenn die Ausgabe nicht leer ist, prüfen Sie, ob die Richtlinie Ihre Arbeitslasten auswählt:

   kubectl describe networkpolicy
   

   Die Ausgabe sieht in etwa so aus:

   ...
   PodSelector:     app=nginx
   Allowing ingress traffic:
      To Port: <any> (traffic allowed to all ports)
      From:
         PodSelector: app=store
   Not affecting egress traffic
   Policy Types: Ingress
   

Bekannte Probleme

StatefulSet-Pod-Beendigung mit Calico

Bei GKE-Clustern, bei denen eine Calico-Netzwerkrichtlinie aktiviert ist, kann das Problem auftreten, dass ein StatefulSet-Pod vorhandene Verbindungen löscht, wenn der Pod gelöscht wird. Nachdem ein Pod den Status Terminating erreicht hat, wird die Konfiguration terminationGracePeriodSeconds in der Pod-Spezifikation nicht berücksichtigt und verursacht Unterbrechungen für andere Anwendungen, die eine vorhandene Verbindung zum StatefulSet-Pod haben. Weitere Informationen zu diesem Problem finden Sie unter Calico-Problem Nr. 4710.

Dieses Problem betrifft die folgenden GKE-Versionen:

• 1.18
• 1.19 bis 1.19.16-gke.99
• 1.20 bis 1.20.11-gke.1299
• 1.21 bis 1.21.4-gke.1499

Aktualisieren Sie Ihre GKE-Steuerungsebene auf eine der folgenden Versionen, um dieses Problem zu beheben:

• 1.19.16-gke.100 oder höher
• 1.20.11-gke.1300 oder höher
• 1.21.4-gke.1500 oder höher

Pod hängt im Zustand containerCreating fest

Es kann vorkommen, dass in GKE-Clustern mit aktivierter Calico-Netzwerkrichtlinie ein Problem auftritt, bei dem Pods im Zustand containerCreating hängen bleiben.

Auf dem Tab Events des Pods wird eine Meldung wie die folgende angezeigt:

plugin type="calico" failed (add): ipAddrs is not compatible with
configured IPAM: host-local

Um dieses Problem zu beheben, verwenden Sie host-local IPAM für Calico anstelle von calico-ipam in GKE-Clustern.

Nächste Schritte

• Anleitung zu Netzwerkrichtlinien

• Kubernetes-Dokumentation zu Netzwerkrichtlinien lesen

• Gängige Ansätze zur Beschränkung des Traffics mithilfe von Netzwerkrichtlinien implementieren

• Logging von Netzwerkrichtlinien verwenden

• Mit Sicherheitsinformationen andere Möglichkeiten zur Verbesserung Ihrer Infrastruktur kennenlernen