Report personalizzati con Operator Metering

Operator Metering è uno strumento di chargeback e reportistica che rende conto dell'utilizzo delle risorse in un cluster Kubernetes. Consente agli amministratori del cluster di pianificare i report in base ai dati di utilizzo storici per pod, spazio dei nomi e cluster. 

Installando Operator Metering si ottiene accesso a diverse query di report pronte all'uso. Ad esempio, se un amministratore desidera misurare l'utilizzo della CPU o della memoria per i nodi o i pod del cluster, può produrre un report (mensile, orario e così via) scrivendo una risorsa personalizzata Report con Operator Metering.

Scenari di utilizzo

Molti clienti si trovano a dover gestire principalmente tre requisiti. 

1. Non è detto che i nodi di lavoro di un cluster OpenShift per ambienti non di produzione siano sempre in esecuzione; ad esempio, un amministratore potrebbe disattivarne alcuni in base alla capacità disponibile o durante i fine settimana. Pertanto, vorrebbe misurare l'utilizzo della CPU o della memoria di un nodo su base mensile, in modo che il team responsabile dell'infrastruttura possa rimborsare gli utenti in base all'utilizzo effettivo.
2. I clienti adottano un modello che prevede il deployment di un cluster OpenShift dedicato per i singoli team. Potrebbero installare Operator Metering e ottenere informazioni sull'utilizzo del nodo; tuttavia, vogliono includere nel report di chargeback il team o la LOB per cui vengono utilizzati i nodi di lavoro. Questo scenario di utilizzo può essere esteso anche ai casi in cui i nodi di un cluster dedicato condiviso presentano un'etichetta che identifica il team o la LOB a cui appartiene il carico di lavoro in esecuzione.
3. In un cluster condiviso, il team operativo desidera rimborsare gli utenti in base al tempo di esecuzione dei pod (ad esempio, il consumo di CPU o di memoria). Anche in questo caso, il cliente vuole semplificare il report per includere il team o la LOB a cui appartengono i pod.

Requisiti simili rendono necessaria la creazione di alcune risorse personalizzate nel cluster. Questo articolo mostra come realizzarle in modo semplice. Tieni presente che l'installazione di Operator Metering non rientra negli obiettivi di questo articolo. Puoi consultare la documentazione sull'installazione qui. Per ulteriori informazioni sull'utilizzo dei report integrati, fai riferimento a questo documento.

Come funziona Metering?

Prima di passare alla creazione di nuove risorse personalizzate per il nostro scenario di utilizzo, analizziamo in breve come funziona OpenShift Metering. Dopo l'installazione, Operator Metering crea un totale di sei risorse personalizzate. Di queste, le seguenti richiedono un approfondimento. 

1. ReportDataSources (rds): è il meccanismo che definisce i dati disponibili e può essere utilizzato dalle risorse personalizzate ReportQuery o Report. Consente inoltre di recuperare i dati da diverse sorgenti. In OpenShift, i dati vengono estratti da Prometheus e dalla risorsa personalizzata ReportQuery (rq). 
2. ReportQuery (rq): contiene le query SQL con cui eseguire l'analisi dei dati archiviati con rds. Se un oggetto rq è referenziato da un oggetto Report, l'oggetto rq gestisce anche gli elementi su cui viene eseguito il report. Se referenziato da un oggetto rds, l'oggetto rq indica a Metering di creare una vista all'interno delle tabelle Presto, create all'installazione di Metering, in base alla query renderizzata.
3. Report: consente di generare report utilizzando la risorsa ReportQuery configurata. Si tratta della risorsa principale con cui interagiscono gli utenti finali di Operator Metering. L'esecuzione di Report può essere pianificata.

Sono disponibili molti rds e rq pronti all'uso. Poiché il focus di questo articolo è il metering a livello di nodo, riportiamo qui quali occorre comprendere per scrivere le query personalizzate. Esegui questo comando nel progetto "openshift-metering": 

Per misurare il consumo di CPU, vorremmo concentrarci sui due rds "node-capacity-cpu-cores" e "node-cpu-capacity-raw". Prendiamo node-capacity-cpu-cores ed eseguiamo il seguente comando per vedere come acquisisce i dati da Prometheus:

È possibile osservare la query Prometheus utilizzata per recuperare i dati da Prometheus e archiviarli nelle tabelle Presto. Eseguiamo la stessa query nella console delle metriche di OpenShift e vediamo il risultato. Abbiamo un cluster OpenShift con 2 nodi di lavoro (ciascuno con 16 core) e 3 nodi master (ciascuno con 8 core). L'ultima colonna, "value", indica i core assegnati ai nodi.

