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.
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.
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
- oderg1-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.
gcloud
-
In the Google Cloud console, 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.
Führen Sie die folgenden Aufgaben aus, um die Durchsetzung von Netzwerkrichtlinien in Ihrem Cluster zu aktivieren:
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.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
Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.
Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.
Klicken Sie unter Cluster Networking (Clusternetzwerk) im Feld Calico Kubernetes Network Policy (Calico-Kubernetes-Netzwerkrichtlinie) auf edit Edit network policy (Netzwerkrichtlinie bearbeiten).
Klicken Sie im Dialogfeld Netzwerkrichtlinie bearbeiten das Kästchen Calico-Kubernetes-Netzwerkrichtlinie für Steuerungsebene aktivieren an und klicken Sie auf Änderungen speichern.
Warten Sie, bis die Änderungen übernommen wurden. Klicken Sie oben rechts in der Konsole auf notifications Benachrichtigungen, um den Fortschritt zu verfolgen.
Klicken Sie im Feld Calico-Kubernetes-Netzwerkrichtlinie noch einmal auf edit Netzwerkrichtlinie bearbeiten.
Klicken Sie im Dialogfeld Netzwerkrichtlinie bearbeiten das Kästchen Calico-Kubernetes-Netzwerkrichtlinie für Knoten aktivieren an.
Klicken Sie auf Änderungen speichern.
Geben Sie das
networkPolicy
-Objekt imcluster
-Objekt an, das Sie für projects.zones.clusters.create oder projects.zones.clusters.update bereitstellen.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 Befehlecreate
undupdate
einen Fehler zurück.
Console
So aktivieren Sie die Durchsetzung von Netzwerkrichtlinien in Ihrem Cluster:
API
So aktivieren Sie die Durchsetzung von Netzwerkrichtlinien:
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.
gcloud
-
In the Google Cloud console, 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.
Führen Sie die folgenden Aufgaben aus, um die Durchsetzung von Netzwerkrichtlinien zu deaktivieren:
- 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.
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.
Nachdem alle Knoten neu erstellt wurden, deaktivieren Sie das Add-on:
gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=DISABLED
Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.
Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.
Klicken Sie unter Netzwerk im Feld Netzwerkrichtlinie auf edit Netzwerkrichtlinie bearbeiten.
Entfernen Sie das Häkchen aus dem Kästchen Netzwerkrichtlinie für Knoten aktivieren und klicken Sie auf Änderungen speichern.
Warten Sie, bis Ihre Änderungen übernommen wurden, und klicken Sie dann noch einmal auf edit Netzwerkrichtlinie bearbeiten.
Entfernen Sie das Häkchen aus dem Kästchen Netzwerkrichtlinie für Master aktivieren.
Klicken Sie auf Änderungen speichern.
Aktualisieren Sie Ihren Cluster für die Verwendung von
networkPolicy.enabled: false
mit dersetNetworkPolicy
API.Ü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.
Aktualisieren Sie Ihren Cluster für die Verwendung von
update.desiredAddonsConfig.NetworkPolicyConfig.disabled: true
mit derupdateCluster
API.
Console
So deaktivieren Sie die Durchsetzung von Netzwerkrichtlinien für einen vorhandenen Cluster:
API
So deaktivieren Sie die Durchsetzung von Netzwerkrichtlinien für einen vorhandenen Cluster:
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 Port988
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 Port988
zulassen. - Lassen Sie für Cluster mit GKE Dataplane V2 ausgehenden Traffic zu
169.254.169.254/32
an Port80
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
einesNetworkPolicy
-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 leeresports.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.
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.
externalTrafficPolicy
hat zwei mögliche Werte:
Cluster
:WennexternalTrafficPolicy
aufCluster
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
:WennexternalTrafficPolicy
aufLocal
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:
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 inmaster-ipv4-cidr
definiert haben. Andernfalls verwendet GKE das Clusterknoten-Subnetz, um jeder Steuerungsebene eine interne IP-Adresse zuzuweisen.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
Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.
Klicken Sie im Navigationsbereich unter Cluster auf den Cluster, dessen interne IP-Adresse Sie suchen.
Rufen Sie unter Clustergrundlagen
Internal endpoint
auf. Dort wird die interne IP-Adresse aufgeführt.
Sobald Sie
privateEndpoint
oderInternal 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:
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.
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
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 denapp=store
-Labels aus dem vorherigen Schritt.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
Gängige Ansätze zur Beschränkung des Traffics mithilfe von Netzwerkrichtlinien implementieren
Mit Sicherheitsinformationen andere Möglichkeiten zur Verbesserung Ihrer Infrastruktur kennenlernen