A manipulação de IP não ajudará aqui. A única solução neste caso será a organização de interfaces adicionais nos nós do cluster, que estarão nas VLANs necessárias, e a organização do acesso a interfaces adicionais dos projetos de que precisamos dentro do cluster. E um projeto chamado Multus CNI pode ajudar nisso .
Multus CNI
Como você sabe, por padrão, o POD no Kubernetes tem uma interface por meio da qual ocorre toda a interação com ele. Multus permite que você crie várias interfaces em POD além da padrão. Na verdade, o Multus é um plug-in CNI, que por sua vez controla a chamada de outros plug-ins CNI. Para este Multus é chamado de CNI meta Plugin. O que Multus faz está bem ilustrado na imagem do artigo da Demystifing Multus :
Claro, o número de interfaces adicionais pode ser mais de um.
Configurando Multus CNI em OpenShift
Portanto, vamos tentar resolver o problema de acesso a uma VLAN dedicada em nosso estande. Por padrão, todos os nós do cluster são atribuídos a uma interface que está na VLAN OpenShift (IP: 192.168.111 / 24). Queremos organizar o acesso do projeto multes-test aos recursos da rede 192.168.112 / 24 localizados em VLAN Restricted. VLAN restrito e VLAN OpenShift não são roteados um para o outro.
Primeiro, vamos adicionar uma interface de VLAN Restricted a um número de nós (em nosso caso, são Node1 e Node2) e colocar o rótulo node-role.kubernetes.io/multus-node= 'yes' nesses nós . Os recursos da VLAN restrita estarão disponíveis a partir de nós com um rótulo de nó multus. Vamos criar nosso projeto multus-test:
[ocp@shift-is01 macvlan]$ oc new-project multus-test
O suporte Multus CNI está presente no OpenShift há muito tempo, não há necessidade de adicioná-lo separadamente. O gerenciamento da configuração Multus é feito via CR em CRD networks.operator.openshift.io . Você precisa editar este recurso adicionando a configuração do Plug-in CNI para a nova 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" } }
Este momento requer decodificação. O que definimos com esta configuração?
- Para POD, uma interface chamada "net1" será adicionada no projeto multus-test
- A configuração desta interface será determinada através do Plugin CNI "ipvlan";
- O plug-in CNI ipvlan é configurado no modo L2;
- A interface física do nó ens224 é usada como a interface principal para net1;
- Finalmente, o plugin estático IPAM será usado para gerenciar o endereçamento IP.
Escolhendo o plugin CNI
Para nossa interface adicional, você precisa selecionar o plug-in CNI usado. A lista de possíveis plug- ins CNI pode ser encontrada no site www.cni.dev . Em nosso exemplo, estamos usando o plugin ipvlan . Na verdade, essa é a ponte mais simples que permite que os contêineres se comuniquem por meio da interface de rede externa do host. Nesse caso, todas as conexões de saída usam seu próprio endereço IP, mas terão o endereço MAC da interface de rede externa. A foto do site hicu.be ilustra bem o plugin ipvlan:
Em ambientes produtivos, o plugin macvlan é mais comumente escolhido , o que difere do ipvlan porque as conexões de saída têm endereços MAC exclusivos. Mas, neste caso, muitas vezes é necessário preparar a infraestrutura da rede para que o equipamento da rede permita a transmissão de pacotes com diferentes endereços MAC de uma porta.
Selecionando o plugin IPAM
Além de organizar a interface de rede, precisamos definir as regras para a emissão de um endereço IP para a nova interface. Isso também é tratado pelo plug-in CNI, que implementa as funções de gerenciamento de endereço IP (ou IPAM). Uma lista de possíveis plug- ins IPAM também pode ser encontrada em www.cni.dev . Neste exemplo, usamos o plugin IPAM estático mais simples que atribui um endereço fixo ao nosso POD.
Se houver muitos desses PODs, o IPAM estático se tornará inconveniente. Uma boa escolha aqui é usar o plugin dhcp (ele atribui os endereços IP do POD por meio de uma solicitação a um servidor DHCP externo) ou usar o plugin paradeiro .
O suporte para esses plug-ins IPAM também está disponível por padrão em OpenShift , você não precisa instalá-los separadamente.
Acesso restrito à VLAN
Depois de definir nossa configuração Multus, um recurso chamado Network Attachment Definition deve aparecer no cluster, o que reflete a configuração atual do Multus:
Network Attachment Definition
[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" } }
Vamos criar um POD de teste com uma interface adicional que terá acesso à nossa VLAN restrita:
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"]
Vamos ao POD criado para visualizar sua configuração de rede e verificar a disponibilidade de endereços na VLAN restrita (na rede 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 você pode ver na saída do comando "ip a", o POD recebeu uma interface de rede net1 @ if826 adicional e o endereço IP que especificamos em seu manifesto. Como a interface adicional funciona através de um adaptador ethernet na VLAN restrita, a partir deste POD temos acesso ao segmento de rede que precisamos.
Autor: Sergey Artemov, Chefe do Departamento de Soluções DevOps, Jet Infosystems
Participe do nosso canal Telegram @DevSecOps Talks !
Bibliografia
- OpenShift 4 com MacVLAN e paradeiro
- Desmistificando multus
- Macvlan vs Ipvlan