Datenverkehr zwischen Pods mit Kubernetes-Richtlinien steuern

Virtuelle private Cloud

Unter Verwendung von Kubernetes-Richtlinien können Sie den Netzwerkverkehr zwischen Pods in Ihrem Cluster steuern und App-Microservices innerhalb eines Namensbereichs oder namensbereichsübergreifend isolieren.

Anwendungsebene: Endpunkt des Workerknotenhosts

Standardverhalten: Standardmäßig sind keine Kubernetes-Netzrichtlinien in Ihrem Cluster vorhanden. Standardmäßig hat jeder Pod Zugriff auf alle anderen Pods im Cluster. Darüber hinaus hat jeder Pod Zugriff auf alle über das Podnetz zugänglich gemachten Services, z. B. einen Metrikservice, den Cluster-DNS, den API-Server sowie alle von Ihnen manuell erstellten Services im Cluster.

Anwendungsfall: Kubernetes-Netzrichtlinien legen fest, wie Pods mit anderen Pods und mit externen Endpunkten kommunizieren können. Sowohl eingehender als auch abgehender Netzdatenverkehr kann basierend auf Protokoll, Port und Quellen- oder Ziel-IP-Adressen zugelassen oder blockiert werden. Der Datenverkehr kann zudem anhand von Pod- und Namensbereichsbezeichnungen gefiltert werden. Kubernetes-Netzrichtlinien werden bei ihrer Anwendung automatisch in Calico-Netzwerkrichtlinien konvertiert. Das Plug-in für das Calico-Netz in Ihrem Cluster setzt diese Richtlinien durch Einrichten von 'Iptables'-Regeln von Linux in den Workerknoten um. 'Iptables'-Regeln dienen als Firewall für den Workerknoten, um die Merkmale zu definieren, die der Netzverkehr erfüllen muss, damit er an die Zielressource weitergeleitet wird.

Wenn die meisten oder alle Pods keinen Zugriff auf bestimmte Pods oder Services benötigen und Sie sicherstellen möchten, dass Pods standardmäßig nicht auf diese Pods oder Services zugreifen können, können Sie eine Kubernetes-Netzrichtlinie erstellen, um den Ingress-Datenverkehr zu diesen Pods oder Services zu blockieren.

Weitere Informationen darüber, wie Kubernetes Netzwerkrichtlinien den Datenverkehr zwischen Pods steuern, sowie weitere Beispielrichtlinien finden Sie in der Kubernetes Dokumentation.

App-Services in einem Namensbereich isolieren

Das folgende Szenario veranschaulicht, wie der Datenverkehr zwischen App-Microservices in einem Namensbereich verwaltet wird.

Ein Team 'Accounts' stellt mehrere App-Services in einem Namensbereich bereit. Diese müssen jedoch isoliert werden, um nur die erforderliche Kommunikation zwischen den Microservices über das öffentliche Netz zu ermöglichen. Für die App Srv1 verfügt das Team über Front-End-, Back-End- und Datenbankservices. Jeder Service erhält die Bezeichnung app: Srv1 sowie die Bezeichnung tier: frontend, tier: backend oder tier: db.

Verwenden Sie eine Netzwerkrichtlinie, um den Datenverkehr zwischen Namespaces zu verwalten. — Verwenden Sie eine Netzwerkrichtlinie, um den Datenverkehr im Namespace zu verwalten.

Das Team 'Accounts' möchte Datenverkehr vom Front-End zum Back-End und vom Back-End zur Datenbank zulassen. Es verwendet Bezeichnungen in den Netzrichtlinien, um festzulegen, welche Datenflüsse zwischen den Microservices zulässig sind.

Zunächst erstellt das Team eine Kubernetes-Netzrichtlinie, die den Datenverkehr vom Front-End zum Back-End ermöglicht:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-allow
spec:
  podSelector:
    matchLabels:
      app: Srv1
      tier: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: Srv1
          Tier: frontend

