Monitoraggio di Kubernetes

A partire dalla versione 2.2.0, Checkmk supporta le seguenti distribuzioni e servizi Kubernetes:

Il nostro obiettivo è supportare ciascuna delle ultime 5 versioni (minori) rilasciate di Kubernetes. Supportiamo quindi anche le versioni di Kubernetes che sono già uscite dal ciclo di vita di Kubernetes (Vanilla). Soprattutto, garantiamo una collaborazione fluida con quei fornitori di cloud che offrono anche periodi di supporto più lunghi per i loro servizi Kubernetes. Subito dopo il rilascio di una nuova versione di Kubernetes, potrebbe volerci un po' di tempo — a seconda della portata delle nuove funzionalità e della tempistica — prima che sia pienamente supportata anche in Checkmk. Non appena Checkmk sarà in grado di funzionare senza intoppi con questa nuova versione, lo annunceremo in un Werk (come ad esempio Werk #14584).

Per un'introduzione al nuovo monitoraggio di Kubernetes, ti consigliamo i nostri due video Monitoraggio di Kubernetes con Checkmk e Rilevamento dei problemi e configurazione degli avvisi per i cluster Kubernetes.

Poiché i cluster Kubernetes possono subire rapidamente cambiamenti significativi in termini di numero e posizione dei singoli componenti, ti consigliamo di creare un'istanza separata per il monitoraggio del tuo ambiente Kubernetes. Puoi quindi effettuare la connessione di questa istanza al tuo sito centrale come di consueto tramite il monitoraggio distribuito.

Checkmk monitora i tuoi cluster Kubernetes in due modi:

L'agente speciale Kubernetes recupera semplicemente le informazioni di base tramite il server API del tuo cluster. Questo può già essere utilizzato per recuperare gli stati dei nodi e dei container. Anche la maggior parte dei metadati dei tuoi pod e dei tuoi deployments viene ottenuta in questo modo.

Per un monitoraggio completo, tuttavia, a questo punto manca ancora qualcosa. Domande come: quanto carico genera una particolare distribuzione sulla CPU, o quanta memoria sta attualmente utilizzando un DaemonSet, non possono trovare risposta in questo modo.

È qui che entrano in gioco il nostro Checkmk Node Collector e il nostro Checkmk Cluster Collector. Questi sono una parte indispensabile del monitoraggio di Kubernetes all’interno di Checkmk. Una parte non trascurabile di ciò che segue in questo articolo riguarda quindi anche l’installazione e la configurazione di questi strumenti. Inoltre, l’uso delle dashboard di Kubernetes nelle edizioni commerciali ha senso solo se i Node e Cluster Collector sono in grado di fornire dati sui carichi per queste.

Quando si effettua il monitoraggio dei pod e delle repliche nei tuoi cluster Kubernetes, a volte i cambiamenti di stato o i ritardi si verificano con maggiore frequenza. Per tenerne conto, i controlli relativi a determinati stati di questi oggetti modificano il loro stato in Checkmk solo dopo 10 minuti.

Il monitoraggio di Kubernetes in Checkmk è stato riscritto da zero. L'ambito dei dati che possono essere monitorati è cresciuto notevolmente. Poiché la base tecnica per il monitoraggio di Kubernetes in Checkmk 2.1.0 è fondamentalmente diversa, non è possibile trasferire o riscrivere i dati di monitoraggio precedenti dei tuoi oggetti Kubernetes.

L'installazione del monitoraggio di Kubernetes avviene con l'aiuto dello strumento helm. Helm è adatto anche agli utenti meno esperti e standardizza la gestione delle configurazioni. Helm è una sorta di gestore di pacchetti per Kubernetes. Se non stai ancora usando Helm, di solito puoi scaricarlo dal gestore di pacchetti della tua distribuzione Linux o dal sito web del progetto Helm.

Puoi usare Helm per includere i repository come fonti e aggiungere facilmente al tuo cluster gli Helm chart che questi contengono, proprio come si fa con i pacchetti. Per prima cosa, identifica il repository. Nell’esempio seguente, usiamo il nome checkmk-chart per facilitare l’accesso al repository in seguito. Ovviamente puoi anche usare qualsiasi altro nome a tua scelta:

