Passa ai contenuti principali

k3OS - La base del Cloud Aperto




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-data
E poi:


k3os-5757 [~]$ kubectl delete node <node-name>
Per visualizzare i servizi di una rete:



k3os-5757 [~]$ kubectl get all --all-namespaces=true







Licenza Creative Commons
Quest'opera è distribuita con Licenza Creative Commons Attribuzione 4.0 Internazionale (CC BY 4.0) - Condividi allo stesso modo

Commenti

Post popolari in questo blog

Alzatapparella con Shelly 2 e Alexa

Alzatapparella con Shelly 2 e Alexa

Qui spiego tutti i passaggi per installare lo Shelly 2 per automatizzare una tapparella e come configurarlo in Alexa.

Impianto attuale




Collegamenti da effettuare:

Schema teorico:





Collegamenti reali:



Impostazioni:

Dopo aver collegato tutto si procede alla configurazione.
Prima di tutto installare la App "Shelly" cercandola nel proprio store e create un account:

















Telecamere Ip con accesso "nascosto"

Telecamere Ip con accesso "nascosto"Storia triste di un auto-hacking obbligato che mi ha fatto scoprire come la nostra privacy è realmente messa a rischi.


Storia
Ho acquistato dal mercatino/fiera del Radioamatore di Fasano quattro telecamere IP. La scatola riporta "Smart Camera" LF4810.




Ne ho montata una e testata in tutte le sue funzionalità per oltre un mese. Chiaramente la manualistica scarsissima, come da tradizione in questi prodotti cinesi di costo molto concorrenziale, consiste in un "pieghevole" di 4 facciate.
Chiaramente non erano documentate le impostazioni necessarie per attivare i protocolli ONVIF e RTSP che mi sono indispensabili per l'uso che ne devo fare. Nonostante questa scarsa documentazione dopo l'installazione base fatta con l'apposita app:




tutto sembrava corretto. Chiaramente la prima azione che ho compiuto è stata quella di cambiare la password che di default è "123".
Subito dopo ho ricavato l'ip che il mio DHCP l…

JHipster - Microservizi 1

Microservizi - 1

Introduzione
In questo post descrivo come creare una architettura a microservizi con JHipster. ArchitetturaMicroservizio
Il microservizio che andremo a creare deve avere totale autonomia ed essere auto-consistente. Questo dice la letteratura. In effetti il microservizio deve svolgere un servizio "completo" a livello di modulo di business logic. Ad esempio in un sistema complesso la gestione delle mail integrata. Quindi deve fornire servizi come l'elenco delle mail di uno specifico utente, crearne, cancellarne, inviarne di nuove. Per fare questo userà il database per accedere alla lista della mail dello specifico utente (che qui ipotizziamo stiano su un db). Questo quello che deve fare. Quello che NON deve fare è autenticare l'utente che gli invia le richieste. Quindi di questa fase se ne occuperà un altro modulo. L'autenticazione, in questo prototipo, avverrà mediante token JWT. Creaiamo il microservizio.
Creato con il wizard di JHipster selezionando il…