Nota di traduzione.: L'autore del materiale originale è Henning Jacobs della Zalando. Ha creato una nuova interfaccia web per lavorare con Kubernetes, che si presenta come "kubectl per il web". Perché è nato questo nuovo progetto Open Source e quali criteri non soddisfacevano le soluzioni già esistenti — leggi nel suo articolo.
In questa pubblicazione analizzo diverse interfacce web Kubernetes con codice sorgente aperto, presento le mie richieste per un UI universale e spiego perché ho sviluppato — un'interfaccia pensata per semplificare il supporto e la risoluzione dei problemi contemporaneamente in più cluster.
Casi d'uso
In Zalando gestiamo un gran numero di utenti Kubernetes (oltre 900) e cluster (oltre 100). Ci sono un paio di casi d'uso tipici in cui sarebbe stata molto utile l'assistenza di uno strumento web specializzato:
- comunicazione con i colleghi nell'ambito del supporto;
- rispondere agli incidenti e investigare sulle loro cause.
Supporto
Dalla mia esperienza, la comunicazione nel supporto spesso appare nel seguente modo:
— Aiuto, il nostro servizio XYZ non è disponibile!
— Cosa vedi quando esegui kubectl describe ingress ...?
O qualcosa di simile per CRD:
— Ho un problema con il servizio di identificazione…
— E cosa restituisce il comando kubectl describe platformcredentialsset ...?
Questa comunicazione di solito si riduce all'immissione di diverse variazioni del comando kubectl per identificare il problema. Di conseguenza, entrambe le parti della conversazione sono costrette a continuare a passare tra terminale e chat web, e osservano situazioni diverse.
Pertanto, sarebbe desiderabile che il frontend web di Kubernetes permettesse quanto segue:
- gli utenti potrebbero scambiare collegamenti e osservare la stessa cosa;
- aiuterebbe a evitare errori umani nel supporto: ad esempio, accesso al cluster sbagliato nel terminale, errori di battitura nei comandi CLI, e così via;
- permetterebbe di generare visualizzazioni personalizzate da inviare ai colleghi, ossia aggiungere colonne di etichette, visualizzare più tipi di risorse su una pagina;
- in ideale questo strumento web dovrebbe consentire di creare "link profondi" a sezioni specifiche di YAML (ad esempio, indicare un parametro errato che provoca errori).
Rispondere agli incidenti e analizzare
La risposta agli incidenti nell'infrastruttura richiede consapevolezza situazionale, capacità di valutare l'impatto e ricerca di schemi nei cluster. Alcuni esempi della vita reale:
- un servizio di produzione critico ha dei problemi e hai bisogno di trovare tutte le risorse Kubernetes per nome in tutti i cluster, per risolvere i guasti;
- i nodi iniziano a cadere durante il ridimensionamento e hai bisogno di trovare tutti i pod con stato «Pending» in tutti i cluster, per valutare l'estensione del problema;
- singoli utenti segnalano un problema con DaemonSet distribuito in tutti i cluster, e bisogna capire se il problema è di natura totale.
La mia soluzione standard in questi casi è qualcosa del tipo for i in $clusters; do kubectl ...; done. È chiaro che si può sviluppare uno strumento che offre capacità simili.
Le interfacce web esistenti di Kubernetes
Il mondo Open Source delle interfacce web per Kubernetes non è molto ampio*, quindi ho provato a raccogliere ulteriori informazioni utilizzando :
* La mia spiegazione del numero limitato di interfacce web per Kubernetes: i servizi cloud e i fornitori di Kubernetes solitamente offrono i propri frontend, quindi il mercato per «buone» interfacce utente di Kubernetes è relativamente limitato.
Con un tweet ho scoperto , e . Diamo un'occhiata a loro e ad altre soluzioni Open Source esistenti, provando a capire cosa rappresentano.
K8Dash
«K8Dash è il modo più semplice per gestire un cluster Kubernetes».
sembra funzionare bene ed è reattivo, ma presenta alcuni difetti per gli scenari d'uso sopra menzionati:
- Funziona solo all'interno di un singolo cluster.
- Ordinamento e filtraggio sono possibili, ma non hanno riferimenti permanenti.
- Manca il supporto per le Custom Resource Definitions (CRDs).
Kubernator
«Kubernator è un'interfaccia utente alternativa per Kubernetes. A differenza della dashboard di Kubernetes ad alto livello, fornisce un controllo a basso livello e una visione chiara di tutti gli oggetti nel cluster con la possibilità di crearne di nuovi, modificarli e risolvere conflitti. Essendo un'applicazione interamente client (come kubectl), non richiede alcun backend tranne il server API di Kubernetes e tiene conto delle regole di accesso al cluster».
È una descrizione abbastanza accurata di . Purtroppo, gli mancano alcune funzionalità:
- Supporta solo un cluster.
- Non c'è una modalità di visualizzazione elenco (cioè non è possibile visualizzare tutti i pod con stato "Pending").
Kubernetes Dashboard
"Kubernetes Dashboard è un'interfaccia web universale per i cluster Kubernetes. Permette agli utenti di gestire le applicazioni in esecuzione nel cluster e di risolvere i problemi, oltre a gestire il cluster stesso."
Purtroppo, non è particolarmente utile nelle mie attività di supporto e risposta agli incidenti, perché in esso:
- non ci sono link permanenti, ad esempio quando filtro le risorse o cambio l'ordinamento;
- non c'è un modo semplice per filtrare per stato — ad esempio, vedere tutti i pod con stato "Pending";
- supporta solo un cluster;
- non supporta CRD (questa funzione è in fase di sviluppo);
- non ci sono colonne personalizzate (ad esempio, colonne con etichette come
kubectl -L).
Kubernetes Operational View (kube-ops-view)
"Un pannello di monitoraggio per lo spazio dei cluster K8s."
A ha un approccio completamente diverso: questo strumento mostra solo i nodi del cluster e i pod utilizzando WebGL, senza dettagli testuali sugli oggetti. È ottimo per una visione operativa dello stato del cluster ("i pod stanno cadendo?")*, ma non è adatto per i casi d'uso descritti sopra nel supporto e nella risposta agli incidenti.
* Nota di traduzione.: In questo senso, potrebbe interessarti anche il nostro plugin , di cui abbiamo parlato più nel dettaglio in .
Kubernetes Resource Report (kube-resource-report)
"Raccogli informazioni sulle richieste di risorse dei pod e del cluster Kubernetes, confrontale con il consumo di risorse e genera HTML statico."
genera report HTML statici sull'uso delle risorse e sulla distribuzione dei costi per team/applicazioni nei cluster. Il report è in qualche modo utile per il supporto e la risposta agli incidenti, poiché consente di individuare più rapidamente il cluster in cui è distribuita l'applicazione.
Nota di traduzione.: Nella visualizzazione delle informazioni sulla distribuzione delle risorse e sui costi, potrebbe risultare utile anche il servizio e lo strumento , di cui abbiamo .
Octant
"Una piattaforma web estensibile per gli sviluppatori, progettata per fornire una migliore comprensione della complessità dei cluster Kubernetes."
, creato in VMware, è un nuovo prodotto di cui ho scoperto relativamente di recente. Con esso è comodo esplorare il cluster sulla macchina locale (ci sono anche delle visualizzazioni), tuttavia tocca il tema della gestione e risposta agli incidenti solo in misura limitata. Svantaggi di Octant:
- Non c'è ricerca tra i cluster.
- Funziona solo sulla macchina locale (non si distribuisce nel cluster).
- Non è possibile ordinare/filtrare gli oggetti (è supportato solo il selettore delle etichette).
- Non si possono definire colonne personalizzate.
- Non è possibile visualizzare l'elenco degli oggetti per namespace.
Ho anche avuto problemi con la stabilità di Octant con i cluster Zalando: in alcuni CRD .
Presento Kubernetes Web View
«kubectl per il web».
Dopo aver analizzato le opzioni disponibili per le interfacce Kubernetes, ho deciso di crearne una nuova: . Infatti, in sostanza ho solo bisogno di tutta la potenza kubectl nel web, ossia:
- disponibilità di tutte le operazioni (sola lettura), in cui gli utenti preferiscono utilizzare kubectl;
- tutti gli URL devono essere permanenti e rappresentare la pagina nell'aspetto originale, affinché i colleghi possano condividerli e utilizzarli in altri strumenti;
- supporto per tutti gli oggetti Kubernetes, che consentirà di risolvere problemi di qualsiasi tipo;
- le liste delle risorse devono essere scaricabili per ulteriori elaborazioni (in fogli di calcolo, strumenti CLI come
grep) e per l'archiviazione (ad esempio, per postmortem); - supporto per la selezione delle risorse in base alle etichette (analogamente a
kubectl get .. -l); - possibilità di creare elenchi aggregati di diversi tipi di risorse (simile a
kubectl get all) per avere un quadro operativo complessivo tra i colleghi (ad esempio, durante la risposta a un incidente); - possibilità di aggiungere link profondi «intelligenti» personalizzabili ad altri strumenti, come pannelli di monitoraggio, logger, registri delle applicazioni, ecc., per facilitare la ricerca/riparazione e la risposta agli incidenti;
- il frontend deve essere il più semplice possibile (HTML pulito), per evitare problemi accidentali, come un JavaScript bloccato;
- supporto per molti cluster per semplificare l'interazione durante la consulenza remota (ad esempio, per memorizzare solo un URL);
- se possibile, deve semplificarsi l'analisi situazionale (ad esempio, con link per scaricare risorse da tutti i cluster/namespace);
- ulteriori funzionalità per la generazione di link flessibili e l'estrazione di informazioni testuali, ad esempio per consentire di indicare ai colleghi una sezione specifica nella descrizione della risorsa (una riga in YAML);
- possibilità di adattarsi alle esigenze specifiche del cliente, ad esempio permettendo di creare modelli personalizzati per CRD, le proprie visualizzazioni tabellari, modificare gli stili CSS;
- strumenti per ulteriori studi nella riga di comando (ad esempio, mostrando comandi completi
kubectl, pronte per essere copiate);
Fuori dagli obiettivi affrontati da Kubernetes Web View (non-obiettivi) sono rimasti:
- astrazione degli oggetti Kubernetes;
- gestione delle applicazioni (ad esempio, gestione dei deployment, Helm charts, ecc.);
- operazioni di scrittura (devono essere effettuate tramite strumenti CI/CD sicuri e/o GitOps);
- interfaccia gradevole (JavaScript, temi, ecc.);
- visualizzazioni (vedi );
- analisi dei costi (vedi ).
Come Kubernetes Web View aiuta nel supporto e nella reazione agli incidenti?
Supporto
- Tutti i link sono permanenti, il che facilita la condivisione delle informazioni con i colleghi.
- È possibile creare le proprie visualizzazioni, ad esempio visualizzare tutti i Deployment e i Pod con un'etichetta specifica in due cluster particolari (è possibile indicare più nomi di cluster e tipi di risorse nel link, separandoli con virgole).
- Si possono fare riferimenti a righe specifiche in un file YAML di un oggetto, indicando potenziali problemi nella specifica dell'oggetto.
Ricerca nei cluster in Kubernetes Web View
Reazione agli incidenti
- Ricerca globale (ricerca globale) permette di cercare oggetti in tutti i cluster.
- Le visualizzazioni in forma di elenco possono mostrare tutti gli oggetti con uno stato/colonna specifico in tutti i cluster (ad esempio, dobbiamo trovare tutti i pod con stato "Pending").
- Le liste degli oggetti possono essere scaricate in formato valori separati da tabulazione (TSV), per analisi successive.
- consentono di passare ai pannelli di monitoraggio e ad altri strumenti pertinenti.
Kubernetes Web View: elenco dei pod con stato "Pending" in tutti i cluster
Se desideri provare Kubernetes Web View, ti consiglio di dare un'occhiata a o di visualizzare .
Certo, l'interfaccia potrebbe essere migliore, ma attualmente Kubernetes Web View è uno strumento per "utenti esperti" che non esitano a manipolare manualmente i percorsi URL, se necessario. Se hai commenti / aggiunte / suggerimenti, ti prego di contattarmi !
Questo articolo è una breve narrazione delle premesse che hanno portato alla creazione di Kubernetes Web View. Ne seguiranno altri! (Nota di traduzione.: Ci si può aspettare nel .)
P.S. dal traduttore
Leggi anche nel nostro blog:
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