Aggiorniamo i nostri Helm chart ogni volta che i nuovi sviluppi in Kubernetes lo richiedono. Vale quindi la pena controllare di tanto in tanto se nel repository sono disponibili nuove versioni. Se hai chiamato la tua copia locale del nostro repository checkmk-chart, come nel comando precedente, puoi usare il seguente comando per visualizzare tutte le versioni dei chart disponibili nel repository:

Se è disponibile una versione più recente, puoi aggiornare con helm repo update.

Poiché non possiamo sapere in anticipo come è strutturato il tuo cluster Kubernetes, abbiamo scelto la variante più sicura per l'avvio dei Cluster Collector: Per impostazione predefinita, non vengono fornite porte accessibili da remoto. Per poter accedere ai collector in un secondo momento, dovrai adattare queste impostazioni al tuo cluster specifico.

Di default supportiamo due percorsi di comunicazione: la query tramite Ingress e la query tramite NodePort. La configurazione di questi varierà a seconda della variante che supporti nel tuo cluster.

Per poter determinare autonomamente determinati parametri in tutte le configurazioni, devi includere un file di controllo, il cosiddetto values.yaml.

Ci sono due modi per creare un file values.yaml. Puoi estrarre il file fornito da noi nei Helm chart e modificarlo, oppure puoi semplicemente crearne una versione minimale da solo.

Ogni volta che vuoi distribuire le modifiche a questo file nel tuo cluster, puoi usare nuovamente il comando di installazione dell'Helm chart di cui parleremo più avanti in questo articolo.

Dopo aver personalizzato values.yaml o averne creato uno tuo, usa il seguente comando per effettuare l'installazione di tutti i componenti necessari nel tuo cluster in modo da poterlo monitorare in Checkmk:

Poiché questo comando non è intuitivo, di seguito forniamo una spiegazione delle singole opzioni:

Una volta eseguito il comando, il tuo cluster Kubernetes è pronto per il monitoraggio con Checkmk. Il cluster si occuperà ora autonomamente di garantire che i pod necessari e i container in essi contenuti siano in esecuzione e accessibili.

È consigliabile memorizzare la password (token) dell'account di servizio nell'archivio password di Checkmk. Questa è l'opzione più sicura, poiché ti permette di separare a livello organizzativo la conservazione e l'utilizzo della password. In alternativa, inserisci la password direttamente in chiaro durante la creazione della regola (vedi sotto). Per informazioni su come visualizzare la password richiesta, consulta l'output del Helm chart. Aggiungi la password all'archivio password di Checkmk con l'opzione `Setup > General > Passwords > Add password`, ad esempio con l'ID e il titolo `My Kubernetes Token`:

Affinché Checkmk si fidi dell'Autorità di Certificazione (CA) dell'account di servizio, devi memorizzare il certificato CA in Checkmk. Come visualizzare il certificato richiesto è indicato anche nell'output del grafico Helm chart. Copia tutto qui, comprese le righe BEGIN CERTIFICATE e END CERTIFICATE, e aggiungi il certificato nel menu di configurazione alla voce Setup > General > Global settings > Site management > Trusted certificate authorities for SSL:

Crea un nuovo host in Checkmk come al solito e chiamalo, ad esempio, mykubernetesclusterhost. Come suggeriscono il titolo e il nome dell'host, questo host viene utilizzato per la raccolta dei dati piggyback e anche per la mappatura di tutti i servizi e le metriche a livello di cluster. Poiché questo host riceve dati solo tramite il special agent, assicurati di impostare l'opzione IP address family su No IP nelle proprietà dell'host.

Per garantire la separazione tra gli oggetti di diversi cluster Kubernetes, può essere utile creare una cartella per ogni cluster tramite Setup > Hosts > Add folder, in cui la gestione dinamica degli host può creare automaticamente tutti gli host di un cluster. Tuttavia, la creazione o l'utilizzo di tale cartella è facoltativo.

Successivamente, configura una connessione nelle edizioni commerciali per i dati piggyback in entrata: con Setup > Hosts > Dynamic host management > Add connection. Inserisci prima un titolo e poi clicca su show more sotto Connection Properties.

