Назначение платформы dBrain.cloud в том, чтобы предоставить готовый к использованию Kubernetes с максимально автоматизированными процессами управления микросервисами. Чтобы поддерживать высокий уровень работы платформы, наша команда формирует начинку dBrain из современных и продвинутых решений. Сегодня расскажем о выборе CNI: что мы использовали в Calico, в каких конфигурациях и как применяем Cilium.

CNI (Container Network Interface) - стандарт взаимодействия Kubernetes с оверлейной кластерной сетью. Сегодня комьюнити Kubernetes отдает на откуп пользователя, какой CNI выбрать, а их бесчисленное множество. Наш путь к идеальному CNI состоял из нескольких шагов: сначала мы использовали Calico на BGP (уровень L2 OSI), затем внедрили Calico cross-subnet VXLAN (L3), а сегодня используем Cilium (L3) на eBPF (extended Berkeley Packet Filter).

Надежный, но устаревший

Calico хорош для сегмента Enterprise-Grade Kubernetes, но имеет весомые минусы - скорость и функционал. Calico существенно медленнее, чем Cilium. Cilium же более производительный: на одинаковых ресурсах с Calico он пропускает больше пакетов с меньшими задержками.

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

Calico - простой и надежный CNI с большим комьюнити и хорошей кодовой базой. Но нехватка функционала делает его все менее привлекательным для разработчиков. Здесь нет современных фич: cluster mesh, service mesh, etc. Cilium по сравнению с Calico - швейцарский нож. Calico - привычный кухонный нож, но все хотят многофункциональный швейцарский.

В Calico есть возможность перехода на eBPF. Выбирая между изменением режима работы оверлейной сети в Calico и переходом на Cilium, мы остановились на последнем из-за нативной реализации eBPF. Cilium построили все решения CNI на основе eBPF+XDP. Это позволило заметно ускорить сетевое взаимодействие сервисов в Kubernetes в сравнении с iptables и IPVS, т.к. Cilium частично или полностью (в зависимости от конфигурации) заменяет собой kube-proxy. С Calico мы использовали реализацию kube-proxy на IPVS, где прописываются все роуты между эндпоинтами в оверлейной сети K8s. От самой медленной реализации на базе iptables мы отказались еще на этапе планирования внедрения Calico в платформу dBrain.

У Calico только в Enterprise-поставке есть удобный UI, в то время как у Cilium есть Hubble UI в Open Source. Он позволяет отслеживать текущее состояние оверлейной сети, все имеющиеся маршруты и правила, а также визуализировать движение трафика в режиме реального времени.

Стильный, модный, молодежный

Cilium многофукционален, заточен под современный запрос разработчика, нашпигован большим количеством фич. eBPF - главная фишка Cilium. Программы BPF, минуя дополнительные уровни абстракции, работают в самом ядре Linux, что делает их очень быстрыми. Происходит это из-за отсутствия копирования пакетов из ядерного неймспейса в user space, а также пропуска стандартных цепочек iptables.

Технология eBPF гарантирует скорость, производительность, низкую задержку по времени и отличную масштабируемость, что позволяет иметь кластер на большее количество подов и нод.

Три опоры, которые Cilium дает любой ИТ-инфраструктуре - скорость (eBPF), наблюдаемость (Hubble UI), безопасность (Network Policies).

С Cilium сетевая подсистема платформы dBrain стала быстрее, время ожидания сетевого взаимодействия внутри кластера уменьшилось, появились новые фичи, такие как service mesh, cluster mesh, egress gateway, Cilium Advanced Network Policies (для L3/L4, как в Calico, и на L7), gateway api.

Сложности перехода

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

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

После обновления ядра необходимо перезагружать ноды, мы смогли совместить это с миграцией на новый CNI в одном релизе.

Мы столкнулись с проблемой совместимости Cillium и используемого ранее на Calico балансировщика нагрузки PureLB. Пришлось вместе с переходом на новый CNI сменить его на MetalLB. Впоследствии это положительно сказалось на быстродействии переноса VIP-адресов на резервные серверы, которые выполняют роль балансировщика нагрузки, если один из них перестал отвечать на arp-запросы. Время переключения в случае отключения или выхода из строя LB сервера сократилось с нескольких секунд (на PureLB) до нескольких десятков миллисекунд, что практически незаметно для конечного пользователя платформы.

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

Какой CNI выбираете вы? Делитесь в комментариях.