Три лучших сетевых инструмента Kubernetes и принципы их работы

Сеть Kubernetes, вероятно, самая сложная часть работы с установками Kubernetes. Одна из основных причин заключается в том, что он имеет довольно специфические критерии, которым необходимо соответствовать в отношении сетевой архитектуры. К ним относятся такие требования, как то, что все модули должны иметь возможность взаимодействовать друг с другом без преобразования сетевых адресов (NAT) и иметь видимый IP-адрес, о котором они знают. Это особенно затрудняет работу контейнеров согласованным и безопасным образом, поскольку вы не можете заставить все ваши модули обмениваться данными друг с другом по принципу «многие ко многим». Кроме того, поддержание сетевого подключения между всеми модулями в кластерах на нескольких хостах является еще более технической и сложной задачей и требует, по меньшей мере, определенного уровня знаний. Но если вы поместите эти три сетевых инструмента Kubernetes в свой набор инструментов, ваша работа станет намного проще.

Подключи и играй

Наряду с диктованием конкретных сетевых требований Kubernetes также допускает определенную гибкость в отношении реализации. Вот почему в этой «субэкосистеме» Kubernetes возник ряд проектов, все с единственной целью сделать контейнерную сеть между хостами быстрой, согласованной, безопасной и, что наиболее важно, простой в использовании. Общая концепция, лежащая в основе этих инструментов, заключается в создании программно разработанных сетей, которые соответствуют сетевым критериям Kubernetes, но в то же время оставляют достаточный контроль в руках администраторов кластера для эффективной защиты и мониторинга системы. Это стало возможным благодаря подключаемым модулям CNI, где CNI означает сетевой интерфейс контейнера, стандарт для сетевых инструментов на основе подключаемых модулей в контейнерах Linux.

Помимо Kubernetes, CNI также позволяет этим плагинам работать с OpenShift, Amazon ECS и другими, где они работают, создавая оверлейную сеть поверх существующих инфраструктур. Затем эти оверлейные сети прозрачно соединяют контейнеры между несколькими хостами и назначают им уникальные IP-адреса, которые они затем могут использовать для прямой связи с другими контейнерами. Поскольку вся связь теперь осуществляется через эту новую оверлейную сеть, мониторинг которой намного проще, нет необходимости утомительно настраивать сетевые политики на хосте, что экономит огромное количество времени. Этот новый уровень видимости также значительно повышает безопасность, поскольку он позволяет выставлять выбранные контейнеры в Интернет, в то время как остальные надежно защищены от вреда.

Лесоруб

Из всех сетевых инструментов, доступных сегодня для Kubernetes, Flannel является одним из первых плагинов CNI, а также самым популярным и простым в использовании. Вероятно, это связано с тем, что он имеет довольно простую сетевую модель, которую можно использовать в большинстве случаев, когда вам нужны основы. Flannel — это оверлейная сеть, разработанная CoreOS, которая позволяет контейнерам взаимодействовать между несколькими хостами, не показывая, что они используют оверлей. Он делает это, назначая диапазон адресов подсети, при этом каждый контейнер получает его, независимо от того, на каком хосте он находится. Затем Фланнель использует инкапсуляцию пакетов и хранилище значений etcd/key с открытым исходным кодом для адресации всего диапазона хостов и записи сопоставлений между адресами.

У Flannel есть ряд опций для инкапсуляции и маршрутизации, но для конфигураций с несколькими хостами по умолчанию рекомендуется использовать vxlan с каким-либо программным коммутатором, например, мостом Linux. Коммутатор — это место, куда отправляется весь трафик, направленный за пределы хоста, а устройство vxlan — это место, куда он, в свою очередь, перенаправляется на L2. Flannel запускает на каждом хосте демон с именем flanneld, который создает правила маршрутизации в таблице маршрутов ядра. Этот демон собирает пакеты из vxlan и помещает в них «обертки» L3 или инкапсуляции UDP для передачи между хостами в физической сети. Хотя на первый взгляд это может показаться сложным, это, безусловно, самая простая версия оверлейной сети в Kubernetes.

