Oramai è più di un anno che Bottlerocket è stato reso disponibile a tutti. Con il proliferare del cloud e dei vari big del settore, come Microsoft, Google ed Amazon, abbiamo iniziato a vedere gli stessi iniziare a proporre delle proprie soluzioni in termini di distribuzioni Linux. Compresa Bottlerocket, nata dalle mani di Bezos con l’idea di sopperire alla -ai tempi- presunta scomparsa di CoreOS (o meglio, il suo assorbimento da parte di Red Hat).

Adesso che la situazione di questa nuova distribuzione pare essere ben strutturata, e che le immagini disponibili su AWS sono state pian piano tunate a dovere, è giunto il momento per Amazon di fare il passo successivo.

E, considerando quello di cui si parla di più negli ultimi anni, quale sarà questo passo? Ma Kubernetes, ovviamente!

Qualche giorno fa, infatti, sul blog di Amazon è apparso l’annuncio ufficiale della disponibilità di Bottlerocket come OS ufficiale per i cluster EKS, il servizio Kubernetes offerto dall’azienda, promettendo di portare i vantaggi tanto decantati della distro di Seattle -semplicità di gestione, sicurezza migliorata e minor overhead dei servizi- anche come nodo per l’erogazione dei propri Pod.

La creazione pare essere semplicissima, nel classico stile EKS: basta inserire Bottlerocket come “amiFamily” nel consueto yaml passato ad eksctl -la versione in salsa Amazon di kubectl per EKS- e si avranno in breve tempo dei nodi Bottlerocket nel proprio cluster.

Inoltre, stando a quanto riportato nel post, l’uso di Bottlerocket permette due vantaggi rispetto ad altre distribuzioni utilizzabili come nodi di EKS:

• integrazione nativa delle API per conoscere lo stato e schedulare upgrade dei nodi in maniera remota ed automatizzabile;
• funzionamento al 100% di tutte le attuali API di EKS per la gestione degli update, rendendo più semplice anche l’aggiornamento del cluster Kubernetes.

Ovviamente, di contro, questa distribuzione nasce per essere minimale ed, una volta rilasciato un nodo, l’unico modo per aggiungere agent esterni (basti pensare al molto usato Prometheus) è necessario utilizzare i Daemonsets o gli “static pod”, poichè nelle immagini non è presente un package manager per l’aggiunta di software a runtime. E quindi, per ambienti più cuciti intorno alle proprie necessità, sarà necessario utilizzare immagini differenti o utilizzare il bootstrap container per crearsi la propria immagine prima dell’avvio della stessa.

Insomma, dei compromessi saranno necessari, però c’è da dire che possiamo supporre che l’avere una distribuzione di casa Amazon in un servizio fornito da Amazon porterà l’azienda a tenere un occhio di riguardo sul suo funzionamento. Se dobbiamo usare quel servizio, potrebbe valer la pena provare ad esplorare anche questa nuova distribuzione.

Matteo Cappadonna

Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.