Kommunikation zwischen Pods und Services mithilfe von Netzwerkrichtlinien steuern

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 Services mithilfe von FQDNs steuern.

Erzwingung von GKE-Netzwerkrichtlinien

Mit der Erzwingung von Netzwerkrichtlinien können Sie in Ihrem Cluster Netzwerkrichtlinien für Kubernetes erstellen. 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.

Vorbereitung

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 diese Aufgabe 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 gcloud components update ab.

Anforderungen und Einschränkungen

Die folgenden Anforderungen und Einschränkungen gelten sowohl für Autopilot- als auch für Standard-Cluster: 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 kleinste empfohlene Clustergröße zum Ausführen der Durchsetzung von Netzwerkrichtlinien besteht aus drei Instanzen vom Typ e2-medium.
  • Die Netzwerkrichtlinie wird für Cluster, deren Knoten f1-micro- oder g1-small-Instanzen sind, nicht unterstützt, da die Ressourcenanforderungen zu hoch sind.

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 Console 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.

gcloud

  1. Aktivieren Sie Cloud Shell in der Google Cloud Console.

    Cloud Shell aktivieren

    Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.

  2. Zum Aktivieren der Durchsetzung von Netzwerkrichtlinien beim Erstellen eines neuen Clusters führen Sie den folgenden Befehl aus:

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

    Ersetzen Sie CLUSTER_NAME durch den Namen des neuen Clusters.

    Zum Aktivieren der Durchsetzung von Netzwerkrichtlinien für einen vorhandenen Cluster führen Sie folgende Aufgaben aus:

    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 beim Erstellen eines neuen Clusters:

  1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

    Zur Seite „Google Kubernetes Engine“

  2. Klicken Sie auf Erstellen.

  3. Klicken Sie im Dialogfeld Cluster erstellen für GKE Standard auf Konfigurieren.

  4. Konfigurieren Sie den Cluster wie gewünscht.

  5. Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.

  6. Klicken Sie auf das Kästchen Netzwerkrichtlinie aktivieren.

  7. Klicken Sie auf Erstellen.

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

  1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf:

    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. Klicken Sie auf das Kästchen Netzwerkrichtlinie für Master aktivieren und anschließend auf Änderungen speichern.

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

  6. Klicken Sie das Kästchen Netzwerkrichtlinie für Knoten aktivieren an.

  7. Klicken Sie auf Änderungen speichern.

API

So aktivieren Sie die Durchsetzung von Netzwerkrichtlinien:

  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 Erzwingung von Netzwerkrichtlinien mit der gcloud CLI, mit der Google Cloud Console 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.

gcloud

  1. Aktivieren Sie Cloud Shell in der Google Cloud Console.

    Cloud Shell aktivieren

    Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.

  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. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf:

    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:

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 Application Load Balancer zu erstellen, müssen Sie die auf die Pods hinter diesem Dienst angewendete Netzwerkrichtlinie konfigurieren, um die entsprechenden IP-Bereiche der Systemdiagnose des Application Load Balancers zuzulassen. Wenn Sie einen internen Application Load Balancer verwenden, müssen Sie außerdem die Netzwerkrichtlinie so konfigurieren, dass das Nur-Proxy-Subnetz zugelassen wird.

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. Dies ist nützlich, da Sie beispielsweise Pods in einem Namespace erlauben, 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 einen allgemeinen CIDR-Bereich konfigurieren, ohne Pod-Traffic zuzulassen, schließen Sie bei dieser Implementierung 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 Pod-IPv4-Adressbereich 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'].

Fehlerbehebung

Pods können nicht mit Steuerungsebenen 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. Weitere Informationen finden Sie unter Öffentliche Cluster mit Private Service Connect. In Clustern, die Private Service Connect verwenden, wird jede Steuerungsebene einer internen IP-Adresse aus dem Subnetz des Clusterknotens zugewiesen.

  2. Konfigurieren Sie die Richtlinie für ausgehenden Traffic Ihres Clusters, um Traffic zur internen IP-Adresse der Steuerungsebene zuzulassen.

    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 der privateEndpoint des angegebenen Clusters abgerufen.

    Console

    1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

      Zur Seite "Google Kubernetes Engine"

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

    3. Gehen Sie unter Clustergrundlagen zu Internal endpoint, wobei die interne IP-Adresse aufgeführt ist.

    Wenn Sie privateEndpoint oder Internal endpoint gefunden haben, konfigurieren Sie die Richtlinie für ausgehenden Traffic Ihres Clusters, um Traffic zur internen IP-Adresse der Steuerungsebene zuzulassen. 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 Ereignisse 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