Supervision Kubernetes
Observabilité complète pour vos clusters Kubernetes. Supervisez vos nœuds, pods, conteneurs et services avec découverte automatique, compatibilité Prometheus et alertes intelligentes.
Observabilité Kubernetes Complète
De la santé du cluster aux métriques individuelles des conteneurs, obtenez une visibilité complète sur votre environnement Kubernetes.
Niveau Cluster
Santé du control plane, latence de l'API server, performances etcd, métriques du scheduler
Niveau Nœud
CPU, mémoire, disque, réseau, statut kubelet, conditions des nœuds
Niveau Pod
Cycle de vie des pods, compteurs de redémarrage, requests vs limits, readiness
Niveau Conteneur
Throttling CPU, utilisation mémoire, événements OOM, états des conteneurs
Réseau
Endpoints de services, trafic ingress, résolution DNS, network policies
Stockage
Utilisation des PersistentVolumes, statut des claims, capacité des storage classes, santé des montages
Ce que nous supervisons
Control Plane
Supervisez le cœur de votre cluster Kubernetes pour la fiabilité et les performances.
- Latence des requêtes API Server
- Santé et latence etcd
- Profondeur de file du scheduler
- Métriques du controller manager
- Expiration des certificats
Nœuds et Kubelet
Suivez la santé des nœuds et les performances du kubelet dans votre cluster.
- CPU, mémoire, disque des nœuds
- Statut de santé du kubelet
- Conditions des nœuds (Ready, DiskPressure, etc.)
- Capacité et allocation des pods
- Métriques du container runtime
Pods et Conteneurs
Visibilité approfondie sur les performances des workloads et la consommation de ressources.
- Utilisation CPU et throttling
- Utilisation mémoire et OOM kills
- Compteurs de redémarrage et crash loops
- Requests vs limits des ressources
- États et événements des conteneurs
Services et Réseau
Supervisez les endpoints de services et la connectivité réseau.
- Santé des endpoints de services
- Trafic et latence Ingress
- Efficacité des network policies
- Temps de résolution DNS
- Métriques service mesh (Istio, Linkerd)
Ressources Workload
Suivez les Deployments, StatefulSets, DaemonSets et Jobs.
- Statut des replicas de deployment
- Progression des rolling updates
- Ordonnancement des StatefulSets
- Couverture des DaemonSets
- Complétion des Jobs et CronJobs
Stockage Persistant
Supervisez les PersistentVolumes et les performances de stockage.
- Statut de liaison PV/PVC
- Utilisation de la capacité de stockage
- Débit et latence I/O
- Provisionnement StorageClass
- Erreurs de montage de volumes
Fonctionnalités Natives Kubernetes
🔍 Découverte Automatique
Découvrez et supervisez automatiquement les pods, services et endpoints. Aucune configuration manuelle nécessaire lors de la mise à l'échelle des workloads.
📊 Compatible Prometheus
Support natif PromQL. Collectez les endpoints Prometheus existants. Utilisez vos recording rules et alertes existantes.
🏷️ Gestion des Labels
Filtrez et agrégez par labels et annotations Kubernetes. Groupez les métriques par namespace, deployment ou labels personnalisés.
📈 Optimisation des Ressources
Dimensionnez correctement les requests et limits des ressources selon l'utilisation réelle. Identifiez les workloads sur-provisionnés et sous-provisionnés.
🔔 Alertes Intelligentes
Alertes pré-configurées pour les problèmes K8s courants : CrashLoopBackOff, pods en attente, nœud NotReady, expiration de certificat.
🌐 Multi-Cluster
Supervisez plusieurs clusters Kubernetes depuis un tableau de bord unique. Comparez les performances entre environnements.
📦 Déploiement Helm
Déployez l'agent Bleemeo avec un seul chart Helm. Prêt pour GitOps avec options de personnalisation complètes.
🔗 OpenTelemetry
Ingérez métriques et logs via OpenTelemetry. Corrélez les métriques d'infrastructure avec les données applicatives.
Installation Rapide avec Helm
Ajouter le dépôt Helm Bleemeo
Ajoutez le dépôt officiel de charts Helm Bleemeo à votre installation Helm.
helm repo add bleemeo-agent https://packages.bleemeo.com/bleemeo-agent/helm-charts
helm repo updateInstaller l'agent
Déployez l'agent Glouton en tant que DaemonSet avec vos identifiants de compte.
helm upgrade --install glouton bleemeo-agent/glouton \
--set account_id="your_account_id" \
--set registration_key="your_registration_key" \
--set config.kubernetes.clustername="my_k8s_cluster_name" \
--set namespace="default"Visualisez votre cluster
Les nœuds, pods et services apparaissent automatiquement dans votre tableau de bord Bleemeo en quelques secondes.
Déploiement DaemonSet
Glouton se déploie en tant que DaemonSet, plaçant automatiquement un pod agent sur chaque nœud de votre cluster — y compris les nœuds ajoutés par les autoscalers.
- Un agent par nœud, toujours
- Tolerations pour tous types de nœuds
- Couverture compatible autoscaler
- Chart Helm prêt pour GitOps
Architecture de l'agent DaemonSet
Un pod Glouton par nœud assure une couverture complète du cluster, de la santé du control plane aux métriques individuelles des conteneurs.
Modèle de déploiement DaemonSet
Glouton se déploie en tant que DaemonSet via Helm, plaçant exactement un pod agent sur chaque nœud de votre cluster. Le chart Helm inclut des tolerations pour tous les types de nœuds standard — nœuds GPU, nœuds système et nœuds gérés par autoscaler reçoivent tous un agent automatiquement. Seules trois variables d'environnement sont requises : GLOUTON_ACCOUNT_ID, GLOUTON_REGISTRATION_KEY et GLOUTON_KUBERNETES_CLUSTERNAME. Le pod agent demande un minimum de ressources (moins de 100 Mo de mémoire) et ne concurrence pas vos workloads de production.
Annotations de pods pour un contrôle précis
Les annotations Kubernetes sur vos pods contrôlent la façon dont Glouton interagit avec chaque workload. Définissez glouton.enable: "false" pour exclure un pod de la supervision. Utilisez glouton.check.ignore.port.* pour ignorer les vérifications de santé sur des ports spécifiques (utile pour les conteneurs sidecar ou les ports de débogage). Ajoutez les annotations Prometheus standard (prometheus.io/scrape: "true", prometheus.io/port, prometheus.io/path) pour exposer les métriques applicatives que Glouton collectera et transmettra à Bleemeo Cloud aux côtés des métriques d'infrastructure.
Métriques Kubernetes complètes
Au-delà des simples compteurs de pods et de nœuds, Glouton collecte des métriques Kubernetes approfondies : comptage de pods par état (Running, Pending, Failed, Succeeded), compteurs de redémarrage par conteneur, utilisation CPU et mémoire comparée aux requests et limits, comptage de nœuds et de namespaces, dates d'expiration des certificats CA et des certificats de nœuds, et indicateurs de santé API server et kubelet. Toutes les métriques sont étiquetées avec le namespace, le type de propriétaire (Deployment, DaemonSet, StatefulSet) et le nom du propriétaire pour un filtrage et une agrégation puissants dans les tableaux de bord.
Personnalisation par ConfigMap
Surchargez les paramètres par défaut de Glouton par cluster en utilisant une ConfigMap Kubernetes. Excluez des namespaces entiers de la supervision (par ex. kube-system ou les namespaces de runners CI), ajustez les intervalles de collecte de métriques, ajoutez des labels personnalisés à toutes les métriques d'un cluster spécifique, ou configurez des cibles de scrape Prometheus supplémentaires. L'approche ConfigMap s'intègre naturellement aux workflows GitOps — stockez votre configuration de supervision aux côtés de vos manifests applicatifs et laissez ArgoCD ou Flux la gérer de façon déclarative.
Alertes Kubernetes Pré-Configurées
Soyez notifié des problèmes Kubernetes courants avant qu'ils n'impactent vos utilisateurs.
Problèmes de Pods
- CrashLoopBackOff détecté
- Pod bloqué en Pending
- Nombre élevé de redémarrages
- Conteneurs OOMKilled
Problèmes de Nœuds
- Nœud NotReady
- Pression CPU/mémoire élevée
- Espace disque faible
- Trop de pods planifiés
Problèmes de Cluster
- Erreurs API server
- Latence etcd élevée
- Certificat expirant
- PVC en attente
Problèmes de Workload
- Replicas de deployment indisponibles
- StatefulSet non prêt
- Job échoué
- HPA au maximum de replicas
Compatible avec votre stack
Pourquoi Bleemeo pour Kubernetes ?
Visibilité Temps Réel
Voyez la création des pods, les événements de mise à l'échelle et les échecs en temps réel. Aucun délai dans la collecte des métriques.
Optimisation des Coûts
Identifiez le gaspillage de ressources et dimensionnez correctement vos workloads. Réduisez vos dépenses cloud sans impacter les performances.
Agent Léger
Glouton utilise un minimum de ressources. Moins de 100 Mo de mémoire par nœud. Ne concurrence pas vos workloads.
13 Mois de Rétention
Conservez les données historiques pour la planification de capacité et l'analyse des tendances. Comparez les performances dans le temps.
Qu'est-ce que la supervision Kubernetes ?
La supervision Kubernetes est la pratique consistant à collecter, analyser et alerter sur les métriques de chaque couche d'un environnement Kubernetes — du control plane du cluster jusqu'aux processus individuels des conteneurs. Contrairement à la supervision traditionnelle de serveurs, Kubernetes introduit des défis uniques : les workloads sont éphémères, les pods sont créés et détruits en permanence, et une seule application peut s'étendre sur des dizaines de replicas répartis sur plusieurs nœuds.
Une supervision Kubernetes efficace nécessite une visibilité sur quatre couches distinctes. La couche cluster surveille la santé du control plane, la latence de l'API server, les performances d'etcd et l'expiration des certificats. La couche nœud supervise le CPU, la mémoire, le disque et le statut kubelet sur chaque nœud worker. La couche workload suit les replicas de Deployment, l'ordonnancement des StatefulSets, la couverture des DaemonSets et la complétion des Jobs. Enfin, la couche pod et conteneur fournit l'utilisation des ressources, les compteurs de redémarrage, les événements OOM et le throttling CPU par conteneur.
Sans supervision multi-couche, les opérateurs Kubernetes sont contraints d'utiliser des commandes kubectl et l'inspection manuelle des logs pour diagnostiquer les problèmes — une approche réactive qui ne passe pas à l'échelle. Une solution de supervision adaptée comme Bleemeo collecte automatiquement les métriques des quatre couches via un déploiement DaemonSet, corrèle les données entre les couches et fournit des alertes pré-configurées pour les modes de défaillance courants comme CrashLoopBackOff, les pods en attente et l'expiration des certificats.
Métriques Kubernetes détaillées
Métriques de Pods
Suivez le comptage de pods par état (Running, Pending, Failed, Succeeded), les compteurs de redémarrage par conteneur, l'utilisation CPU et mémoire par rapport aux requests et limits, et l'âge des pods. Les labels incluent le namespace, le type de propriétaire (Deployment, DaemonSet, StatefulSet) et le nom du propriétaire pour une agrégation et un filtrage faciles.
Requests vs Limits de ressources
Comparez ce que les pods ont demandé (requests CPU et mémoire) avec ce qu'ils consomment réellement. Identifiez les workloads sur-provisionnés qui gaspillent des ressources et les sous-provisionnés qui risquent le throttling CPU ou l'OOMKill. Ces données sont essentielles pour dimensionner correctement les définitions de ressources dans vos manifests de déploiement.
Santé du Cluster
Supervisez le nombre total de nœuds, les nœuds Ready vs NotReady, le nombre de namespaces et le statut global du cluster. Suivez la disponibilité de l'API server, la latence d'etcd et la profondeur de file du scheduler. Ces métriques vous aident à évaluer la santé globale et la capacité de votre infrastructure Kubernetes.
Expiration des certificats
Suivez les dates d'expiration des certificats CA et des certificats de nœuds utilisés pour la communication interne de Kubernetes. Soyez alerté avant l'expiration des certificats — une cause fréquente de pannes soudaines de cluster qui est entièrement évitable avec une supervision automatisée.
Kubelet et conditions des nœuds
Supervisez le statut de santé du kubelet sur chaque nœud, les conditions des nœuds (Ready, DiskPressure, MemoryPressure, PIDPressure) et la santé du container runtime. Détectez les nœuds dégradés avant qu'ils ne commencent à évincer des pods ou ne deviennent NotReady.
Réseau et Ingress
Suivez les octets réseau reçus et transmis par pod, les paquets perdus et les compteurs d'erreurs. Supervisez les taux de requêtes du contrôleur Ingress, les latences de réponse et les ratios d'erreurs HTTP. Corrélez les métriques réseau avec les redémarrages de pods ou la dégradation de service pour identifier les problèmes de connectivité, les échecs de résolution DNS ou les network policies mal configurées.
Cas d'utilisation
Dépannage des échecs de pods
Quand un pod entre en CrashLoopBackOff, vous devez savoir pourquoi immédiatement. Bleemeo montre le compteur de redémarrage, le dernier code de sortie, les logs du conteneur et les métriques corrélées au niveau du nœud. Déterminez si le crash est causé par des erreurs applicatives, des OOM kills ou une pression de ressources du nœud sous-jacent — le tout depuis un seul tableau de bord.
Dimensionnement des workloads
Des requests de ressources sur-provisionnées gaspillent la capacité du cluster et augmentent les coûts cloud. Des requests sous-provisionnées causent du throttling et des OOM kills. Utilisez les métriques de requests vs utilisation réelle de Bleemeo dans le temps pour identifier les requests CPU et mémoire optimales pour chaque workload, réduisant le gaspillage tout en prévenant la contention de ressources.
Planification de capacité
Suivez les tendances d'utilisation des ressources du cluster sur des semaines et des mois. Identifiez quand les nœuds approchent des limites de capacité et planifiez les événements de mise à l'échelle avant que les pods ne se retrouvent en attente par manque de ressources. Utilisez 13 mois de données historiques pour prévoir les schémas saisonniers et budgéter la croissance de l'infrastructure.
Gestion multi-cluster
Supervisez vos clusters de développement, staging et production depuis un seul tableau de bord. Comparez l'utilisation des ressources entre environnements, détectez les dérives de configuration entre clusters et vérifiez que les clusters de staging reflètent le dimensionnement de production. Chaque cluster est identifié par son nom configuré pour un filtrage facile.
Validation de déploiement GitOps
Après un déploiement Flux ou ArgoCD, supervisez le déploiement en temps réel. Suivez la création de nouveaux pods, la terminaison des anciens pods et la disponibilité des replicas pendant les rolling updates. Détectez les déploiements échoués (rollouts bloqués, crash loops dans les nouvelles versions) et corrélez le timing de déploiement avec les changements de métriques pour valider que les releases fonctionnent comme prévu.
Optimisation des coûts et refacturation
Analysez la consommation de ressources par namespace pour allouer les coûts d'infrastructure aux équipes ou projets. Identifiez les namespaces avec une utilisation CPU et mémoire constamment faible qui sont sur-provisionnés. Utilisez les données d'utilisation historiques pour dimensionner correctement les pools de nœuds du cluster, basculer vers des instances spot ou préemptibles pour les workloads tolérants, et réduire les dépenses globales d'infrastructure Kubernetes.
Bonnes pratiques de supervision Kubernetes
Déployer en DaemonSet
Exécutez l'agent de supervision en tant que DaemonSet pour que chaque nœud reçoive automatiquement un pod agent — y compris les nœuds ajoutés par les autoscalers. Cela garantit une couverture complète du cluster sans intervention manuelle. Le chart Helm de Bleemeo gère cela par défaut, incluant les tolerations et limites de ressources appropriées.
Utiliser les annotations Prometheus pour les métriques personnalisées
Ajoutez prometheus.io/scrape: "true" aux annotations de vos pods pour exposer les métriques applicatives au format Prometheus. L'agent de Bleemeo découvre automatiquement ces endpoints et envoie les métriques vers le cloud. C'est l'approche standard Kubernetes-native pour les métriques d'application personnalisées sans nécessiter de configuration supplémentaire.
Toujours définir les requests et limits de ressources
Les pods sans requests de ressources ne peuvent pas être correctement dimensionnés car il n'y a pas de base de comparaison. Définissez toujours les requests CPU et mémoire dans vos manifests de déploiement. Bleemeo compare ensuite l'utilisation réelle aux ressources demandées, permettant des décisions de dimensionnement basées sur les données qui réduisent le gaspillage et préviennent la contention de ressources.
Surveiller l'expiration des certificats
Kubernetes utilise des certificats TLS pour la communication interne entre l'API server, le kubelet et etcd. Des certificats expirés causent une panne soudaine et totale du cluster. Bleemeo suit les dates d'expiration des certificats et vous alerte avant leur expiration, vous donnant le temps de renouveler les certificats de manière proactive au lieu de découvrir le problème pendant une panne.
Corréler les métriques avec les logs des conteneurs
Un compteur de redémarrage de pod qui augmente vous dit que quelque chose ne va pas. Les logs du conteneur vous disent exactement quoi. Activez la collecte de logs en parallèle des métriques pour l'analyse de cause racine la plus rapide. L'agent de Bleemeo collecte les deux depuis le même DaemonSet, et la plateforme cloud les affiche ensemble, liés par le nom du pod et l'horodatage.
Vous voulez aller plus loin ?
Lire la documentationQuestions fréquemment posées
Tout ce que vous devez savoir sur la supervision Kubernetes de Bleemeo
Comment déployer Bleemeo dans mon cluster Kubernetes ?
Bleemeo se déploie via un chart Helm en tant que DaemonSet, plaçant un agent Glouton sur chaque nœud. Ajoutez simplement le dépôt Helm Bleemeo, puis exécutez helm upgrade --install avec vos identifiants de compte et le nom du cluster. L'agent découvre automatiquement tous les pods et services. Vous pouvez aussi déployer avec des manifests kubectl standard. Les outils GitOps comme ArgoCD et Flux sont entièrement supportés.
Quelles métriques Kubernetes Bleemeo collecte-t-il ?
Bleemeo collecte des métriques complètes incluant : Métriques de pods (compteurs par état, compteurs de redémarrage, utilisation CPU/mémoire vs requests/limits), Métriques de nœuds (CPU, mémoire, disque, réseau, statut kubelet), Métriques de cluster (nombre de nœuds, nombre de namespaces, statut API), et Expiration des certificats (CA et certificats de nœuds). Les métriques sont étiquetées par namespace, type de propriétaire (Deployment, DaemonSet) et nom de propriétaire pour un filtrage facile.
Bleemeo découvre-t-il automatiquement les services dans mes pods ?
Oui, la découverte automatique de services est une fonctionnalité centrale. L'agent Bleemeo détecte tous les services en cours d'exécution dans vos pods (bases de données, serveurs web, files d'attente, etc.) et commence à les surveiller sans configuration manuelle. Il reconnaît plus de 100 services nativement. Lorsque les pods montent ou descendent en charge, la supervision suit automatiquement - aucune reconfiguration nécessaire pour les workloads éphémères.
Puis-je collecter les métriques Prometheus de mes applications ?
Oui, Bleemeo supporte la collecte de métriques style Prometheus via les annotations de pods. Ajoutez prometheus.io/scrape: "true" à vos pods, et optionnellement spécifiez prometheus.io/path et prometheus.io/port pour les endpoints de métriques personnalisés. L'agent découvre et collecte automatiquement ces endpoints. Vous pouvez également utiliser PromQL pour interroger les métriques dans vos tableaux de bord.
Quels sont les besoins en ressources de l'agent ?
L'agent Glouton est conçu pour être léger. Il utilise généralement moins de 100 Mo de mémoire et un minimum de CPU par nœud. L'agent ne concurrence pas vos workloads de production pour les ressources. Les requests et limits de ressources peuvent être personnalisés dans les valeurs Helm si nécessaire. L'agent est optimisé pour les environnements à haute densité avec de nombreux pods par nœud.
Quelles distributions Kubernetes sont supportées ?
Bleemeo fonctionne avec toutes les principales distributions Kubernetes : Services managés (EKS, GKE, AKS, DigitalOcean Kubernetes), Auto-hébergé (kubeadm, k3s, k0s, microk8s) et Distributions entreprise (OpenShift, Rancher, Tanzu). Nous supportons Kubernetes 1.19 et ultérieur. L'agent s'adapte aux différents runtimes de conteneurs incluant containerd, CRI-O et Docker.
Puis-je surveiller plusieurs clusters Kubernetes ?
Oui, Bleemeo supporte la surveillance multi-cluster. Chaque cluster apparaît comme une entité séparée dans votre tableau de bord avec son propre nom (configuré via config.kubernetes.clustername). Vous pouvez visualiser tous les clusters dans un tableau de bord unifié, comparer les métriques entre clusters et explorer les détails de chaque cluster. C'est idéal pour gérer les environnements de développement, staging et production.
Quelles alertes sont pré-configurées pour Kubernetes ?
Bleemeo inclut des alertes pré-construites pour les problèmes Kubernetes courants : Problèmes de pods (CrashLoopBackOff, pods en attente, nombre élevé de redémarrages, OOMKilled), Problèmes de nœuds (NotReady, pression disque/mémoire), Problèmes de cluster (erreurs API server, expiration de certificat) et Problèmes de workloads (replicas de deployment indisponibles, jobs échoués). Vous pouvez personnaliser les seuils ou créer des alertes supplémentaires.
Comment suivre les requests de ressources vs l'utilisation réelle ?
Bleemeo collecte à la fois les requests/limits de ressources et l'utilisation réelle pour le CPU et la mémoire. Les tableaux de bord montrent la comparaison entre ce que les pods ont demandé et ce qu'ils utilisent réellement, vous aidant à identifier les workloads sur-provisionnés (gaspillage de ressources) et sous-provisionnés (à risque de throttling ou OOM). Cela permet un dimensionnement optimal de vos workloads.
Bleemeo surveille-t-il les logs des conteneurs ?
Oui, avec la collecte de logs activée, Glouton capture automatiquement les logs de tous les conteneurs de votre cluster Kubernetes. Les logs sont collectés depuis stdout/stderr des conteneurs sans configuration supplémentaire. Vous pouvez appliquer des parsers et filtres personnalisés via les annotations de pods (glouton.log_format, glouton.log_filter). Les logs peuvent être corrélés avec les métriques pour un dépannage complet.
Commencez à superviser vos clusters Kubernetes
Déploiement en quelques minutes. Obtenez une visibilité complète sur votre infrastructure K8s.