Mehrere Netzwerkschnittstellen für Pods konfigurieren

In diesem Dokument wird beschrieben, wie Sie GDCV für Bare Metal konfigurieren, um für Ihre Pods mehrere Netzwerkschnittstellen (Multi-NICs) bereitzustellen. Das Feature mit mehreren NICs für Pods kann dabei helfen, den Traffic auf Steuerungsebene vom Traffic auf Datenebene zu trennen, wodurch eine Isolation zwischen den Ebenen entsteht. Zusätzliche Netzwerkschnittstellen ermöglichen auch Multicast-Funktionen für Ihre Pods. Multi-NIC für Pods wird für Nutzercluster, Hybridcluster und eigenständige Cluster unterstützt. Bei Administratortyp-Clustern ist es nicht zulässig.

Die Isolierung der Netzwerkebene ist für Systeme wichtig, die Virtual Functions für Netzwerkfunktionen (NFVs) verwenden, z. B. softwarebasierte Netzwerke in einem Wide Area Network (SD-WAN), einen Cloud Access Security Broker (CASB) und Generierungsfirewalls (NG-FWs). Diese Arten von NFVs erfordern Zugriff auf mehrere Schnittstellen, um die Verwaltungs- und Datenebenen getrennt zu halten, während sie als Container ausgeführt werden.

Die Konfiguration der mehreren Netzwerkschnittstellen unterstützt die Verknüpfung von Netzwerkschnittstellen mit Knotenpools, was zu Leistungsvorteilen führen kann. Cluster können eine Mischung aus Knotentypen enthalten. Wenn Sie leistungsstarke Maschinen in einem Knotenpool gruppieren, können Sie dem Knotenpool zusätzliche Schnittstellen hinzufügen, um den Trafficfluss zu verbessern.

Mehrere Netzwerkschnittstellen einrichten

Im Allgemeinen gibt es drei Schritte, um mehrere Netzwerkschnittstellen für Ihre Pods einzurichten:

  1. Aktivieren Sie Multi-NIC für Ihren Cluster mit dem Feld multipleNetworkInterfaces in der benutzerdefinierten Clusterressource.

  2. Netzwerkschnittstellen mit NetworkAttachmentDefinition benutzerdefinierten Ressourcen angeben.

  3. Weisen Sie Pods Netzwerkschnittstellen mit der Annotation k8s.v1.cni.cncf.io/networks zu.

Es werden zusätzliche Informationen bereitgestellt, mit denen Sie das Multi-NIC-Feature so konfigurieren und verwenden können, dass es Ihren Netzwerkanforderungen am besten entspricht.

Mehrere NICs aktivieren

Aktivieren Sie die Multi-NIC für Ihre Pods. Fügen Sie dazu das Feld multipleNetworkInterfaces in den Bereich clusterNetwork der benutzerdefinierten Clusterressource ein und legen Sie dafür den Wert true fest.

  ...
  clusterNetwork:
    multipleNetworkInterfaces: true
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  ...

Netzwerkschnittstellen angeben

Verwenden Sie benutzerdefinierte NetworkAttachmentDefinition-Ressourcen, um weitere Netzwerkschnittstellen anzugeben. Die benutzerdefinierten Ressourcen NetworkAttachmentDefinition entsprechen den Netzwerken, die für Ihre Pods verfügbar sind. Sie können die benutzerdefinierten Ressourcen in der Clusterkonfiguration angeben, wie im folgenden Beispiel gezeigt, oder Sie können die benutzerdefinierten Ressourcen NetworkAttachmentDefinition direkt erstellen.

---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: my-cluster
  namespace: cluster-my-cluster
spec:
    type: user
    clusterNetwork:
      multipleNetworkInterfaces: true
...
---
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: gke-network-1
  namespace: cluster-my-cluster
spec:
  config: '{
  "cniVersion":"0.3.0",
  "type": "ipvlan",
  "master": "enp2342",  # defines the node interface that this pod interface would
                         map to.
  "mode": "l2",
  "ipam": {
    "type": "whereabouts",
    "range": "172.120.0.0/24"
  }
}'
---
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: gke-network-2
  namespace: cluster-my-cluster
spec:
  config: '{
  "cniVersion":"0.3.0",
  "type": "macvlan",
  "mode": "bridge",
  "master": "vlan102",
  "ipam": {
    "type": "static",
    "addresses": [
      {
        "address": "10.10.0.1/24",
        "gateway": "10.10.0.254"
      }
    ],
    "routes": [
      { "dst": "192.168.0.0/16", "gw": "10.10.5.1" }
    ]
  }
}'

