In diesem Dokument wird beschrieben, wie Sie Google Distributed Cloud so konfigurieren, dass mehrere Netzwerkschnittstellen mit mehreren NICs für Ihre Pods bereitgestellt werden. 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:
Aktivieren Sie Multi-NIC für Ihren Cluster mit dem Feld
multipleNetworkInterfacesin der benutzerdefinierten Clusterressource.Netzwerkschnittstellen mit
NetworkAttachmentDefinitionbenutzerdefinierten Ressourcen angeben.Weisen Sie Pods Netzwerkschnittstellen mit der Annotation
k8s.v1.cni.cncf.io/networkszu.
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 Google Distributed Cloud diesen Namen, um die benutzerdefinierte Ressource NetworkAttachmentDefinition nach der Clustererstellung zu steuern.
Google Distributed Cloud behandelt diese benutzerdefinierte Ressource innerhalb des Cluster-Namespace als „Source of Truth“ und vergleicht sie mit dem Namespace default des Zielclusters.
Das folgende Diagramm zeigt, wie Google Distributed Cloud benutzerdefinierte NetworkAttachmentDefinition-Ressourcen vom clusterspezifischen Namespace mit dem Namespace default abgleicht.
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. Google Distributed Cloud gleicht benutzerdefinierte NetworkAttachmentDefinition-Ressourcen ab, die im Cluster-Namespace definiert sind. Der Abgleich erfolgt auch beim Löschen. Wenn eine benutzerdefinierte NetworkAttachmentDefinition-Ressource von einem Cluster-Namespace entfernt wird, entfernt Google Distributed Cloud die benutzerdefinierte Ressource aus dem Ziel-Cluster.
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 Siedefaultfür den Standard-Namespace. Dies ist Standard. Eine Ausnahme finden Sie unter Sicherheitsbedenken.NAD_NAME: der Name der benutzerdefinierten RessourceNetworkAttachmentDefinition.
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.
Google Distributed Cloud erzwingt, dass alle Pods, die auf diese benutzerdefinierte Ressource verweisen, auf diesen spezifischen Knoten bereitgestellt werden. Im folgenden Beispiel erzwingt Google Distributed Cloud die Bereitstellung aller Pods, denen die gke-network-1-Netzwerkschnittstelle zum Knotenpool multinicNP zugewiesen ist.
Google Distributed Cloud kennzeichnet einen Knotenpool mit dem entsprechenden baremetal.cluster.gke.io/node-pool-Label.
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_KEYist der für Ihr Label zu verwendende Schlüssel.LABEL_VALUE: der Labelname.
Sobald der Knoten beschriftet ist, wenden Sie die Annotation baremetal.cluster.gke.io/label-taint-no-sync auf diesem Knoten an, um Google Distributed Cloud am Abgleich der Labels zu hindern. 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.
Unterstützte CNI-Plug-ins
In diesem Abschnitt werden die CNI-Plug-ins aufgeführt, die von der Multi-NIC-Funktion für Google Distributed Cloud unterstützt werden. Verwenden Sie nur die folgenden Plug-ins, wenn Sie eine benutzerdefinierte NetworkAttachmentDefinition-Ressource angeben.
Schnittstellenerstellung:
ipvlanmacvlanbridgesriov
Meta-Plug-ins:
portmapsbrtuning
IPAM-Plug-ins:
host-localstaticwhereabouts
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:
sbrstaticwhereabouts
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
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
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