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.

Erzwingung von GKE-Netzwerkrichtlinien

Mit der Erzwingung von Netzwerkrichtlinien können Sie in Ihrem Cluster Netzwerkrichtlinien für Kubernetes erstellen. Alle Pods innerhalb eines Clusters können standardmäßig 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.

Vorbereitung

Führen Sie die folgenden Schritte durch, 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.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

Anforderungen und Einschränkungen

Es gelten die folgenden Anforderungen und Einschränkungen:

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.

Erzwingung von Netzwerkrichtlinien aktivieren

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

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.

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.

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

Fehlerbehebung

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

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. 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 Clusterknotensubnetz zugewiesen.
Konfigurieren Sie die Richtlinie für ausgehenden Traffic des Clusters, um Traffic zur internen IP-Adresse der Steuerungsebene zuzulassen.

So ermitteln 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, wo die interne IP-Adresse aufgeführt ist.
Wenn Sie privateEndpoint oder Internal endpoint finden, konfigurieren Sie die Richtlinie für ausgehenden Traffic des 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.

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 den app=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
```