Ep. 27: Rilevamento dei problemi e configurazione degli avvisi per i cluster Kubernetes

Per caricare questo video di YouTube è necessario accettare i cookie pubblicitari.

[0:00:00]	In questo video vi mostreremo come rilevare i problemi nei vostri cluster Kubernetes e configurare gli avvisi.
[0:00:14]	Prima o poi in ogni cluster Kubernetes ci sono dei problemi, di prestazioni e di capacità.
[0:00:25]	Possono esservi carichi di lavoro che non funzionano come previsto. Per questo è necessario il monitoraggio.
[0:00:30]	In questo video vi mostrerò innanzitutto come si presenta il nuovo monitoraggio di Kubernetes, come si possono scoprire i problemi e risolveremo un problema che abbiamo trovato.
[0:00:40]	E poi vi mostrerò come configurare facilmente i vostri avvisi. Diamo ora un'occhiata.
[0:00:48]	Ok, iniziamo a dare un'occhiata alla dashboard di Kubernetes Cluster.
[0:00:53]	È il punto di accesso al monitoraggio di Kubernetes e fornisce una panoramica dello stato di salute del cluster.
[0:01:00]	Prima di passare agli avvisi veri e propri, cerchiamo di capire quanto sia effettivamente sano il mio cluster.
[0:01:05]	Nella parte destra posso vedere le risorse della CPU, della memoria e del Pod del mio cluster.
[0:01:14]	Posso vedere l'utilizzo effettivo della CPU, del cluster, del totale, quali sono le richieste, quali sono i limiti e quanto è effettivamente allocabile.
[0:01:27]	Sì, si può vedere anche nel tempo. Si può anche vedere l'intero utilizzo della memoria. E posso anche vedere qui, quanti pod sono effettivamente in esecuzione. Posso vedere che 3 sono in attesa, 1 è libero.
[0:01:44]	E vi è un totale di 51 che posso allocare in questo cluster, il che mi porta al primo avviso che vedo qui, che è questa grande cosa rossa qui, che mi dice, hey, c'è solo un pod libero nel mio cluster, che non è troppo grande.
[0:02:03]	Al di sotto di queste metriche di performance, posso vedere quali sono i problemi del mio cluster.
[0:02:09]	C'è una tabella di tutti i problemi del vostro cluster. Si può vedere che c'è solo un pod libero in tutto il cluster, un paio di nodi non hanno alcun pod libero.
[0:02:21]	Ho qui una distribuzione che sembra avere un paio di problemi e così via. Sulla parte sinistra, in alto, posso vedere alcune informazioni sullo stato, se ricevo effettivamente i dati, se l'API è sana.
[0:02:37]	Posso vedere lo stato di salute dei miei nodi. Anche qui non sembra molto buono e posso vedere sotto DaemonSets, StatefulSets e Deployments.
[0:02:44]	Quindi, si possono vedere i carichi di lavoro nel mio cluster. Posso vedere quanto viene consumata la memoria della CPU.
[0:02:52]	Per ogni carico di lavoro, posso vedere chi sta consumando molto. Quindi, questo deployment è quello che consuma di più nel mio cluster e ha anche un problema, sì.
[0:03:02]	Possiamo dare un'occhiata cliccando sul nome dell'installazione client, che ci condurrà alla dashboard dell'installazione client, molto semplice per capire cosa sta succedendo.
[0:03:14]	Abbiamo di nuovo alcune metriche sulle prestazioni, come l'utilizzo della CPU di questo specifico deployment e la somma di tutti i pod presenti.
[0:03:25]	Possiamo vedere anche i singoli pod qui a destra. Si può notare che c'è stato un calo un paio di istanti fa.
[0:03:32]	Possiamo vedere lo stesso per l'utilizzo della memoria, dove non c'è stato un calo. E poi, più in basso, possiamo vedere: "Ehi, ok, ci sono 5 pod in esecuzione, uno è in attesa".
[0:03:44]	Anche questo viene visualizzato, quindi ora possiamo capire perché prima mostrava CRIT. E vediamo che ci sono 5 repliche pronte e 1 '6'. E questo viene mostrato anche nei problemi di deployment.
[0:03:57]	Quindi, questi sono un paio di esempi di avvisi a scaffale forniti con Checkmk e non vogliamo solo vedere gli avvisi, ma anche vedere come si possono effettivamente risolvere. Cerchiamo quindi di capire qual è il problema.
[0:04:11]	A tale scopo, darò un'occhiata al pod effettivo. Posso passare attraverso la panoramica del pod e vedere: "Ehi, questa parte è rossa, non posso usarla per navigare verso l'erba", oppure posso usare il problema di distribuzione e dire "Ehi, questa parte è in sospeso".
[0:04:28]	Lasciate che ci dia un'occhiata e qui arrivo alla classica panoramica dei servizi di Checkmk per questo specifico oggetto, per questo host. E si può vedere di nuovo, ok, ecco lo stato. È in attesa da 1 ora e 49 minuti.
[0:04:41]	Posso vedere, ok, qualcosa non funziona e posso vedere qui nella condizione perché non funziona.
[0:04:48]	Si vede che non è programmato e non può essere programmato perché non ci sono nodi disponibili. Ci sono troppi pod e la CPU è insufficiente.
[0:04:58]	Qual è la soluzione? Si possono eliminare alcuni pod. Ma questo non risolverà il problema a lungo termine.
[0:05:04]	Credo che la soluzione reale sia aggiungere un altro nodo al vostro cluster, perché se non avete abbastanza CPU, la cosa più semplice è aggiungere un nodo, ed è quello che faremo ora.
[0:05:18]	Passerò alla console AWS o all'interfaccia utente del mio cluster. E modificherò il gruppo di nodi per aggiungere un altro nodo.
[0:05:33]	Salverò le modifiche e darò un'occhiata alla cronologia degli aggiornamenti. Pochi secondi fa, è in corso. Ci vorrà un po' di tempo. Tra un paio di minuti il problema sarà risolto e il cluster sarà un po' più sano.
[0:05:48]	Ok, siamo tornati. Possiamo vedere che il nodo è stato distribuito, almeno così pensa AWS. Diamo un'occhiata ai dati effettivi del nostro monitoraggio.
[0:06:02]	Torniamo al nostro deployment e possiamo già vedere che sembra aver funzionato. Ora abbiamo 6 pod in esecuzione.
[0:06:13]	Quindi, 6 desiderata e invece di 5, ora siamo a 6. Qui si può vedere ora, non c'è più nulla in sospeso, che è esattamente quello che volevamo. Non ci sono più problemi.
[0:06:26]	Andiamo ancora un po' più indietro nel nostro cluster. Possiamo vedere che ora abbiamo 4 nodi nel cluster e 13 pod.
[0:06:38]	13 pod liberi per poter eseguire altri carichi di lavoro sul nostro cluster. L'aggiunta del nodo ci ha aiutato a risolvere un paio di problemi nel nostro cluster. Possiamo vedere che il deployment non ha più problemi, va bene.
[0:06:55]	Ma si può ancora vedere che un paio di nodi hanno problemi. Alcuni dei nostri nodi non sembrano in buona salute. Diamo loro un'occhiata per avere una visione del monitoraggio dei nodi che viene fornito con il monitoraggio di Checkmk 2.1.
[0:07:11]	Ok, ecco la vista dei servizi dell'host. Come si può vedere, sono ancora presenti sulle risorse del pod. Questo è il punto critico, perché ci sono ancora 3 pod a 0.
[0:07:24]	Perché quello che è successo è che ovviamente il materiale arriva sul nuovo nodo, ma Kubernetes non sposta i carichi di lavoro da questo nodo ad altri nodi. Quindi, al momento, la situazione è piuttosto sbilanciata.
[0:07:37]	Questo è un problema che, se volete, potete risolvere. Non è necessario, ma ci dice qualcosa sull'equilibrio all'interno del cluster.
[0:07:47]	Oltre al servizio critico che vediamo, vediamo molti altri servizi che ci dicono molto sullo stato di salute di un nodo.
[0:07:55]	Diamo un'occhiata ai singoli servizi che vediamo qui per quel nodo.
[0:07:59]	La prima cosa che vediamo è una condizione e questa condizione proviene da Kubernetes, dall'API di Kubernetes. Kubernetes ritiene che questo nodo sia sano perché supera tutte le condizioni. Possiamo anche vedere quanti container sono in esecuzione su questo nodo.
[0:08:15]	Possiamo vedere il carico della CPU e possiamo anche vedere qualcosa come le risorse e l'utilizzo della CPU. Ci si potrebbe chiedere perché ci sono tre servizi che si occupano della CPU.
[0:08:26]	Il motivo è semplice: c'è la vista Kubernetes, che rappresenta le risorse della CPU, e c'è la vista del nodo vero e proprio.
[0:08:36]	Perché Kubernetes non sa nulla delle cose che girano al di fuori di Kubernetes sul nodo e potrebbero esserci cose in esecuzione su questo nodo che non dovrebbero essere nella best practice.
[0:08:46]	Ma potrebbero esserci cose in esecuzione sul nodo che consumano il carico della CPU ed è bene conoscere queste cose, perché se c'è qualche problema di prestazioni su quel nodo, potreste volerlo sapere.
[0:08:58]	Ecco perché forniamo un monitoraggio olistico sui nodi Kubernetes, in modo da poter scoprire anche i problemi che risiedono al di fuori di Kubernetes.
[0:09:06]	Per esempio, il vostro file system viene riempito da qualche applicazione vicina al cluster Kubernetes. Penso sia importante saperlo perché in questo caso Kubernetes non vi avvertirà, ma Checkmk può farlo.
[0:09:21]	È inoltre possibile visualizzare ulteriori informazioni sul tipo di nodo effettivo, sul sistema operativo in esecuzione, sul runtime del container e su alcune informazioni di contesto.
[0:09:30]	Si possono vedere ulteriori informazioni sulle prestazioni del kernel. Si può vedere se il kubelet è effettivamente in esecuzione, molto importante se il kubelet non è in esecuzione, allora il nodo non funzionerà affatto.
[0:09:42]	Per Kubernetes, è possibile vedere la memoria, molto simile alla CPU. Non è importante solo ciò che è in esecuzione all'interno del cluster Kubernetes, ma anche all'esterno. E si possono vedere altre informazioni sul nodo.
[0:09:58]	Come potete vedere, abbiamo un monitoraggio olistico per i vostri nodi che è molto importante perché tutti i carichi di lavoro nel vostro cluster Kubernetes sono in esecuzione sui nodi ed è molto importante essere in grado di avvisare su questo.
[0:10:11]	Passiamo ora agli avvisi, perché abbiamo visto che ci sono un paio di avvisi preconfigurati. Ma ci siamo concentrati solo sulla fornitura dei soli avvisi di cui potrete avere bisogno.
[0:10:22]	Ma potreste avere un vostro caso d'uso, potreste volere degli avvisi su cose specifiche. E possiamo farlo configurando i nostri avvisi. Facciamolo.
[0:10:31]	Per configurare un avviso da un servizio, basta andare nel menu hamburger, fare clic su Parametri per questo servizio e creare un avviso per le risorse della cpu.
[0:10:44]	Ora vediamo che c'è questa regola applicabile. Basta fare clic qui. Così arriviamo direttamente alla regola che ci interessa.
[0:10:53]	Creo una regola, una regola generica e, ad esempio, dico che voglio essere avvisato per i limiti di utilizzo.
[0:11:02]	Perché potrebbe accadere che i miei pod non vadano in throttling della CPU, cosa che accade se l'utilizzo dei limiti raggiunge il 100%.
[0:11:15]	Kubernetes inizierà a strozzare i pod e questo comporterà problemi di prestazioni per l'applicazione, quindi è meglio avere un avviso per questo. E si vuole essere avvisati un po' prima che ciò accada effettivamente, in modo da poter usare queste cose.
[0:11:30]	Ora definiamo per quali oggetti questo avviso deve essere valido. Possiamo usare le etichette. Le etichette sono molto potenti e Checkmk 2.1 è dotato di molte etichette predefinite per Kubernetes. Una di queste è tutto ciò che riguarda gli oggetti.
[0:11:51]	Quindi, ad esempio, voglio che questa regola sia applicabile solo ai pod. E non mi interessa che funzioni per tutte le distribuzioni o cose del genere, ho una distribuzione specifica che è molto importante per me.
[0:12:11]	E il deployment si chiama, diamo un'occhiata, so come si chiama. È php-apache.
[0:12:16]	Questo è il deployment. Voglio solo che questo avviso sia valido per i pod di questa distribuzione. Tutto qui. Ecco come posso configurare facilmente un avviso, ad esempio, per l'utilizzo del limite della CPU.
[0:12:32]	Salviamo e attiviamo le modifiche. Per vedere effettivamente questo avviso in azione, torniamo alla nostra dashboard.
[0:12:49]	Diamo un'occhiata alla dashboard di deployment. In questo momento siamo piuttosto lontani da un limite di utilizzo effettivo, come possiamo vedere qui.
[0:13:06]	È piuttosto lontano. Non riceviamo ancora un avviso. Quindi, quello che farò è aumentare il carico di lavoro di questo deployment.
[0:13:14]	Ok, per aumentare il carico di lavoro su questo deployment, ho una piccola applicazione fittizia qui.
[0:13:28]	Scaliamo questa applicazione. Si chiama infinite-calls. Ora aumenterò il carico di lavoro aggiungendo altri pod. Proviamo con 35.
[0:13:49]	Aspettiamo un po' finché non vengono generati tutti. A quel punto potremo vedere un avviso nel monitoraggio di Checkmk.
[0:14:00]	Ora siamo tornati alla nostra dashboard di deployment e possiamo già vedere il primo avviso, sì. Si può già vedere che 1 pod ha un utilizzo pari a 0,4.
[0:14:11]	E se diamo un'occhiata a questo, possiamo vedere che l'utilizzo del limite è all'85%. Abbiamo un limite di 0,5.
[0:14:19]	Possiamo dare un'occhiata in dettaglio alle metriche. Come potete vedere, i limiti sono la linea qui sopra, l'area verde è l'utilizzo. Abbiamo anche un grafico per l'utilizzo dei limiti, dove ora abbiamo il nostro monitoraggio.
[0:14:41]	Si può vedere immediatamente dove sono le nostre soglie per tutti gli avvisi. Abbiamo l'avviso all'80% e il critico al 90%.
[0:14:50]	E qui si può vedere che abbiamo già raggiunto l'80%, quindi sappiamo già che c'è un carico di lavoro notevole su quel singolo pod. Non siamo ancora al massimo. Non siamo ancora a 100, ma non siamo troppo lontani.
[0:15:05]	E per questo ora riceveremo un avviso sulla e-mail, o per esempio, sui canali slack, o tramite qualsiasi modo li abbiate configurati. Ecco quanto è facile impostare gli avvisi con il nuovo monitoraggio Kubernetes di Checkmk 2.1.
[0:15:18]	Spero che il video vi sia piaciuto e che vi divertiate a monitorare Kubernetes. Grazie per aver guardato, mettete mi piace e iscrivetevi.