La manipulation d'adresse IP n'aidera pas ici. La seule solution dans ce cas sera l'organisation d'interfaces supplémentaires sur les nœuds du cluster, qui seront dans les VLAN requis, et l'organisation de l'accès aux interfaces supplémentaires des projets dont nous avons besoin au sein du cluster. Et un projet appelé Multus CNI peut y contribuer .
Multus CNI
Comme vous le savez, par défaut, POD dans Kubernetes a une interface à travers laquelle toutes les interactions avec lui ont lieu. Multus vous permet de créer plusieurs interfaces dans POD en plus de celle par défaut. En fait, Multus est lui-même un CNI-Plugin, qui à son tour contrôle l'appel des autres CNI-Plugin. Pour ce Multus est appelé le CNI meta Plugin. Ce que fait Multus est bien illustré dans l'image de l' article Demystifing Multus :
Bien entendu, le nombre d'interfaces supplémentaires peut être supérieur à une.
Configuration de Multus CNI dans OpenShift
Essayons donc de résoudre le problème d'accès à un VLAN dédié sur notre stand. Par défaut, tous les nœuds de cluster se voient attribuer une interface située dans le VLAN OpenShift (IP: 192.168.111 / 24). Nous voulons organiser l'accès du projet multes-test aux ressources du réseau 192.168.112 / 24 situé dans le VLAN restreint. Le VLAN restreint et le VLAN OpenShift ne sont pas acheminés l'un vers l'autre.
Tout d'abord, ajoutons une interface de VLAN Restreint à un certain nombre de nœuds (dans notre cas, ce sont Node1 et Node2), et mettons le label node-role.kubernetes.io/multus-node= 'yes' sur ces nœuds . Les ressources du VLAN restreint seront disponibles à partir de nœuds avec une étiquette multi-nœuds. Créons notre projet multus-test:
[ocp@shift-is01 macvlan]$ oc new-project multus-test
Le support CNI de Multus est présent dans OpenShift depuis longtemps, il n'est pas nécessaire de l'ajouter séparément. La gestion de la configuration Multus se fait via CR sur CRD networks.operator.openshift.io . Vous devez éditer cette ressource en ajoutant la configuration du plugin CNI pour la nouvelle interface:
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" } }
Ce moment nécessite un décodage. Qu'avons-nous défini avec cette configuration?
- Pour POD, une interface nommée "net1" sera ajoutée dans le projet multus-test
- La configuration de cette interface sera déterminée par le plugin CNI "ipvlan";
- CNI Plugin ipvlan est configuré en mode L2;
- L'interface physique du nœud ens224 est utilisée comme interface principale pour net1;
- Enfin, le plugin statique IPAM sera utilisé pour gérer l'adressage IP.
Choisir le plugin CNI
Pour notre interface supplémentaire, vous devez sélectionner le plugin CNI utilisé. Une liste des plugins CNI possibles est disponible sur le site www.cni.dev . Dans notre exemple, nous utilisons le plugin ipvlan . En fait, il s'agit du pont le plus simple qui permet aux conteneurs de communiquer via l'interface réseau externe de l'hôte. Dans ce cas, toutes les connexions sortantes utilisent leur propre adresse IP, mais auront l'adresse MAC de l'interface réseau externe. La photo du site hicu.be illustre bien le plugin ipvlan:
Dans les environnements productifs, le plugin macvlan est plus souvent choisi , ce qui diffère d'ipvlan en ce que les connexions sortantes ont des adresses MAC uniques. Mais dans ce cas, il est souvent nécessaire de préparer l'infrastructure réseau pour que l'équipement réseau permette la transmission de paquets avec différentes adresses MAC depuis un port.
Sélection du plug-in IPAM
En plus d'organiser l'interface réseau, nous devons définir les règles d'émission d'une adresse IP pour la nouvelle interface. Ceci est également géré par le plugin CNI, qui implémente les fonctions de gestion des adresses IP (ou IPAM). Une liste des plugins IPAM possibles est également disponible sur www.cni.dev . Dans cet exemple, nous avons utilisé le plugin IPAM statique le plus simple qui attribue une adresse fixe à notre POD.
S'il existe de nombreux POD de ce type, l'IPAM statique deviendra peu pratique. Un bon choix ici est soit d'utiliser le plugin dhcp (il attribue les adresses IP du POD via une requête à un serveur DHCP externe) soit d'utiliser le plugin whereabouts .
La prise en charge de ces plugins IPAM est également disponible par défaut dans OpenShift , vous n'avez pas besoin de les installer séparément.
Accès VLAN restreint
Après avoir défini notre configuration Multus, une ressource appelée Définition de l'attachement réseau doit apparaître dans le cluster, ce qui reflète la configuration Multus actuelle:
Définition de l'attachement réseau
[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" } }
Créons un POD de test avec une interface supplémentaire qui aura accès à notre VLAN restreint:
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"]
Allons au POD créé pour visualiser sa configuration réseau et vérifier la disponibilité des adresses dans le VLAN restreint (sur le réseau 192.168.112.0/24):
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
Comme vous pouvez le voir dans la sortie de la commande «ip a», le POD a reçu une interface réseau supplémentaire net1 @ if826 et l'adresse IP que nous avons spécifiée dans son manifeste. Étant donné que l'interface supplémentaire fonctionne via un adaptateur Ethernet dans le VLAN restreint, à partir de ce POD, nous avons accès au segment de réseau dont nous avons besoin.
Auteur: Sergey Artemov, responsable du département DevOps Solutions, Jet Infosystems
Rejoignez notre chaîne Telegram @DevSecOps Talks !