Решение сетевых проблем Kubernetes с помощью CNI

Микросервисы сегодня меняют способ создания, управления и доставки программного обеспечения. Хотя микросервисы упрощают разработку приложений, заставить эти микросервисы взаимодействовать друг с другом — непростая задача. По мере роста популярности Kubernetes возникают и проблемы с сетью Kubernetes. Давайте взглянем на некоторые основные разработки и продукты, которые могут помочь облегчить проблемы.

Использование Kubernetes растет

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

На самом деле, другие инструменты оркестровки отстали в плане принятия, и ни один из них не имеет значительного преимущества перед другими.

Опрос указывает на множество других положительных тенденций, ведущих к росту Kubernetes. Это показывает, что многие пользователи запускают Kubernetes в производство и используют большое количество контейнеров, определенно больше года назад. Кроме того, Kubernetes возглавляет список проектов Cloud Native Computing Foundation (CNCF), которые тестируются и используются пользователями. Это очень многообещающие признаки для Kubernetes, и очевидно, что он на пути к тому, чтобы стать нарицательным во многих ИТ-компаниях на предприятиях.

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

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

Сеть Kubernetes сложна

Kubernetes позволяет создавать тысячи контейнеров и управлять ими в облаке, но для их работы эти контейнеры должны быть объединены в сеть. Фактически, большинство пользователей начинают использовать Kubernetes просто из-за его способности обрабатывать рабочие нагрузки контейнеров в масштабе. Это происходит из-за его родословной, прошедшей боевые испытания в Google, и является одной из ключевых причин, по которой такие компании, как Box, выбрали Kubernetes.

Хотя Kubernetes отлично подходит для запуска, остановки и управления модулями контейнеров и кластерами, это также открытая платформа, над которой предстоит проделать большую работу, чтобы полностью раскрыть ее потенциал. Сеть — это одна из областей, где Kubernetes все еще находится на ранних стадиях, и прямо сейчас делается некоторая подготовительная работа, чтобы гарантировать, что сеть для Kubernetes движется в правильном направлении. Присутствие представителей многих организаций в составе Комитета по техническому надзору (TOC) помогает гарантировать отсутствие блокировки, и ни один поставщик не имеет большего влияния на формирование сети Kubernetes.

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

Существует два широко используемых сетевых инструмента Kubernetes — модель контейнерной сети Docker (CNM) и сетевой интерфейс контейнера (CNI) от CoreOS. Команда Kubernetes присматривалась к обоим этим проектам, но с самого начала отдавала предпочтение. Были признаки того, что сообщество Kubernetes, особенно инженеры Google, которые играют ключевую роль в определении направления Kubernetes, предпочли CNI, а не CNM.

CNM Докера

CNM был ответвлением Libnetwork, которое еще в 2015 году инкапсулировало план Docker по контейнерной сети. CNM состоит из трех компонентов — сетевой песочницы, конечной точки и сети. Цель CNM — сделать сеть для Docker легко подключаемой и расширяемой.

Однако Kubernetes не принял CNM, потому что ему нужно сетевое решение, которое может работать с несколькими средами выполнения контейнеров, а не только с Docker. По этой причине он обратился к CNI от CoreOS, который мог бы поддерживать несколько сред выполнения контейнеров, таких как Rocket, Docker и Hyper от CoreOS.

Введите CNI

CNI был впервые разработан CoreOS как сетевой плагин. Вскоре он был выделен как сетевой стандарт с открытым исходным кодом, на основе которого другие организации могут создавать сетевые решения для контейнеров. Вскоре он стал стандартным сетевым инструментом для Kubernetes, что стало большим шагом на пути к его внедрению. Несколько месяцев спустя его даже поддержал Mesos, один из трех больших оркестраторов наряду с Kubernetes и Docker Swarm.

Подобно CNM, CNI также работает по модели плагинов, поскольку не может обслуживать все типы сетей. Расширяемость зависит от плагинов. CNI находится между средой выполнения контейнера и сетевыми плагинами. Например, он может действовать как мост между rkt, средой выполнения контейнера, и Flannel, сетевым плагином.

CNI проще, чем CNM, и содержит только две команды для запуска контейнера и удаления контейнера. Он поддерживает семь сред выполнения контейнеров и имеет 14 плагинов. Два из них - фланель и плетение.

Плагины Flannel & Weave

Flannel — это виртуальная сеть, также созданная CoreOS, которая действует как альтернатива программно-определяемым сетевым решениям. Контейнеры сопоставления портов — это проблема, и Kubernetes решает эту проблему, предоставляя каждому поду свой IP-адрес. Flannel управляет сетью Kubernetes, предоставляя каждому хосту подсеть. Он устанавливает агент на каждый хост и автоматически назначает хосту подсеть. Являясь частью платформы CoreOS Tectonic, Flannel хорошо протестирован как сетевой плагин для CNI.

Weave — еще один сетевой плагин, который может работать вместо Flannel. Он устойчив, способен обходить сбои и автоматизировать сеть. В отличие от Flannel, Weave не использует SkyDNS, а поддерживает DNS «из коробки». Однако большинство Kubernetes уже переняли Flannel и довольны его производительностью, они не видят смысла переходить на Weave. Кроме того, у Kubernetes есть надстройка (kube2sky), которая поддерживает SkyDNS, что делает Flannel безопасным выбором.

Принятие CNCF — это большой шаг для CNI и большой прогресс для Kubernetes и экосистемы контейнеров в целом. CNCF поможет быстрее довести проект CNI до версии 1.0. Они сделают это, помогая протестировать инструмент и написав для него документацию. Кроме того, TOC, который использует подход невмешательства к проектам, всегда доступен для руководства по важным решениям, когда это необходимо. Эта отраслевая поддержка, которой пользуется CNI, стала ключевым фактором в его принятии.

Сеть была проблемой для оркестрации контейнеров, но теперь со стандартизацией в форме CNI мы можем сосредоточить внимание на том, чтобы довести ее до зрелости и сделать ее такой же функциональной, как устаревшие варианты, такие как OpenStack Neutron или VMware NSX.

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