Una breve introduzione alla personalizzazione

Nota. trad.: L'articolo è stato scritto da Scott Lowe, un ingegnere con una vasta esperienza nel campo IT, autore/coautore di sette libri stampati (principalmente su VMware vSphere). Ora lavora per la sua controllata VMware Heptio (acquisita nel 2016), specializzata in cloud computing e Kubernetes. Il testo stesso funge da introduzione concisa e di facile comprensione alla gestione della configurazione per Kubernetes tramite la tecnologia Personalizza, che recentemente è entrato a far parte di K8s.

Kustomize è uno strumento che consente agli utenti di "personalizzare file YAML semplici e privi di modelli per scopi diversi, lasciando lo YAML originale intatto e utilizzabile" (descrizione presa in prestito direttamente da repository kustomize su GitHub). Kustomize può essere eseguito direttamente o, a partire da Kubernetes 1.14, utilizzato kubectl -k per accedere alle sue funzionalità (sebbene a partire da Kubernetes 1.15, il file binario separato sia più recente delle funzionalità integrate in kubectl). (Nota. trad.: E con la recente versione Kubernet 1.16 personalizza supportato anche nell'utilità kubeadm.) In questo post, voglio presentare ai lettori le basi di kustomize.

Nella sua forma/applicazione più semplice, kustomize è semplicemente una raccolta di risorse (file YAML che definiscono oggetti Kubernetes: distribuzioni, servizi, ecc.) più un elenco di istruzioni per le modifiche che devono essere apportate a tali risorse. Proprio come make utilizza il set di istruzioni contenuto in Makefilee Docker crea il contenitore in base alle istruzioni di Dockerfile, personalizzare gli usi kustomization.yaml per memorizzare istruzioni su quali modifiche l'utente desidera apportare a un insieme di risorse.

Ecco un file di esempio kustomization.yaml:

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

Non proverò a parlare di tutti i possibili campi nel file. kustomization.yaml (questo è ben scritto qui), ma darò una breve spiegazione di un esempio specifico:

• Campo resources indica cosa (quali risorse) kustomize cambierà. In questo caso, cercherà le risorse nei file deployment.yaml и service.yaml nella tua directory (puoi specificare percorsi completi o relativi se necessario).
• Campo namePrefix ordina a kustomize di aggiungere un determinato prefisso (in questo caso - dev-) attribuire name tutte le risorse definite sul campo resources. Pertanto, se Deployment ha name con significato nginx-deployment, personalizzare ce la farà dev-nginx-deployment.
• Campo namespace indica a kustomize di aggiungere lo spazio dei nomi specificato a tutte le risorse. In questo caso, Deployment e Service rientreranno nello spazio dei nomi development.
• Infine, il campo commonLabels contiene una serie di etichette che verranno aggiunte a tutte le risorse. Nel nostro esempio, kustomize assegnerà un'etichetta alle risorse con il nome environment e significato development.

Se l'utente lo fa kustomize build . nella directory con il file kustomization.yaml e le risorse necessarie (ad esempio file deployment.yaml и service.yaml), quindi in uscita riceverà un testo con le modifiche specificate in kustomization.yaml.

Nota. trad.: Illustrazione tratta dalla documentazione del progetto sull'uso “semplice” di kustomize

L'output può essere reindirizzato se è necessario eseguire il commit delle modifiche:

kustomize build . > custom-config.yaml

I dati di output sono deterministici (gli stessi dati di input produrranno gli stessi risultati di output), quindi non è necessario salvare il risultato in un file. Invece, può essere passato direttamente a un altro comando:

kustomize build . | kubectl apply -f -

È possibile accedere alle funzionalità kustomize anche tramite kubectl -k (dalla versione Kubernetes 1.14). Tuttavia, tieni presente che il pacchetto kustomize autonomo viene aggiornato più velocemente del pacchetto kubectl integrato (almeno questo è il caso della versione Kubernetes 1.15).

I lettori potrebbero chiedersi: “Perché tutta questa complessità se puoi modificare direttamente i file?” Ottima domanda. Nel nostro esempio, infatti si può modificare i file deployment.yaml и service.yaml direttamente, ma cosa succede se sono un fork del progetto di qualcun altro? La modifica diretta dei file rende difficile (se non impossibile) riorganizzare un fork quando vengono apportate modifiche all'origine/sorgente. L'utilizzo di kustomize ti consente di centralizzare queste modifiche in un file kustomization.yaml, lasciando intatti i file originali e rendendo così più semplice la nuova creazione dei file originali, se necessario.

I vantaggi di kustomize diventano evidenti nei casi d'uso più complessi. Nell'esempio sopra kustomization.yaml e le risorse si trovano nella stessa directory. Tuttavia, kustomize supporta casi d'uso in cui è presente una configurazione di base e molte varianti della stessa, note anche come overlay. Ad esempio, un utente voleva prendere Deployment and Service per nginx, che ho usato come esempio, e creare versioni (o varianti) di sviluppo, gestione temporanea e produzione di tali file. Per fare ciò, avrà bisogno degli overlay sopra menzionati e, di fatto, delle risorse di base stesse.

Per illustrare l'idea di sovrapposizioni e risorse sottostanti (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

In archivio base/kustomization.yaml utenti che utilizzano il campo resources dichiara semplicemente le risorse che kustomize dovrebbe includere.

In ciascuno dei file overlays/{dev,staging,prod}/kustomization.yaml gli utenti fanno riferimento alla configurazione di base sul campo resources, quindi indicare modifiche specifiche per dato ambiente. Ad esempio, file overlays/dev/kustomization.yaml potrebbe assomigliare all'esempio fornito in precedenza:

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

In questo caso il file overlays/prod/kustomization.yaml potrebbe essere completamente diverso:

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

Quando l'utente esegue kustomize build . nel catalogo overlays/dev, kustomize genererà l'opzione di sviluppo. Se corri kustomize build . nel catalogo overlays/prod - ottieni l'opzione di produzione. E tutto questo senza apportare alcuna modifica all'originale (base) file, il tutto in modo dichiarativo e deterministico. Puoi affidare la configurazione di base e sovrapporre le directory direttamente al controllo della versione, sapendo che sulla base di questi file puoi riprodurre la configurazione desiderata in qualsiasi momento.

Nota. trad.: Illustrazione tratta dalla documentazione del progetto sull'utilizzo degli overlay in Kustomize

Personalizza lattina più più di quanto trattato in questo articolo. Spero comunque che serva da buona introduzione.

Risorse addizionali

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

• Modifica la configurazione YAML di base per la produzione/test di ambienti diversi utilizzando Kustomize;
• Kustomize: il modo giusto per creare modelli in Kubernetes;
• Gestione dichiarativa degli oggetti Kubernetes utilizzando la personalizzazione;
• Personalizzazione dei grafici Helm upstream con Personalizza.

Nota. trad.: Puoi anche consigliare un blocco di link pubblicati come Risorse sul sito web dell'utilità, seguito da una raccolta di video con gli ultimi resoconti su kustomize.

Se hai domande o suggerimenti per migliorare questo materiale, sono sempre aperto al feedback. Puoi contattarmi a Twitter o Canale Kubernetes Slack. Divertiti a modificare i tuoi manifest con kustomize!

PS da traduttore

Leggi anche sul nostro blog:

• «Strumenti per sviluppatori di applicazioni in esecuzione su Kubernetes";
• «Kubernetes 1.14: punti salienti delle novità";
• «Cinque risultati principali dell'Helm Summit 2019 ad Amsterdam";
• «Introduzione pratica al gestore pacchetti per Kubernetes - Helm'.

Fonte: habr.com