Im Abschnitt spec.podSelector.matchLabels werden die Bezeichnungen für den Back-End-Service Srv1 aufgelistet, sodass die Richtlinie nur zu diesen Pods anwendbar ist. Im Abschnitt spec.ingress.from.podSelector.matchLabels werden die Bezeichnungen für den Front-End-Service Srv1 aufgelistet, sodass Ingress nur von diesen Pods zulässig ist.

Anschließend erstellt das Team eine ähnliche Kubernetes-Netzrichtlinie, durch die der Datenverkehr vom Back-End zur Datenbank zulässig ist:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: db-allow
spec:
  podSelector:
    matchLabels:
      app: Srv1
      tier: db
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: Srv1
          Tier: backend

Im Abschnitt spec.podSelector.matchLabels werden die Bezeichnungen für den Srv1 -Datenbankservice aufgelistet, sodass die Richtlinie nur zu diesen Pods anwendbar ist. Im Abschnitt spec.ingress.from.podSelector.matchLabels werden die Bezeichnungen für den Srv1 -Back-End-Service aufgelistet, sodass Ingress nur von diesen Pods zulässig ist.

Der Datenverkehr kann nun vom Front-End zum Back-End und vom Back-End zur Datenbank fließen. Die Datenbank kann auf das Back-End reagieren und das Back-End auf das Front-End; es können jedoch keine umgekehrten Datenverkehrsverbindungen aufgebaut werden.

App-Services zwischen Namensbereichen isolieren

Im folgenden Szenario wird gezeigt, wie der Datenverkehr zwischen App-Microservices über mehrere Namensbereiche hinweg verwaltet wird.

Dienste, die verschiedenen Unterteams gehören, müssen miteinander kommunizieren, sind jedoch in unterschiedlichen Namespaces innerhalb desselben Clusters bereitgestellt. Das Team 'Accounts' stellt Front-End-, Back-End- und Datenbankservices für die App 'Srv1' im Namensbereich 'account' bereit. Das Team 'Finance' stellt Front-End-, Back-End- und Datenbankservices für die App 'Srv2' im Namensbereich 'finance' bereit. Jeder Service erhält von den Teams die Bezeichnung app: Srv1 oder app: Srv2 sowie die Bezeichnung tier: frontend, tier: backend oder tier: db. Außerdem werden die Namensbereiche mit der Bezeichnung usage: accounts oder usage: finance versehen.

'Srv2' des Teams 'Finance' muss Informationen vom Back-End für 'Srv1' des Teams 'Accounts' aufrufen. Das Team 'Accounts' erstellt daher eine Kubernetes-Netzrichtlinie, die mithilfe von Bezeichnungen den gesamten Datenverkehr vom Namensbereich 'finance' zum Back-End für 'Srv1' im Namensbereich 'accounts' zulässt. Das Team gibt zudem den Port 3111 an, um den Zugriff ausschließlich an diesem Port zu ermöglichen.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  Namespace: accounts
  name: accounts-allow
spec:
  podSelector:
    matchLabels:
      app: Srv1
      Tier: backend
  ingress:
  - from:
    - NamespaceSelector:
        matchLabels:
          usage: finance
      ports:
        port: 3111

Im Abschnitt spec.podSelector.matchLabels werden die Bezeichnungen für den Back-End-Service Srv1 aufgelistet, sodass die Richtlinie nur zu diesen Pods anwendbar ist. Im Abschnitt spec.ingress.from.NamespaceSelector.matchLabels wird die Bezeichnung für den Namensbereich 'finance' aufgelistet, sodass Ingress nur von Services in diesem Namensbereich zulässig ist.

Der Datenverkehr kann nun von den Microservices von 'finance' zum Back-End für 'Srv1' von 'accounts' fließen. Das Back-End für Srv1 von 'accounts' kann auf die Microservices von 'finance' antworten, jedoch keine umgekehrte Datenverkehrsverbindung herstellen.

In diesem Beispiel ist der gesamte Datenverkehr von allen Microservices im Namensbereich 'finance' zulässig. Der Datenverkehr von bestimmten App-Pods in einem anderen Namensbereich ist nicht möglich, da podSelector und namespaceSelector nicht kombiniert werden können.