🥇Introduzione a Kustomize

Nota di traduzione.: L'articolo è stato scritto da Scott Lowe, un ingegnere con una lunga carriera nel settore IT, autore/coautore di sette libri pubblicati (principalmente su VMware vSphere). Attualmente lavora nella sua filiale VMware - Heptio (acquisita nel 2016), specializzandosi in cloud computing e Kubernetes. Il testo serve come un'introduzione concisa e facilmente comprensibile alla gestione delle configurazioni per Kubernetes tramite la tecnologia Kustomize, recentemente integrata in K8s.

Kustomize è uno strumento che consente agli utenti di "personalizzare file YAML semplici e privi di template per vari scopi, lasciando intatto l'originale YAML e utilizzabile" (descrizione presa direttamente dal repository kustomize su GitHub). Kustomize può essere eseguito direttamente o, a partire da Kubernetes 1.14, utilizzato con kubectl -k per accedere alle sue funzioni (anche se, a partire da Kubernetes 1.15, un binario separato è più recente delle funzionalità integrate in kubectl). (Nota di traduzione.: Con il recente rilascio di Kubernetes 1.16 kustomize è supportato è disponibile anche nell'utility kubeadm.) In questo articolo, voglio introdurre i lettori alle basi di kustomize.

Nella sua forma/sotto applicazione più semplice, kustomize è semplicemente un insieme di risorse (file YAML che definiscono oggetti Kubernetes: Deployments, Services, ecc.) più un elenco di istruzioni sui cambiamenti che devono essere apportati a queste risorse. Analogamente a come make utilizza un set di istruzioni contenuto in Makefile, e Docker costruisce un'immagine del container sulla base delle istruzioni presenti in Dockerfile, kustomize utilizza kustomization.yaml per memorizzare le indicazioni su quali modifiche l'utente desidera apportare all'insieme di risorse.

Ecco un esempio di file kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Non cercherò di parlare di tutti i possibili campi nel file kustomization.yaml (di questo è stato scritto bene qui), ma fornirò una breve spiegazione di un esempio specifico:

Campo resources indica quali (quali risorse) kustomize cambierà. In questo caso, cercherà risorse nei file deployment.yaml e service.yaml nella sua directory (è possibile specificare percorsi completi o relativi, se necessario).
Campo namePrefix ordina a kustomize di aggiungere un certo prefisso (in questo caso - dev-) all'attributo name di tutte le risorse definite nel campo resources. Quindi, se nel Deployment c'è name con valore nginx-deployment, kustomize lo trasformerà in dev-nginx-deployment.
Campo namespace prescrive a kustomize di aggiungere lo spazio dei nomi specificato a tutte le risorse. In questo caso, Deployment e Service rientreranno nello spazio dei nomi sviluppo.
Infine, il campo commonLabels contiene un insieme di etichette che saranno aggiunte a tutte le risorse. Nel nostro esempio, kustomize assegnerà alle risorse un'etichetta con il nome ambiente e il valore sviluppo.

Se l'utente esegue kustomize build . nella directory con il file kustomization.yaml e le risorse necessarie (ovvero i file deployment.yaml e service.yaml), all'uscita otterrà un testo con le modifiche specificate in kustomization.yaml.

Nota di traduzione.: Illustrazione dalla documentazione del progetto sull'uso "semplice" di kustomize

L'output può essere reindirizzato, se necessario per registrare le modifiche:

kustomize build . > custom-config.yaml

L'output è deterministico (con gli stessi dati in input si otterranno gli stessi risultati in output), quindi non è necessario salvare il risultato in un file. Invece, può essere passato direttamente a un altro comando:

kustomize build . | kubectl apply -f -

L'accesso alle funzionalità di kustomize può essere ottenuto anche tramite kubectl -k (a partire dalla versione 1.14 di Kubernetes). Tuttavia, tenete presente che un pacchetto kustomize separato si aggiorna più rapidamente rispetto a quello integrato in kubectl (perlomeno, così è per la versione di rilascio di Kubernetes 1.15).

I lettori possono chiedere: "Perché tutte queste complicazioni, se posso modificare i file direttamente?". Ottima domanda. Nel nostro esempio, è effettivamente è possibile modificare i file deployment.yaml e service.yaml direttamente, ma cosa succede se sono un fork di un progetto di qualcun altro? Modificare direttamente i file rende difficile (se non impossibile) il rebase del fork, quando vengono apportate modifiche all'origine. Utilizzare kustomize consente di centralizzare queste modifiche in un file kustomization.yaml, lasciando i file originali intatti e, in tal modo, facilitando il rebase dei file originali, se necessario.

I vantaggi di kustomize diventano evidenti in casi d'uso più complessi. Nell'esempio sopra kustomization.yaml e le risorse si trovano nella stessa directory. Tuttavia, kustomize supporta scenari d'uso in cui esiste una configurazione di base e molte sue varianti, conosciute anche come overlay. Ad esempio, un utente ha voluto utilizzare il Deployment e il Service per nginx, che ho usato come esempio, e creare versioni (o varianti) per development, staging e production di quei file. Per questo avrà bisogno degli overlays menzionati in precedenza e, in definitiva, delle risorse di base stesse.

Per illustrare l'idea degli overlays e delle risorse di base (risorse di base), supponiamo che le directory abbiano la seguente struttura:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

Nel file base/kustomization.yaml gli utenti utilizzando il campo resources dichiarano semplicemente le risorse che kustomize deve includere.

In ciascuno dei file overlays/{dev,staging,prod}/kustomization.yaml gli utenti si riferiscono alla configurazione di base nel campo resources, e poi specificano le modifiche specifiche per questo ambiente. Ad esempio, il file overlays/dev/kustomization.yaml può apparire come l'esempio fornito in precedenza:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Nel frattempo, il file overlays/prod/kustomization.yaml può essere completamente diverso:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

Quando l'utente eseguirà kustomize build . nella directory overlays/dev, kustomize genererà la variante development. Se invece viene eseguito kustomize build . nella directory overlays/prod , si otterrà la variante production. E tutto questo — senza apportare alcuna modifica ai file originali (base) , e tutto questo — in modo dichiarativo e deterministico. È possibile committare la configurazione di base e le directory di overlay direttamente nel sistema di controllo versione, sapendo che sulla base di questi file è possibile riprodurre la configurazione desiderata in qualsiasi momento.

Nota di traduzione.: Illustrazione dalla documentazione del progetto sull'uso degli overlays in kustomize

Kustomize è in grado di fare molto di più di quanto sia stato detto in questo articolo. Tuttavia, spero che questo serva come una buona introduzione.

Risorse aggiuntive

Ci sono molti articoli e pubblicazioni interessanti su kustomize. Ecco alcuni che ho trovato particolarmente utili:

Nota di traduzione.: Si consiglia anche un blocco di link, pubblicato come Risorse sito dell'utilità, e una successiva collezione di video con le ultime presentazioni su kustomize.

Se hai domande o suggerimenti su come migliorare questo materiale, sono sempre aperto a feedback. Puoi contattarmi su Twitter oppure nel canale Slack di Kubernetes. Goditi il piacere di modificare i tuoi manifesti con kustomize!

Kubernetes 1.15: novità principali

Risorse aggiuntive

P.S. dal traduttore