Wenn Sie die benutzerdefinierte Ressource NetworkAttachmentDefinition in der Clusterkonfigurationsdatei angeben, verwendet GKE on Bare Metal diesen Namen, um die benutzerdefinierte Ressource NetworkAttachmentDefinition nach der Clustererstellung zu steuern. GKE on Bare Metal behandelt diese benutzerdefinierte Ressource im Cluster-Namespace als „Source of Truth“ und gleicht sie mit dem default-Namespace des Zielclusters ab.

Das folgende Diagramm zeigt, wie GKE on Bare Metal benutzerdefinierte NetworkAttachmentDefinition-Ressourcen aus dem clusterspezifischen Namespace mit dem Namespace default abgleicht.

Abgleich von NetworkAttachmentDefinition

Obwohl es optional ist, empfehlen wir, dass Sie während der Clustererstellung NetworkAttachmentDefinition benutzerdefinierte Ressourcen angeben. Nutzercluster profitieren am meisten, wenn Sie die benutzerdefinierten Ressourcen während der Clustererstellung angeben, da Sie dann die benutzerdefinierten Ressourcen NetworkAttachmentDefinition vom Administratorcluster steuern können.

Wenn Sie bei der Clustererstellung keine benutzerdefinierten NetworkAttachmentDefinition-Ressourcen angeben, können Sie benutzerdefinierte NetworkAttachmentDefinition-Ressourcen direkt einem vorhandenen Zielcluster hinzufügen. GKE on Bare Metal gleicht NetworkAttachmentDefinition benutzerdefinierte Ressourcen ab, die im Cluster-Namespace definiert sind. Der Abgleich erfolgt auch beim Löschen. Wenn eine benutzerdefinierte NetworkAttachmentDefinition-Ressource aus einem Cluster-Namespace entfernt wird, entfernt GKE on Bare Metal die benutzerdefinierte Ressource aus dem Zielcluster.

Einem Pod Netzwerkschnittstellen zuweisen

Verwenden Sie die Annotation k8s.v1.cni.cncf.io/networks, um einem Pod eine oder mehrere Netzwerkschnittstellen zuzuweisen. Jede Netzwerkschnittstelle wird mit einem Namespace und dem Namen einer benutzerdefinierten NetworkAttachmentDefinition-Ressource angegeben, die durch einen Schrägstrich (/) getrennt sind.

---
apiVersion: v1
kind: Pod
metadata:
  name: samplepod
  annotations:
    k8s.v1.cni.cncf.io/networks: NAMESPACE/NAD_NAME
spec:
  containers:
  ...

Ersetzen Sie Folgendes:

  • NAMESPACE: der Namespace. Verwenden Sie default für den Standard-Namespace. Dies ist Standard. Eine Ausnahme finden Sie unter Sicherheitsbedenken.
  • NAD_NAME: der Name der benutzerdefinierten Ressource NetworkAttachmentDefinition.

Verwenden Sie eine durch Kommas getrennte Liste, um mehrere Netzwerkschnittstellen anzugeben.

Im folgenden Beispiel werden dem Pod samplepod zwei Netzwerkschnittstellen zugewiesen. Die Netzwerkschnittstellen werden durch den Namen von zwei benutzerdefinierten NetworkAttachmentDefinition-Ressourcen, gke-network-1 und gke-network-2, im Standard-Namespace des Zielclusters angegeben.

---
apiVersion: v1
kind: Pod
metadata:
  name: samplepod
  annotations:
    k8s.v1.cni.cncf.io/networks: default/gke-network-1,default/gke-network-2
spec:
  containers:
  ...

Netzwerkschnittstellen auf einen Knotenpool beschränken

Verwenden Sie die Annotation k8s.v1.cni.cncf.io/nodeSelector, um den Pool der Knoten anzugeben, für die eine benutzerdefinierte NetworkAttachmentDefinition-Ressource gültig ist. GKE on Bare Metal erzwingt die Bereitstellung aller Pods, die auf diese benutzerdefinierte Ressource verweisen, auf diesen spezifischen Knoten. Im folgenden Beispiel erzwingt GKE on Bare Metal das Deployment aller Pods, die der Netzwerkschnittstelle gke-network-1 dem Knotenpool multinicNP zugewiesen sind. GKE on Bare Metal kennzeichnet einen Knotenpool entsprechend mit dem Label baremetal.cluster.gke.io/node-pool.

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    k8s.v1.cni.cncf.io/nodeSelector: baremetal.cluster.gke.io/node-pool=multinicNP
  name: gke-network-1
spec:
...

Sie sind nicht auf die Verwendung der Standardlabels beschränkt. Sie können eigene, benutzerdefinierte Pools aus den Clusterknoten erstellen, indem Sie auf diese Knoten ein benutzerdefiniertes Label anwenden. Verwenden Sie den Befehl kubectl label nodes, um ein benutzerdefiniertes Label anzuwenden:

