В первой части статьи По поводу OpenShift Egress мы рассмотрели варианты организации фиксированных исходящих IP-адресов для POD в кластере.
Но что, если вам необходимо предоставить доступ к внешним по отношению к кластеру сегментам сети, расположенным в определенных VLAN? 
Манипулирование IP-адресацией здесь не поможет. Единственным решением в этом случае будет организация дополнительных интерфейсов на узлах кластера, которые будут располагаться в необходимых VLAN, и организация доступа к дополнительным интерфейсам от нужных нам проектов внутри кластера.
И проект под названием Мультис ЦНИ .
Мультис ЦНИ
Как вы знаете, по умолчанию POD в Kubernetes имеет один интерфейс, через который происходит все взаимодействие с ним.Multus позволяет создавать в POD несколько интерфейсов помимо интерфейса по умолчанию.
Фактически, Multus сам по себе является CNI-плагином, который, в свою очередь, управляет вызовом других CNI-плагинов.
По этой причине Multus называется мета-плагином CNI. Что делает Мультус наглядно показано на картинке из статьи Демистифицируя Мултус : 
Разумеется, количество дополнительных интерфейсов может быть больше одного.
Настройка Multus CNI в OpenShift
Итак, попробуем решить проблему доступа к выделенному VLAN на нашем стенде.По умолчанию всем узлам кластера выделяется один интерфейс, расположенный в OpenShift VLAN (IP: 192.168.111/24).
Хотим организовать доступ из проекта multes-test к ресурсам сети 192.168.112/24, расположенным в VLAN Restricted. VLAN Restricted и VLAN OpenShift не маршрутизируются между собой.
Для начала добавим интерфейс из VLAN Restricted на ряд узлов (в нашем случае Node1 и Node2), и поставим метку на эти узлы node-role.kubernetes.io/multus-node= 'да'.
Узлы, помеченные как multi-node, будут иметь доступ к ресурсам из ограниченной VLAN. Создадим наш мультитестовый проект:
Поддержка Multus CNI присутствует в OpenShift уже давно; нет необходимости добавлять его отдельно.[ocp@shift-is01 macvlan]$ oc new-project multus-test
Конфигурация Multus управляется через CR в CRD. network.operator.openshift.io .
Вам необходимо отредактировать этот ресурс, добавив конфигурацию плагина CNI для нового интерфейса: oc редактировать кластер network.operator.openshift.io spec:
additionalNetworks:
- name : net1
namespace: multus-test
type: Raw
rawCNIConfig: |-
{ "cniVersion": "0.3.1",
"type": "ipvlan",
"mode": "l2",
"master": "ens224",
"ipam": {
"type": "static"
}
}
Этот момент требует расшифровки.
Что мы определили по этой конфигурации?
- Для POD в проект multus-test будет добавлен интерфейс под названием «net1».
- Конфигурация этого интерфейса будет определяться через плагин CNI «ipvlan»;
- Плагин CNI ipvlan будет настроен в режиме L2;
- Физический интерфейс узла ens224 используется в качестве основного интерфейса для net1;
- Наконец, статический плагин IPAM будет использоваться для управления IP-адресацией.
Выбор плагина CNI
Для нашего дополнительного интерфейса нам нужно выбрать используемый плагин CNI. Список возможных плагинов CNI можно найти на веб-сайте.В нашем примере мы используем плагин ipvlan .
По сути, это простейший мост, позволяющий контейнерам взаимодействовать через внешний сетевой интерфейс хоста.
В этом случае все исходящие соединения будут использовать собственный IP-адрес, но будут иметь MAC-адрес внешнего сетевого интерфейса.
Картинка с сайта hicu.be хорошо иллюстрирует работу плагина ipvlan: 
В продуктивной среде они с большей вероятностью будут выбирать плагин macvlan , который отличается от ipvlan тем, что исходящие соединения имеют уникальные MAC-адреса.
Но в этом случае зачастую необходимо подготовить сетевую инфраструктуру так, чтобы сетевое оборудование позволяло передавать с одного и того же порта пакеты с разными MAC-адресами.
Выберите плагин IPAM
Помимо организации сетевого интерфейса нам необходимо определить правила выдачи IP-адреса новому интерфейсу.Это также делается с помощью плагина CNI, который реализует функции управления IP-адресами (или IPAM).
Список возможных IPAM-плагинов также можно найти на сайте.
В этом примере мы использовали простейший плагин статического IPAM, который назначает нашему POD фиксированный адрес.
Если таких POD много, использовать статический IPAM станет неудобно.
Хорошим выбором здесь было бы либо использовать плагин DHCP (он назначает IP-адреса POD через запрос к внешнему DHCP-серверу), либо использовать плагин местонахождения .
Поддержка этих плагинов IPAM также доступна по умолчанию в Опеншифт , вам не нужно устанавливать их отдельно.
Доступ к ограниченной VLAN
После определения нашей конфигурации Multus в кластере должен появиться ресурс под названием Network Attachment Definition, который отражает текущую конфигурацию Multus: Определение сетевого подключения [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"
}
}
Давайте создадим тестовый POD с дополнительным интерфейсом, который будет иметь доступ к нашей ограниченной VLAN: 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"]
Зайдем в созданный POD, чтобы просмотреть его сетевую конфигурацию и проверить наличие адресов в ограниченном VLAN (в сети 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
Как видно из вывода команды «ip a», POD получил дополнительный сетевой интерфейс net1@if826 и IP-адрес, который мы указали в его манифесте.
Поскольку дополнительный интерфейс работает через Ethernet-адаптер, расположенный в ограниченной VLAN, из этого POD мы получили доступ к нужному нам сегменту сети.
Автор: Сергей Артемов, руководитель направления DevOps-решений компании «Инфосистемы Джет».
Присоединяйтесь к нашему каналу в Telegram Переговоры @DevSecOps !
Библиография
Теги: #ИТ-инфраструктура #DevOps #Openshift-
Принцип Замены Лискова
19 Oct, 24 -
База Ит-Знаний В Вашей Компании
19 Oct, 24 -
Швеция Откроет Посольство В Second Life
19 Oct, 24
