Автор продолжает свой рассказ для Otomato об инструментах с поддержкой eBPF.
NOS означает Networking, Observability и Security.
- Некоторые детали стоит повторить
- Популярные проекты на базе eBPF
- Что такое Cilium? Каковы его особенности?
- Парадигма безопасности с наименьшими привилегиями для сетевой политики
- Подключение нескольких кластеров и балансировка нагрузки
- «Подводные» особенности Cilium
- Наблюдаемость имеет значение!
- «Какую пользу я могу извлечь из этого?»
- GCP GKE
- AWS EKS
- Azure AKS
- OpenShift
- k3s & minikube
- Практические лабораторные работы на Instruqt®
- Добрые пожелания & что еще почитать
Некоторые детали стоит повторить
Вы можете знать, что 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.