Immagini delle macchine personalizzate di Linux (legacy)

Questa procedura consente di eseguire i passaggi per creare un'immagine di macchina personalizzata di Linux da utilizzare durante la creazione di cluster basati sul piano (legacy) in AWS, Azure o vSphere. È suddivisa nelle sezioni seguenti. Per ulteriori informazioni sui tipi di cluster in Tanzu Kubernetes Grid, vedere Tipi di cluster del carico di lavoro.

Prerequisiti dell'immagine di Linux indica ciò che è necessario per creare e utilizzare correttamente un'immagine di Linux personalizzata.
Creazione di un'immagine di Linux illustra come utilizzare Kubernetes Image Builder e Docker per personalizzare e creare un'immagine.
Creazione di un TKr per l'immagine di Linux illustra come convertire l'immagine di Linux in una versione di Tanzu Kubernetes (TKr), in modo da renderla l'immagine predefinita per le versioni future di Kubernetes e indica ulteriori opzioni per utilizzarla e gestirla.
Utilizzo di un'immagine di Linux per un cluster di gestione illustra come distribuire un cluster di gestione che utilizza l'immagine personalizzata come modello.
Utilizzo di un'immagine di Linux per un cluster del carico di lavoro illustra come distribuire un cluster del carico di lavoro che utilizza l'immagine personalizzata come modello.

Prerequisiti dell'immagine di Linux

Per creare un'immagine di macchina personalizzata di Linux, è necessario:

Un account nell'infrastruttura di destinazione, AWS, Azure o vSphere.
Una workstation macOS o Linux in cui sia installato quanto segue:
- Docker Desktop
- Per AWS: la CLI (Command-Line Interface) aws
- Per Azure: la CLI az
- Per vSphere: per creare un'immagine di RHEL 8, è necessaria una workstation Linux, non macOS.

Creazione di un'immagine di Linux

In AWS e Azure, accedere alla CLI dell'infrastruttura. Eseguire l'autenticazione e specificare la propria regione, se richiesto:
- AWS: eseguire aws configure.
- Azure: eseguire az login.
In Azure, creare un file JSON di configurazione azure-sig.json e inserire le informazioni specifiche di Azure. Un esempio di tale file si trova qui.

In vSphere, creare un file JSON delle credenziali e compilarne i valori:

{
"cluster": "",
"convert_to_template": "false",
"create_snapshot": "true",
"datacenter": "",
"datastore": "",
"folder": "",
"insecure_connection": "false",
"linked_clone": "true",
"network": "",
"password": "",
"resource_pool": "",
"template": "",
"username": "",
"vcenter_server": ""
}

Determinare la versione della configurazione di Image Builder da cui si desidera creare l'immagine.
- Per visualizzare l'elenco delle versioni disponibili, cercare TKG Image Builder in VMware {code} Sample Exchange.
- Ogni versione di Image Builder corrisponde alle versioni compatibili di Kubernetes e Tanzu Kubernetes Grid. Ad esempio TKG-Image-Builder-for-Kubernetes-v1.24.10-on-TKG-v2.1.1-master.zip crea un'immagine Kubernetes v1.24.10 per Tanzu Kubernetes Grid v2.1.1.
- Se si desidera creare un cluster di gestione, operazione necessaria quando si installa Tanzu Kubernetes Grid per la prima volta, scegliere la versione predefinita di Kubernetes nella versione di Tanzu Kubernetes Grid. Ad esempio, in Tanzu Kubernetes Grid v2.1.1, la versione predefinita di Kubernetes è v1.24.10. Per i cluster del carico di lavoro, è possibile creare un'immagine di Kubernetes v1.23.16 o v1.22.17 oltre a v1.24.10.
I passaggi seguenti indicano come creare un'immagine di Kubernetes v1.24.10 per Tanzu Kubernetes Grid v2.1.1.
Scaricare il file ZIP del codice di configurazione e decomprimerne il contenuto.
cd nella directory TKG-Image-Builder-, in modo che il file tkg.json si trovi nella directory corrente.
Assicurarsi che la workstation possa accedere al registro delle immagini di VMware projects.registry.vmware.com.

Scaricare ed eseguire il container dell'artefatto desiderato da projects.registry.vmware.com.

docker pull projects.registry.vmware.com/tkg/linux-resource-bundle:v1.24.10_vmware.1-tkg.2

docker run -d -p 3000:3000 projects.registry.vmware.com/tkg/linux-resource-bundle:v1.24.10_vmware.1-tkg.2