kubectl label nodes NODE_NAME LABEL_KEY=LABEL_VALUE

Ersetzen Sie Folgendes:

  • NODE_NAME: der Name des Knotens, den Sie mit einem Label versehen.
  • LABEL_KEY ist der für Ihr Label zu verwendende Schlüssel.
  • LABEL_VALUE: der Labelname.

Sobald der Knoten mit einem Label versehen ist, wenden Sie die Annotation baremetal.cluster.gke.io/label-taint-no-sync auf diesen Knoten an, um zu verhindern, dass GKE on Bare Metal die Labels abgleicht. Prüfen Sie mit dem Befehl kubectl get nodes --show-labels, ob ein Knoten mit einem Label versehen ist:

Sicherheitsbedenken

Eine benutzerdefinierte NetworkAttachmentDefinition-Ressource bietet uneingeschränkten Zugriff auf ein Netzwerk. Daher müssen Clusteradministratoren darauf achten, dass sie anderen Nutzern Zugriffsrechte für das Erstellen, Aktualisieren oder Löschen gewähren. Wenn eine bestimmte benutzerdefinierte NetworkAttachmentDefinition-Ressource isoliert werden muss, kann sie in einem nicht standardmäßigen Namespace platziert werden, auf den nur die Pods aus diesem Namespace zugreifen können. Zum Abgleichen der in der Clusterkonfigurationsdatei angegebenen benutzerdefinierten NetworkAttachmentDefinition-Ressourcen werden diese immer im Standard-Namespace abgelegt.

Im folgenden Diagramm können Pods aus dem Namespace default nicht auf die Netzwerkschnittstelle im Namespace privileged zugreifen.

Netzwerkverkehr mithilfe von Namespaces isolieren

Unterstützte CNI-Plug-ins

In diesem Abschnitt werden die CNI-Plug-ins aufgeführt, die vom Multi-NIC-Feature für GKE on Bare Metal unterstützt werden. Verwenden Sie nur die folgenden Plug-ins, wenn Sie eine benutzerdefinierte NetworkAttachmentDefinition-Ressource angeben.

Schnittstellenerstellung:

  • ipvlan
  • macvlan
  • bridge
  • sriov

Meta-Plug-ins:

  • portmap
  • sbr
  • tuning

IPAM-Plug-ins:

  • host-local
  • static
  • whereabouts

Routenkonfiguration

Ein Pod mit einer oder mehreren zugewiesenen NetworkAttachmentDefinition benutzerdefinierten Ressourcen hat mehrere Netzwerkschnittstellen. Standardmäßig wird die Routingtabelle in diesem Fall nur um die lokal verfügbaren zusätzlichen Schnittstellen aus zugewiesenen NetworkAttachmentDefinition benutzerdefinierten Ressourcen erweitert. Das Standardgateway ist weiterhin so konfiguriert, dass es die Master-/Standardschnittstelle des Pods eth0 verwendet.

Sie können dieses Verhalten mithilfe der folgenden CNI-Plug-ins ändern:

  • sbr
  • static
  • whereabouts

So möchten Sie beispielsweise, dass der gesamte Traffic über das Standardgateway, die Standardschnittstelle, geleitet wird. Bestimmter Traffic geht jedoch über eine der nicht standardmäßigen Schnittstellen. Es kann schwierig sein, den Traffic basierend auf der Ziel-IP zu unterscheiden (normales Routing), da derselbe Endpunkt über beide Schnittstellentypen verfügbar ist. In diesem Fall kann das quellenbasierte Routing (SBR) helfen.

SBR-Plug-in

Das Plug-in sbr gibt der Anwendung die Kontrolle über Routingentscheidungen. Die Anwendung steuert, was als Quell-IP-Adresse der hergestellten Verbindung verwendet wird. Wenn die Anwendung die IP-Adresse der benutzerdefinierten Ressource NetworkAttachmentDefinition für die Quell-IP-Adresse verwendet, landen Pakete in der zusätzlichen Routingtabelle sbr, die eingerichtet wurde. In der Routingtabelle sbr wird die Schnittstelle der benutzerdefinierten Ressource NetworkAttachmentDefinition als Standardgateway festgelegt. Die Standard-Gateway-IP in dieser Tabelle wird mit dem Feld gateway in den Plug-ins whereabouts oder static gesteuert. Geben Sie das Plug-in sbr als verkettetes Plug-in an. Weitere Informationen zum sbr-Plug-in, einschließlich der Nutzungsinformationen, finden Sie unter Quellbasiertes Routing-Plug-in.