Цепная пила

Однако, если вам нужны не только основы, вероятно, в ваших интересах рассмотреть Project Calico. В отличие от Flannel, которому необходимо инкапсулировать пакеты перед отправкой, Calico фактически настраивает сеть L3 с использованием протокола маршрутизации BGP для прямой связи между хостами. Этот «чистый» подход L3 не только проще, но и обеспечивает более высокое масштабирование, лучшую производительность и эффективность. Отсутствие каких-либо оберток и «камуфляжа» также означает, что пакеты намного проще отслеживать с помощью Calico, и здесь также можно использовать стандартные инструменты и процедуры отладки. К сожалению, для некоторых Calico не очень популярен из-за своей простоты, а люди используют его из-за его расширенных функций, таких как управление сетевыми политиками и списки контроля доступа.

Хотя Kubernetes NetworkPolicy API позволяет пользователям назначать политики входящего трафика модулям с помощью портов и меток, другие функции, такие как назначение политик исходящего трафика и CIDR, пока не поддерживаются. Calico прекрасно заполняет этот пробел, не только поддерживая ряд функций политик, которые пока не поддерживаются, но и предотвращая исходящие подключения от модулей, сопоставляя модули с пространствами имен. Кроме того, Calico хорошо интегрируется с Istio, сеткой сервисов с открытым исходным кодом, созданной для архитектуры распределенных микросервисов. Это означает, что Calico применяет политики не только на уровне сетевой инфраструктуры, но и на уровне сервисной сетки. В общем, Project Calico — неплохой выбор, если вам важнее производительность. Есть также коммерческая поддержка, если у вас есть деньги.

Сетевые инструменты Kubernetes: понемногу

Если дополнительная сложность и управление исключены, но вам по-прежнему нужны мощность и производительность ваших сетевых инструментов Kubernetes, Weave Net от Weaveworks — это третий вариант, на который вам, вероятно, следует обратить внимание. В отличие от Calico, который настраивает всю сеть L3 с нуля, Weave Net создает ячеистую наложенную сеть, которая соединяет каждый узел в кластере. Он также использует DNS-сервер под названием weaveDNS для предоставления таких функций, как автоматическое обнаружение служб, балансировка нагрузки, разрешение имен и отказоустойчивость. Хотя он инкапсулирует пакеты vxlan так же, как Flannel, он делает это непосредственно в ядре, так что пакеты идут прямо к целевому модулю, не тратя время на перемещение в пространство пользователя и из него. Эта маленькая деталь дает ему значительное преимущество в производительности.

В случае, когда топология сети не поддерживает этот быстрый путь передачи данных, используется более медленный режим инкапсуляции резервных копий, называемый «режим рукава». Weave Net также имеет систему шифрования, которая шифрует весь трафик между хостами, шифрование NaCl для рукавного трафика и Ipsec ESP для быстрого трафика данных. Кроме того, сетевые политики автоматически настраиваются при установке, поэтому все, что вам нужно сделать, это установить правила, и все готово. Что наиболее важно, Weave Net относительно легко настроить и настроить, и он поставляется почти со всем, предварительно настроенным для пользователя. Если вы ищете мощность и простоту, это, вероятно, ваш лучший выбор.

Хотя Kubernetes, безусловно, является сложной проблемой, целое сообщество разработчиков работает круглосуточно, чтобы облегчить нам задачу, пока мы говорим. Если вы знаете о своих навыках и ограничениях в отношении сети Kubernetes, а также о своих требованиях и о том, чего вы хотите достичь с помощью этого сетевого плагина, очевидный выбор должен быть прямо перед вами. Если вы все еще не уверены, помните, что это только три лучших, и существует разнообразная группа плагинов CNI, подходящих для разных нужд. Наконец, сегодняшние корпоративные решения больше не представляют собой автономные инструменты, и чаще всего ответ заключается в двух или трех разных инструментах, которые хорошо работают вместе.