Come installare eksctl su Ubuntu Linux passo dopo passo

Su Ubuntu, eksctl si installa in modo pulito in pochi minuti, ma conviene farlo con una regola chiara: prima si verifica l’architettura del sistema, poi si scarica il binario corretto, infine si controlla che la versione sia quella attesa. Saltare uno di questi passaggi porta spesso a errori banali ma fastidiosi, come eseguibili non compatibili, permessi sbagliati o PATH non aggiornato.

eksctl è il tool CLI più usato per creare e gestire cluster Amazon EKS senza passare ogni volta dalla console AWS. Su Ubuntu non dipende da un pacchetto APT ufficiale nella maggior parte dei casi d’uso: la strada più robusta è il download del binario pubblicato dal progetto, con verifica della release e installazione in una directory già presente nel PATH, tipicamente /usr/local/bin.

Verifica preliminare del sistema Ubuntu

Prima di installare qualunque binario, conviene capire su quale macchina stai operando. Il punto critico è l’architettura: amd64 e arm64 richiedono file diversi. In ambienti cloud e VPS moderne non è raro trovare ARM, soprattutto su istanze economiche o ottimizzate per efficienza.

Esegui questi controlli:

uname -m
lsb_release -a
which curl
which unzip

Interpretazione rapida: x86_64 indica un sistema amd64; aarch64 o arm64 indicano architettura ARM a 64 bit. Se curl o unzip mancano, installali prima perché servono quasi sempre nel flusso di installazione e aggiornamento.

sudo apt update
sudo apt install -y curl unzip

Se il server è gestito da più persone, conviene anche verificare se esiste già una versione di eksctl installata manualmente o tramite script precedente:

command -v eksctl
eksctl version

Se il comando risponde con una versione valida, l’installazione potrebbe essere già presente. In quel caso, prima di sovrascrivere tutto, conviene capire se serve un semplice aggiornamento oppure una pulizia della precedente copia. Questo evita di avere più binari in percorso diverso e comportamenti incoerenti tra shell interattiva e automazione.

Installazione consigliata con binario ufficiale

Il metodo più lineare su Ubuntu è scaricare il binario della release dal repository ufficiale del progetto e copiarlo in /usr/local/bin. È una scelta pratica perché non dipende da repository esterni del sistema e non introduce pacchetti accessori inutili.

Il flusso generale è questo: si determina la versione da installare, si scarica l’archivio corrispondente all’architettura, si estrae il binario e lo si rende eseguibile. Di seguito un esempio con versione esplicita; sostituisci vX.Y.Z con la release reale che vuoi installare.

VER="vX.Y.Z"
ARCH="amd64"

curl -L -o /tmp/eksctl.tar.gz \
  "https://github.com/eksctl-io/eksctl/releases/download/${VER}/eksctl_Linux_${ARCH}.tar.gz"

sudo tar -xzf /tmp/eksctl.tar.gz -C /usr/local/bin eksctl
sudo chmod +x /usr/local/bin/eksctl

Se sei su ARM, cambia ARCH in arm64. Il nome esatto del file release può variare a seconda della pubblicazione; se il download fallisce con errore 404, non forzare tentativi casuali: apri la pagina delle release del progetto e verifica il nome preciso dell’asset disponibile per quella versione.

Dopo l’estrazione, verifica che il binario sia davvero nel posto giusto:

ls -l /usr/local/bin/eksctl
file /usr/local/bin/eksctl

Il comando file deve indicare un eseguibile ELF compatibile con la tua architettura. Se mostra architettura errata, hai scaricato il pacchetto sbagliato: non tentare workaround con symlink, perché il problema non è nel PATH ma nel binario.

Installazione rapida con script di bootstrap

In alcuni casi viene usato uno script che automatizza download e posizionamento del binario. È comodo, ma io lo considero una scorciatoia da usare solo quando hai chiaro cosa fa lo script e da dove proviene. In produzione o su host condivisi preferisco sempre vedere URL, versione e destinazione finale in chiaro.

Se scegli questa strada, il vantaggio è la velocità; il limite è che dipendi dall’affidabilità dello script remoto. Per questo è meglio conservarne una copia locale o, almeno, ispezionare il contenuto prima dell’esecuzione.

curl -L https://github.com/eksctl-io/eksctl/raw/main/user_data/bootstrap.sh -o /tmp/bootstrap-eksctl.sh
sed -n '1,200p' /tmp/bootstrap-eksctl.sh

Se il contenuto ti torna, eseguilo solo dopo aver verificato che la logica di installazione corrisponda alle tue aspettative. In pratica, controlla sempre tre cose: URL di download, directory di destinazione e eventuale cleanup di file temporanei.

Verifica della versione installata

Dopo l’installazione, la verifica non è un optional. Il comando deve rispondere e la versione deve essere quella attesa. Anche qui non basta che “funzioni”: serve coerenza, soprattutto se in seguito usi eksctl in script CI/CD o in procedure operative condivise.

eksctl version
command -v eksctl

Un risultato sano è qualcosa del tipo eksctl version X.Y.Z e un percorso come /usr/local/bin/eksctl. Se invece il comando non viene trovato, il problema più probabile è il PATH; se la versione non coincide, potresti avere un altro binario installato in precedenza e con precedenza nel PATH.

Per vedere l’ordine con cui la shell cerca gli eseguibili:

echo "$PATH"
compgen -c eksctl | head

Se /usr/local/bin non è nel PATH, il sistema non vedrà il binario appena installato. In una shell standard di Ubuntu dovrebbe esserci; se manca, il problema è nella configurazione dell’ambiente utente o del servizio che lancia il comando, non in eksctl.

Aggiornamento senza rompere l’ambiente

