La manipulación de IP no ayudará aquí. La única solución en este caso será la organización de interfaces adicionales en los nodos del clúster, que estarán en las VLAN requeridas, y la organización del acceso a interfaces adicionales de los proyectos que necesitamos dentro del clúster. Y un proyecto llamado Multus CNI puede ayudar en esto .
Multus CNI
Como sabe, de forma predeterminada, POD en Kubernetes tiene una interfaz a través de la cual tiene lugar toda la interacción con él. Multus te permite crear múltiples interfaces en POD además de la predeterminada. De hecho, Multus es en sí mismo un CNI-Plugin, que a su vez controla la llamada de otros CNI-Plugin. Para esto, Multus se llama CNI meta Plugin. Lo que hace Multus está bien ilustrado en la imagen del artículo Demystifing Multus :
Por supuesto, la cantidad de interfaces adicionales puede ser más de una.
Configuración de Multus CNI en OpenShift
Entonces, intentemos resolver el problema del acceso a una VLAN dedicada en nuestro stand. De manera predeterminada, a todos los nodos del clúster se les asigna una interfaz ubicada en la VLAN OpenShift (IP: 192.168.111 / 24). Queremos organizar el acceso desde el proyecto multes-test a los recursos de la red 192.168.112 / 24 ubicada en la VLAN Restringida. VLAN restringida y VLAN OpenShift no se enrutan entre sí.
Primero, agreguemos una interfaz de VLAN restringida a varios nodos (en nuestro caso, estos son Nodo1 y Nodo2), y coloquemos la etiqueta node-role.kubernetes.io/multus-node= 'yes' en estos nodos . Los recursos de la VLAN restringida estarán disponibles en los nodos con una etiqueta de nodo múltiple. Creemos nuestro proyecto multus-test:
[ocp@shift-is01 macvlan]$ oc new-project multus-test
La compatibilidad con Multus CNI ha estado presente en OpenShift durante mucho tiempo, no es necesario agregarla por separado. La gestión de la configuración de Multus se realiza mediante CR en CRD networks.operator.openshift.io . Debe editar este recurso agregando la configuración del complemento CNI para la nueva interfaz:
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" } }
Este momento requiere decodificación. ¿Qué hemos definido con esta configuración?
- Para POD, se agregará una interfaz llamada "net1" en el proyecto multus-test
- La configuración de esta interfaz se determinará a través del complemento CNI "ipvlan";
- El ipvlan del complemento CNI está configurado en modo L2;
- La interfaz física del nodo ens224 se utiliza como interfaz principal para net1;
- Finalmente, el complemento estático IPAM se utilizará para administrar el direccionamiento IP.
Elegir el complemento CNI
Para nuestra interfaz adicional, debe seleccionar el complemento CNI utilizado. La lista de posibles complementos CNI se puede encontrar en el sitio web www.cni.dev . En nuestro ejemplo, estamos usando el complemento ipvlan . De hecho, este es el puente más simple que permite que los contenedores se comuniquen a través de la interfaz de red externa del host. En este caso, todas las conexiones salientes usan su propia dirección IP, pero tendrán la dirección MAC de la interfaz de red externa. La imagen del sitio hicu.be ilustra bien el complemento ipvlan:
En entornos productivos, el complemento macvlan se elige con mayor frecuencia , que se diferencia de ipvlan en que las conexiones salientes tienen direcciones MAC únicas. Pero en este caso, a menudo es necesario preparar la infraestructura de red para que el equipo de red permita la transmisión de paquetes con diferentes direcciones MAC desde un puerto.
Seleccionar el complemento IPAM
Además de organizar la interfaz de red, necesitamos definir las reglas para emitir una dirección IP para la nueva interfaz. Esto también lo maneja el complemento CNI, que implementa las funciones de administración de direcciones IP (o IPAM). También se puede encontrar una lista de posibles complementos de IPAM en www.cni.dev . En este ejemplo, usamos el complemento IPAM estático más simple que asigna una dirección fija a nuestro POD.
Si hay muchos POD de este tipo, el IPAM estático resultará inconveniente. Una buena opción aquí es usar el complemento dhcp (asigna las direcciones IP del POD a través de una solicitud a un servidor DHCP externo) o usar el complemento de localización .
El soporte para estos complementos de IPAM también está disponible de forma predeterminada en OpenShift , no es necesario instalarlos por separado.
Acceso VLAN restringido
Después de definir nuestra configuración de Multus, debería aparecer en el clúster un recurso denominado Definición de conexión a la red , que refleja la configuración actual de Multus: Definición de conexión a la
red
[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" } }
Creemos un POD de prueba con una interfaz adicional que tendrá acceso a nuestra VLAN restringida:
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"]
Vayamos al POD creado para ver su configuración de red y verificar la disponibilidad de direcciones en la VLAN restringida (en la red 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
Como puede ver en la salida del comando "ip a", POD recibió una interfaz de red net1 @ if826 adicional y la dirección IP que especificamos en su manifiesto. Dado que la interfaz adicional funciona a través de un adaptador ethernet ubicado en la VLAN restringida, desde este POD obtuvimos acceso al segmento de red que necesitamos.
Autor: Sergey Artemov, Jefe del Departamento de Soluciones DevOps, Jet Infosystems ¡
Únase a nuestro canal de Telegram @DevSecOps Talks !
Bibliografía
- OpenShift 4 con MacVLAN y paradero
- Desmitificando multus
- Macvlan contra Ipvlan