Breve introduzione a Kustomize

Nota del traduttore.: L'articolo è stato scritto da Scott Lowe, un ingegnere con una lunga esperienza nel settore IT, autore o coautore di sette libri cartacei (principalmente su VMware vSphere). Attualmente lavora per la sua controllata VMware — Heptio (acquisita nel 2016), specializzandosi in cloud computing e Kubernetes. Il testo serve come un'introduzione chiara e concisa alla gestione delle configurazioni per Kubernetes utilizzando la tecnologia Kustomize, recentemente integrata in K8s.

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

Nella sua forma più semplice kustomize è un insieme di risorse (file YAML che definiscono oggetti Kubernetes: Deployments, Services, ecc.) insieme a un elenco di istruzioni sui cambiamenti da apportare a queste risorse. Proprio come make utilizza un insieme di istruzioni contenute in Makefile, e Docker costruisce un contenitore in base alle istruzioni di Dockerfile, kustomize utilizza kustomization.yaml per memorizzare le prescrizioni su quali cambiamenti l'utente desidera apportare al set di risorse.

Ecco un esempio di file kustomization.yaml:

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

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

• Campo risorse indica quali risorse kustomize modificherà. In questo caso cercherà risorse nei file deployment.yaml e service.yaml nella sua directory (è possibile specificare percorsi assoluti o relativi, se necessario).
• Campo namePrefix prescrive a kustomize di aggiungere un prefisso specifico (in questo caso — dev-) all'attributo name di tutte le risorse definite nel campo risorse. Così, se nel Deployment c'è name con il valore nginx-deployment, kustomize lo trasformerà in dev-nginx-deployment.
• Campo namespace insegna a kustomize di aggiungere lo spazio dei nomi specificato a tutte le risorse. In questo caso, Deployment e Service finiranno nello spazio dei nomi sviluppo.
• Infine, il campo commonLabels contiene un insieme di etichette che verranno aggiunte a tutte le risorse. Nel nostro esempio, kustomize assegnerà alle risorse un'etichetta chiamata environment e valore sviluppo.

Se l'utente esegue kustomize build . nella directory con il file kustomization.yaml e le risorse necessarie (cioè file deployment.yaml e service.yaml), allora in output riceverà il testo con le modifiche specificate in kustomization.yaml.

Nota del traduttore.: 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 sempre 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 è disponibile anche tramite kubectl -k (a partire dalla versione 1.14 di Kubernetes). Tuttavia, tieni presente che un pacchetto kustomize separato si aggiorna più rapidamente rispetto a quello integrato in kubectl (perlomeno, questo è il caso con il rilascio di Kubernetes 1.15).

I lettori possono chiedere: «Perché tutte queste complessità, se posso modificare i file direttamente?». Ottima domanda. Nel nostro esempio, è vero che si possono è 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 ci sono modifiche nell'origine. L'uso di kustomize consente di centralizzare queste modifiche in un file kustomization.yaml, lasciando intatti i file originali e, in questo modo, semplificando eventualmente il rebase dei file sorgente.

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

Per illustrare il concetto di overlays e 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 risorse dichiarano semplicemente le risorse che deve includere kustomize.

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

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

D'altra parte, il file overlays/prod/kustomization.yaml potrebbe essere completamente diverso:

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

Quando un utente esegue kustomize build . nella directory overlays/dev, kustomize genererà la variante di sviluppo. Se invece si esegue kustomize build . nella directory overlays/prod si otterrà la variante di produzione. E tutto questo avviene senza apportare alcuna modifica alle originali (risorse di base) file, e tutto questo in modo dichiarativo e deterministico. Puoi impegnarti con la configurazione di base e le directory overlay direttamente nel sistema di controllo versione, sapendo che basandoti su questi file puoi riprodurre la configurazione desiderata in qualsiasi momento.

Nota del traduttore.: Illustrazione dalla documentazione del progetto sull'uso degli overlay in kustomize

Kustomize sa fare molto più di quanto detto in questo articolo. Tuttavia, spero che possa servire da buona introduzione.

Risorse aggiuntive

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

• Modifica la configurazione YAML di base per diversi ambienti prod/test utilizzando Kustomize;
• Kustomize — Il modo giusto di fare templating in Kubernetes;
• Gestione dichiarativa degli oggetti Kubernetes utilizzando Kustomize;
• Personalizzazione dei chart Helm upstream con Kustomize.

Nota del traduttore.: È possibile consigliare anche un blocco di link, pubblicati come Risorse sul sito dello strumento, e la successiva collezione di video con le ultime presentazioni su kustomize.

Se hai domande o suggerimenti per migliorare questo materiale, sono sempre aperto al feedback. Puoi contattarmi nel Twitter o su canale Slack di Kubernetes. Divertiti a modificare i tuoi manifesti utilizzando kustomize!

P.S. dal traduttore

Leggete anche nel nostro blog:

• «Strumenti per sviluppatori di applicazioni in esecuzione su Kubernetes»;
• «Kubernetes 1.14: panoramica delle principali novità»;
• «Cinque principali risultati del Helm Summit 2019 ad Amsterdam»;
• «Introduzione pratica al gestore di pacchetti per Kubernetes — Helm».

Fonte: habr.com