Modificare tkg.json per popolare <IP> e <PORT>, in cui:
- IP corrisponde all'IP della macchina che esegue il container Docker.
- PORT associa una porta inutilizzata nell'host Docker alla porta 3000 nel container, ad esempio 3001:3000. Il container espone gli artefatti sulla porta 3000.
Se si crea un file OVA di Photon-3, modificare "extra_rpms" in tkg.json in modo che rifletta i pacchetti personalizzati aggiuntivi supportati:
```
"extra_rpms": "sysstat nfs-utils ethtool apparmor-parser"
```
Per creare un'immagine con supporto FIPS, rimuovere la riga seguente in tkg.json:
```
"ansible_user_vars": "install_fips=no"
```
Con limitazioni Internet: per creare immagini per un ambiente con limitazioni Internet che accede a Internet tramite il server proxy HTTP, aggiungere quanto segue nel file tkg.json:
```
{
  "http_proxy": "http://proxy.acme.com:80",
  "https_proxy": "http://proxy.acme.com:80",
  "no_proxy": "localhost, 127.0.0.1, acme.com, 10.0.0.0/8"
}
```
Cluster abilitati per GPU: Per creare un'immagine per un cluster abilitato per GPU per vSphere, creare un file denominato customizations.json e aggiungere quanto segue:
```
{
"vmx_version": "17"
}
```
Salvare customizations.json nella stessa directory di tkg.json modificata in un passaggio precedente.
Raccogliere le seguenti stringhe di parametri da collegare al comando nel passaggio successivo. Molti di questi specificano i parametri di docker run -v che copiano le directory di lavoro correnti nella directory /home/imagebuilder del container utilizzato per creare l'immagine.
- AUTHENTICATION: copia la directory della CLI locale:
  - AWS: Utilizzare ~/.aws:/home/imagebuilder/.aws
  - Azure: Utilizzare ~/.azure:/home/imagebuilder/.azure
  - vSphere: /PATH/TO/CREDENTIALS.json:/home/imagebuilder/vsphere.json
- SOURCES: copia il file tkg.json del repository, in cui sono elencate le origini dei download per il sistema operativo con versione, Kubernetes e l'interfaccia CNI (Container Network Interface).
  - Utilizzare /PATH/TO/tkg.json:/home/imagebuilder/tkg.json
- ROLES: Copia la directory tkg del repository, che contiene i ruoli di Ansible richiesti da Image Builder.
  - Utilizzare /PATH/TO/tkg:/home/imagebuilder/tkg
  - Per aggiungere ruoli di Ansible personalizzati, modificare il file tkg.json per formattare nuovamente l'impostazione custom_role_names con virgolette con caratteri di escape (\"), in modo da renderla un elenco con più ruoli. Ad esempio:
    "custom_role_names": "\"/home/imagebuilder/tkg /home/imagebuilder/mycustomrole\"",
- TESTS: Copia una directory di test goss progettata per l'infrastruttura di destinazione dell'immagine, il sistema operativo e la versione di Kubernetes:
  - Utilizzare il nome del file nella directory goss del repository, ad esempio amazon-ubuntu-1.24.10+vmware.1-goss-spec.yaml.
- CUSTOMIZATIONS: Copia un file di personalizzazione nel formato JSON. Vedere Personalizzazione nella documentazione di Image Builder. Prima di apportare eventuali modifiche, consultare VMware Customer Reliability Engineering (CRE) per le procedure consigliate e i suggerimenti.
- PACKER_VAR_FILES: elenco delimitato da spazi dei file JSON precedenti che contengono variabili per Packer.
- (Azure) AZURE-CREDS: percorso di un file di credenziali di Azure, come descritto nella documentazione di Image Builder.
- COMMAND: Utilizzare un comando simile a uno dei seguenti, in base al sistema operativo dell'immagine personalizzata. Per le immagini di vSphere e Azure, i comandi iniziano con build-node-ova- e build-azure-sig-:
  - build-ami-ubuntu-2004: Ubuntu v20.04
  - build-ami-ubuntu-1804: Ubuntu v18.04
  - build-ami-amazon-2: Amazon Linux 2
  - build-node-ova-vsphere-ubuntu-2004: Cluster abilitati per GPU

Utilizzando le stringhe precedenti, eseguire Image Builder in un container Docker estratto dal registro di VMware projects.registry.vmware.com:

docker run -it --rm \
    -v AUTHENTICATION \
    -v SOURCES \
    -v ROLES \
    -v /PATH/TO/goss/TESTS.yaml:/home/imagebuilder/goss/goss.yaml \
    -v /PATH/TO/CUSTOMIZATIONS.json:/home/imagebuilder/CUSTOMIZATIONS.json \
    --env PACKER_VAR_FILES="tkg.json CUSTOMIZATIONS.json" \
    --env-file AZURE-CREDS \
    --env IB_OVFTOOL=1 \
    projects.registry.vmware.com/tkg/image-builder:v0.1.13_vmware.2 \
    COMMAND

Nota
Omettere env-file se non si sta creando un'immagine per Azure. Per completare il comando, potrebbero essere necessari alcuni minuti.

Ad esempio, per creare un'immagine personalizzata con Ubuntu v20.04 e Kubernetes v1.24.10 da eseguire in AWS dalla directory che contiene tkg.json:

docker run -it --rm \
    -v ~/.aws:/home/imagebuilder/.aws \
    -v $(pwd)/tkg.json:/home/imagebuilder/tkg.json \
    -v $(pwd)/tkg:/home/imagebuilder/tkg \
    -v $(pwd)/goss/amazon-ubuntu-1.24.10+vmware.1-goss-spec.yaml:/home/imagebuilder/goss/goss.yaml \
    -v /PATH/TO/CUSTOMIZATIONS.json /home/imagebuilder/aws.json \
    --env PACKER_VAR_FILES="tkg.json aws.json" \
    --env IB_OVFTOOL=1 \
    projects.registry.vmware.com/tkg/image-builder:v0.1.13_vmware.2 \
    build-ami-ubuntu-2004

Per vSphere, è necessario utilizzare l'immagine del container personalizzata creata in precedenza. È inoltre necessario impostare una stringa di versione che corrisponda a quella che verrà passata nel TKr personalizzato nei passaggi successivi. Mentre i file OVA pubblicati da VMware avranno una stringa di versione simile a v1.24.10+vmware.1-tkg.1, è consigliabile sostituire -tkg.1 con una stringa significativa per la propria organizzazione. Per impostare questa stringa di versione, definirla in un file metadata.json come indicato di seguito:

{
  "VERSION": "v1.24.10+vmware.1-myorg.0"
}

Quando si generano file OVA, il file .ova viene salvato nel file system locale della workstation. Qualsiasi cartella in cui si desidera salvare i file OVA deve essere montata in /home/imagebuilder/output nel container. Creare quindi l'OVA utilizzando l'immagine del container:

docker run -it --rm \
  -v /PATH/TO/CREDENTIALS.json:/home/imagebuilder/vsphere.json \
  -v $(pwd)/tkg.json:/home/imagebuilder/tkg.json \
  -v $(pwd)/tkg:/home/imagebuilder/tkg \
  -v $(pwd)/goss/vsphere-ubuntu-1.24.10+vmware.1-goss-spec.yaml:/home/imagebuilder/goss/goss.yaml \
  -v $(pwd)/metadata.json:/home/imagebuilder/metadata.json \
  -v /PATH/TO/OVA/DIR:/home/imagebuilder/output \
  --env PACKER_VAR_FILES="tkg.json vsphere.json" \
  --env OVF_CUSTOM_PROPERTIES=/home/imagebuilder/metadata.json \
  --env IB_OVFTOOL=1 \
  projects.registry.vmware.com/tkg/image-builder:v0.1.13_vmware.2 \
  build-node-ova-vsphere-ubuntu-2004

Per i cluster abilitati per GPU, è necessario includere il file customizations.json creato nei passaggi precedenti quando si esegue il comando per creare il file OVA.

docker run -it --rm \
  -v /PATH/TO/CREDENTIALS.json:/home/imagebuilder/vsphere.json \
  -v $(pwd)/tkg.json:/home/imagebuilder/tkg.json \
  -v $(pwd)/tkg:/home/imagebuilder/tkg \
  -v $(pwd)/goss/vsphere-ubuntu-1.24.10+vmware.1-goss-spec.yaml:/home/imagebuilder/goss/goss.yaml \
  -v $(pwd)/metadata.json:/home/imagebuilder/metadata.json \
  -v $(pwd)/customizations.json:/home/imagebuilder/customizations.json \
  -v /PATH/TO/OVA/DIR:/home/imagebuilder/output \
  --env PACKER_VAR_FILES="tkg.json vsphere.json customizations.json" \
  --env OVF_CUSTOM_PROPERTIES=/home/imagebuilder/metadata.json \
  --env IB_OVFTOOL=1 \
  projects.registry.vmware.com/tkg/image-builder:v0.1.13_vmware.2 \
  build-node-ova-vsphere-ubuntu-2004

