k3OS - La base del Cloud Aperto
Premessa
Esiste un problema alla base dell'uso di un qualsiasi sistema operativo per far girare Kubernetes su un nodo di un cluster per la containerizzazione: dover manutenere (configurare, patchare, aggiornare e fare il backup) di più entità separate ma dipendenti che sono il Sistema Operativo, Kubernetes e i container.
L'idea, che approfondisco in questo post, venuta a quelli di Rancher è di creare una distro con Kubernetes ad-hoc da manutenere con Kubernetes stesso.
Perchè Kubernetes ? Perché è diventato uno standard de-facto per quanto riguarda il containers management adottato dai maggiori fornitori di cloud pubblico.
Quindi questo significa che adottare Kubernetes significa predisporre una infrastruttura, di cloud ibrido, generalizzata che può appoggiarsi ad uno qualsiasi dei fornitori di cloud pubblico alla bisogna (picchi di carico).
Architettura
Il cluster
L'obiettivo è la costruzione di un cluster di nodi che consenta di eseguire delle istanze di applicazioni server a partire da immagini fornite. Ogni nodo può essere un server, una macchina virtuale o un dispositivo IoT. Ogni nodo è un elemento capace di far girare una o più istanze di immagini di container. Ogni nodo capace di far girare i container nell'accezione di Kubernetes si chiama "worker". Ogni worker deve essere registrato presso un Register.
Ogni nodo worker in Kubernetes è costituito da uno stack software che si chiama K3S:
L'idea che hanno avuto in K3OS è stata quella di creare una distribuzione Linux completa di tutto ciò che serve per fare da nodo in Kubernetes:
K3OS
La distribuzione k3Os prevede tutto il necessario per fare in modo che il nodo venga gestito completamente da Kubernetes, venga avviato rapidamente e possa girare, eventualmente, anche su risorse di scarsa potenza.
Questo perché si possano sfruttare hardware non potente ma numeroso (datacenter con dispositivi datati o IoT) che messo in cluster possa raggiungere la potenza necessaria a svolgere compiti che altrimenti richiederebbero aggiornamenti costosi. Inoltre, l'avvio rapido è utile nelle situazioni critiche che richiedono l'avvio di una nuova istanza di container a partire da una immagine per sopperire a situazioni di carico eccezionale. L'avvio rapido del nodo e dei container gestiti dal worker è una garanzia di rapidità nello scalare i servizi forniti.
K3os è stato dotato di un wizard con il quale è facile configurare i nodi e la componente "Server" e quella "Agent".
L'agent è la componente che effettivamente farà girare i container, che nell'accezione di Kubernetes vengono detti "Pod". Mentre la componente server fornirà la parte di "controller" e "scheduler" oltre alle API con le quali controllare i nodi.
Rancher
Queste API vengono usate, ad un più alto livello per consentire la gestione centralizzata di più cluster Kubernetes, da un "Container Manager" che si chiama Rancher. Grazie a questa ulteriore astrazione si ha la possibilità di controllare i cluster Kubernetes su cloud privato ma anche pubblico.
La soluzione Rancher deve fare da "integratore" fra le fasi e gli attori del processo di sviluppo rendendo semplice e locale la gestione di tutte le componenti necessarie dal repository delle immagini ("Service Catalog") alla applicazione che fa CI/CD, all'Alerting ma anche per quanto riguarda il controllo dei costi, la sicurezza e la fornitura dei servizi ai clienti. Tutte queste componenti le si potrà, grazie all'uno di Kubernetes, ripartire fra datacenter bare metal privati, virtuali e cloud pubblico.
Installazione
Configurazione HA
La soluzione che uso per il prototipo prevede l'approccio "Single Master" che NON prevede l'High-Availability che è raccomandata in ambiente di produzione.
Un cluster k3s con HA prevede:
- due o più nodi server che forniscono le API di Kubernetes ed eseguono gli altri servizi di controllo
- un archivio dati esterno per la persistenza
- un indirizzo di registrazione fisso messo davanti ai nodi server per consentire ai nodi worker di registrarsi con il cluster.
In questa configurazione ogni nodo è un server fisico o virtuale che esegue la parte server di k3s. Un nodo worker è una macchina che esegue la parte agent di k3s.
I nodi worker si registrano attraverso l'indirizzo di registrazione fisso, ma dopo tale registrazione stabiliscono una connessione diretta con uno dei nodi server. Questa è una connessione websocket avviata dall'agent k3s e mantenuta lato client dal load balancer che è in esecuzione con il processo agent.
Per i dettagli in fase di realizzazione dell'impianto di produzione vedere qui.
Server
Avviare una macchina virtuale facendole puntare la iso scaricabile qui.
Loggarsi con l'utente "rancher" senza password. Lanciare il wizard come super utente: "sudo os-config". Seguire il wizard e configurare un nodo "Server".
Scegliere un "Tokern secret" da usare anche per l'agent.
Agent
Avviare una macchina virtuale facendole puntare la iso scaricabile qui.
Loggarsi con l'utente "rancher" senza password. Lanciare il wizard come super utente: "sudo os-config". Seguire il wizard e configurare un nodo "Agent".
ATTENZIONE: "URL of server:" deve essere nel formato
URL of server: https://10.10.252.192:6443
Rancher
Usiamo un container docker per lanciare rancher:
$ docker run -d --restart=unless-stopped --network host -p 80:50 -p 433:433 rancher/rancher
Puntando l'ip del server con un browser:
Scegliere una password per l'accesso ed indicare l'url del server Rancher:
Entrati nel pannello principale la dashboard sarà vuota.
Cliccare sul bottone "Add a Cluster" e scegliere "Import an existing cluster".
Assegnare un nome al cluster.
In basso comparirà l'istruzione da lanciare sul Sever node per fidelizzarlo. Copiare entrambe le istruzioni in un documento.
Lanciato questo sul server k3os VEDI SOPRA parte su rancher:
curl --insecure -sfL https://10.10.252.254/v3/import/6p5ddg89pqp7ghj7cmnmpqdnsctfjmv77fhzdkv2ppmk4x59mmw77p.yaml | kubectl apply -f -
OK lo vedo da Rancher:
kubectl get all --all-namespaces=true
non vedo nulla
se faccio cat /lib/var/rancher/k3os/config.yaml
token: demo
4) su un'altra vm con ubuntu server:
docker run -d --restart=unless-stopped -network host -p 80:50 -p 433:433 rancher/rancher
Abbiamo due nodi nel cluster uno risulta un "worker" e l'altro un "Contol Plane"
Basi di Kubernetes
Per visualizzare i nodi di un cluster:
k3os-5757 [~]$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
k3os-5041 Ready <none> 2m58s v1.16.3-k3s.2
k3os-5757 Ready master 16h v1.16.3-k3s.2
Per rimuovere un nodo:
k3os-5757 [~]$ kubectl drain <node-name> --ignore-daemonsets --delete-local-datak3os-5757 [~]$ kubectl delete node <node-name>k3os-5757 [~]$ kubectl get all --all-namespaces=true
Quest'opera è distribuita con Licenza Creative Commons Attribuzione 4.0 Internazionale (CC BY 4.0) - Condividi allo stesso modo
Commenti
Posta un commento