Installazione di Kubernetes: mini guida dedicata all’installazione di Kubernetes in locale

Installare e dunque avviare Kubernetes in locale è il modo migliore per vedere e comprendere tutti i componenti di Kubernetes e come si integrano fra di loro.

Kubernetes funziona quasi ovunque, su diverse versioni di Linux e grazie a diversi servizi cloud (link articolo “Servizi Cloud Kubernetes”), la compatibilità di questo tool con i sistemi operativi utilizzati in tutto il mondo rappresenta uno dei veri punti di forza di questo strumento.

Se date un’occhiata  al sito ufficiale di Kubernetes troverete una pagina della documentazione che riepiloga lo stato delle numerose combinazioni di distribuzione del sistema oltre a tutta una serie di guide introduttive che vi potranno dare alcuni spunti notevoli per una corretta installazione di Kubernetes in locale.

Detto questo, Kubernetes può essere distribuito in modalità autonoma, l’unica vera necessità è quella di avere Linux con Docker installato sulla propria macchina o su una virtual machine. 

Prima di entrare nel dettaglio diamo una ripassata all’architettura di Kubernetes, vi tornerà utile nel prosieguo della lettura: 

• Il master è il “piano di controllo” di Kubernetes e ha una serie di componenti a livello di cluster, incluso un server API che gli strumenti (ad esempio kubectl ) utilizzano per interagire con il cluster.
• Ogni nodo ha un servizio kubelet che riceve ordini dal master e un runtime del container (incluso ma non limitato a Docker) con cui si interfaccia per gestire le istanze del container. Vediamolo in azione e descriviamo ulteriormente questi componenti mentre li configuriamo.

Installazione Kubernetes in locale

Come descritto nella guida introduttiva, ci sono solo tre passaggi per ottenere un cluster autonomo attivo e funzionante, li vediamo insieme

Fase uno: eseguire etcd

docker run -d \

    –net=host \

    gcr.io/google_containers/etcd:2.0.9 \

    /usr/local/bin/etcd \

        –addr=127.0.0.1:4001 \

        –bind-addr=0.0.0.0:4001 \

        –data-dir=/var/etcd/data

Kubernetes utilizza etcd per archiviare in modo affidabile lo stato principale e la configurazione. I vari componenti master “osservano” questi dati e agiscono di conseguenza, ad esempio avviando un nuovo contenitore per mantenere un numero desiderato di repliche.

Fase due: eseguire il Master

docker run -d \

    –net=host \

    -v /var/run/docker.sock:/var/run/docker.sock \

    jetstack/hyperkube:v0.20.1 \

    /hyperkube kubelet \

        –api_servers=http://localhost:8080 \

        –v=2 \

        –address=0.0.0.0 \

        –enable_server \

        –hostname_override=127.0.0.1 \

        –config=/etc/kubernetes/manifests

Questo passaggio esegue un contenitore kubelet, che in questa distribuzione locale esegue a sua volta i componenti a livello di cluster che formano il “piano di controllo” principale di Kubernetes.

• Server API : fornisce l’API Kubernetes RESTful per gestire la configurazione del cluster, supportata dal datastore etcd.
• Scheduler : posiziona i pod sui nodi in base a regole (ad es. etichette). In questa fase, lo scheduler è semplice ma, come la maggior parte dei componenti in Kubernetes, è configurabile.
• Controller Manager : gestisce tutte le funzioni a livello di cluster, inclusa la creazione/aggiornamento degli endpoint, il rilevamento dei nodi, la gestione e il monitoraggio e la gestione dei pod.

Passaggio tre: eseguire il proxy di servizio

docker run -d \

   –net=host \

   –privileged \

   jetstack/hyperkube:v0.20.1 \

   /hyperkube proxy \

        –master=http://127.0.0.1:8080 \

        –v=2

Il proxy ( kube-proxy ) viene eseguito su ciascun nodo e fornisce un semplice proxy di rete e capacità di bilanciamento del carico. Questo proxy consente di esporre i servizi con un indirizzo di rete e un nome stabili.

A questo punto dovremmo avere un cluster Kubernetes eseguibile localmente. Per essere sicuri che tutto sia a posto, potete usare Docker ps per controllare le istanze del contenitore in esecuzione; dovrebbe essere simile a questo che vedete nell’immagine qui sotto (diverse colonne sono state omesse per brevità):

IMMAGINE	COMANDO
jetstack/hyperkube:v0.20.1	/hyperkube proxy
jetstack/hyperkube:v0.20.1	/hyperkube scheduler
jetstack/hyperkube:v0.20.1	/hyperkube apiserver
jetstack/hyperkube:v0.20.1	/hyperkube controller
gcr.io/google_containers/pause:0.8.0	/pause
jetstack/hyperkube:v0.20.1	/hyperkube kubelet
gcr.io/google_containers/etcd:2.0.9	/usr/local/bin/etcd

tag alt = installazione Kubernetes

Per interagire con il cluster dobbiamo utilizzare lo strumento CLI di kubectl. Può essere scaricato  pre-costruito direttamente da Google (nota 0.20.1 è l’ultima versione al momento della scrittura).

wget https://storage.googleapis.com/kubernetes-release/release/v0.20.1/bin/linux/amd64/kubectl

chmod u+x kubetctl

sudo  mv kubectl /usr/local/bin/

Il modo più rapido per avviare un container nel cluster consiste nell’usare il comando kubectl run. Quindi, ad esempio, per avviare un container Nginx, potrete utilizzare il comando e fare riferimento al nome dell’immagine del contenitore.

kubectl run web –image=nginx

Sebbene ciò sia conveniente e adatto per la sperimentazione, le risorse come i pod vengono generalmente create utilizzando artefatti di configurazione che possono avere dei vantaggi dal fatto che possano essere versionati con GIT, quindi ad esempio facilitando i rollback.

Se si usa YAML (o JSON), viene dichiarato un pod e il suo stato desiderato; è compito poi di Kubernetes garantire che questo pod esista sempre in base a questa specifica fino a quando non viene eliminato.

Ecco un semplice esempio di configurazione di un pod per quel pod nginx (file nginx-pod.yml).

apiVersion: v1

kind: Pod

metadata:

 name: nginx

 labels:

   app: web

spec:

 containers:

   – name: nginx

     image: nginx

Questo esegue la stessa immagine del  container (nginx) di cui sopra, ma in questo caso la configurazione della risorsa specifica alcuni metadati aggiuntivi, ad esempio un’etichetta (coppia chiave/valore) che assegna a questo pod un’etichetta del tipo “app” di “web”. 

kubectl create -f nginx-pod.yml

Kubernetes, in background, istruirà un nodo per estrarre l’immagine del contenitore avviando a sua volta il medesimo container.

A questo punto userete di nuovo kubectl pochi istanti dopo e dovresti essere in grado di vedere il pod nginx in esecuzione.

$ kubectl get pods

POD    IP              CONTAINER(S)  IMAGE(S)   HOST                     LABELS     STATUS    CREATED

web1   172.17.0.1      nginx         nginx      127.0.0.1/127.0.0.1      app=web  Running   About a minute web1

Come richiesto, un contenitore Nginx è ora in esecuzione in un pod (web1-qtlc1 in questo caso) e gli è stato inoltre assegnato un indirizzo IP. In Kubernetes, a ogni pod viene assegnato un indirizzo IP da una rete interna e questo significa che i pod possono comunicare tra loro, peraltro, in questo caso abbiamo distribuito Kubernetes con Docker utilizzando la rete host (–net=host) e questi indirizzi IP saranno accessibili localmente.