IP-Manipulation hilft hier nicht weiter. Die einzige Lösung in diesem Fall ist die Organisation zusätzlicher Schnittstellen auf den Clusterknoten, die sich in den erforderlichen VLANs befinden, und die Organisation des Zugriffs auf zusätzliche Schnittstellen aus den Projekten, die wir innerhalb des Clusters benötigen. Und ein Projekt namens Multus CNI kann dabei helfen .
Multus CNI
Wie Sie wissen, verfügt POD in Kubernetes standardmäßig über eine Schnittstelle, über die die gesamte Interaktion mit ihm stattfindet. Mit Multus können Sie zusätzlich zur Standardschnittstelle mehrere Schnittstellen in POD erstellen. Tatsächlich ist Multus selbst ein CNI-Plugin, das wiederum den Aufruf anderer CNI-Plugins steuert. Dafür heißt Multus CNI Meta Plugin. Was Multus tut, zeigt das Bild aus dem Artikel Demystifing Multus :
Natürlich kann die Anzahl der zusätzlichen Schnittstellen mehr als eins betragen.
Multus CNI in OpenShift konfigurieren
Versuchen wir also, das Problem des Zugriffs auf ein dediziertes VLAN an unserem Stand zu lösen. Standardmäßig wird allen Clusterknoten eine Schnittstelle im OpenShift-VLAN zugewiesen (IP: 192.168.111 / 24). Wir möchten den Zugriff vom Multes-Test-Projekt auf die Ressourcen des 192.168.112 / 24-Netzwerks in VLAN Restricted organisieren. VLAN Restricted und VLAN OpenShift werden nicht aneinander weitergeleitet.
Fügen Sie zunächst eine Schnittstelle aus VLAN hinzu, die auf eine Reihe von Knoten beschränkt ist (in unserem Fall sind dies Knoten1 und Knoten2), und setzen Sie diese Knoten mit der Bezeichnung node-role.kubernetes.io/multus-node= 'yes'. Ressourcen aus dem eingeschränkten VLAN sind von Knoten mit einer Mehrknotenbezeichnung verfügbar. Lassen Sie uns unser Multus-Test-Projekt erstellen:
[ocp@shift-is01 macvlan]$ oc new-project multus-test
Die Unterstützung von Multus CNI ist in OpenShift seit langem vorhanden. Es ist nicht erforderlich, sie separat hinzuzufügen. Das Multus-Konfigurationsmanagement erfolgt über CR unter CRD networks.operator.openshift.io . Sie müssen diese Ressource bearbeiten, indem Sie die CNI-Plugin-Konfiguration für die neue Schnittstelle hinzufügen:
oc edit networks.operator.openshift.io cluster
spec: additionalNetworks: - name : net1 namespace: multus-test type: Raw rawCNIConfig: |- { "cniVersion": "0.3.1", "type": "ipvlan", "mode": "l2", "master": "ens224", "ipam": { "type": "static" } }
Dieser Moment erfordert eine Dekodierung. Was haben wir mit dieser Konfiguration definiert?
- Für POD wird im Multus-Test-Projekt eine Schnittstelle mit dem Namen "net1" hinzugefügt
- Die Konfiguration dieser Schnittstelle wird über das CNI-Plugin "ipvlan" festgelegt;
- Das CNI-Plugin ipvlan ist im L2-Modus konfiguriert.
- Die physische Schnittstelle des ens224-Knotens wird als Hauptschnittstelle für net1 verwendet.
- Schließlich wird das statische IPAM-Plugin zum Verwalten der IP-Adressierung verwendet.
CNI Plugin auswählen
Für unsere zusätzliche Schnittstelle müssen Sie das verwendete CNI-Plugin auswählen. Eine Liste möglicher CNI-Plugins finden Sie auf der Website www.cni.dev . In unserem Beispiel verwenden wir das IPvlan-Plugin . Tatsächlich ist dies die einfachste Brücke, über die Container über die externe Netzwerkschnittstelle des Hosts kommunizieren können. In diesem Fall verwenden alle ausgehenden Verbindungen ihre eigene IP-Adresse, haben jedoch die MAC-Adresse der externen Netzwerkschnittstelle. Das Bild von der Seite hicu.be zeigt gut das IPvlan-Plugin:
In produktiven Umgebungen wird häufiger das Macvlan-Plugin ausgewählt , das sich von IPvlan dadurch unterscheidet, dass ausgehende Verbindungen eindeutige MAC-Adressen haben. In diesem Fall ist es jedoch häufig erforderlich, die Netzwerkinfrastruktur so vorzubereiten, dass die Netzwerkausrüstung die Übertragung von Paketen mit unterschiedlichen MAC-Adressen von einem Port ermöglicht.
IPAM Plugin auswählen
Zusätzlich zur Organisation der Netzwerkschnittstelle müssen die Regeln für die Ausgabe einer IP-Adresse für die neue Schnittstelle definiert werden. Dies wird auch vom CNI-Plugin erledigt, das die IP-Adressverwaltungsfunktionen (IPAM) implementiert. Die Liste der möglichen IPAM- Plugins finden Sie auch unter www.cni.dev . In diesem Beispiel haben wir das einfachste statische IPAM-Plugin verwendet, das unserem POD eine feste Adresse zuweist.
Wenn es viele solcher PODs gibt, wird statisches IPAM unpraktisch. Eine gute Wahl ist hier entweder das DHCP-Plugin (es weist die IP-Adressen des POD über eine Anfrage an einen externen DHCP-Server zu) oder das Aufenthaltsort-Plugin .
Die Unterstützung für dieses IPAM-Plugin ist standardmäßig auch in verfügbar OpenShift müssen nicht separat installiert werden.
Eingeschränkter VLAN-Zugriff
Nach dem Definieren unserer Multus-Konfiguration sollte im Cluster eine Ressource namens "Netzwerkanhangsdefinition" angezeigt werden, die die aktuelle Multus-Konfiguration widerspiegelt: "
Netzwerkanhangsdefinition"
[ocp@shift-is01 macvlan]$ oc get network-attachment-definitions --all-namespaces NAMESPACE NAME AGE multus-test net1 3m4s [ocp@shift-is01 macvlan]$ oc get network-attachment-definitions.k8s.cni.cncf.io -n multus-test net1 -o yaml apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: creationTimestamp: "2020-11-02T16:44:46Z" generation: 1 managedFields: - apiVersion: k8s.cni.cncf.io/v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:ownerReferences: .: {} k:{"uid":"01a4f46a-fc3c-495f-b196-b39352421e2a"}: .: {} f:apiVersion: {} f:blockOwnerDeletion: {} f:controller: {} f:kind: {} f:name: {} f:uid: {} f:spec: .: {} f:config: {} manager: cluster-network-operator operation: Update time: "2020-11-02T16:44:46Z" name: net1 namespace: multus-test ownerReferences: - apiVersion: operator.openshift.io/v1 blockOwnerDeletion: true controller: true kind: Network name: cluster uid: 01a4f46a-fc3c-495f-b196-b39352421e2a resourceVersion: "25898949" selfLink: /apis/k8s.cni.cncf.io/v1/namespaces/multus-test/network-attachment-definitions/net1 uid: 7a7d718b-82c5-46fe-8f72-8fd4299508ec spec: config: |- { "cniVersion": "0.3.1", "type": "ipvlan", "mode": "l2", "master": "ens224", "ipam": { "type": "static" } }
Erstellen wir einen Test-POD mit einer zusätzlichen Schnittstelle, die Zugriff auf unser eingeschränktes VLAN hat:
pod-ipvlan-static.yaml
[ocp@shift-is01 ipvlan]$ cat ./pod-ipvlan-static.yaml apiVersion: v1 kind: Pod metadata: namespace: multus-test name: test-multus-pod labels: app: test-multus-pod annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "net1", "ips": ["192.168.112.250/24"] } ]' spec: nodeSelector: node-role.kubernetes.io/multus-node: yes containers: - name: test-multus-pod image: centos/tools command: ["/bin/bash", "-c", "sleep 9000000"]
Gehen wir zum erstellten POD, um dessen Netzwerkkonfiguration anzuzeigen und die Verfügbarkeit von Adressen im eingeschränkten VLAN (im Netzwerk 192.168.112.0/24) zu überprüfen:
ocp@shift-is01 ipvlan]$ oc rsh test-multus-pod sh-4.2# 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 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0@if2142: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default link/ether 0a:58:0a:fe:04:a0 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.254.4.160/24 brd 10.254.4.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::bc4b:abff:fe0b:91f8/64 scope link valid_lft forever preferred_lft forever 4: net1@if826: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default link/ether 00:50:56:96:f3:02 brd ff:ff:ff:ff:ff:ff inet 192.168.112.250/24 brd 192.168.112.255 scope global net1 valid_lft forever preferred_lft forever inet6 fe80::50:5600:196:f302/64 scope link valid_lft forever preferred_lft forever sh-4.2# ping 192.168.112.1 -c 3 PING 192.168.112.1 (192.168.112.1) 56(84) bytes of data. 64 bytes from 192.168.112.1: icmp_seq=1 ttl=64 time=0.179 ms 64 bytes from 192.168.112.1: icmp_seq=2 ttl=64 time=0.230 ms 64 bytes from 192.168.112.1: icmp_seq=3 ttl=64 time=0.223 ms --- 192.168.112.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2041ms rtt min/avg/max/mdev = 0.179/0.210/0.230/0.028 ms
Wie Sie der Ausgabe des Befehls "ip a" entnehmen können, hat POD eine zusätzliche Netzwerkschnittstelle net1 @ if826 und die IP-Adresse erhalten, die wir in seinem Manifest angegeben haben. Da die zusätzliche Schnittstelle über einen Ethernet-Adapter im eingeschränkten VLAN funktioniert, haben wir von diesem POD aus Zugriff auf das benötigte Netzwerksegment.
Autor: Sergey Artemov, Leiter der Abteilung DevOps Solutions, Jet Infosystems Treten
Sie unserem Telegrammkanal @DevSecOps Talks bei !