Améliorez la surveillance des clusters avec le mappage réseau dans Grafana | de Stefanie Lai | janvier 2023

Une plongée approfondie dans l’obtention de cartes réseau et la corrélation de l’IP avec les charges de travail du cluster pour accélérer le débogage

Kubernetes, en tant que plate-forme de déploiement standard de facto, a permis aux développeurs de déployer rapidement des applications de production avec un pipeline CI/CD. Son utilisation, cependant, a entraîné une explosion du nombre de ressources dans les clusters Kubernetes. Pour une meilleure maintenance de la plate-forme, nous avons besoin d’une observabilité plus élevée pour nous aider à surveiller l’état de santé du cluster en temps opportun.

Observabilité dans Kubernetes est le « processus continu d’utilisation des métriques, des événements, des journaux et des données de trace qu’un système Kubernetes génère pour identifier, comprendre et optimiser sa santé et ses performances ».

La surveillance des clusters est le moyen le plus important d’atteindre l’observabilité, couvrant de nombreux aspects, y compris les ressources, les performances, les événements, les journaux, etc. Une série d’indicateurs et de journaux du système observé peut être collectée avec des outils de surveillance.

Avec un cluster générant quotidiennement des millions de ces métriques, deux grands défis nous attendent : premièrement, de nombreux systèmes de surveillance conventionnels doivent surveiller les nombreuses métriques provenant des clusters Kubernetes. Deuxièmement, il est difficile de distinguer les mesures les plus critiques des « données encombrantes ».

Par conséquent, nous recherchons une solution capable de gérer toutes les données, d’analyser et de représenter automatiquement des graphiques et d’indiquer les mesures critiques. En collectant efficacement les données dont nous avons besoin tout en filtrant l’inutile, nous pouvons économiser beaucoup d’efforts pour que tout fonctionne correctement.

Surveillance des clusters et cartographie du réseau

Soyons plus précis. Les données réseau énormes et complexes sont ce à quoi nous devrions adhérer car elles sont toujours isolées et différentes en termes de granularité et de changement rapide. Par exemple, les adresses IP de courte durée augmentent à mesure que les charges de travail augmentent, et il est difficile de localiser et de résoudre le problème une fois que le problème de réseau se produit.

Certains outils tiers ne peuvent jouer qu’un rôle limité en raison de leur complexité d’utilisation et du mode side-car invasif. De plus, ils semblent impuissants face aux retards du réseau de service, pour lesquels nous avons besoin d’outils avancés pour obtenir la carte du réseau entre les charges de travail cloud.

Nous utiliserons donc Caretta ici, ce qui nous permet de localiser rapidement le problème à partir des charges de travail associées que nous trouvons par espace de noms, nom et port dans l’interface utilisateur lorsqu’il est combiné avec Grafana.

Caretta est un outil open source qui offre une surveillance du réseau en rassemblant des informations sur les ressources du cluster et en traitant les données du noyau avec eBPF (filtre de paquets Berkeley étendu), envoi de métriques étiquetées via Prometheus et visualisation des données sur un tableau de bord Grafana.

Il comprend un K8sIPResolver mis en œuvre par le client-aller package et un traceur avec un serveur de métriques qui envoie les données eBPF.

K8sIPResolver surveille dynamiquement les neuf types de ressources de cluster (pods, node, replicaset, daemonset, statefulset, job, service, deployment, cronjob) avec le mécanisme de surveillance client-go, collecte et analyse des données telles que les adresses IP, les enregistre dans un cache LRU et prend des instantanés.

Metrics utilise eBPF pour collecter des données réseau et envoie les métriques à Prometheus après les avoir étiquetées en fonction des informations de ressource ci-dessus.

On peut dire que eBPF apporte des performances élevées à Caretta.

eBPF est non intrusif, efficace, sécurisé et fonctionne à l’intérieur du noyau Linux, ce qui présente de grands avantages par rapport aux méthodes d’implémentation traditionnelles lorsqu’il est appliqué dans des outils d’observabilité. eBPF permet aux utilisateurs d’écrire des plugins pour le noyau Linux dans l’état de la boîte noire. Et la méthode eBPF est exécutée une fois que le programme dans le noyau s’exécute jusqu’au point où le plugin doit être inséré, remplissant l’expansion des fonctions du noyau.

Comment fonctionne eBPF dans Caretta

Dans Caretta, les sondes associées sont personnalisées pour suivre les données du réseau telles que tcp_data_queue et inet_sock_set_state. Et bpfobject est généré avec le cil ebpf package pour collecter rapidement les données de liaison réseau.

Vous pouvez trouver le code pour cela sur GitHub.

eBPF est implémenté en deux étapes.

Le premier est le codec’est-à-dire personnaliser la structure et l’algorithme des données : analyser les données TCP, la chaussette et le rôle dans eBPF, les stocker dans une carte et générer des sondes dans le code Go.

Ensuite, empaquetez eBPF avec le code Go avec la commande suivante dans Makefile et déployer.

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 est l’outil de visualisation le plus connu pour la surveillance des données dans la communauté cloud. Il prend en charge divers graphiques, filtres et configurations d’alarme en affichant des données provenant de sources de données telles que Prometheus et est intégré à Caretta pour afficher des diagrammes de cartographie du réseau.

Caretta s’intègre à Grafana en ajoutant son graphique de barre et son tableau de bord dans sa source pour que les utilisateurs obtiennent rapidement la visualisation attendue. Il y a quatre panneaux dans le tableau de bord : ServiceMap, Active Ports, Top Throughput Workloads et Top Throughput Connections, qui sont tous obtenus par différentes agrégations basées sur caretta_links_observed métrique.

Par exemple, l’expression de Top Throughput Workloads est le top 8 des charges de travail par sum après group selon 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]))))

Ces quatre panneaux répondent à nos besoins de base pour surveiller le mappage du réseau de charge de travail, et nous pouvons également personnaliser les requêtes ou plans associés pour obtenir plus d’informations.

Comment ils travaillent ensemble

Voyons une démonstration rapide de Caretta.

Installez un cluster de type. Si vous êtes sur une machine Mac, une machine virtuelle Linux est requise.

Le cluster de kind par défaut ne contient qu’un seul nœud. Créons un cluster avec trois nœuds de travail avec la configuration suivante pour mieux afficher les données.

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

Créez ensuite le cluster avec la configuration ci-dessus.

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

Pour installer Caretta, vous devez d’abord installer la CLI helm localement.

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

Vérifiez l’état de fonctionnement des pods Caretta avec kubectl get pods -ncaretta.

Note: Vous devez utiliser la dernière version de Docker (4.13). Sinon, le code eBPF ne s’exécutera pas et vous obtiendrez l’invite d’erreur suivante :

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

Transférer les ports vers un Grafana local sur le port 3000.

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

Maintenant, nous pouvons voir l’état du mappage réseau du cluster dans le navigateur localhost:3000. S’il n’y a pas de déploiement et de service pour afficher les données dans le cluster au début, nous pouvons installer un 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

Ensuite, les informations spécifiques au réseau sont affichées dans Grafana.

Dans l’ensemble, Caretta est très efficace pour créer un mappage réseau à l’exception d’une limitation : eBPF n’est pris en charge que par Linux, pas par Mac. Le développement eBPF sur Mac M1 doit être amélioré.

Les aspects liés au réseau de Kubernetes, quelle que soit la configuration, l’application ou la surveillance, ont dérangé de nombreux développeurs de cloud.

Cependant, certains outils de surveillance légers et performants comme Caretta peuvent nous aider de manière significative à obtenir des cartes réseau et à corréler l’IP avec la charge de travail, facilitant la gestion de l’état du réseau du cluster et accélérant le débogage.

J’espère que Caretta ajoutera bientôt la prise en charge des ressources personnalisées et davantage de fonctionnalités basées sur eBPF pour améliorer la surveillance du réseau cloud.