RHEL: per creare un file OVA di RHEL, è necessario utilizzare una macchina Linux, non macOS, perché Docker in macOS non supporta l'opzione --network host.
È inoltre necessario registrare il sistema operativo con licenza in Red Hat e iscriversi per ottenere gli aggiornamenti aggiungendo quanto segue al comando docker run precedente:

  -v $(pwd)/isos/rhel-8.4-x86_64-dvd.iso:/rhel-8.4-x86_64-dvd.iso \
  --network host \
  --env RHSM_USER=USER --env RHSM_PASS=PASS

In cui:

RHSM_USER e RHSM_PASS sono il nome utente e la password per l'account di Red Hat Subscription Manager.
Nell'esempio precedente, il percorso dell'ISO di RHEL locale viene mappato in $(pwd)/isos/rhel-8.4-x86-64-dvd.iso come volume aggiuntivo.

Creazione di un TKr per l'immagine di Linux

Per rendere l'immagine di Linux predefinita per le versioni future di Kubernetes, creare un TKr basato su tale immagine. Altrimenti, passare a Utilizzo di un'immagine di Linux per un cluster del carico di lavoro.

Il diagramma seguente fornisce una panoramica generale su come creare un TKr per un'immagine di Linux personalizzata in vSphere.

Creazione di un TKr

Per creare un TKr:

Dalla directory ~/.config/tanzu/tkg/bom/ aprire il BoM di TKr corrispondente alla versione di Kubernetes dell'immagine personalizzata. Ad esempio con un nome di file come tkr-bom-v1.24.10+vmware.1-tkg.1.yaml per Kubernetes v1.24.10.

Se la directory non include il file BOM di TKr necessario, è possibile crearlo distribuendo un cluster con la versione di Kubernetes desiderata, come descritto in Distribuzione di un cluster con una versione di Kubernetes non predefinita.
1. Nel file BoM, individuare i blocchi di definizione dell'immagine per l'infrastruttura: ova per vSphere, ami per AWS e azure per Azure. Ogni blocco di definizione dell'immagine contiene osinfo.name, osinfo.version e osinfo.arch, in cui:
  - osinfo.name è il nome del sistema operativo. Ad esempio, ubuntu. Per visualizzare l'elenco dei sistemi operativi supportati, vedere Sistemi operativi di destinazione.
  - osinfo.version è la versione del sistema operativo. Ad esempio, 20.04. Per visualizzare l'elenco delle versioni supportate, vedere Sistemi operativi di destinazione.
  - osinfo.arch è l'architettura del sistema operativo. Il valore supportato è amd64.
2. Per aggiungere un riferimento alla nuova immagine del sistema operativo, aggiungere un blocco di definizione dell'immagine in ova, ami o azure, in base all'infrastruttura di destinazione. Il blocco di definizione dell'immagine deve contenere osinfo.name, osinfo.version e osinfo.arch, come descritto in precedenza. Inoltre, quando si aggiunge un blocco di definizione dell'immagine in:
  - vSphere:
    - name: è un nome univoco per OVA che include la versione del sistema operativo, ad esempio my-ova-ubuntu-2004.
    - version: utilizzare il valore univoco di VERSION assegnato in metadata.json quando è stato creato il file OVA, ad esempio v1.24.10+vmware.1-myorg.0.
    Nota
    Il valore di version deve corrispondere esattamente al valore di VERSION in metadata.json.
  - AWS: Per ogni regione in cui si intende utilizzare l'immagine personalizzata, seguire il formato del valore id esistente, ma utilizzare una stringa esadecimale univoca alla fine, ad esempio ami-693a5e2348b25e428.
  Se il file BoM definisce immagini nelle regioni, il blocco di definizione dell'immagine personalizzata deve essere elencato per primo nella relativa regione. In ogni regione, il processo di creazione del cluster seleziona la prima immagine idonea elencata.
3. Nel valore release.version impostare una versione personalizzata aggiungendo un suffisso. Non personalizzare la versione aggiungendo un prefisso. Ad esempio, modificare v1.24.10+vmware.1-tkg.1 specificando v1.24.10+vmware.1-tkg.1-mycustomtkr.
4. Salvare il file BoM con lo stesso suffisso personalizzato specificato per release.version nel passaggio precedente.
  
  Se il nome del file include un carattere più (+), sostituire il + con un trattino triplo (---).
  
  Ad esempio, salvare il file BOM come tkr-bom-v1.24.10---vmware.1-tkg.1-mycustomtkr.yaml.
