Qu’est-ce que les métriques réseau de conteneurs ?

Chaque pod, service et nœud d’un cluster Kubernetes génère constamment une activité réseau : ouverture des connexions, paquets transférés ou supprimés, requêtes DNS résolution ou échec. Comprendre que l’activité est essentielle pour le débogage, la planification de la capacité et maintenir la bonne santé des services. Toutefois, la plupart des configurations de surveillance sont insuffisantes de deux manières :

• Pas assez de visibilité. Les agrégats au niveau du nœud vous indiquent un problème, mais pas où. Sans répartitions au niveau du pod qui incluent le contexte source et de destination, l’isolation d’une charge de travail défaillante signifie deviner.
• Trop de données à grande échelle. Un cluster exécutant des centaines de microservices peut produire des milliers de séries chronologiques de métriques par nœud. La collecte de tous les éléments entraîne des coûts de stockage et ralentit les tableaux de bord.

Métriques réseau de conteneurs dans Advanced Container Networking Services pour Azure Kubernetes Service (AKS) aborde les deux. La fonctionnalité collecte les métriques réseau au niveau du nœud et du pod au niveau des plans de données Cilium et non-Cilium pris en charge, sur Linux et Windows.

Sur les clusters Cilium, vous pouvez aller plus loin avec le filtrage au niveau source, ce qui vous permet de sélectionner exactement quels espaces de noms, charges de travail et types de métriques sont collectés avant que les données quittent le nœud.

Le filtrage des métriques des conteneurs est une mesure de pré-ingestion pour les données d’observabilité. Au lieu de collecter chaque métrique disponible et le filtrage plus loin dans les tableaux de bord ou les requêtes, vous définissez ce qu’il faut collecter à la source. Cela permet de conserver des métriques à valeur élevée pour les charges de travail qui vous intéressent et évite d’ingérer des séries chronologiques à faible valeur ou bruyante.

Résultat : observabilité réseau actionnable sur n’importe quel plan de données pris en charge, avec filtrage facultatif économique sur Cilium.

Les métriques réseau de conteneurs vous offrent une visibilité approfondie au niveau de la charge de travail pour la résolution des problèmes et la planification, tandis que le filtrage au niveau source sur Cilium permet de maintenir les coûts d’observation proportionnels aux charges de travail critiques pour l’entreprise.

Collection et filtrage en un clin d’œil

Utilisez ce tableau pour comprendre rapidement où la collection étendue est disponible et où le filtrage affiné est disponible :

Principaux avantages

• Granularité au niveau du nœud et du pod. Suivez le volume du trafic, les taux de chute et les états de connexion au niveau du nœud pour l’intégrité de l’infrastructure. Explorez les pods individuels avec des étiquettes source et de destination pour identifier la charge de travail exacte à l’origine d’un problème.

• Résolution des problèmes plus rapides. Lorsqu’un service commence à supprimer des paquets ou des requêtes DNS échouent, les métriques au niveau du pod vous permettent d’isoler le problème en un pod, un espace de noms ou un protocole spécifique en secondes, et non en heures.

• Visualisation flexible. Stockez les métriques dans Azure Prometheus managé et visualisez dans Azure Managed Grafana (complètement managé) ou apportez votre propre infrastructure Prometheus et Grafana.

• Scalable par conception. Le pipeline gère des clusters dynamiques volumineux avec des centaines de nœuds et des milliers de pods sans avoir à choisir entre une couverture complète et des volumes de données gérables.

• Observabilité ciblée (clusters Cilium). Sur les clusters Cilium, le filtrage au niveau source vous permet de définir les espaces de noms, les étiquettes de pod ou les types de métriques qui vous intéressent et de les collecter uniquement. Aucun rognage post-collecte n’est requis.

