Глубокое погружение в получение сетевых карт и сопоставление IP-адресов с рабочими нагрузками кластера для ускорения отладки.

Kubernetes, ставшая стандартной платформой развертывания де-факто, позволила разработчикам быстро развертывать производственные приложения с конвейером CI/CD. Однако его использование привело к резкому увеличению количества ресурсов в кластерах Kubernetes. Для лучшего обслуживания платформы нам нужна более высокая наблюдаемость, которая поможет нам своевременно отслеживать состояние работоспособности кластера.

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

Что такое кластерный мониторинг?

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

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

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

Мониторинг кластера и сопоставление сети

Давайте будем более конкретными. Огромные и сложные сетевые данные — это то, чего мы должны придерживаться, поскольку они всегда изолированы и отличаются степенью детализации и быстрыми изменениями. Например, количество недолговечных IP-адресов увеличивается по мере увеличения рабочих нагрузок, и трудно найти и решить проблему после возникновения проблемы с сетью.

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

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

Caretta — это инструмент с открытым исходным кодом, который предлагает мониторинг сети, собирая информацию о ресурсах кластера и обрабатывая данные ядра с помощью eBPF (расширенный фильтр пакетов Беркли), отправляя помеченные метрики через Prometheus и визуализируя данные на панели инструментов Grafana.

Он состоит из K8sIPResolver, реализованного пакетом client-go, и трассировщика с сервером метрик, который отправляет данные eBPF.

K8sIPResolver динамически отслеживает девять типов ресурсов кластера (pods, node, replicaset, daemonset, statefulset, job, service, deployment, cronjob) с помощью механизма client-go watch, собирает и анализирует данные, такие как IP-адреса, записывает их в Кэш LRU и делает снимки.

Что такое eBPF?

Metrics использует eBPF для сбора сетевых данных и отправляет метрики в Prometheus после их маркировки на основе приведенной выше информации о ресурсах.

Можно сказать, что eBPF обеспечивает высокую производительность Caretta.

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

Как работает eBPF в Caretta

В Caretta соответствующие зонды настроены для отслеживания сетевых данных, таких как tcp_data_queue и inet_sock_set_state. А bpfobject создается с помощью пакета cilium ebpf для быстрого сбора данных о сетевых ссылках.

Вы можете найти код для этого на GitHub.

eBPF реализуется в два этапа.

Первый — это код, то есть настройка структуры данных и алгоритма: парсинг данных TCP, sock и роли в eBPF, сохранение их в карте и генерация зондов в коде Go.

Во-вторых, упакуйте eBPF с кодом Go с помощью следующей команды в Makefile и разверните.

generate_ebpf: ${BPF2GO_BINARY}_${BPF2GO_VERSION} \
    download_libbpf_headers
 go mod vendor
 (cd ${REPODIR}/pkg/tracing && \
  GOPACKAGE=tracing ${REPODIR}/${BPF2GO_BINARY}_${BPF2GO_VERSION} \
  -cc "${BPF_CLANG}" -cflags "${BPF_CFLAGS}"  \
  -target native bpf \
  ebpf/caretta.bpf.c --)

Каретта с Графаной

Grafana — самый известный инструмент визуализации для мониторинга данных в облачном сообществе. Он поддерживает различные диаграммы, фильтры и конфигурации сигналов тревоги, отображая данные из таких источников данных, как Prometheus, и интегрируется в Caretta для отображения диаграмм отображения сети.

Caretta интегрируется с Grafana, добавляя свою диаграмму руля и панель управления в исходный код, чтобы пользователи могли быстро получить ожидаемую визуализацию. На приборной панели есть четыре панели: ServiceMap, Active Ports, Workloads с максимальной пропускной способностью и соединения с максимальной пропускной способностью, которые получаются с помощью различных агрегаций на основе метрик caretta_links_observed.

Например, выражение Top Throughput Workloads — это 8 основных рабочих нагрузок на sum после group в соответствии с client_name.

topk(8, sum by (client_name) ((rate(caretta_links_observed{client_namespace=~\"$namespace\", client_kind=~\"$kind\", client_name=~\"$workload\", server_port=~\"$port\"}[$__range:$__interval]))))

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

Как они работают вместе

Давайте посмотрим быструю демонстрацию Caretta.

Установите добрый кластер. Если вы работаете на компьютере Mac, требуется виртуальная машина Linux.

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

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
- role: worker

Затем создайте кластер с приведенной выше конфигурацией.

shell
kind create cluster --config=config.yaml
kubectl cluster-info --context kind-kind

Чтобы установить Caretta, вам сначала нужно установить helm CLI локально.

helm repo add groundcover https://helm.groundcover.com/
helm repo update
helm install caretta --namespace caretta --create-namespace groundcover/caretta

Проверьте рабочее состояние модулей Caretta с помощью kubectl get pods -ncaretta.

Примечание. Необходимо использовать последнюю версию Docker (4.13). В противном случае код eBPF не будет выполнен, и вы получите следующее сообщение об ошибке:

Couldn't load probes - error loading BPF objects from go-side. field HandleSockSetState: program handle_sock_set_state: apply CO-RE relocations: no BTF found for kernel version 5.15.49-linuxkit: not supported

Переадресация портов на локальную Grafana через порт 3000.

kubectl port-forward --namespace caretta caretta-grafana-5b8594ddb8-cxmvr 3000:3000

Теперь мы можем просмотреть состояние сопоставления сети кластера в браузере localhost:3000. Если нет развертывания и службы для отображения данных в кластере в начале, мы можем установить hello-app.

kubectl create deployment hello-app --image=hello-repo/hello-app:v2
# expose 
kubectl expose deployment hello-app --name=hello-app-service --type=LoadBalancer --port 80 --target-port 8080

Затем конкретная информация о сети отображается в Grafana.

В целом, Caretta очень эффективна при создании сетевого сопоставления, за исключением одного ограничения: eBPF поддерживается только Linux, а не Mac. Разработка eBPF на Mac M1 нуждается в улучшении.

Заключение

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

Однако некоторые легкие, высокопроизводительные инструменты мониторинга, такие как Caretta, могут значительно помочь нам получить карты сети и сопоставить IP с рабочей нагрузкой, облегчая управление состоянием сети кластера и ускоряя отладку.

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