Появление докера было революционным, оно изменило способ разработки и развертывания проектов. Сообщество работает над стандартизацией технологии контейнеров, и эта статья посвящена одному из этих аспектов: работе в сети.

Сетевой уровень: виртуальные машины против технологии контейнеров

Прежде чем мы начнем обсуждать различные стандартные модели контейнерной сети, давайте сравним виртуальные машины и докер с сетевой точки зрения.

Виртуальная машина — это набор средств виртуализации на уровне ОС, который также виртуализирует виртуальные сетевые карты (NIC), которые подключены к сетевым картам реальной физической машины.

Docker — это, по сути, процесс, управляемый средой выполнения контейнера и использующий ядро Linux. Итак, контейнеры имеют более гибкие сетевые решения:

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

Дизайн контейнерной сети

Ранние проекты сетей контейнеров были сосредоточены на том, как соединить контейнеры на хосте, чтобы они могли взаимодействовать с внешним миром.

В режиме «хост» контейнеры, работающие на хосте, используют сетевое пространство имен хоста и IP-адрес хоста. Чтобы выставить контейнер, контейнер занимает порт на хосте и связывается с внешним миром через этот порт. Таким образом, вам нужно поддерживать назначение портов вручную, не запускайте разные контейнерные службы на одном порту.

Режим «мост» имеет некоторые улучшения, основанные на режиме «хост». В этом режиме контейнер назначается виртуальной локальной сети, а назначенный ip-адрес получается в этом сетевом пространстве имен.Поскольку ip-адрес независим, это решает проблему, заключающуюся в том, что разные службы контейнера не могут работать на одном и том же порту в режим "хозяин" вопрос. Однако проблема остается: если контейнер хочет общаться с внешним миром, ему все равно нужно использовать ip-адрес хоста. В настоящее время вам необходимо использовать NAT для преобразования host-ip:port в private-ip:port. Правила NAT в этом разделе предназначены для поддержки Linux Iptables, что несколько (хотя и незначительно) повлияет на производительность.

Ни один из двух вышеперечисленных режимов не решает одну проблему: многоузловые сетевые решения.

Сравнение CNI и CNM

CNM: Представлено Docker, компанией, разработавшей среду выполнения контейнеров Docker.
CNI: предложено CoreOS.

При работе с сетью Kubernetes не стал создавать еще одну саму по себе, а выбрал CNI в качестве собственного сетевого подключаемого модуля. (Что касается того, почему бы не выбрать CNM, вы можете увидеть это официальное объяснение: Почему Kubernetes не использует libnetwork). Наиболее важным моментом отказа от использования CNM является то, что k8s считает, что CNM в определенной степени относительно тесно связан со средой выполнения контейнера, и его нелегко отделить. При выборе такого гиганта, как k8s, многие последующие проекты выбирали CNI между CNM и CNI.

Ниже приводится подробное сравнение двух сетевых моделей:

API CNM состоит из двух частей: подключаемого модуля IPAM и сетевого подключаемого модуля. Плагин IPAM отвечает за создание/удаление пулов адресов, назначение сетевых адресов, а сетевой плагин отвечает за создание/удаление сетей и назначение или освобождение IP-адресов контейнеров. На самом деле, оба плагина могут реализовывать все API, вы можете использовать IPAM, сеть или ОБА. Однако среда выполнения контейнера использует разные подключаемые модули в разных ситуациях, что усложняет процесс. Кроме того, CNM необходимо использовать распределенную систему хранения для хранения информации о конфигурации сети, например, etcd.

Воздействие CNI Иностранное добавление и удаление контейнера изнутри сетевого интерфейса. CNI json с использованием файла конфигурации, сохраненной информации о конфигурации сети. И CNM уже не тот, CNI не требует дополнительного механизма распределенного хранения.

Суммировать

CNI пользуется популярностью во многих проектах с открытым исходным кодом, таких как K8S, Memos и Cloud Foundry. Также признан Фондом облачных вычислений. За CNCF стоит много технологических магнатов, поэтому можно предвидеть, что CNI станет стандартом контейнерной сети в будущем.