I dati vengono quindi raccolti e archiviati nelle tabelle Presto. Prendiamo ora alcune risorse personalizzate ReportQuery (rq): 

In questo caso ci concentriamo su "node-cpu-capacity" e "node-cpu-capacity-raw". Descrivendo queste ReportQuery, è chiaro che abbiano a che fare con l'elaborazione dei dati (ad esempio, il tempo di attività del nodo, il numero di CPU assegnate e così via) e la loro aggregazione. 

In effetti, il diagramma seguente mostra in che modo i due rds e i due rq sono collegati.

node-cpu-capacity (rq) usa node-cpu-capacity-raw (rds) usa node-cpu-capacity-raw (rq) usa node-capacity-cpu-cores (rds)

Personalizzazione dei report

Vediamo ora come funziona la scrittura degli rds e degli rq personalizzati. In primo luogo, è necessario modificare la query Prometheus in modo che indichi se il nodo è un nodo master o di lavoro, quindi includere un'etichetta appropriata che identifichi il team a cui appartiene. La metrica "kube_node_role" di Prometheus contiene dati relativi al ruolo del nodo (come master o di lavoro). Guarda la colonna "role":

La metrica "kube_node_labels" di Prometheus acquisisce tutte le etichette applicate a un nodo, con la dicitura "label_". Ad esempio, se un nodo presenta l'etichetta "node_lob", la metrica Prometheus acquisisce i dati come "label_node_lob". 

Per ottenere dati pertinenti, è sufficiente modificare la query originale con queste ulteriori query Prometheus. Ecco come appare la query:

((kube_node_status_capacity_cpu_cores * on(node) group_left(provider_id) max(kube_node_info) by (node, provider_id)) * on(node) group_left (role) kube_node_role{role='worker'}) * on(node) group_right(provider_id, role) kube_node_labels

Eseguiamo questa query nella console delle metriche di OpenShift e verifichiamo di aver ottenuto sia l'etichetta (node_lob) sia le informazioni sul ruolo. Qui label_node_lob indica sia l'output sia il ruolo. Non è possibile visualizzare le informazioni sul ruolo poiché la query genera molte colonne, ma acquisisce le informazioni:

Possiamo scrivere quattro risorse personalizzate. Per semplicità, sono disponibili qui: 

1. rds-custom-node-capacity-cpu-cores.yaml: definisce la query Prometheus
2. rq-custom-node-cpu-capacity-raw.yaml: si riferisce all'rds precedente e calcola i dati grezzi
3. rds-custom-node-cpu-capacity-raw.yaml: si riferisce all'rq precedente e crea una vista in Presto
4. rq-custom-node-cpu-capacity-with-cpus-labels.yaml: si riferisce all'rds menzionato al punto 3 e calcola i dati in base ai dati iniziali e finali di input. Si tratta anche del file da cui è possibile recuperare le colonne role e node_label.

Dopo aver scritto questi file yaml, vai al progetto openshift-metering ed esegui i seguenti comandi: 

Infine, è sufficiente scrivere un oggetto personalizzato Report che faccia riferimento all'ultimo oggetto rq creato in precedenza. Puoi scriverne uno come mostrato di seguito. Il report seguente verrà eseguito immediatamente e mostrerà i dati tra il 15 e il 30 settembre.

Dopo aver eseguito il report, è possibile scaricare il file in formato .csv o .json tramite questo URL (modificando DOMAIN_NAME con il nome del dominio):

https://metering-openshift-metering.DOMAIN_NAME/api/v1/reports/get?name=custom-role-node-cpu-capacity-hourly&namespace=openshift-metering&format=csv

Lo snapshot CSV riportato di seguito mostra i dati acquisiti con la colonna role e node_lob. Per ottenere il tempo di esecuzione del nodo in secondi, la colonna "node_capacity_cpu_core_seconds" deve essere divisa per "node_capacity_cpu_cores": 

Riepilogo

Operator Metering è una risorsa piuttosto interessante, che può essere eseguita su cluster OpenShift in qualsiasi ambiente. Fornisce un framework estensibile con cui i clienti possono scrivere le proprie risorse personalizzate e creare report in base alle proprie esigenze. Tutto il codice utilizzato nell'articolo è disponibile qui.