Cilium: CNI с поддержкой eBPF, решение NOS для современных облаков

Автор продолжает свой рассказ для Otomato об инструментах с поддержкой eBPF.

NOS означает Networking, Observability и Security.

Некоторые детали стоит повторить

Вы можете знать, что Kubernetes использует iptables для kube-proxy, компонента, который реализует сервисы и балансировку нагрузки с помощью правил iptables DNAT, а также большинство плагинов CNI используют iptables для сетевых политик.

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

Чтобы преодолеть эти проблемы, была изобретена технология eBPF. В конечном итоге она была реализована в ядре Linux 3.18.

Для полноценного использования eBPF требуется как минимум Linux 4.4 или выше!

e[xtended]BPF, каким мы его знаем сегодня, был создан Алексеем Старовойтовым и Даниэлем Боркманном, которые до сих пор являются сопровождающими, но к ним присоединились более сотни участников. Забегая вперед, важно отметить, что Даниэль сейчас работает в компании Isovalent.

eBPF, что расшифровывается как extended Berkeley Packet Filter, — это функция ядра linux, позволяющая автоматически собирать данные сетевой телеметрии, такие как полные запросы, метрики ресурсов и сети, профили приложений и многое другое.

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

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

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

Например, он гарантирует и обеспечивает:

• ваша программа выполняется за ограниченное количество процессорного времени (без бесконечных циклов);
• ваша программа не аварийно завершается и не создает вредных, фатальных ошибок;
• ваш код eBPF загружается процессом с необходимыми разрешениями;
• ваш код имеет ограничение по размеру;
• не допускается недоступный код.

Таким образом, считайте, что это легкая, полностью изолированная виртуальная машина (VM) внутри ядра Linux. Программы eBPF основаны на событиях, и выполняются по определенному крючку, такому как сетевые события, системные вызовы, записи функций и точки трассировки ядра.

Популярные проекты на базе eBPF

• Pixie, платформа устранения неполадок приложений для Kubernetes
• Cilium by Isovalent, eBPF Networking, Security and Observability для Kubernetes
• Falco, облачная нативная среда безопасности выполнения
• Tracee от Aqua, безопасность и криминалистика среды выполнения
• Calico от Tigera, прямой конкурент Cilium в качестве CNI.

Что такое Cilium? Каковы его особенности?

Для того чтобы удовлетворить требования к сети, безопасности и видимости контейнерных рабочих нагрузок, Cilium — это проект с открытым исходным кодом, построенный на базе eBPF. Поверх eBPF он предлагает высокоуровневую абстракцию.

Как Kubernetes и контейнерные среды исполнения являются для ядра Linux namespaces, cgroups и seccomp, Cilium является для eBPF: соответствующим уровнем абстракции над ним.

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

Реализация безопасности с наименьшими привилегиями при взаимодействии ваших K8s pods друг с другом является рекомендуемой практикой. Фундаментальные сетевые политики K8s (которые функционируют на уровне L3/L4) эффективны, но сетевые политики Cilium позволяют вам улучшить их (работать шире, на уровне L3-L7).

В эпоху K8s и микросервисов это может быть весьма полезно, поскольку мониторинг и регулирование сетевого трафика с помощью метаданных (таких как IP и порты) не приносит особой пользы. Поскольку сервисы появляются и уходят, IP и порты постоянно меняются.

Гибкость подхода заключается в том, что вы можете управлять трафиком с помощью Cilium, используя Pod, HTTP, gRPC, Kafka, DNS и другие метаданные.

Например, вы можете создавать HTTP-правила, которые определяют методы route, header и request, позволяющие определенному Pod сделать конкретный вызов API. Другой пример — создание правил DNS на основе FQDN для ограничения доступа только к определенным доменам. Благодаря этому мы можем создавать политики безопасности, которые более полезны и практичны для наших реальных случаев использования.

В Cilium v1.12 вы даже можете установить маршрут, который информирует другие конечные точки о том, что Pod теперь недоступен (т.е. когда Pod удален)!

Подключение нескольких кластеров и балансировка нагрузки

Cilium обеспечивает взаимодействие и обнаружение K8s pods между кластерами K8s с помощью кластерной сетки. High Availability и Multi-Cloud — вот несколько сценариев использования (соединение кластеров K8s между облачными провайдерами).

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

kube-proxy может быть заменен на Cilium для eBPF; iptables, который вытесняется eBPF, используется kube-proxy.

В результате, производительность значительно увеличивается благодаря этой настройке.

«Подводные» особенности Cilium

• Прозрачное шифрование между подами. Поддержка протоколов IPsec и Wireguard
• Повышение производительности сети
• Масштабируемость инфраструктуры
• Улучшенная видимость потоков трафика, включая протоколы L7, в дополнение к IP-адресам и портам.
• Мониторинг и улучшенная видимость неисправностей сети между вашими микросервисами Метрики, работающие с Prometheus, предлагаются компанией Cilium.

