 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introduzione
Kubernetes è da tempo lo strumento più utilizzato per l'orchestrazione dei container. Checkmk ti aiuta a monitorare i tuoi ambienti Kubernetes.
A partire da Checkmk 2.1.0, puoi usare Checkmk per monitorare i seguenti oggetti di Kubernetes:
Cluster
Nodi
Deployment
Pod
DaemonSet
StatefulSet
Rivendicazioni di volumi persistenti
Cronjob (a partire dalla versione 2.2.0)
Per un elenco completo di tutti i plug-in di controllo disponibili per il monitoraggio di Kubernetes, consulta il nostro Catalogo dei plug-in di controllo.
1.1. Distribuzioni e versioni supportate
A partire dalla versione 2.2.0, Checkmk supporta le seguenti distribuzioni e servizi Kubernetes:
Vanilla Kubernetes
Amazon Elastic Kubernetes Service (Amazon EKS)
Azure Kubernetes Service (AKS)
Google Kubernetes Engine (GKE) inclusa la modalità Autopilot
Tanzu Kubernetes (a partire da Checkmk 2.2.0p9)
Il nostro obiettivo è quello di supportare ognuna delle ultime 5 versioni (minori) di Kubernetes rilasciate. In questo modo supportiamo anche le versioni di Kubernetes che sono già uscite dal ciclo di vita di Kubernetes (Vanilla). Soprattutto, assicuriamo una collaborazione senza problemi con i cloud provider che offrono anche periodi di servizio 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 delle tempistiche - prima che sia pienamente supportata anche da Checkmk. Non appena Checkmk sarà in grado di funzionare senza problemi con questa nuova versione, lo annunceremo in un Werk (come il Werk #14584).
1.2. Come iniziare con il monitoraggio di Kubernetes
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 di Kubernetes.
1.3. Struttura dell'ambiente di monitoraggio
Dato che i cluster Kubernetes possono subire rapidamente grandi cambiamenti in termini di numero e posizione dei singoli componenti, ti consigliamo di creare un sito separato per il monitoraggio del tuo ambiente Kubernetes, che potrai poi collegare al tuo sito centrale come di consueto tramite il monitoraggio distribuito.
1.4. Il processo di monitoraggio di Kubernetes in Checkmk
Checkmk monitora i tuoi cluster Kubernetes in due modi:
Lo special agent di Kubernetes Cluster recupera semplicemente le informazioni di base attraverso il server API del tuo cluster, che può già essere utilizzato per recuperare gli stati dei nodi e dei container. Anche la maggior parte dei metadati dei pod e dei deployment si ottengono in questo modo.
Per un monitoraggio completo, tuttavia, manca ancora qualcosa: domande come il carico che un particolare deployment genera sulla CPU o la quantità di memoria che un DaemonSet sta utilizzando non possono trovare risposta in questo modo.
È qui che entrano in gioco il nostro Node Collector di Checkmk e il nostro Cluster Collector di Checkmk, che 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 dei dashboard di Kubernetes nelle edizioni commerciali ha senso solo se i Node Collector e i Cluster Collector possono fornire dati sui carichi.
1.5. Differenze rispetto ad altri monitoraggi di Checkmk
Quando si monitorano i pod e le repliche nei cluster Kubernetes, a volte i cambiamenti di stato o i ritardi si verificano molto più frequentemente. Per tenerne conto, i controlli di alcuni stati di questi oggetti cambiano il loro stato in Checkmk solo dopo 10 minuti.
1.6. Differenze rispetto al monitoraggio Kubernetes esistente
Il monitoraggio di Kubernetes in Checkmk è stato riscritto da zero e la portata dei dati che possono essere monitorati è cresciuta notevolmente. Poiché la base tecnica del monitoraggio di Kubernetes in Checkmk 2.1.0 è fondamentalmente diversa, non è possibile trasferire o riscrivere i dati di monitoraggio precedenti dei tuoi oggetti Kubernetes.
2. Creare i prerequisiti nel cluster
Per poter monitorare il tuo cluster Kubernetes in Checkmk, devi innanzitutto creare i prerequisiti nel tuo cluster. Innanzitutto, devi indicare al cluster quali pod/container distribuire e come configurarli.
2.1. Impostazione del repository Helm
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 usi ancora Helm, di solito lo puoi ottenere dal gestore di pacchetti della tua distribuzione Linux o dal sito web del progetto Helm.
Puoi usare Helm per includere i repository come sorgenti e aggiungere facilmente le Helm chart che contengono al tuo cluster come se fossero dei pacchetti. Prima di tutto, identifica il repository. Nell'esempio che segue, usiamo il nome checkmk-chart per rendere più facile l'accesso al repository in seguito. Naturalmente, puoi anche usare qualsiasi altro nome a tua scelta:
user@host:~$ helm repo add checkmk-chart https://checkmk.github.io/checkmk_kube_agentAggiorniamo i nostri grafici Helm chart ogni volta che i nuovi sviluppi di Kubernetes lo richiedono. Vale quindi la pena controllare di tanto in tanto se sono disponibili nuove versioni nel repository. Se hai chiamato la tua copia locale del repository checkmk-chart, come nel comando precedente, puoi usare il comando seguente per visualizzare tutte le versioni dei grafici disponibili nel repository:
user@host:~$ helm search repo checkmk-chart --versions
NAME CHART VERSION APP VERSION DESCRIPTION
checkmk-chart/checkmk 1.2.0 1.2.0 Helm chart for Checkmk - Your complete IT monit...
checkmk-chart/checkmk 1.1.0 1.1.0 Helm chart for Checkmk - Your complete IT monit...
checkmk-chart/checkmk 1.0.1 1.0.1 Helm chart for Checkmk - Your complete IT monit...
checkmk-chart/checkmk 1.0.0 1.0.0 Helm chart for Checkmk - Your complete IT monit...Se è disponibile una versione più recente, puoi aggiornarla con helm repo update.
2.2. Personalizzare la configurazione in base all'ambiente di configurazione
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 a cui si possa accedere da remoto. Per poter accedere ai provider in un secondo momento, dovrai adattare queste impostazioni al tuo cluster specifico.
Per impostazione predefinita, supportiamo due percorsi di comunicazione: la query via Ingress e la query via NodePort, la cui configurazione varia a seconda della variante supportata nel tuo cluster.
Per poter determinare autonomamente alcuni parametri in tutte le configurazioni, devi includere un file di controllo, il cosiddetto values.yaml.
Esistono due modi per creare un file di questo tipo values.yaml. Puoi estrarre il file fornito da noi nelle chart di Helm e modificarlo, oppure puoi semplicemente creare tu stesso una versione minima.
Ogni volta che vorrai distribuire le modifiche a questo file nel tuo cluster, potrai utilizzare il comando di installazione di Helm chart che tratteremo più avanti in questo articolo.
Creare il proprio values.yaml di base
Puoi creare un values.yaml in cui inserire solo i valori che vuoi modificare. Nel nostro Helm chart, ad esempio, il tipo di servizio del Cluster Collector è impostato di default su ClusterIP. Se ora vuoi cambiare solo il tipo di servizio in NodePort e la porta in 30035, è sufficiente creare un values.yaml come segue:
user@host:~$ echo 'clusterCollector: {service: {type: NodePort, nodePort: 30035}}' > values.yamlUn'attivazione di Ingress potrebbe avere questo aspetto:
user@host:~$ echo 'clusterCollector: {ingress: { enabled: true }}' > values.yamlEstrazione di values.yaml da Helm chart
L'intero values.yaml fornito da noi può essere facilmente estratto con il seguente comando:
user@host:~$ helm show values checkmk-chart/checkmk > values.yamlA questo punto puoi adattare il file così creato alle tue esigenze e passarlo a helm con il parametro -f values.yaml durante l'installazione o durante un successivo aggiornamento.
Provider di comunicazione via Ingress
Se utilizzi Ingress per controllare l'accesso ai tuoi servizi, modifica di conseguenza le parti già preparate in values.yaml. Per una panoramica migliore, nell'esempio abbreviato che segue viene mostrata solo la parte pertinente. Imposta il parametro enabled su true. Adatta i parametri rimanenti in base al tuo ambiente:
ingress:
enabled: true
className: ""
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
hosts:
- host: checkmk-cluster-collector.local
paths:
- path: /
pathType: Prefix
tls: []
# - secretName: chart-example-tls
# hosts:
# - chart-example.localFornire comunicazione tramite NodePort
Puoi anche fornire l'accesso ai servizi direttamente tramite una porta. Questo è necessario se non utilizzi Ingress. Nell'esempio seguente, viene mostrata solo la sezione pertinente. Imposta il valore type su NodePort e rimuovi il commento per il valore nodePort:
service:
# if required specify "NodePort" here to expose the cluster-collector via the "nodePort" specified below
type: NodePort
port: 8080
nodePort: 30035Configurare Cluster Collector per HTTPS
Se vuoi switchare la comunicazione con e tra i Cluster Collector in HTTPS, devi apportare delle modifiche anche al file values.yaml.
Di seguito è riportata la sezione di values.yaml che devi modificare per abilitare l'HTTPS:
tlsCommunication:
enabled: false
verifySsl: false
# clusterCollectorKey: |-
# -----BEGIN EC PRIVATE KEY-----
# XYZ
# -----END EC PRIVATE KEY-----
# clusterCollectorCert: |-
# -----BEGIN CERTIFICATE-----
# XYZ
# -----END CERTIFICATE-----
# checkmkCaCert: |-
# -----BEGIN CERTIFICATE-----
# XYZ
# -----END CERTIFICATE-----Nelle righe che iniziano con enabled o verifySsl, devi sostituire false con true. Poi, rimuovi i segni di hash prima delle tre sezioni clusterCollectorKey, clusterCollectorCert e checkmkCaCert e inserisci i dati corrispondenti dopo di esse. La tua organizzazione deve decidere se utilizzare certificati self-signed o se ottenere certificati da un'autorità di certificazione (CA).
I certificati devono soddisfare i seguenti requisiti:
Il certificato della CA deve contenere il nome host o il nome dell'Ingress come FQDN.
Per il certificato del server, l'FQDN deve corrispondere al seguente schema:
<service_name>.<namespace>.cluster.local.Nella sezione
[ v3_ext ]del file di configurazione per la generazione della richiesta di firma del certificato,subjectAltNamedeve corrispondere al seguente schema:subjectAltName: DNS:<service_name>.<namespace>.cluster.local, IP:<service ip>
Utilizzo del proprio account di servizio
Utilizzando le nostre Helm chart, nel tuo cluster verrà creato un account di servizio per impostazione predefinita. Se hai già un account di servizio adatto, è sufficiente aggiungerlo a values.yaml e sopprimere la creazione di un nuovo account.
serviceAccount:
create: false
name: "myserviceaccount"Prerequisito per il monitoraggio di GKE Autopilot
Se operi il tuo cluster GKE (Google Kubernetes Engine) in modalità Autopilot, è possibile monitorarlo anche con Checkmk, in quanto quest'ultimo è un cosiddetto partner Autopilot.
È sufficiente impostare var_run su readOnly nel file values.yaml:
volumeMountPermissions:
var_run:
readOnly: trueConfigurare il controller di ammissione di Pod Security
Se utilizzi gli standard di Pod Security nel tuo cluster, devi configurare il Cluster Collector di Checkmk in modo che abbia accesso illimitato al namespace corrispondente. Idealmente, crea un namespace con le seguenti specifiche:
apiVersion: v1
kind: Namespace
metadata:
name: checkmk-monitoring
labels:
pod-security.kubernetes.io/enforce: privileged
pod-security.kubernetes.io/enforce-version: latestPuoi creare il namespace eseguendo, ad es. kubectl apply -f namespace.yaml. Tieni presente che non dovrai utilizzare l'opzione --create-namespace quando eseguirai il comando helm upgrade in seguito.
Se il Cluster Collector è già in esecuzione o il namespace esiste già, puoi anche impostare le etichette di cui sopra con il seguente comando:
user@host:~$ kubectl label --overwrite ns checkmk-monitoring pod-security.kubernetes.io/enforce=privileged pod-security.kubernetes.io/enforce-version=latestPolicy di sicurezza dei pod e policy di rete
Le policy PodSecurityPolicy (PSP in breve) e NetworkPolicy sono incluse nella nostra Helm chart principalmente per motivi di compatibilità. Poiché le PSP sono state completamente rimosse da Kubernetes a partire da v1.25, le abbiamo disabilitate per impostazione predefinita a partire dalla versione 1.3.0 della nostra Helm chart.
La sezione corrispondente ha ora il seguente aspetto:
rbac:
pspEnabled: falseSe utilizzi ancora il PSP nel tuo cluster, è necessario impostare questa opzione su true nel file values.yaml:
rbac:
pspEnabled: trueSe in un secondo momento dovessimo scoprire che questa voce non viene processata correttamente anche se disabilitata, la rimuoveremo completamente.
Lo stesso vale per la NetworkPolicy: se la utilizzi nel tuo cluster, dovrai cambiare la posizione in values.yaml da enabled: false a enabled: true. In questo caso, fai riferimento alla seguente documentazione all'interno di values.yaml per configurare correttamente la NetworkPolicy.
## ref: https://kubernetes.io/docs/concepts/services-networking/network-policies/
networkPolicy:
# keep in mind: your cluster network plugin has to support NetworkPolicies, otherwise they won't have any effect
enabled: false
# specify ipBlock cidrs here to allow ingress to the cluster-collector
# this is required for the checkmk servers to be able to scrape data from checkmk, so include the resprective ip range(s) here
allowIngressFromCIDRs: []
# - 127.0.0.1/32 # e.g. Checkmk Server
# - 127.0.0.1/24 # e.g. Metallb speakers
# the cluster-collector needs to be able to contact the kube-apiserver
# you have three options here to choose from, depending on your cluster setup:
# 1) if your apiserver resides outside the cluster, resp. you have a kubernetes endpoint available (check via "kubectl -n default get ep kubernetes")
# we can make use of helm lookup to automatically inject the endpoint (cidr + port) here.
# This is the most comfortable one, just note that helm lookup won't work on a "helm template" or "helm diff" command.
# (see also: https://helm.sh/docs/chart_template_guide/functions_and_pipelines/#using-the-lookup-function)
# 2) similar to 1) you can also specify the "ipBlockCidr" directly. Make sure to disable "enableCidrLookup", and also fill the "port".
# 3) if the apiserver resides inside the cluster, disable "enableCidrLookup", unset "ipBlockCidr", and fill the "labelSelectors" section
# with the name of the namespace where the kube-apiserver is availabe, and the label key and label value that defines your kube-apiserver pod.
egressKubeApiserver:
enableCidrLookup: true
# ipBlockCidr: 172.31.0.3/32
# port: 6443
# labelSelectors:
# namespace: kube-system
# key: app
# value: kube-apiserver2.3. Installazione di Helm chart
Dopo aver personalizzato values.yaml o averne creati di propri, usa il seguente comando per installare tutti i componenti necessari nel tuo cluster per poterlo monitorare in Checkmk:
user@host:~$ helm upgrade --install --create-namespace -n checkmk-monitoring myrelease checkmk-chart/checkmk -f values.yamlPoiché questo comando non è autoesplicativo, di seguito forniamo una spiegazione delle singole opzioni:
| Elemento del comando | Descrizione |
|---|---|
|
Questa parte è il comando di base per inviare la configurazione al cluster Kubernetes. |
|
In Kubernetes, devi sempre specificare a quale namespace deve essere aggiunta la configurazione. Questa opzione è necessaria se il namespace non esiste ancora. In questo caso Helm lo creerà. |
|
Questa opzione specifica il namespace a cui aggiungere la configurazione. |
|
In questo caso, |
|
La prima parte di questa opzione descrive il repository che hai creato in precedenza. La seconda parte - dopo la barra - è il pacchetto che contiene le informazioni necessarie per creare la configurazione per il monitoraggio di Kubernetes. |
|
Infine, inserisci il file di configurazione che hai creato o adattato in precedenza. Esso contiene tutte le personalizzazioni da includere nei file di configurazione creati con |
Una volta eseguito il comando, il tuo cluster Kubernetes è pronto per il monitoraggio con Checkmk. Il cluster si occuperà ora di garantire che i pod necessari e i container che contengono siano in esecuzione e accessibili.
L'output di Helm chart
Per semplificare al massimo l'installazione, abbiamo dotato l'output dei nostri Helm chart di una serie di comandi che si conformano automaticamente ai valori specificati nel file values.yaml. Se utilizzi la NodePort, otterrai i comandi per visualizzare l'IP e la porta della NodePort, tra le altre cose. Se invece utilizzi Ingress, l'output sarà adattato di conseguenza. Di seguito mostriamo l'output - leggermente abbreviato - a seguito di un'installazione andata a buon fine utilizzando la NodePort:
user@host:~$ helm upgrade --install --create-namespace -n checkmk-monitoring myrelease checkmk-chart/checkmk -f values.yaml Release "myrelease" has been upgraded. Happy Helming! NAME: myrelease LAST DEPLOYED: Sat Dec 16 19:00:11 2022 NAMESPACE: checkmk-monitoring STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: You can access the checkmkmyrelease-checkmk-cluster-collector.checkmk-monitoringCon il token del nome del serviziocluster-collectorvia: NodePort: export NODE_PORT=$(kubectl get --namespace checkmk-monitoring -o jsonpath="{.spec.ports[0].nodePort}" services myrelease-checkmk-cluster-collector); export NODE_IP=$(kubectl get nodes --namespace checkmk-monitoring -o jsonpath="{.items[0].status.addresses[0].address}"); echo http://$NODE_IP:$NODE_PORT # Cluster-internal DNS ofcluster-collectormyrelease-checkmk-checkmknel namespacecheckmk-monitoringpuoi ora eseguire delle query controcluster-collector.Esegui quanto segue per recuperare il token e il certificato del cluster: export TOKEN=$(kubectl get secret myrelease-checkmk-checkmk -n checkmk-monitoring -o=jsonpath='{.data.token}' | base64 --decode); export CA_CRT="$(kubectl get secret myrelease-checkmk-checkmk -n checkmk-monitoring -o=jsonpath='{.data.ca\.crt}' | base64 --decode)"; # Nota: Cita la variabile quando echo'ing a preserva le interruzioni di riga corrette :echo "$CA_CRT"Per verificare l'accesso puoi eseguire: curl -H "Autorizzazione: Bearer $TOKEN" http://$NODE_IP:$NODE_PORT/metadata | jq
Da questo output, copia semplicemente le linee colorate ed esegui i comandi.
Il primo blocco mostra le informazioni sulla porta del nodo:
user@host:~$ export NODE_PORT=$(kubectl get --namespace checkmk-monitoring -o jsonpath="{.spec.ports[0].nodePort}" services myrelease-checkmk-cluster-collector);
user@host:~$ export NODE_IP=$(kubectl get nodes --namespace checkmk-monitoring -o jsonpath="{.items[0].status.addresses[0].address}");
user@host:~$ echo http://$NODE_IP:$NODE_PORT
http://10.184.38.103:30035Questo è esattamente l'indirizzo che dovrai inserire in Checkmk più avanti nella regola di Kubernetes nel campo Collector NodePort / Ingress endpoint.
Con i comandi del blocco successivo ottieni sia il token che il certificato per l'account del servizio. I dati vengono archiviati nelle variabili d'ambiente TOKEN e CA_CRT. Quando inserisci la variabile CA_CRT, assicurati di racchiuderla tra virgolette, altrimenti le importanti interruzioni di riga del certificato andranno perse.
user@host:~$ export TOKEN=$(kubectl get secret myrelease-checkmk-checkmk -n checkmk-monitoring -o=jsonpath='{.data.token}' | base64 --decode);
user@host:~$ export CA_CRT="$(kubectl get secret myrelease-checkmk-checkmk -n checkmk-monitoring -o=jsonpath='{.data.ca\.crt}' | base64 --decode)";
user@host:~$ echo $TOKEN
eyJhbGciOiJSUzI1NiIsImtpZCI6InR6VXhGSU ...
user@host:~$ echo "$CA_CRT"
-----BEGIN CERTIFICATE-----
MIIBdjCCAR2gAwIBAgIBADAKBggqhkjOPQQDAjAjMSEwHwYDVQQDDBhrM3Mtc2Vy
dmVyLWNhQDE2NjIxNDc5NTMwHhcNMjIwOTAyMTk0NTUzWhcNMzIwODMwMTk0NTUz
...
-----END CERTIFICATE-----Quando effettui la configurazione in Checkmk, devi memorizzare sia il token che il certificato. Lascia aperta la shell con queste informazioni o copia il token e il certificato in una posizione a cui potrai accedere durante la successiva configurazione in Checkmk.
Se hai eseguito i due comandi di esportazione precedenti, puoi usare l'ultimo comando per verificare che la configurazione sia andata a buon fine:
curl -H "Authorization: Bearer $TOKEN" http://$NODE_IP:$NODE_PORT/metadata | jq
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1815 100 1815 0 0 126k 0 --:--:-- --:--:-- --:--:-- 126k
{
"cluster_collector_metadata": {
"node": "mynode",
"host_name": "myrelease-checkmk-cluster-collector-58f97df9c9-mdhsw",
"container_platform": {
"os_name": "alpine",
"os_version": "3.15.4",
"python_version": "3.10.4",
"python_compiler": "GCC 10.3.1 20211027"
},
"checkmk_kube_agent": {
"project_version": "1.0.1"
}
}
...All'inizio dell'output molto abbreviato, ad esempio, puoi vedere la versione del Cluster Collector. Più avanti, seguiranno i metadati di tutti i nodi del cluster.
3. Impostazione del monitoraggio in Checkmk
Successivamente, nella GUI di Checkmk, passiamo all'impostazione dell'agente speciale e di una regola per la creazione automatica di host per i tuoi oggetti Kubernetes. Per impostare l'agente speciale, tuttavia, è necessario soddisfare alcuni prerequisiti:
3.1. Memorizzazione della password (token) in Checkmk
È meglio memorizzare la password (token) per l'account del servizio nell'archivio password di Checkmk. Questa è l'opzione più sicura, in quanto puoi separare la memorizzazione e l'uso della password dal punto di vista organizzativo. In alternativa, inserisci la password direttamente in testo normale durante la creazione della regola (vedi sotto). Per informazioni su come visualizzare la password richiesta, vedi l'output dell'Helm chart. Aggiungi la password all'archivio password di Checkmk con Setup > General > Passwords > Add password es. sotto l'ID e il titolo My Kubernetes Token:
3.2. Importare il certificato CA di un account di servizio in Checkmk.
Affinché Checkmk si fidi dell'Autorità di Certificazione (CA) dell'account di servizio, devi memorizzare il certificato CA in Checkmk. Il modo in cui visualizzare il certificato richiesto si trova anche nell'output di 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:
3.3. Creazione di un host piggyback
Crea un nuovo host in Checkmk nel modo consueto e chiamalo, ad esempio, mykubernetesclusterhost. Come suggeriscono il titolo e il nome dell'host, questo host viene utilizzato per raccogliere i dati piggyback e anche per mappare tutti i servizi e le metriche a livello del cluster. Poiché questo host riceve i dati solo tramite l'agente special agent, assicurati di impostare l'opzione IP address family su No IP nelle proprietà dell'host.
3.4. Configurazione dinamica dell'host
Per garantire la separazione tra gli oggetti di diversi cluster Kubernetes, può essere utile creare una cartella per cluster tramite Setup > Hosts > Add folder, in cui la configurazione dinamica degli host può creare automaticamente tutti gli host del cluster. Tuttavia, la creazione o l'utilizzo di tale cartella è facoltativa.
Quindi, imposta un connettore nelle edizioni commerciali per i dati piggyback in arrivo: con Setup > Hosts > Dynamic host management > Add connection.inserisci prima un titolo e poi clicca su show more sotto Connection Properties.
Poi clicca su Add new element e seleziona la cartella creata in precedenza sotto Create hosts in.
Lascia invariati gli attributi predefiniti in Host attributes to set, che garantiscono che Checkmk si attenga ai dati piggyback solo per gli host creati automaticamente e non tenti di pingarli o di raggiungerli tramite SNMP, ad esempio.
In un ambiente Kubernetes in cui gli oggetti monitorati e monitorabili vanno e vengono continuamente, è consigliabile attivare anche 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 configurazione dinamica degli host.
Ora inserisci l'host piggyback creato in precedenza sotto Restrict source hosts e attiva l'opzione Discover services during creation.
La sezione Connection Properties di questo nuovo connettore potrebbe avere il seguente aspetto:
3.5. Processo dei dati piggyback in Checkmk Raw
In Checkmk Raw dovrai creare manualmente gli host per l'accumulo dei dati piggyback. Poiché in un cluster Kubernetes è probabile che si verifichi un gran numero di host piggyback, ti consigliamo di utilizzare il nostro script find_piggy_orphans nella directory ~/share/doc/check_mk/treasures/ della tua istanza Checkmk.
3.6. Personalizzare la scoperta periodica del servizio
Per impostazione predefinita, Checkmk esegue una scoperta del servizio ogni due ore e visualizza i risultati di questa ricerca 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 tutti gli host che rappresentano oggetti Kubernetes. Dovresti selezionare un intervallo più breve per la scoperta del servizio e attivare anche l'opzione Automatically update service configuration. Le impostazioni riportate nella seguente schermata sono solo esempi. Dovrai decidere caso per caso cosa ha senso per i tuoi cluster.
Per limitare questa regola a tutti gli host del cluster, è sufficiente 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. Queste etichette hanno sempre il modulo cmk/kubernetes/cluster:mycluster.
3.7. Impostazione dell'agente speciale
Ora che tutti i prerequisiti sono stati creati nel cluster e in Checkmk, puoi dedicarti alla configurazione dell'agente Checkmk, che puoi trovare 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 liberamente questo nome, che viene utilizzato per dare un nome univoco a tutti gli oggetti che provengono da questo particolare cluster. Ad esempio, se inserisci mycluster, i nomi degli host di tutti i pod di questo cluster inizieranno con pod_mycluster. La parte successiva del nome dell'host sarà sempre il namespace in cui esiste questo oggetto Kubernetes. Il nome host di un pod potrebbe quindi essere pod_mycluster_kube-system_svclb-traefik-8bgw7, ad esempio.
Alla voce Token, seleziona ora la voce creata in precedenza dall'archivio password di Checkmk.
Alla voce API server connection > Endpoint, Checkmk ti chiede ora di inserire l'URL (o l'indirizzo IP) attraverso il quale è possibile accedere al server API di Kubernetes. È necessario inserire la porta solo se il servizio non è fornito tramite un host virtuale. Il modo più semplice per trovare questo indirizzo - se non ce l'hai già a portata di mano - dipenderà dal tuo ambiente Kubernetes. Il comando seguente ti fornirà l'endpoint del server API nella riga server:
user@host:~$ kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://DFE7A4191DCEC150F63F9DE2ECA1B407.mi6.eu-central-1.eks.amazonaws.com
name: xyz:aws:eks:eu-central-1:150143619628:cluster/my-kubernetesTuttavia, l'output effettivo di kubectl config view varia notevolmente. Se viene specificata anche una porta nella riga server, assicurati di includerla anche nella regola.
Se finora hai seguito passo dopo passo queste istruzioni e hai depositato il certificato CA del tuo cluster -come descritto in precedenza- in Checkmk, seleziona alla voce SSL certificate verification la voce Verify the certificate.
Successivamente, hai la possibilità di arricchire il monitoraggio del tuo cluster Kubernetes con i dati di utilizzo raccolti dal Cluster Collector di Checkmk. Lo ripetiamo ancora una volta per sottolinearne l'importanza:la configurazione del Cluster Collector è assolutamente essenziale per un monitoraggio completo dei tuoi cluster.È l'unico modo per ottenere dati importanti come l'utilizzo della CPU e della memoria e per 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 della NodePort o dell'Ingress. Il modo in cui visualizzare nuovamente questo endpoint è nell'output di Helm chart.
Con l'opzione Collect information about… puoi selezionare quali oggetti del cluster devono essere monitorati. La nostra preselezione copre gli oggetti più importanti. Se decidi di monitorare anche Pods of CronJobs, consulta l'aiuto inline su questo punto.
Con le due opzioni successive, puoi limitare ulteriormente gli oggetti da monitorare. Se ti interessano solo gli oggetti di alcuni namespace, imposta questo aspetto in Monitor namespaces. Qui puoi inserire i singoli namespace da monitorare o escludere esplicitamente i singoli namespace dal monitoraggio.
Con l'opzione Cluster resource aggregation puoi specificare i nodi che non forniscono risorse per il workload del tuo cluster. Questi nodi devono essere esclusi dal calcolo delle risorse disponibili, altrimenti c'è il rischio che non vengano rilevati i colli di bottiglia della capacità. Per impostazione predefinita, quindi, escludiamo i nodi control-plane e infra dalla valutazione.
Come ultima opzione, puoi importare le cosiddette annotazioni da Kubernetes. In Checkmk, queste annotazioni diventano etichette dell'host e possono quindi essere utilizzate come condizioni per le regole. Puoi specificare quali annotazioni devono essere importate utilizzando espressioni regolari. Anche in questo caso, consulta l'aiuto inline dettagliato.
Nota: l'opzione Import all valid annotations viene fornita qui solo per completezza. Non consigliamo di importare alla cieca tutte le annotazioni, perché ciò potrebbe creare una montagna di etichette inutili in Checkmk.
Importante: in Conditions > Explicit hosts devi inserire l'host creato in precedenza:
Quindi salva la regola ed esegui una scoperta del servizio su questo host: vedrai subito i primi servizi a livello di cluster:
A questo punto attiva le modifiche apportate e lascia che la configurazione dinamica degli host faccia il lavoro per te: in questo modo creerai tutti gli host per i tuoi oggetti Kubernetes in breve tempo.
4. Etichette per gli oggetti Kubernetes
Checkmk genera automaticamente delle etichette per gli oggetti Kubernetes come cluster, deployment o namespace durante la scoperta del servizio. Tutte le etichette per gli oggetti Kubernetes che Checkmk genera automaticamente iniziano con cmk/kubernetes/. Ad esempio, un pod riceve sempre un'etichetta del nodo (cmk/kubernetes/node:mynode), un'etichetta che indica che questo oggetto è un pod (cmk/kubernetes/object:pod) e un'etichetta del namespace (cmk/kubernetes/namespace:mynamespace). Questo rende molto facile creare filtri e regole per tutti gli oggetti dello stesso tipo o dello stesso namespace.
5. Dashboard e visualizzazioni
5.1. Dashboard di Kubernetes
Le edizioni commerciali di Checkmk vengono fornite con sei dashboard integrate per Kubernetes. Per utilizzare queste dashboard in modo pratico, è necessario installare e configurare il nostro Cluster Collector. Nello specifico, queste sei dashboard sono chiamate:
Kubernetes
Kubernetes Cluster
Kubernetes DaemonSet
Kubernetes Deployments
Kubernetes namespace
StatefulSet di Kubernetes
Il punto di ingresso è sempre la dashboard Kubernetes, a cui puoi accedere tramite Monitor > Applications > Kubernetes:
Nella dashboard Kubernetes, tutti i cluster Kubernetes monitorati sono elencati sul lato sinistro. Questo elenco di cluster è anche la voce dell'elenco per approfondire le dashboard Kubernetes. Facendo clic sul nome di un cluster si accede alla dashboard Kubernetes Cluster del cluster selezionato. Nella dashboard Kubernetes Cluster, facendo clic sul rispettivo nome si accede alle altre dashboard dipendenti dal contesto:
5.2. L'inventario hardware/software
Il monitoraggio di Kubernetes Cluster supporta anche l'inventario HW/SW. Ad esempio, se fai clic sul nome primario del cluster (qui: mycluster) nel dashboard del cluster di cui sopra, passerai all'inventario del cluster.
Allo stesso modo, cioè tramite i box con i nomi primari degli oggetti, potrai accedere all'inventario del rispettivo oggetto anche negli altri dashboard. L'esempio seguente mostra l'inventario HW/SW di un pod:
6. Verifica dell'installazione
Nella sezione dedicata all'output di Helm chart, hai già appreso il primo metodo per verificare che i componenti per un monitoraggio completo di Kubernetes siano stati installati con successo. Nella GUI di Checkmk puoi anche verificare l'avvenuta installazione e configurazione in diversi punti.
I servizi più importanti sono sicuramente Kubernetes API e Cluster Collector. Questi devono essere presenti sull'host del cluster che hai creato e devono anche visualizzare alcune informazioni.
Il servizio Kubernetes API dovrebbe normalmente riportare Live, Ready sotto Summary. Il servizio Cluster Collector deve mostrare il numero di versione del Cluster Collector installato. Se questo non avviene per uno o l'altro di questi servizi, devi controllare l'installazione di Helm chart e la configurazione dello special agent.
Ulteriori possibilità di verifica sono fornite dalle dashboard dei cluster delle edizioni commerciali.
Nella dashboard Kubernetes puoi vedere subito se il Cluster Collector è in esecuzione in un cluster e sta raccogliendo dati. Se le colonne CPU resources e Memory resources non contengono dati, questo è già un forte indicatore che il Cluster Collector non sta funzionando correttamente. Se è stata impostata correttamente, la dashboard Kubernetes dovrebbe avere un aspetto simile a questo:
Se ora clicchi sul nome del cluster in questa finestra, ti ritroverai nella dashboard del rispettivo cluster Kubernetes Cluster. Qui i tre box Primary datasource, Cluster collector e API health dovrebbero essere verdi e mostrare OK.
7. Rimozione dei componenti di monitoraggio da un cluster
Se hai distribuito Checkmk nel tuo cluster utilizzando le nostre Helm chart, puoi rimuovere gli account, i servizi, i pod e le porte dei nodi creati con la stessa facilità con cui li hai configurati. Per farlo, è sufficiente disinstallare la release che è stata installata utilizzando le nostre chart.
Se non sei sicuro del nome della versione, visualizza prima tutte le versioni di Helm in tutti i namespace:
user@host:~$ helm list --all-namespaces
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
myrelease checkmk-monitoring 1 2022-08-15 19:00:42.318666784 +0200 CEST deployed checkmk-1.0.1 1.0.1Come nell'esempio sopra riportato, dovresti trovare una release che contiene un riferimento a Checkmk nella colonna CHART.
Rimuovi questa release con il comando seguente, specificando il namespace corretto:
user@host:~$ helm uninstall myrelease -n checkmk-monitoring
release "myrelease" uninstalled