eksctl viene aggiornato spesso, e in un ambiente operativo conviene trattarlo come un tool da manutenere, non come un software “installato una volta e basta”. L’aggiornamento corretto segue la stessa logica dell’installazione: backup della versione corrente, sostituzione controllata, verifica immediata.

Prima di sovrascrivere il binario, conserva una copia della release in uso. È un rollback semplice e veloce nel caso l’upgrade introduca un comportamento inatteso in uno script o in una pipeline.

sudo cp /usr/local/bin/eksctl /usr/local/bin/eksctl.bak
# poi scarichi la nuova release e la sostituisci
sudo tar -xzf /tmp/eksctl.tar.gz -C /usr/local/bin eksctl
eksctl version

Se il nuovo binario non si comporta come previsto, il rollback è immediato:

sudo mv /usr/local/bin/eksctl.bak /usr/local/bin/eksctl
sudo chmod +x /usr/local/bin/eksctl
eksctl version

Questo approccio ha un blast radius minimo: impatta solo il binario locale e non modifica configurazioni di Kubernetes, credenziali AWS o file di progetto. È il modo giusto di gestire un upgrade di tool CLI in ambienti dove la ripetibilità conta più della comodità.

Installazione in ambiente multiutente o server condiviso

Su un server condiviso la domanda non è solo “come installo eksctl”, ma anche “chi lo userà e con quali permessi”. Il binario può stare in /usr/local/bin per renderlo disponibile a tutti, ma l’accesso effettivo alle API AWS dipende dalle credenziali dell’utente che lo esegue.

Per questo motivo conviene separare nettamente i livelli: il tool di sistema da un lato, le credenziali AWS dall’altro. Non mettere chiavi in chiaro in file condivisi e non usare account con privilegi più alti del necessario solo perché “è più comodo”.

Una buona pratica è testare il comando con l’utente reale che lo userà, non solo con root. Se lanci eksctl come utente normale, verifica che la configurazione AWS sia disponibile nel suo profilo oppure tramite ruoli temporanei e meccanismi standard del tuo ambiente.

sudo -u nomeutente eksctl version
sudo -u nomeutente aws sts get-caller-identity

Il secondo comando non serve a installare eksctl, ma a confermare che l’identità AWS usata dal contesto operativo è quella corretta. Se eksctl è presente ma AWS non risponde, il problema non è l’installazione del tool: è l’autenticazione o il profilo credenziali.

Problemi comuni e come riconoscerli in fretta

Il primo errore tipico è il download del file sbagliato per architettura o versione. Lo riconosci subito perché l’esecuzione fallisce con messaggi come Exec format error oppure con un binario che non parte proprio. In quel caso la correzione è riscaricare l’asset giusto, non cambiare permessi o riprovare più volte.

Il secondo errore tipico è l’assenza di permessi di esecuzione. Si risolve con chmod +x, ma solo dopo aver verificato che il file scaricato sia quello corretto. Un file corrotto reso eseguibile resta comunque inutilizzabile.

ls -l /usr/local/bin/eksctl
chmod +x /usr/local/bin/eksctl
eksctl version

Il terzo errore è il PATH incompleto. È frequente nei servizi systemd, nei container o negli script lanciati da cron, dove l’ambiente non è quello della shell interattiva. In questi casi il binario può esserci, ma il processo non lo trova. La soluzione è usare il path assoluto o definire un PATH esplicito nel servizio o nello script.

Se usi systemd, un controllo rapido è:

systemctl cat nome-servizio
systemctl show nome-servizio -p Environment
journalctl -u nome-servizio -n 50 --no-pager

In questo modo capisci se il servizio ha un PATH diverso o se sta invocando un vecchio binario da un percorso non previsto. È un dettaglio che spesso spiega “funziona a mano ma non in automatico”.

Uso minimo per validare che eksctl risponda correttamente

Dopo l’installazione, il test più utile non è subito creare un cluster, ma verificare che il tool veda correttamente la configurazione AWS e che parli con l’account giusto. Il comando sotto non modifica nulla e ti dà un segnale rapido sulla bontà dell’ambiente.

eksctl get clusters
aws sts get-caller-identity

Il primo comando può restituire una lista vuota se non hai cluster EKS, e va benissimo. L’importante è che non fallisca per problemi di binario o autenticazione. Il secondo conferma l’identità AWS effettiva. Se uno dei due non funziona, hai già ristretto il problema: installazione del tool, credenziali o permessi IAM.

Quando conviene scegliere un metodo diverso

In ambienti molto controllati potresti preferire un pacchetto gestito centralmente, un mirror interno o un’immagine container con eksctl già presente. Ha senso se devi standardizzare decine di host o se vuoi evitare download diretti da Internet su macchine non esposte. In quel caso la logica non cambia: stesso binario, stessa verifica, stesso controllo della versione.

Se invece stai lavorando su una workstation o su una VM temporanea, il binario ufficiale resta la scelta più pragmatica. Poche dipendenze, installazione rapida, rollback semplice. Per il tipo di utilizzo tipico di eksctl, è spesso il compromesso migliore tra semplicità e controllo.

Checklist finale operativa

Prima di considerare chiusa l’installazione, passa questa checklist rapida:

• uname -m conferma l’architettura corretta.

• command -v eksctl restituisce /usr/local/bin/eksctl o il percorso previsto.

• eksctl version mostra la release attesa.

• aws sts get-caller-identity conferma l’identità AWS del contesto operativo.

• Se hai aggiornato il binario, il backup eksctl.bak è disponibile per un rollback immediato.

Se uno di questi punti non torna, non andare oltre con la creazione del cluster. Prima chiudi il problema di base: binario, ambiente o credenziali. È il modo più veloce per evitare di trasformare un’installazione semplice in un debug lungo e inutile.