Mehrere Netzwerkschnittstellen für Pods konfigurieren

In diesem Dokument wird beschrieben, wie Sie Anthos-Cluster auf Bare-Metal konfigurieren, um mehrere Netzwerkschnittstellen mit mehreren NICs für Ihre Pods 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.

Multi-NIC 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/12
  ...

Netzwerkschnittstellen angeben

Verwenden Sie benutzerdefinierte NetworkAttachmentDefinition-Ressourcen, um zusätzliche 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: '{
  "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: '{
  "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 Anthos-Cluster auf Bare-Metal diesen Namen, um die benutzerdefinierte Ressource NetworkAttachmentDefinition nach dem Erstellen des Clusters zu steuern. Anthos-Cluster auf Bare-Metal behandeln diese benutzerdefinierte Ressource innerhalb des Cluster-Namespace als "Source of Truth" und vergleicht sie mit dem default-Namespace des Zielclusters.

Das folgende Diagramm veranschaulicht, wie Anthos-Cluster auf Bare-Metal-Servern benutzerdefinierte NetworkAttachmentDefinition-Ressourcen vom clusterspezifischen Namespace mit dem Namespace default abgleichen.

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. Anthos-Cluster auf Bare-Metal-Servern gleichen die im Cluster-Namespace definierten benutzerdefinierten NetworkAttachmentDefinition-Ressourcen ab. Der Abgleich erfolgt auch beim Löschen. Wenn eine benutzerdefinierte NetworkAttachmentDefinition-Ressource aus einem Cluster-Namespace entfernt wird, entfernt Anthos-Cluster in 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:
  ...

Dabei gilt:

  • 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

Mit der Annotation k8s.v1.cni.cncf.io/nodeSelector müssen Sie einen Pool von Knoten angeben, für die eine benutzerdefinierte NetworkAttachmentDefinition-Ressource gültig ist. Anthos-Cluster auf Bare-Metal zwingen alle Pods, die auf diese benutzerdefinierte Ressource verweisen, auf diesen bestimmten Knoten bereitzustellen. Im folgenden Beispiel erzwingt Anthos Cluster auf der Bare-Metal-Bereitstellung die Bereitstellung aller Pods, denen die Netzwerkschnittstelle gke-network-1 dem Node multinicNP-Knoten zugewiesen ist. Anthos-Cluster auf Bare-Metal-Labels versehen einen NodePool 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

Dabei gilt:

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

Wenn 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 Anthos-Cluster in Bare-Metal die Labels abgleichen 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. NetworkAttachmentDefinition benutzerdefinierte Ressourcen, die in der Clusterkonfigurationsdatei angegeben sind, werden immer mit dem Standard-Namespace abgeglichen.

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 von der Multi-NIC-Funktion für Anthos-Cluster auf Bare-Metal-Geräten unterstützt werden. Verwenden Sie nur die folgenden Plug-ins, wenn Sie eine benutzerdefinierte NetworkAttachmentDefinition-Ressource angeben.

Schnittstellenerstellung:

  • ipvlan
  • macvlan
  • bridge

Meta-Plug-ins:

  • portmap
  • sbr
  • tuning

IPAM-Plug-ins:

  • host-local
  • static
  • whereabouts

Routing

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:

user@node1:~$ 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