Cilium CNI поддерживает политики уровня 7 (L7). По этой функции он конкурирует с Istio. Политика 7-го уровня Cilium проста в использовании благодаря собственному фильтру на основе Envoy & proxylib.

Наблюдаемость имеет значение!

Команда Cilium также предлагает Hubble (да, название такое же, как у знаменитого телескопа, ползущего в дальний космос, но для облаков), который представляет собой полностью распределенную платформу наблюдаемости сетей и безопасности для облачных рабочих нагрузок. Hubble — это программное обеспечение с открытым исходным кодом, построенное на базе Cilium и eBPF, что позволяет обеспечить глубокую видимость взаимодействия и поведения сервисов, а также сетевой инфраструктуры в полностью прозрачной манере.

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

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

И никто лучше команды Datadog не понимал нюансов мониторинга на базе Cilium. Иллюстрация принадлежит им.

Метрики Hubble, в отличие от метрик Cilium, позволяют следить за связностью и безопасностью сети, в которой работают ваши управляемые Cilium капсулы Kubernetes.

«Какую пользу я могу извлечь из этого?»

Что ж, убеждение автора: если бесполезно для масс, то никакая новая технология не нужна!

GCP GKE

☁️ В середине 2021 года Google уже представила так называемый GKE Dataplane V2, самолёт данных, использующий возможности eBPF и Cilium. Они также используют Dataplane V2, чтобы привнести логирование сетевой политики Kubernetes в Google Kubernetes Engine (GKE).

Чтобы опробовать протоколирование сетевой политики Kubernetes, создайте новый кластер GKE с Dataplane V2 с помощью следующей команды:

gcloud container clusters create <cluster-name> 
    --enable-dataplane-v2 
    --enable-ip-alias 
    --release-channel rapid 
    {--region region-name | --zone zone-name}

Конфигурация агента Cilium и сетевой политики Cilium определяет, принимает ли конечная точка трафик от источника или нет. Применение сетевой политики встроено в GKE Dataplane V2. Вам не нужно включать внедрение сетевой политики в кластерах, использующих GKE Dataplane V2.

AWS EKS

☁️ Если вы работаете на AWS, знайте, что EKS Anywhere использует Cilium для сетевого взаимодействия и безопасности Pod.

По умолчанию в кластере Kubernetes разрешена любая форма связи Pod to Pod. Хотя это может способствовать экспериментам, такая гибкость не считается безопасной. Вы можете ограничить сетевой трафик между pods (часто называемый трафиком Восток/Запад) и между pods и внешними сервисами с помощью сетевых политик Kubernetes. Сетевые политики Kubernetes действуют на уровнях 3 и 4 модели OSI. Сетевые политики могут также использовать IP-адреса, номера портов, номера протоколов или их комбинацию для идентификации исходных и конечных стручков в дополнение к селекторам стручков и меткам. Calico от Tigera — это движок политик с открытым исходным кодом, совместимый с EKS.

В сочетании с Istio, Calico позволяет расширить сетевые политики с более широким набором функций, включая поддержку правил уровня 7, таких как HTTP, в дополнение к предоставлению всего набора функций сетевой политики Kubernetes. Разработчики Cilium, Isovalent, также расширили сетевые политики, предложив ограниченную поддержку правил уровня 7, таких как HTTP. Для ограничения связи между службами/подами Kubernetes и ресурсами, которые работают внутри или за пределами вашего VPC, Cilium дополнительно поддерживает имена хостов DNS.

Azure AKS

☁️ Если вы работаете на Azure, вы можете знать, что AKS официально поддерживал только два CNI, Kubenet и Azure CNI. В апреле 2022 года они объявили о возможности создания кластера AKS без CNI. Это означает, что вы можете развернуть любой CNI, какой захотите. В этой статье британские MVP из Pixel Robots показывают, как создать кластер AKS без CNI, а затем… развернуть Cilium!

OpenShift

☁️ OpenShift: Cilium также может быть установлен на традиционных виртуальных машинах или пустых серверах. Команды платформы OpenShift могут реализовать контроль на основе меток над обменом данными между капсулами приложений и внешними узлами, разрешив ВМ или пустым серверам присоединиться к кластеру Cilium. С другой стороны, внешние узлы будут иметь доступ к службам кластера и смогут разрешать имена кластера.

k3s & minikube

☁️ В конце концов, вы сможете играть с Cilium на k3s или даже на minikube, просто в гараже. 🚜

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

Практические лабораторные работы на Instruqt®

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

Добрые пожелания & что еще почитать

Внедряйте с осторожностью! Стремитесь к тому, чтобы рядом с вами были гуру!

Автор выражает благодарность Ярелу Маману, Йоханну Ребергеру, Крису Мачлеру, Лину Суну, Артуру Чиао, Глену Ю и Ричарду Хуперу за их вклад в развитие сообщества.

P.S.: хардкорные разработчики могут найти некоторые технические подробности здесь и здесь, о разборе L7 с proxylib в Golang.