Monitoraggio Kubernetes
Osservabilità completa per i vostri cluster Kubernetes. Monitorate nodi, pod, container e servizi con discovery automatico, compatibilità Prometheus e alerting intelligente.
Osservabilità Full-Stack Kubernetes
Dalla salute del cluster alle metriche dei singoli container, ottenete visibilità completa sul vostro ambiente Kubernetes.
Livello Cluster
Salute del control plane, latenza API server, performance etcd, metriche scheduler
Livello Nodo
CPU, memoria, disco, rete, stato kubelet, condizioni dei nodi
Livello Pod
Ciclo di vita dei pod, conteggio riavvii, richieste risorse vs limiti, readiness
Livello Container
CPU throttling, utilizzo memoria, eventi OOM, stati dei container
Networking
Endpoint dei servizi, traffico ingress, risoluzione DNS, network policy
Storage
Utilizzo PersistentVolume, stato dei claim, capacità storage class, salute dei mount
Cosa Monitoriamo
Control Plane
Monitorate il cuore del vostro cluster Kubernetes per affidabilità e performance.
- Latenza richieste API Server
- Salute e latenza etcd
- Profondità coda Scheduler
- Metriche Controller manager
- Scadenza certificati
Nodi e Kubelet
Monitorate la salute dei nodi e le performance del kubelet in tutto il cluster.
- CPU, memoria, disco del nodo
- Stato di salute Kubelet
- Condizioni del nodo (Ready, DiskPressure, ecc.)
- Capacità e allocazione pod
- Metriche container runtime
Pod e Container
Visibilità approfondita sulle performance dei workload e il consumo di risorse.
- Utilizzo CPU e throttling
- Utilizzo memoria e OOM kill
- Conteggio riavvii e crash loop
- Richieste risorse vs limiti
- Stati ed eventi dei container
Servizi e Networking
Monitorate gli endpoint dei servizi e la connettività di rete.
- Salute endpoint servizi
- Traffico e latenza Ingress
- Efficacia network policy
- Tempi di risoluzione DNS
- Metriche service mesh (Istio, Linkerd)
Risorse Workload
Monitorate Deployment, StatefulSet, DaemonSet e Job.
- Stato repliche Deployment
- Progresso rolling update
- Ordinamento StatefulSet
- Copertura DaemonSet
- Completamento Job e CronJob
Storage Persistente
Monitorate PersistentVolume e performance dello storage.
- Stato binding PV/PVC
- Utilizzo capacità storage
- Throughput e latenza I/O
- Provisioning StorageClass
- Errori mount volume
Funzionalità Kubernetes-Native
🔍 Auto-Discovery
Scoprite e monitorate automaticamente pod, servizi ed endpoint. Nessuna configurazione manuale necessaria quando i workload scalano.
📊 Compatibile Prometheus
Supporto nativo PromQL. Scraping degli endpoint Prometheus esistenti. Usate le vostre recording rule e alert esistenti.
🏷️ Label-Aware
Filtrate e aggregate per label e annotation Kubernetes. Raggruppate le metriche per namespace, deployment o label personalizzate.
📈 Ottimizzazione Risorse
Dimensionate correttamente richieste e limiti delle risorse basandovi sull'utilizzo reale. Identificate workload sovra e sotto-dimensionati.
🔔 Alerting Intelligente
Alert preconfigurati per problemi comuni K8s: CrashLoopBackOff, pod pending, nodi NotReady, scadenza certificati.
🌐 Multi-Cluster
Monitorate più cluster Kubernetes da un'unica dashboard. Confrontate le performance tra ambienti diversi.
📦 Deploy con Helm
Distribuite l'agente Bleemeo con un singolo chart Helm. Pronto per GitOps con opzioni di personalizzazione complete.
🔗 OpenTelemetry
Ingerite metriche e log via OpenTelemetry. Correlate le metriche dell'infrastruttura con i dati applicativi.
Setup Rapido con Helm
Aggiungete il Repository Helm Bleemeo
Aggiungete il repository ufficiale del chart Helm Bleemeo alla vostra installazione Helm.
helm repo add bleemeo-agent https://packages.bleemeo.com/bleemeo-agent/helm-charts
helm repo updateInstallate l'Agente
Distribuite l'agente Glouton come DaemonSet con le credenziali del vostro account.
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"Visualizzate il Vostro Cluster
Nodi, pod e servizi appaiono automaticamente nella vostra dashboard Bleemeo in pochi secondi.
Deploy DaemonSet
Glouton si distribuisce come DaemonSet, posizionando automaticamente un pod agente su ogni nodo del vostro cluster, inclusi i nodi aggiunti dagli autoscaler.
- Un agente per nodo, sempre
- Toleration per tutti i tipi di nodo
- Copertura autoscaler-aware
- Chart Helm pronto per GitOps
Architettura Agente DaemonSet
Un pod Glouton per nodo garantisce una copertura completa del cluster, dalla salute del control plane alle metriche dei singoli container.
Modello di Deploy DaemonSet
Glouton si distribuisce come DaemonSet tramite Helm, posizionando esattamente un pod agente su ogni nodo del vostro cluster. Il chart Helm include toleration per tutti i tipi di nodo standard: nodi GPU, nodi di sistema e nodi gestiti dall'autoscaler ricevono tutti un agente automaticamente. Sono richieste solo tre variabili d'ambiente: GLOUTON_ACCOUNT_ID, GLOUTON_REGISTRATION_KEY e GLOUTON_KUBERNETES_CLUSTERNAME. Il pod agente richiede risorse minime (meno di 100 MB di memoria) e non compete con i vostri workload di produzione.
Annotation Pod per Controllo Granulare
Le annotation Kubernetes sui vostri pod controllano come Glouton interagisce con ogni workload. Impostate glouton.enable: "false" per escludere un pod dal monitoraggio completamente. Usate glouton.check.ignore.port.* per saltare i controlli di salute su porte specifiche (utile per container sidecar o porte di debug). Aggiungete le annotation Prometheus standard (prometheus.io/scrape: "true", prometheus.io/port, prometheus.io/path) per esporre metriche specifiche dell'applicazione che Glouton raccogliera e inviera a Bleemeo Cloud insieme alle metriche dell'infrastruttura.
Metriche Kubernetes Complete
Oltre ai semplici conteggi di pod e nodi, Glouton raccoglie metriche Kubernetes approfondite: conteggio pod per stato (Running, Pending, Failed, Succeeded), conteggio riavvii per container, utilizzo CPU e memoria confrontati con richieste e limiti, conteggio nodi e namespace, date di scadenza dei certificati per CA e certificati dei nodi, e indicatori di salute di API server e kubelet. Tutte le metriche sono etichettate con namespace, owner kind (Deployment, DaemonSet, StatefulSet) e owner name per un filtraggio e aggregazione potenti nelle dashboard.
Personalizzazione ConfigMap
Sovrascrivete i default di Glouton per cluster usando una ConfigMap Kubernetes. Escludete interi namespace dal monitoraggio (es. kube-system o namespace CI runner), regolate gli intervalli di scraping delle metriche, aggiungete label personalizzate a tutte le metriche di un cluster specifico, o configurate target Prometheus aggiuntivi. L'approccio ConfigMap si integra naturalmente con i workflow GitOps: archiviate la vostra configurazione di monitoraggio insieme ai manifest applicativi e lasciate che ArgoCD o Flux la gestiscano in modo dichiarativo.
Alert Kubernetes Preconfigurati
Ricevete notifiche sui problemi comuni di Kubernetes prima che impattino i vostri utenti.
Problemi Pod
- CrashLoopBackOff rilevato
- Pod bloccato in Pending
- Conteggio riavvii elevato
- Container OOMKilled
Problemi Nodo
- Nodo NotReady
- Pressione CPU/memoria elevata
- Spazio disco insufficiente
- Troppi pod schedulati
Problemi Cluster
- Errori API server
- Latenza etcd elevata
- Certificato in scadenza
- PVC pending
Problemi Workload
- Repliche Deployment non disponibili
- StatefulSet non pronto
- Job fallito
- HPA al massimo delle repliche
Funziona con il Vostro Stack
Perché Bleemeo per Kubernetes?
Visibilità in Tempo Reale
Visualizzate creazione pod, eventi di scaling e failure nel momento in cui accadono. Nessun ritardo nella raccolta delle metriche.
Ottimizzazione Costi
Identificate sprechi di risorse e dimensionate correttamente i vostri workload. Riducete la spesa cloud senza impattare le performance.
Agente Leggero
Glouton utilizza risorse minime. Meno di 100MB di memoria per nodo. Non compete con i vostri workload.
13 Mesi di Retention
Conservate i dati storici per capacity planning e analisi dei trend. Confrontate le performance nel tempo.
Cos'è il Monitoraggio Kubernetes?
Il monitoraggio Kubernetes è la pratica di raccogliere, analizzare e generare alert sulle metriche di ogni livello di un ambiente Kubernetes, dal control plane del cluster fino ai singoli processi dei container. A differenza del monitoraggio server tradizionale, Kubernetes introduce sfide uniche: i workload sono effimeri, i pod vengono creati e distrutti costantemente, e una singola applicazione può estendersi su decine di repliche distribuite su più nodi.
Un monitoraggio Kubernetes efficace richiede visibilità su quattro livelli distinti. Il livello cluster monitora la salute del control plane, la latenza dell'API server, le performance di etcd e la scadenza dei certificati. Il livello nodo monitora CPU, memoria, disco e stato del kubelet su ogni worker node. Il livello workload monitora le repliche dei Deployment, l'ordinamento degli StatefulSet, la copertura dei DaemonSet e il completamento dei Job. Infine, il livello pod e container fornisce utilizzo risorse, conteggio riavvii, eventi OOM e CPU throttling per container.
Senza monitoraggio multi-livello, gli operatori Kubernetes sono costretti a usare comandi kubectl e ispezione manuale dei log per diagnosticare i problemi, un approccio reattivo che non scala. Una soluzione di monitoraggio adeguata come Bleemeo raccoglie metriche da tutti e quattro i livelli automaticamente tramite deploy DaemonSet, correla i dati tra i livelli e fornisce alert preconfigurati per le modalità di failure comuni come CrashLoopBackOff, pod pending e scadenza certificati.
Metriche Kubernetes Dettagliate
Metriche Pod
Monitorate i conteggi pod per stato (Running, Pending, Failed, Succeeded), conteggio riavvii per container, utilizzo CPU e memoria rispetto a richieste e limiti, e eta dei pod. Le label includono namespace, owner kind (Deployment, DaemonSet, StatefulSet) e owner name per aggregazione e filtraggio semplici.
Richieste Risorse vs Limiti
Confrontate ciò che i pod hanno richiesto (richieste CPU e memoria) con ciò che consumano effettivamente. Identificate workload sovra-provisionati che sprecano risorse e quelli sotto-provisionati a rischio di CPU throttling o OOMKill. Questi dati sono essenziali per il right-sizing delle definizioni risorse nei vostri manifest di deployment.
Salute del Cluster
Monitorate il conteggio totale dei nodi, nodi Ready vs NotReady, conteggio namespace e stato complessivo del cluster. Monitorate la disponibilità dell'API server, la latenza etcd e la profondità della coda dello scheduler. Queste metriche vi aiutano a valutare la salute e la capacità complessiva della vostra infrastruttura Kubernetes.
Scadenza Certificati
Monitorate le date di scadenza dei certificati CA e dei certificati dei nodi utilizzati per la comunicazione interna di Kubernetes. Ricevete alert prima che i certificati scadano, una causa comune di failure improvvisi del cluster che è interamente prevenibile con il monitoraggio automatizzato.
Kubelet e Condizioni dei Nodi
Monitorate lo stato di salute del kubelet su ogni nodo, le condizioni dei nodi (Ready, DiskPressure, MemoryPressure, PIDPressure) e la salute del container runtime. Rilevate nodi degradati prima che inizino a evacuare pod o diventino NotReady.
Network & Ingress
Monitorate byte ricevuti e trasmessi per pod, pacchetti persi e conteggio errori. Monitorate le request rate del controller Ingress, le latenze di risposta e i rapporti di errore HTTP. Correlate le metriche di rete con i riavvii dei pod o il degrado dei servizi per identificare problemi di connettività, failure di risoluzione DNS o network policy mal configurate.
Casi d'Uso
Troubleshooting Failure dei Pod
Quando un pod entra in CrashLoopBackOff, dovete sapere il perché immediatamente. Bleemeo mostra il conteggio riavvii, l'ultimo codice di uscita, i log del container e le metriche correlate a livello di nodo. Determinate se il crash è causato da errori applicativi, OOM kill o pressione sulle risorse del nodo sottostante, tutto da un'unica dashboard.
Right-Sizing dei Workload
Richieste di risorse sovra-provvisionate sprecano capacità del cluster e aumentano i costi cloud. Richieste sotto-provvisionate causano throttling e OOM kill. Usate le metriche di Bleemeo sulle richieste risorse vs utilizzo effettivo nel tempo per identificare le richieste CPU e memoria ottimali per ogni workload, riducendo gli sprechi e prevenendo la contesa di risorse.
Capacity Planning
Monitorate i trend di utilizzo risorse del cluster su settimane e mesi. Identificate quando i nodi si avvicinano ai limiti di capacità e pianificate gli eventi di scaling prima che i pod restino in pending per risorse insufficienti. Usate 13 mesi di dati storici per prevedere pattern stagionali e pianificare il budget per la crescita dell'infrastruttura.
Gestione Multi-Cluster
Monitorate cluster di sviluppo, staging e produzione da un'unica dashboard. Confrontate l'utilizzo risorse tra ambienti, rilevate derive di configurazione tra cluster e assicuratevi che i cluster di staging rispecchino il dimensionamento della produzione. Ogni cluster e identificato dal nome configurato per un filtraggio semplice.
Validazione Deploy GitOps
Dopo un deploy con Flux o ArgoCD, monitorate il rollout in tempo reale. Monitorate la creazione dei nuovi pod, la terminazione dei vecchi pod e la disponibilità delle repliche durante i rolling update. Rilevate deploy falliti (rollout bloccati, crash loop nelle nuove versioni) e correlate la tempistica del deploy con le variazioni delle metriche per verificare che i rilasci funzionino come previsto.
Ottimizzazione Costi & Chargeback
Analizzate il consumo di risorse per namespace per allocare i costi dell'infrastruttura a team o progetti. Identificate namespace con utilizzo CPU e memoria costantemente basso che sono sovra-provisionati. Usate i dati storici di utilizzo per dimensionare correttamente i pool di nodi del cluster, passare a istanze spot o preemptible per workload tolleranti, e ridurre la spesa complessiva dell'infrastruttura Kubernetes.
Best Practice per il Monitoraggio Kubernetes
Deploy come DaemonSet
Eseguite l'agente di monitoraggio come DaemonSet in modo che ogni nodo riceva automaticamente un pod agente, inclusi i nodi aggiunti dagli autoscaler. Questo garantisce una copertura completa del cluster senza intervento manuale. Il chart Helm di Bleemeo gestisce questo per default, incluse le toleration appropriate e i limiti delle risorse.
Usate le Annotation Prometheus per Metriche Personalizzate
Aggiungete prometheus.io/scrape: "true" alle annotation dei vostri pod per esporre metriche specifiche dell'applicazione tramite il formato Prometheus. L'agente Bleemeo scopre questi endpoint automaticamente e invia le metriche al cloud. Questo e l'approccio Kubernetes-native standard per le metriche applicative personalizzate senza richiedere configurazione aggiuntiva.
Impostate Sempre Richieste e Limiti delle Risorse
I pod senza richieste di risorse non possono essere dimensionati correttamente perché non esiste una baseline con cui confrontarsi. Impostate sempre le richieste CPU e memoria nei vostri manifest di deployment. Bleemeo confronta poi l'utilizzo effettivo con le risorse richieste, permettendo decisioni di right-sizing basate sui dati che riducono gli sprechi e prevengono la contesa di risorse.
Monitorate la Scadenza dei Certificati
Kubernetes utilizza certificati TLS per la comunicazione interna tra API server, kubelet e etcd. Certificati scaduti causano failure totali e improvvisi del cluster. Bleemeo monitora le date di scadenza dei certificati e vi avvisa prima che scadano, dandovi il tempo di ruotare i certificati in modo proattivo invece di scoprire il problema durante un'interruzione.
Correlate Metriche con i Log dei Container
Un conteggio riavvii dei pod in aumento vi dice che qualcosa non va. I log dei container vi dicono esattamente cosa. Abilitate la raccolta log insieme alle metriche per l'analisi delle cause più rapida. L'agente Bleemeo raccoglie entrambi dallo stesso DaemonSet, e la piattaforma cloud li visualizza insieme, collegati per nome del pod e timestamp.
Volete approfondire?
Leggete la DocumentazioneDomande Frequenti
Tutto quello che dovete sapere sul monitoraggio Kubernetes di Bleemeo
Come faccio a deployare Bleemeo nel mio cluster Kubernetes?
Bleemeo si deploya tramite chart Helm come DaemonSet, posizionando un agente Glouton su ogni nodo. Basta aggiungere il repository Helm di Bleemeo, poi eseguire helm upgrade --install con le credenziali del vostro account e il nome del cluster. L'agente scopre automaticamente tutti i pod e i servizi. Potete anche deployare usando kubectl con i manifest che forniamo. Gli strumenti GitOps come ArgoCD e Flux sono pienamente supportati.
Quali metriche Kubernetes raccoglie Bleemeo?
Bleemeo raccoglie metriche complete incluse: Metriche pod (conteggi per stato, conteggi riavvii, uso CPU/memoria vs richieste/limiti), Metriche nodi (CPU, memoria, disco, rete, stato kubelet), Metriche cluster (conteggio nodi, conteggio namespace, stato API), e Scadenza certificati (certificati CA e nodi). Le metriche sono etichettate per namespace, owner kind (Deployment, DaemonSet), e owner name per un filtraggio semplice.
Bleemeo scopre automaticamente i servizi nei miei pod?
Sì, l'auto-discovery dei servizi è una funzionalità principale. L'agente Bleemeo rileva tutti i servizi in esecuzione nei vostri pod (database, web server, code messaggi, ecc.) e inizia a monitorarli senza configurazione manuale. Riconosce oltre 100 servizi out of the box. Man mano che i pod scalano su o giù, il monitoraggio segue automaticamente - nessuna riconfigurazione necessaria per workload effimeri.
Posso fare scraping delle metriche Prometheus dalle mie applicazioni?
Sì, Bleemeo supporta lo scraping stile Prometheus tramite annotation sui pod. Aggiungete prometheus.io/scrape: "true" ai vostri pod, e opzionalmente specificate prometheus.io/path e prometheus.io/port per endpoint metriche personalizzati. L'agente scopre e fa scraping automaticamente di questi endpoint. Potete anche usare PromQL per interrogare le metriche nelle vostre dashboard.
Quali sono i requisiti di risorse per l'agente?
L'agente Glouton è progettato per essere leggero. Tipicamente usa meno di 100MB di memoria e CPU minima per nodo. L'agente non compete con i vostri workload di produzione per le risorse. Le richieste e i limiti delle risorse possono essere personalizzati nei valori Helm se necessario. L'agente è ottimizzato per ambienti ad alta densità con molti pod per nodo.
Quali distribuzioni Kubernetes sono supportate?
Bleemeo funziona con tutte le principali distribuzioni Kubernetes: Servizi managed (EKS, GKE, AKS, DigitalOcean Kubernetes), Self-managed (kubeadm, k3s, k0s, microk8s), e Distribuzioni enterprise (OpenShift, Rancher, Tanzu). Supportiamo Kubernetes 1.19+. L'agente si adatta a diversi container runtime inclusi containerd, CRI-O e Docker.
Posso monitorare più cluster Kubernetes?
Sì, Bleemeo supporta il monitoraggio multi-cluster. Ogni cluster appare come entità separata nella vostra dashboard con il proprio nome (configurato tramite config.kubernetes.clustername). Potete visualizzare tutti i cluster in una dashboard unificata, confrontare le metriche tra cluster, e approfondire i dettagli dei singoli cluster. Questo è ideale per gestire ambienti di sviluppo, staging e produzione.
Quali alert sono preconfigurati per Kubernetes?
Bleemeo include alert preconfigurati per problemi comuni Kubernetes: Problemi pod (CrashLoopBackOff, pod pending, conteggi riavvii elevati, OOMKilled), Problemi nodo (NotReady, pressione disco/memoria), Problemi cluster (errori API server, certificati in scadenza), e Problemi workload (repliche deployment non disponibili, job falliti). Potete personalizzare le soglie o creare alert aggiuntivi.
Come faccio a monitorare le richieste risorse vs l'uso effettivo?
Bleemeo raccoglie sia le richieste/limiti delle risorse che l'uso effettivo per CPU e memoria. Le dashboard mostrano il confronto tra ciò che i pod hanno richiesto e ciò che stanno effettivamente usando, aiutandovi a identificare workload sovra-provisionati (che sprecano risorse) e sotto-provisionati (a rischio di throttling o OOM). Questo permette un right-sizing efficace dei vostri workload.
Bleemeo monitora i log dei container?
Sì, con la raccolta log abilitata, Glouton cattura automaticamente i log da tutti i container nel vostro cluster Kubernetes. I log vengono raccolti da stdout/stderr dei container senza configurazione aggiuntiva. Potete applicare parser e filtri personalizzati usando annotation sui pod (glouton.log_format, glouton.log_filter). I log possono essere correlati con le metriche per un troubleshooting completo.
Iniziate a Monitorare i Vostri Cluster Kubernetes
Deploy in pochi minuti. Ottenete visibilità completa sulla vostra infrastruttura K8s.