Сетевое взаимодействие

Для сетевой реализации модели Kubernetes должны быть соблюдены некоторые требования:

• каждый модуль может взаимодействовать с любыми другими модулями без использования трансляции сетевых адресов (NAT).
  
• IP-адрес, который Pod видит в себе, идентичен тому, который видят другие.
  
• все узлы могут связываться со всеми модулями без NAT.
  

Так остаются следующие сетевые проблемы взаимодействия, требующие решения:

1. Сеть контейнер-контейнер

2. Сеть Pod-to-Pod

Ниже подробнее рассказано об этих проблемах и способах их решения.

Как правило сетевая связь на виртуальной машине представляется как взаимодействие напрямую с устройством Ethernet (это показано на рисунке).

В Linux каждый запущенный процесс взаимодействует с сетевым пространством имен (новый сетевой стек для всех процессов в пространстве имен), обеспечивающее логический сетевой стек со своими маршрутами, правилами брандмауэра и сетевыми устройствами.

Сетевое пространство имен могут можно создать при помощи команды ip. Пример команды для создания нового сетевого пространства имен с именем ns1.

Следует создать точку монтирования /var/run/netns, создавая пространство имен, т.к. она помогает пространству имен сохраняться, даже если к нему не привязан процесс.

При необходимости вывести список доступных пространств имен, перечислив все точки монтирования под /var/run/netns, можно воспользоваться командой ip.

Автоматически Linux определяет каждый процесс корневому сетевому пространству имен, чтобы обеспечить доступ к внешнему миру:

Со стороны конструкций Docker, Pod моделируется как группа контейнеров Docker, совместно использующие пространство имен сети. Контейнеры внутри модуля имеют одинаковый IP-адрес и пространство портов, назначенное через сетевое пространство имен, назначенное модулю, и могут находить друг друга через localhost, т.к. они находятся в одном пространстве имен. Сетевое пространство имен можно создать для каждого модуля на ВМ. Это реализовано с использованием Docker в качестве «контейнера Pod», который удерживает сетевое пространство имен открытым, в то время как «контейнеры приложений» (то, что указал пользователь) присоединяются к этому пространству имен с помощью Docker –net = container:функция.

Доступ к общим томам, являющиеся частью модуля и доступные для монтирования в файловую систему каждого приложения, имеют и приложения внутри модуля.

В Kubernetes у каждого модуля есть реальный IP-адрес, и каждый модуль взаимодействует с другими модулями, используя этот IP-адрес. Необходимо понять, как Kubernetes обеспечивает связь Pod-to-Pod с использованием реальных IP-адресов, независимо от того, развернут ли Pod на одном физическом узле или на другом узле в кластере. Рассмотрим модули, которые находятся на одном компьютере, чтобы избежать сложностей, связанных с переходом по внутренней сети для связи между узлами.

С точки зрения Pod он существует в собственном пространстве имен Ethernet, которому необходимо взаимодействовать с другими сетевыми пространствами имен на том же узле. К счастью, пространства имен могут быть связаны с помощью виртуального устройства Ethernet Linux или пары veth состоящей из двух виртуальных интерфейсов, которые могут быть распределены по нескольким пространствам имен. Чтобы связать пространства имен Pod, можем назначить одну сторону пары veth корневому сетевому пространству имен, а другую сторону — сетевому пространству имен Pod. Каждая пара veth работает как патч-кабель, соединяя две стороны и позволяя трафику течь между ними. Эту настройку можно воспроизвести для любого количества модулей, имеющихся на машине.

На этом этапе настроены поды, чтобы у каждого было одно сетевое пространство имен, чтобы они считали, что у них есть собственное устройство Ethernet и IP-адрес, и они подключены к корневому пространству имен для Node. Теперь необходимо обеспечить общение подов друг с другом через корневое пространство имен, и для этого будет использован сетевой мост.

Мост Linux Ethernet — это виртуальное сетевое устройство уровня 2, используемое для объединения двух или более сетевых сегментов, работающее прозрачно для соединения двух сетей вместе. Мост работает, поддерживая таблицу пересылки между источниками и получателями, проверяя место назначения пакетов данных, которые проходят через него, и решая, передавать ли пакеты другим сегментам сети, подключенным к мосту. Мостовой код решает, передавать ли данные или отбрасывать их, просматривая MAC-адрес, уникальный для каждого устройства Ethernet в сети.

Мосты реализуют протокол ARP для обнаружения MAC-адреса канального уровня, связанного с заданным IP-адресом. Когда фрейм данных принимается мостом, мост передает фрейм всем подключенным устройствам (кроме исходного отправителя), а устройство, которое отвечает на фрейм, сохраняется в таблице поиска. Будущий трафик с тем же IP-адресом использует таблицу поиска для определения правильного MAC-адреса для пересылки пакета.