Sarebbe davvero bello se Docker Desktop includesse una GUI per Kubernetes pronta all’uso, ma purtroppo non è così. E se vi dicessi che possiamo ottenere un’esperienza simile utilizzando Kubernetes Dashboard ?!?!?!
In questo articolo parliamo di “Kubernetes dashboard per Docker Desktop – Installazione e configurazione“. Kubernetes su Docker Desktop non fornisce nativamente una dashboard simile a quelle messe a disposizione da, solo per fare un paio di esempi, GKE o da OpenShift. Dashboard che può risultare utile, seppur in un ambiente di sviluppo, in diverse occasioni. Per questo motivo, vediamo come si installa la dashboard in un ambiente basato su Docker Desktop.
Questo progetto fornisce un’interfaccia utente Web per la gestione del tuo cluster, fornendo un modo semplice per visualizzare una panoramica del tuo cluster e persino per la modifica e l’esecuzione dei containers.
Let’s go!
Disclaimer
ATTENZIONE!!! Questa guida è ideata per un ambiente locale di sviluppo. NON ESEGUIRE LA PROCEDURA DESCRITTA IN QUESTA GUIDA IN AMBIENTI DI PRODUZIONE o metterai a rischio la sicurezza del cluster.
Non saremo in alcun modo responsabili delle conseguenze derivanti dall’applicazione di questa procedura. Ciò significa che qualunque esito ne derivi, sarà di tua unica e completa responsabilità.
Indice dei contenuti
- Pre-Requisiti installazione Kubernetes dashboard
- Download e installazione
- Disabilitare i criteri di sicurezza
- Creare un nuovo service account con i privilegi di admin
- Installare Kubernetes Metric Server
- Visualizzare la dashboard
- Conclusioni
Pre-Requisiti installazione Kubernetes dashboard
Per poter installare la dashboard è ovviamente necessario che abbiate già un’installazione di Kubernetes attiva sul vostro PC, Laptop, Macbook, o quel che sia :).
Download e installazione Kubernetes dashboard
Iniziamo col dire che la Dashboard è valida, ovviamente, sia per ambienti linux, che Windows che MacOS.
La prima cosa da fare per poter installare la nostra dashboard è quella di scaricare un bel file da internet 😅.
Se utilizzate Linux o MacOS, aprite il terminale e lanciate il comando:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yamlLo stesso comando è valido anche da Power Shell su Windows.
Questo comando scarica il manifest di distribuzione e lo applica al tuo cluster. Dopo aver laniato il comando, dovresti vedere qualcosa di simile a:
namespace/kubernetes-dashboard created
serviceaccount/kubernetes-dashboard created
service/kubernetes-dashboard created
...
service/dashboard-metrics-scraper created
deployment.apps/dashboard-metrics-scraper createdA questo punto, dando un’occhiata a Docker Desktop, vedrai alcuni nuovi container in esecuzione, con nomi abbastanza lunghi. Questi sono i container in esecuzione come parte dei pod della nostra nuova dashboard.
A questo punto, potremmo tecnicamente avviare la nostra Dashboard, ma ci verrà presentata la seguente schermata di accesso:
Piuttosto che perdere tempo con i token, visto che siamo in un ambiente di sviluppo, abiliteremo un’impostazione che ti consentirà di ignorare completamente questa pagina di autenticazione.
Disabilitare i criteri di sicurezza di Kubernets Dashboard
NON ESEGUIRE QUESTA PROCEDURA IN AMBIENTI DI PRODUZIONE o metterai a rischio la sicurezza del tuo cluster.
E’ possibile ignorare la pagina di accesso se andiamo a modificare la distribuzione predefinita, aggiungendo un argomento aggiuntivo –enable-skip-login.
Ci sono due modi principali per farlo:
- Utilizzando kubectl edit per modificare il manifest YAML
- Usando kubectl patch per correggere direttamente il manifest YAML
In questo esempio utilizzeremo il secondo esempio, che è più semplice e veloce.
Se non adottassimo questo workaround e provassimo ad accedere alle voci di menù della nostra dashboard, troveremo errori similia a:
error
pods is forbidden: User "system:serviceaccount:kubernetes-dashboard:default" cannot list resource "pods" in API group "" in the namespace "default" 1 minutes ago
error
deployments.apps is forbidden: User "system:serviceaccount:kubernetes-dashboard:default" cannot list resource "deployments" in API group "apps" in the namespace "default" 1 minutes agoQuesto perchè, al fine di proteggere i dati del cluster, la Dashboard viene distribuita con una configurazione RBAC minima per impostazione predefinita. Di default infatti, la Dashboard supporta solo l’accesso con un Bearer Token.
Vediamo quali passi seguire affinché non si presentino questi errori e sopratutto affinché la nostra dashboard sia visibile.
Sarà sufficiente lanciare i seguenti 3 comandi:
(NON FATELO MAI IN AMBIENTE DI PRODUZIONE)
kubectl patch deployment kubernetes-dashboard -n kubernetes-dashboard --type 'json' -p '[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--enable-skip-login"}]'
kubectl patch deployment kubernetes-dashboard -n kubernetes-dashboard --type 'json' -p '[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--enable-insecure-login"}]'
kubectl patch deployment kubernetes-dashboard -n kubernetes-dashboard --type 'json' -p '[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--disable-settings-authorizer"}]'I 3 comandi appena elencati disabilitano tutti i criteri di protezione del cluster, autenticazione inclusa, permettendo si l’accesso alla dashboard, ma mettendo a rischio la sicurezza del cluster stesso.
Creare un nuovo service account con i privilegi di admin
Ora che abbiamo disabilitato i processi di autenticazione, dobbiamo creare un service account associato alla nostra dashboard, che abbia i ruoli di cluster admin.
Prima di procedere alla creazione del nuovo service account, andiamo a cancellare i ruoli già assegnati:
kubectl delete clusterrolebinding kubernetes-dashboardAvviso: l’utente di esempio creato nel tutorial avrà privilegi amministrativi ed è solo a scopo didattico. NON FATELO MAI IN AMBIENTE DI PRODUZIONE.
A questo punto siamo pronti per creare il nuovo account con i privilegi di root:
kubectl create clusterrolebinding kubernetes-dashboard --clusterrole=cluster-admin --serviceaccount=kubernetes-dashboard:kubernetes-dashboardDa questo momento , l nostra dashboard è in grado di leggere e scrivere le configurazioni (etcd) del nostro cluster Kubernetes.
Installare Kubernetes Metric Server
Metrics Server raccoglie le metriche delle risorse da Kubelet e le espone in Kubernetes apiserver tramite l’API Metrics…
Kubernetes Dashboard include già i prerequisiti per lavorare con Metrics Server (hai notato il pod “metrics-scraper” nel tuo cluster?), quindi devi solo installare Metrics Server.
Eseguire il seguente comando per scaricare i manifest di Metrics Server e installarli nel cluster:
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.4.2/components.yamlQuesto installa una varietà di risorse nel tuo cluster, ma anche stavolta, dobbiamo applicare una patch a una delle distribuzioni. Dobbiamo aggiungere l’argomento –kubelet-insecure-tls a Server Metrics, altrimenti verrà visualizzato un messaggio di errore che si avvicina a qualcosa di simile a “Impossibile recuperare le metriche dal nodo docker-desktop”.
Il seguente comando correggerà il problema:
kubectl patch deployment metrics-server -n kube-system --type 'json' -p '[{"op": "add", "path": "/spec/template/spec/containers/0/args/-" , "valore": "--kubelet-insecure-tls"}]'Con ciò, otterremo dei bei grafici per i nostri pod :).
Visualizzare la Kubernetes dashboard
Abbiamo svolto tutto il lavoro necessario per poter finalmente accedere e visualizzare i dati presenti nella nostra dashboard. Ci restano soltanto un paio di passi da svolgere.
Apriamo di nuovo un terminale e lanciamo il comando:
kubectl proxyL’output sarà:
Starting to serve on 127.0.0.1:8001Prima di visualizzare la nostra dashboard, aggiungiamo un aduno che ci permetterà di visualizzare anche l’utilizzo di CPU e MEMORIA dei nostri pods.
A questo punto non ci resta altro da fare che aprire un browser e digitare la URL:
http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/
Ed ecco il risultato finale:
Conclusioni
Concludiamo questa guida ripetendo per l’ennesima volta di non applicare queste configurazioni in ambienti di produzione.
La guida ha il solo scopo dimostrativo e risulterà sicuramente utile negli ambienti di sviluppo e di test.
I passi, come avrete potuto notare, sono estremamente semplici, ma porteranno a ottimi risultati, facendovi capire in modo estremamente intuitivo l’utilizzo delle risorse del vostro cluster.
Spero che l’articolo vi sia risultato utile, in tal caso, potreste condividerlo 🙂 .
Se avete dei dubbi o se volete condividere il vostro punto di vista, scrivete nei commenti e cercherò di rispondere al più presto.
Se volete restare in contatto, vi lascio anche il link della mia newsletter di LinkedIn.
Principal Web Solutions Architect – Technology & Architecture Manager @ Accenture – Google Cloud Certified – Professional Cloud Architect
Parla di #web, #cloud, #websecurity, #webperformance e #webarchitecture