Successivamente, clicca su "Add new element" e seleziona la cartella creata in precedenza sotto "Create hosts in".

Lascia gli attributi predefiniti sotto "Host attributes to set" così come sono. Questi assicurano che Checkmk si limiti a utilizzare i dati piggyback per gli host creati automaticamente e non tenti, ad esempio, di eseguire il ping o di raggiungerli tramite SNMP.

In un ambiente Kubernetes in cui gli oggetti monitorabili e monitorati vanno e vengono continuamente, si consiglia inoltre di attivare l'opzione "Automatically delete hosts without piggyback data". Cosa fa esattamente questa opzione e in quali circostanze gli host vengono effettivamente eliminati è spiegato nel capitolo "Eliminazione automatica degli host" nell'articolo sulla gestione dinamica degli host.

Ora inserisci l'host piggyback creato in precedenza in "Restrict source hosts" e attiva l'opzione "Discover services during creation".

La sezione "Connection Properties" di questa nuova connessione potrebbe quindi apparire così:

In Comunità Checkmk dovrai creare manualmente gli host per i dati piggyback accumulati. Poiché in un cluster Kubernetes è probabile che si verifichi un numero elevato di host piggyback, ti consigliamo di utilizzare il comando cmk-piggyback list orphans.

Per impostazione predefinita, Checkmk esegue la scoperta del servizio ogni due ore e visualizza il risultato di questa scoperta nel servizio Check_MK Discovery. Puoi trovare questa impostazione nel set di regole Periodic service discovery. Nel contesto di Kubernetes, ti consigliamo di creare una regola per tutti gli host con l'etichetta cmk/kubernetes:yes. Questa etichetta viene assegnata automaticamente da Checkmk a ogni host che rappresenta oggetti Kubernetes. Qui dovresti selezionare un intervallo più breve per la scoperta del servizio e attivare anche l'opzione "Automatically update service configuration". Le impostazioni nella schermata seguente sono solo esempi. Dovrai decidere cosa è più sensato per i tuoi cluster caso per caso.

Per limitare questa regola a tutti gli host del tuo cluster, basta inserire cmk/kubernetes:yes nel campo "Conditions" sotto "Host labels". Tuttavia, se vuoi creare regole individuali per più cluster, usa semplicemente l'etichetta specifica del cluster in questione. Queste etichette hanno sempre il formato cmk/kubernetes/cluster:mycluster.

Ora che tutti i prerequisiti sono stati creati nel cluster e in Checkmk, puoi dedicarti alla configurazione dell'special agent. Lo trovi all'indirizzo Setup > Agents > VM, cloud, container > Kubernetes. Crea una nuova regola con Add rule.

Prima di tutto, devi assegnare un nome al cluster da monitorare. Puoi scegliere questo nome liberamente. Viene utilizzato per dare un nome univoco a tutti gli oggetti provenienti da questo particolare cluster. Ad esempio, se qui inserisci mycluster, i nomi degli host di tutti i pod di questo cluster inizieranno in seguito con pod_mycluster. La parte successiva del nome host sarà quindi sempre lo space dei nomi in cui si trova questo oggetto Kubernetes. Il nome host di un pod potrebbe quindi essere, ad esempio, pod_mycluster_kube-system_svclb-traefik-8bgw7.

In Token, seleziona ora la voce creata in precedenza dall'archivio password di Checkmk.

In API server connection > Endpoint, Checkmk ti chiede ora di inserire l’URL (o l’indirizzo IP) tramite il quale è possibile accedere al tuo server API Kubernetes. Devi inserire la porta solo se il servizio non viene fornito tramite un host virtuale. Il modo più semplice per scoprire questo indirizzo — se non lo hai già a portata di mano — dipenderà dal tuo ambiente Kubernetes. Il seguente comando ti fornirà l'endpoint del server API nella riga server:

Tuttavia, l'output effettivo di kubectl config view varia notevolmente. Se qui nella riga server è specificata anche una porta, assicurati di includerla anche nella regola.

Se finora hai seguito queste istruzioni passo dopo passo e hai depositato il certificato CA del tuo cluster — come descritto sopra — in Checkmk, seleziona sotto SSL certificate verification la voce Verify the certificate.