• Réduction des coûts d’ingestion des métriques (clusters Cilium). Étant donné que le filtrage se produit à la source de chaque nœud, les séries chronologiques métriques indésirables ne sont jamais collectées, transmises ou ingérées dans votre back-end Prometheus. Vous payez uniquement pour les métriques dont vous avez réellement besoin. Dans les grands clusters où la collecte non filtrée peut produire des milliers de séries chronologiques par nœud, le filtrage au niveau source peut réduire considérablement les coûts d'ingestion et de stockage de Prometheus géré par Azure.

Fonctionnement

La pile des agents sur chaque nœud dépend du plan de données, comme indiqué dans le diagramme.

Les nœuds Linux Cilium utilisent une pile eBPF en couches : les crochets de noyau eBPF capturent les données de trafic brutes, Cilium les traite et Hubble l’expose en tant que métriques au format Prometheus. Étant donné que Hubble se trouve entre le nœud et le point de terminaison de collecte, le filtrage au niveau source s’effectue à cette couche : vous choisissez quels espaces de noms, étiquettes de pod et types de métriques sont exportés avant que les données ne quittent le nœud.

Les nœuds Linux non-Cilium utilisent des crochets du noyau eBPF qui alimentent Microsoft Retina, avec une couche Hubble au-dessus pour l'inspection des flux. Microsoft Retina gère la collecte des métriques et exporte les métriques au niveau du nœud et du pod au format Prometheus.

À partir de tous les chemins, les métriques sont récupérées au format Prometheus et ingérées dans Azure Prometheus managé ou votre propre back-end Prometheus, puis visualisées dans Azure Managed Grafana ou votre propre pile Grafana.

Pour commencer, configurez les métriques du réseau de conteneurs, puis configurez le filtrage des métriques réseau de conteneur pour les clusters Cilium.

Quand utiliser des métriques réseau de conteneur

Les métriques réseau de conteneur sont conçues pour les équipes qui ont besoin de données réseau ciblées et exploitables plutôt que de données de télémétrie brutes. Les scénarios courants sont les suivants :

• Débogage d’une charge de travail spécifique. Utilisez des métriques au niveau du pod pour isoler les suppressions de paquets, les réinitialisations TCP ou les échecs DNS pour un service particulier. Sur les clusters Cilium, le filtrage peut limiter la collecte à cet espace de noms ou à cette étiquette de pod, ce qui permet de réduire le bruit à l'échelle du cluster.
• Surveillance des clusters multilocataires. Effectuez le suivi de l’intégrité du réseau par espace de noms afin que chaque équipe ait une visibilité sur ses propres modèles de trafic. Sur les clusters Cilium, le filtrage délimité conserve la collecte limitée aux espaces de noms spécifiques au locataire.
• Planification de la capacité. Effectuez le suivi des nombres d’octets transférés et supprimés par nœud pour identifier les liens saturés ou le positionnement de la charge de travail déséquilibrée.
• Surveillance de l’intégrité DNS. Mettre en évidence les échecs des requêtes DNS et les temps de résolution lents pour identifier les problèmes avant qu'ils ne se transforment en erreurs d'application.
• Réduction des coûts d’observabilité à grande échelle. Dans les grands clusters, la collection non filtrée peut générer des milliers de séries chronologiques par nœud. Sur les clusters Cilium, le filtrage au niveau source supprime les séries indésirables avant l’ingestion afin que les coûts restent alignés sur les charges de travail et les types de métriques que vous choisissez.

Comment choisir ce qu’il faut collecter (clusters Cilium)

Utilisez ce modèle de déploiement pour équilibrer la visibilité et le coût :

1. Commencez par une collection étendue dans un espace de noms hors production pour établir une base de référence.
2. Conservez les métriques de perte de paquets, de DNS et d’état TCP pour les espaces de noms critiques.
3. Étendue des métriques de flux à cardinalité élevée aux charges de travail critiques pour l’entreprise uniquement.
4. Passez en revue les tendances d’ingestion Prometheus et affinez les filtres hebdomadairement.

Cette approche vous aide à conserver des métriques de grande valeur tout en contrôlant la croissance et les coûts d'ingestion des séries temporelles.

Avant de passer en revue les tables de métriques

Gardez à l’esprit les points suivants :

• Les métriques au niveau du nœud sont disponibles dans les plans de données Cilium et non-Cilium pris en charge.
• Les métriques au niveau du pod sont disponibles sur Linux.
• Le filtrage au niveau source est disponible uniquement sur les clusters Cilium.
• Sur les clusters Cilium, les métriques DNS nécessitent une stratégie de réseau FQDN Cilium.

Informations de référence sur les métriques

Métriques au niveau du nœud

Les métriques au niveau du nœud fournissent des statistiques de trafic agrégées par nœud : paquets transférés et supprimés, nombres d’octets et états de connexion. Ces métriques sont stockées au format Prometheus et peuvent être visualisées dans Grafana.

Les métriques suivantes sont agrégées par nœud. Toutes les métriques incluent ces étiquettes :

• cluster
• instance (nom du nœud)

Métriques au niveau du pod (métriques Hubble)

Les métriques au niveau du pod incluent des informations sur les pods source et de destination. Vous pouvez donc identifier les problèmes réseau au niveau de la charge de travail individuelle. Ces métriques couvrent le volume du trafic, les paquets supprimés, les réinitialisations TCP et les flux de couche 4/couche 7.

Les métriques DNS (nombres de requêtes, codes de réponse et erreurs) sont collectées par défaut sur des plans de données autres que Cilium. Sur les plans de données Cilium, les métriques DNS nécessitent une stratégie réseau FQDN Cilium. Vous pouvez également résoudre les problèmes dns en temps réel à l’aide de l’interface CLI Hubble.

Le tableau suivant décrit les métriques agrégées par pod (les informations de nœud sont conservées).

Toutes les métriques incluent des étiquettes :

• cluster

• instance (nom du nœud)

• source ou destination

  • Pour le trafic sortant, une étiquette source indique l’espace de noms et le nom du pod source.

  • Pour le trafic entrant, une destination étiquette indique l’espace de noms et le nom du pod de destination.

Limitations

Plan de plateforme et de données :

• Les métriques au niveau des pods sont disponibles seulement sur Linux.
• Le plan de données Cilium est pris en charge à partir de Kubernetes version 1.29.
• Le filtrage des métriques au niveau source est disponible uniquement sur les clusters Cilium.
• Les étiquettes de métriques présentent des différences subtiles entre les clusters Cilium et non-Cilium.

Métriques DNS :

• Sur les clusters Cilium, les métriques DNS nécessitent une stratégie réseau de nom de domaine complet Cilium, ou vous pouvez utiliser l’interface CLI Hubble pour la résolution des problèmes DNS en temps réel.

Problèmes connus :

• Si un agent de nœud Hubble tombe en panne, le relais Hubble peut se bloquer, ce qui peut interrompre les sessions CLI Hubble.

Support de FIPS (uniquement pour les plans de données non-Cilium) :

• FIPS n’est pas disponible sur les nœuds Ubuntu 20.04 en raison des restrictions du noyau. Utilisez plutôt un pool de nœuds Linux Azure. Cette limitation ne s’applique pas aux plans de données Cilium. Pour connaître les mises à jour, consultez le suivi des problèmes AKS.

Échelle:

• Le service managé pour Prometheus dans Azure Monitor et Azure Managed Grafana impose des limitations de mise à l’échelle spécifiques au service. Pour plus d’informations, consultez l’article Supprimer les métriques Prometheus à grande échelle dans Azure Monitor.

Pricing

Pour plus d’informations sur la tarification, consultez Tarification des services avancés de mise en réseau de conteneurs.

Contenu connexe

• Configurer des métriques de réseau de conteneurs
• Configurer le filtrage des métriques réseau de conteneurs
• Services de mise en réseau avancés pour conteneurs AKS
• Observabilité du réseau de conteneurs dans Advanced Container Networking Services
• Sécurité du réseau de conteneurs dans Advanced Container Networking Services