Das folgende Beispiel zeigt "gateway":"21.0.111.254", das in whereabouts festgelegt ist und sbr als verkettetes Plug-in nach ipvlan festgelegt ist:

# ip route
default via 192.168.0.64 dev eth0  mtu 1500
192.168.0.64 dev eth0 scope link
# ip route list table 100
default via 21.0.111.254 dev net1
21.0.104.0/21 dev net1 proto kernel scope link src 21.0.111.1

Statische und Standort-Plug-ins

Das Plug-in whereabouts ist im Grunde eine Erweiterung des Plug-ins static. Beide nutzen die Routingkonfiguration gemeinsam. Ein Konfigurationsbeispiel finden Sie unter Plug-in für die statische IP-Adressverwaltung. Sie können ein Gateway und eine Route definieren, die zur Routingtabelle des Pods hinzugefügt werden soll. Sie können das Standardgateway des Pods jedoch nicht so ändern.

Das folgende Beispiel zeigt das Hinzufügen von "routes": [{ "dst": "172.31.0.0/16" }] zur benutzerdefinierten Ressource NetworkAttachmentDefinition:

# ip route
default via 192.168.0.64 dev eth0  mtu 1500
172.31.0.0/16 via 21.0.111.254 dev net1
21.0.104.0/21 dev net1 proto kernel scope link src 21.0.111.1
192.168.0.64 dev eth0 scope link

Konfigurationsbeispiele

In diesem Abschnitt werden einige der allgemeinen Netzwerkkonfigurationen erläutert, die von der Multi-NIC-Funktion unterstützt werden.

Von mehreren Pods verwendeter einzelner Netzwerkanhang

Von mehreren Pods verwendeter einzelner Netzwerkanhang

Mehrere Netzwerkanhänge, die von einem einzelnen Pod verwendet werden

Mehrere Netzwerkanhänge, die von einem einzelnen Pod verwendet werden

Mehrere Netzwerkanhänge, die auf dieselbe Schnittstelle verweisen, die von einem einzelnen Pod verwendet wird

Mehrere Netzwerkanhänge, die auf dieselbe Schnittstelle verweisen, die von einem einzelnen Pod verwendet wird

Derselbe Netzwerkanhang, der von einem einzelnen Pod mehrmals verwendet wird

Derselbe Netzwerkanhang, der von einem einzelnen Pod mehrmals verwendet wird

Fehlerbehebung

Wenn weitere Netzwerkschnittstellen falsch konfiguriert sind, werden die Pods, denen sie zugewiesen sind, nicht gestartet. In diesem Abschnitt wird beschrieben, wie Sie Informationen zur Fehlerbehebung bei Multi-NIC-Features finden.

Pod-Ereignisse prüfen

Multus meldet Fehler über Kubernetes-Pod-Ereignisse. Verwenden Sie den folgenden kubectl describe-Befehl, um Ereignisse für einen bestimmten Pod aufzurufen:

kubectl describe pod POD_NAME

Logs prüfen

Für jeden Knoten finden Sie die Orte- und Ortungslogs an den folgenden Speicherorten:

  • /var/log/whereabouts.log
  • /var/log/multus.log

Pod-Oberflächen prüfen

Prüfen Sie Ihre Pod-Schnittstellen mit dem Befehl kubectl exec. Wenn die benutzerdefinierten Ressourcen NetworkAttachmentDefinition erfolgreich angewendet wurden, sehen die Pod-Schnittstellen so aus:

$ kubectl exec samplepod-5c6df74f66-5jgxs -- ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether 00:50:56:82:3e:f0 brd ff:ff:ff:ff:ff:ff
    inet 21.0.103.112/21 scope global net1
       valid_lft forever preferred_lft forever
38: eth0@if39: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 36:23:79:a9:26:b3 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.2.191/32 scope global eth0
       valid_lft forever preferred_lft forever

Pod-Status abrufen

Verwenden Sie kubectl get, um den Netzwerkstatus für einen bestimmten Pod abzurufen:

kubectl get pods POD_NAME -oyaml

Die folgende Beispielausgabe zeigt den Status eines Pods mit mehreren Netzwerken:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/network-status: |-
      [{
          "name": "",
          "interface": "eth0",
          "ips": [
              "192.168.1.88"
          ],
          "mac": "36:0e:29:e7:42:ad",
          "default": true,
          "dns": {}
      },{
          "name": "default/gke-network-1",
          "interface": "net1",
          "ips": [
              "21.0.111.1"
          ],
          "mac": "00:50:56:82:a7:ab",
          "dns": {}
      }]
    k8s.v1.cni.cncf.io/networks: gke-network-1