base64: codificare il contenuto del file in una stringa binaria, ad esempio:
```
cat tkr-bom-v1.24.10---vmware.1-tkg.1-mycustomtkr.yaml | base64 -w 0
```
Creare un file YAML ConfigMap, ad esempio denominato configmap-v1.24.10---vmware.1-tkg.1-mycustomtkr.yaml, con i valori seguenti:
```
apiVersion: v1
kind: ConfigMap
metadata:
 name: CUSTOM-TKG-BOM
 labels:
   tanzuKubernetesRelease: CUSTOM-TKR
binaryData:
 bomContent: "BOM-BINARY-CONTENT"
```
In cui:
- CUSTOM-TKG-BOM è il nome del ConfigMap che deve includere il valore release.version di TKr specificato nel file BOM e sostituire qualsiasi simbolo + con un trattino triplo (—). Ad esempio, impostare v1.24.10---vmware.1-tkg.1-mycustomtkr.
- CUSTOM-TKR è un nome per TKr, che deve corrispondere al valore specificato per CUSTOM-TKG-BOM. Ad esempio, v1.24.10---vmware.1-tkg.1-mycustomtkr.
- BOM-BINARY-CONTENT è il contenuto codificato in base64 del file BoM personalizzato, generato nel passaggio precedente.
Ad esempio:
```
apiVersion: v1
kind: ConfigMap
metadata:
 name: v1.24.10---vmware.1-tkg.1-mycustomtkr
 labels:
   tanzuKubernetesRelease: v1.24.10---vmware.1-tkg.1-mycustomtkr
binaryData:
 bomContent: "YXBpVmVyc2lvbjogcnVuLnRhbnp1...."
```
Salvare il file ConfigMap, impostare il contesto kubectl su un cluster di gestione a cui si desidera aggiungere il TKr e applicare il file al cluster, ad esempio:
```
kubectl -n tkr-system apply -f configmap-v1.24.10---vmware.1-tkg.1-mycustomtkr.yaml
```
TKr Controller riconcilia il nuovo oggetto ConfigMap creando un TanzuKubernetesRelease. Il periodo di riconciliazione predefinito è 600 secondi. È possibile evitare questo ritardo eliminando il pod di TKr Controller in modo che il pod venga ripristinato e riconciliato immediatamente:
1. Elencare i pod nello spazio dei nomi tkr-system:
```
kubectl get pod -n tkr-system
```
2. Recuperare il nome del pod di TKr Controller, che è simile a tkr-controller-manager-f7bbb4bd4-d5lfd
3. Eliminare il pod:
```
kubectl delete pod -n tkr-system TKG-CONTROLLER
```
  In cui TKG-CONTROLLER è il nome del pod di TKr Controller.
Per verificare che il TKr personalizzato sia stato aggiunto, eseguire tanzu kubernetes-release get o kubectl get tkr e cercare il valore CUSTOM-TKR impostato in precedenza nell'output.

Una volta che il TKr personalizzato è elencato nelle CLI kubectl e tanzu, è possibile utilizzarlo per creare cluster di gestione o del carico di lavoro come descritto di seguito.

Utilizzo di un'immagine di Linux per un cluster di gestione

Per creare un cluster di gestione che utilizzi l'immagine personalizzata come sistema operativo di base per i suoi nodi:

Caricare l'immagine nel provider del cloud.
Quando si esegue l'interfaccia del programma di installazione, selezionare l'immagine personalizzata nel riquadro Immagine sistema operativo (OS Image), come descritto in Selezione dell'immagine del sistema operativo di base.

Per ulteriori informazioni, vedere Come vengono generate le scelte dell'immagine del sistema operativo di base.

Utilizzo di un'immagine di Linux per un cluster del carico di lavoro

La procedura per la creazione di un cluster del carico di lavoro dall'immagine di Linux varia in base al fatto che sia stato creato un TKr nella sezione Creazione di un TKr per l'immagine di Linux precedente.

Se è stato creato un TKr, passare il nome di TKr come indicato da tanzu kubernetes-release get all'opzione --tkr di tanzu cluster create.
Se non è stato creato un TKr, eseguire i passaggi seguenti:
1. Copiare il file di configurazione del cluster di gestione e salvarlo con un nuovo nome eseguendo la procedura descritta in File di configurazione e specifiche degli oggetti.
2. Nel nuovo file di configurazione, aggiungere o modificare quanto segue:
```
VSPHERE_TEMPLATE: LINUX-IMAGE
```
  In cui LINUX-IMAGE è il nome dell'immagine di Linux creata in Creazione di un'immagine di Linux.
  
  Rimuovere CLUSTER_NAME e la relativa impostazione, se presente.
3. Distribuire un cluster del carico di lavoro come descritto in Creazione di cluster del carico di lavoro.