Контейнерные сети: от DIY до покупки

Сообщество аналитиков практически не освещало контейнерные сетевые решения корпоративного уровня — рынок, который до недавнего времени состоял в основном из решений с открытым исходным кодом.

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

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

Параллели с облачными сетями

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

Однако десять лет назад предприятия применяли самостоятельный подход к управлению облачными сетями. Но поскольку поставщики облачных услуг предлагали собственные сетевые функции, организации столкнулись со многими трудностями в управлении сетями разных поставщиков облачных услуг. Рынок быстро осознал потребность в облачных сетевых решениях, которые могли бы обеспечить связь в гибридных и мультиоблачных средах.

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

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

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

Самостоятельный подход к созданию контейнерной сети намного сложнее по сравнению с облачной сетью. Для работы в сети контейнеров требуются знания как о средах выполнения контейнеров, так и о платформах оркестрации, а также требуется несколько сторонних плагинов, таких как CNI и входящие контроллеры. Это совершенно другая задача, чем та, с которой привыкли иметь дело сетевые специалисты, прошедшие путь обучения, состоящий из таких сертификатов, как CCNA/CCNP или Network+.

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

Таким образом, сетевое бремя ложится на команды DevOps, которые традиционно не несут (и не должны нести) ответственность за развертывание сети и управление ею. Для этого им необходимо изучить уровни с 3 по 7, протокол пограничного шлюза (BGP), подсети, преобразование сетевых адресов (NAT) и тому подобное, но это довольно долгий путь обучения.

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

• Хороший графический интерфейс.
• Механизмы определения политики.
• Безопасность, выходящая за рамки правил разрешения/блокировки.
• Аналитика и наблюдаемость.
• Мультикластерные возможности.
• Расширенные возможности маршрутизации.

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

Зрелость рынка и конкуренция

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

Исторически сложилось так, что организации рассматривали CNI с открытым исходным кодом, чтобы начать работу в сети Kubernetes. Cilium и Calico являются одними из наиболее широко распространенных CNI, а их версии корпоративного уровня являются очевидным выбором для многих организаций. Это особенно верно, поскольку некоторые CNI, такие как Flannel, Canal или kuber-router, не имеют плана корпоративного уровня, а другие, такие как Tungsten Fabric и Weave Net (последний был широко распространен CNI), были прекращены. и больше не поддерживаются.

Интересно, что значительное количество поставщиков сетевых технологий, таких как Cisco, Juniper и Arista, разработали собственные CNI, чтобы предлагать контейнерные сети как часть своих продуктов. Проблема с этим подходом заключается в том, что многие организации выбрали CNI с открытым исходным кодом как часть тенденции DIY. Переход от уже развернутого CNI с открытым исходным кодом к коммерческому решению с проприетарным CNI может потребовать больше усилий, и для этого организациям потребуется сильный стимул.

Поставщикам сетевых технологий уже слишком поздно выходить на рынок с открытым исходным кодом CNI. Вместо этого они могут и должны извлечь выгоду из существующих развертываний Calico и Cilium и создать свои контейнерные сетевые решения корпоративного уровня, предлагающие расширенные функции и интеграцию с более широким портфелем продуктов этих поставщиков.

Следующие шаги

Чтобы узнать больше, ознакомьтесь с отчетом Sonar по контейнерным сетям -. В этом отчете представлен всесторонний обзор рынка, изложены критерии, которые вы должны учитывать при принятии решения о покупке, и оценивается эффективность ряда поставщиков в соответствии с этими критериями принятия решения.

Если вы еще не являетесь подписчиком -, вы можете получить доступ к исследованию, используя бесплатная пробная версия.