Ora hai la possibilità di arricchire il monitoraggio del tuo cluster Kubernetes con i dati di utilizzo raccolti dal Checkmk Cluster Collector. Lo ripetiamo ancora una volta per sottolinearne l’importanza: la configurazione del Cluster Collector è assolutamente essenziale per un monitoraggio completo dei tuoi cluster. Solo così potrai ottenere dati importanti come l’utilizzo della CPU e della memoria e ricevere informazioni sui file system utilizzati dai singoli componenti.

Attiva quindi l'opzione "Enrich with usage data from Checkmk Cluster Collector" e specifica l'endpoint del NodePort o dell'Ingress. Come visualizzare nuovamente questo endpoint è indicato nell'output dell'Helm chart.

Con le opzioni "Collect information about…​" puoi ora selezionare quali oggetti all'interno del tuo cluster devono essere sottoposti a monitoraggio. La nostra preselezione copre gli oggetti più rilevanti. Se decidi di sottoporre a monitoraggio anche l'Pods of CronJobs, fai riferimento all'aiuto in linea su questo punto.

Con le due opzioni successive, puoi limitare ulteriormente gli oggetti da monitorare. Se ti interessano solo gli oggetti di determinati namespace, imposta questa opzione di conseguenza in Monitor namespaces. Qui puoi inserire i singoli namespace da monitorare oppure escludere esplicitamente singoli namespace dal monitoraggio.

Con l'opzione "Cluster resource aggregation" puoi specificare i nodi che non forniscono risorse per il carico di lavoro del tuo cluster. Questi nodi dovrebbero essere esclusi dal calcolo delle risorse disponibili, altrimenti c'è il rischio che i colli di bottiglia di capacità non vengano rilevati. Per impostazione predefinita, escludiamo quindi i nodi control-plane e infra dalla valutazione.

Come opzione finale, puoi importare le cosiddette annotazioni da Kubernetes. In Checkmk, queste annotazioni diventano etichette dell'host e possono quindi essere utilizzate come condizioni nelle regole. Puoi specificare quali annotazioni devono essere importate utilizzando espressioni regolari. Anche in questo caso, consulta l'aiuto in linea.

Nota: l'opzione "Import all valid annotations" è fornita qui solo per completezza. Non consigliamo di importare ciecamente tutte le annotazioni, poiché ciò può creare una montagna enorme di etichette inutili in Checkmk.

Importante: In "Conditions > Explicit hosts" devi ora inserire l'host creato in precedenza:

Quindi salva la regola ed esegui la scoperta del servizio su questo host. Qui vedrai immediatamente i primi servizi a livello di cluster:

Ora attiva tutte le modifiche che hai apportato e lascia che la gestione dinamica degli host faccia il lavoro per te. In questo modo verranno creati tutti gli host per i tuoi oggetti Kubernetes in breve tempo.

Le edizioni commerciali di Checkmk sono fornite con sei dashboard integrate per Kubernetes. Per poter utilizzare queste dashboard in modo pratico, è necessario installare e configurare il nostro Cluster Collector. Nello specifico, queste sei dashboard si chiamano:

Il punto di accesso è sempre la dashboard di Kubernetes, a cui puoi accedere tramite Monitor > Applications > Kubernetes:

Nella dashboard di Kubernetes, tutti i tuoi cluster Kubernetes sottoposti al monitoraggio saranno elencati sul lato sinistro. Questo elenco di cluster è anche il tuo punto di accesso per approfondire le dashboard di Kubernetes. Cliccando sul nome di un cluster verrai reindirizzato alla dashboard di Kubernetes Cluster del cluster selezionato. Nella dashboard di Kubernetes Cluster, cliccando sul nome corrispondente verrai reindirizzato alle altre dashboard dipendenti dal contesto:

Il monitoraggio Kubernetes di Checkmk supporta anche l'inventario HW/SW. Ad esempio, se clicchi sul nome principale del cluster (qui: mycluster) nella dashboard del cluster sopra riportata, verrai reindirizzato all'inventario del cluster.

Allo stesso modo, cioè tramite le box con i nomi primari degli oggetti, potrai accedere all’inventario del rispettivo oggetto anche nelle altre dashboard. L’esempio seguente mostra l’inventario HW/SW di un pod: