Quando abbiamo parlato la prima volta di k0s, nell’articolo “Per voi è troppo k8s? Avete provato k3s e lo trovate esoso? Arriva Mirantis con il suo k0s, Kubernetes in un eseguibile“, avevamo analizzato in maniera approssimativa le funzionalità di questa soluzione, senza approfondire.
L’occasione di rimediare viene però data dall’annuncio da parte di Mirantis della disponibilità della versione 1.27 di k0s che segue chiaramente Chill Vibes, la nuova release di Kubernetes.
L’aspetto su cui punta Mirantis per promuovere k0s è in prima istanza quello della sicurezza. Infatti ciò che è garantito dall’azienda proprietaria di Docker è il fatto che l’eseguibile viene distribuito senza alcuna CVE conosciuta riscontrabile.
Per chiarire meglio riportiamo le parole di Miska Kaipiainen, VP of engineering, product strategy, and open source in Mirantis:
Before 1.27, k0s relied on system images published by various upstream projects, this has worked pretty well, but there are some downsides. For one thing, it’s understood (sadly) that most upstream system images used by Kubernetes contain CVEs.
Prima della 1.27 k0s si basava sulle immagini di sistema pubblicate dai vari progetti upstream, e questo ha funzionato bene, ma con qualche controindicazione. Per prima cosa, è risaputo che (tristemente) la maggioranza delle immagini di sistema upstream usate da Kubernetes contiene CVE.E la soluzione a questo è citata appunto nella nuova modalità con cui k0s è prodotto:
Starting with this 1.27 release, k0s will run all system components with images that we build ourselves. We still use pure upstream functionality and do not use any custom forks of project components. Essentially what we do is take the upstream components as-is and rebuild the images in a way that mitigates as many known CVEs as possible.
A partire da questa release 1.27 tutte le componenti di sistema con cui funzionerà k0s si baseranno su immagini che costruiremo per nostro conto. Usiamo ancora le funzionalità upstream, senza fare fork delle componenti di progetto. Quello che facciamo è essenzialmente prendere le componenti upstream come sono e farne la rebuild in modo da mitigare più CVE possibili.Le premesse quindi sembrano interessanti, ma nella pratica come funziona questo k0s?
Installare k0s
L’installazione di k0s potrebbe essere fatta lanciando direttamente un file .sh da internet, ma non essendo particolarmente fan di questa modalità, qualcosa di più canonico funziona ugualmente:
Una volta che l’eseguibile è disponibile si può avviare la creazione del controller e l’avvio del cluster:
Da qui in poi il Kubernetes di k0s sarà accessibile mediante sudo k0s kubectl o, se avete già kubectl disponibile sul vostro sistema (come in questo caso) andando a creare il file kubeconfig di k0s che conterrà tutte le informazioni di accesso:
Il cluster è quindi pronto all’uso.
Deploy di un’applicazione
k0s è Kubernetes ed in questo senso la creazione di un deployment e del relativo servizio può essere fatta nella consueta modalità:
In questo test k0s è stato installato in una macchina virtuale non particolarmente potente (2 CPU, 4 GB RAM), ma i tempi di risposta sono davvero eccellenti, ed in pochi secondi l’applicazione di test (il webserver nginx) è disponibile:
A proposito di servizi
A questo punto, nella maggioranza degli ambienti Kubernetes verrebbe il dubbio in merito a come esporre i servizi all’esterno del cluster poiché il servizio creato qui sopra è di tipo ClusterIP, quindi visibile unicamente all’interno della rete cluster. Ci vorrebbe una componente ingress e verosimilmente un load balancer, entrambi non presenti di default in k0s.
C’è però un aspetto molto interessante di k0s che vale la pena citare, e lo si introduce andando a stampare lo stato delle interfacce di rete presenti nel sistema dopo l’installazione, ponendo attenzione sul device kube-bridge:
E visualizzando le regole di NAT del firewall, create in automatico mediante nft, relative all’indirizzo IP del servizio che abbiamo creato, ossia 10.106.130.151:
Quindi sì, kube-bridge viene usata dalle regole per mettere in comunicazione l’host con la rete cluster di Kubernetes, consentendo quindi l’accesso diretto ai servizi di tipo ClusterIP:
In questo modo il test di eventuali applicazioni risulta assolutamente immediato e non vi è necessità di effettuare il deploy di componenti aggiuntive, comunque supportate da k0s, quali Ingress NGINX come ingress controller o MetalLB come load balancer.
Conclusioni
Se le esigenze poi esulano dai semplici test va sottolineato come k8s sia a tutti gli effetti adatto alla produzione, infatti mediante l’utilizzo di k0ctl è possibile creare e gestire istanze multiple di k0s attraverso un semplice yaml, in maniera centralizzata, andando a risolvere anche la problematica di gestione multi-cluster.
Mica male per un singolo eseguibile!
Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.
English (US)