Immagini delle macchine personalizzate di Linux

Questa procedura consente di eseguire i passaggi per creare un'immagine di macchina personalizzata di Linux da utilizzare durante la creazione di cluster 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.

Come indicato nelle procedure, alcuni passaggi variano a seconda che si stia creando un'immagine per un cluster basato sulla classe o basato sul piano (legacy).

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.

(Basato sulla classe, vSphere) Recupero della versione dell'immagine del sistema operativo

Prima di creare un'immagine da utilizzare per i cluster basati sulla classe in vSphere, è necessario recuperare la versione dell'immagine del sistema operativo associata al file OVA di Ubuntu predefinito per la versione di Kubernetes che si desidera utilizzare per l'immagine personalizzata. Questa versione dell'immagine del sistema operativo verrà assegnata all'immagine personalizzata nel passaggio seguente Creazione di un'immagine di Linux.

Per recuperare la versione dell'immagine del sistema operativo, eseguire una delle operazioni seguenti in base al proprio caso d'uso:

Se si dispone di un cluster di gestione in esecuzione creato utilizzando la versione predefinita di Kubernetes per la versione di Tanzu Kubernetes Grid corrente, è possibile recuperare la versione dell'immagine del sistema operativo dal cluster:
1. Impostare il contesto di kubectl sul cluster di gestione.
2. Nell'elenco dei TKr disponibili, scegliere la versione di Tanzu Kubernetes (TKr) per la versione di Kubernetes che si desidera utilizzare per l'immagine personalizzata. Ad esempio, v1.27.5---vmware.2-tkg.1. Per visualizzare un elenco dei TKr disponibili, eseguire:
```
kubectl get tkr
```
3. Aprire il TKr e individuare la proprietà osImages. Questa proprietà specifica i nomi degli oggetti OSImage associati al TKr.
4. Individuare e aprire l'oggetto OSImage per il file OVA di Ubuntu predefinito. Il nome dell'oggetto OSImage corrisponde a uno dei nomi di osImages del TKr.
```
kubectl get osimages
```
5. Nell'oggetto OSImage per il file OVA di Ubuntu predefinito, individuare il valore della proprietà version in spec.image.ref e prenderne nota. Ad esempio, v1.27.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e.
Se non si dispone di un cluster di gestione in esecuzione creato utilizzando la versione di Kubernetes predefinita per la versione di Tanzu Kubernetes Grid corrente, è possibile recuperare la versione dell'immagine del sistema operativo direttamente dal file OVA di Ubuntu predefinito, in locale o da vSphere:
- Per recuperare la versione dell'immagine del sistema operativo in locale:
  1. Scaricare il file OVA di Ubuntu predefinito per la versione di Kubernetes di destinazione da Customer Connect:
    1. Passare alla pagina dei download di Tanzu Kubernetes Grid accedendo con le credenziali di VMware Customer Connect e facendo clic su Vai ai download (Go to Downloads).
    2. Scaricare il file OVA. Ad esempio, Ubuntu 2004 Kubernetes v1.27.5 OVA.
  2. Decomprimere il file OVA scaricato utilizzando lo strumento di estrazione desiderato.
  3. Nella directory decompressa, individuare il file .ofv.
  4. Nel file .ofv cercare la proprietà VERSION di OVA e registrarne il valore. Ad esempio, v1.27.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e. La proprietà è simile alla seguente:
```
<Property ovf:key="VERSION" ovf:type="string" ovf:userConfigurable="false" ovf:value="v1.27.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e"/>
```
- Se il file OVA di Ubuntu predefinito per la versione di Kubernetes di destinazione è già stato caricato in vSphere, in alternativa è possibile recuperare la versione dell'immagine del sistema operativo ispezionando le proprietà della macchina virtuale di OVA nell'interfaccia utente di vSphere o utilizzando la CLI govc. Per utilizzare questo metodo, recuperare la versione dell'immagine del sistema operativo prima di convertire la macchina virtuale di OVA in un modello.
  - Per recuperare la versione dell'immagine del sistema operativo dall'interfaccia utente di vSphere:
    1. Individuare la macchina virtuale di OVA e aprire la scheda Configura (Configure) nella pagina di riepilogo della macchina virtuale di OVA.
    2. Passare a Impostazioni (Settings) -> Opzioni vApp (vApp Options).
    3. Nella tabella Proprietà (Properties) individuare la chiave VERSION e registrarne il Valore predefinito. Ad esempio, v1.27.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e.
  - Per recuperare la versione dell'immagine del sistema operativo utilizzando la CLI govc, eseguire il comando govc vm.info. Ad esempio:
```
govc vm.info -json /dc0/vm/ubuntu-2004-kube-v1.27.5+vmware.1-tkg.1 | jq
```
    Nell'output, cercare "Id": "VERSION" e prendere nota del valore della proprietà "DefaultValue". Ad esempio:
```
{
"Key": 10,
"ClassId": "",
"InstanceId": "",
"Id": "VERSION",
"Category": "Cluster API Provider (CAPI)",
"Label": "VERSION",
"Type": "string",
"TypeReference": "",
"UserConfigurable": false,
"DefaultValue": "v1.27.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e",
"Value": "",
"Description": ""
}
```

Creazione di un'immagine di Linux

Configurare l'autenticazione per l'infrastruttura:
- 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": ""
}
```
- AWS: Accedere alla CLI di aws. Eseguire l'autenticazione e specificare la propria regione, se richiesto:
```
aws configure
```
- Azure: Accedere alla CLI di az. Quindi, creare un file JSON di configurazione azure-sig.json e inserire le informazioni specifiche di Azure. Un esempio di tale file si trova qui.
Scaricare il container del bundle di risorse di Linux da projects.registry.vmware.com:
1. Assicurarsi che la workstation possa accedere al registro delle immagini di VMware projects.registry.vmware.com.
2. Scaricare ed eseguire il container con i file binari di Kubernetes Linux di cui Image Builder ha bisogno per creare un file OVA di Linux:
```
docker pull projects.registry.vmware.com/tkg/linux-resource-bundle:v1.27.5_vmware.1-tkg.1

docker run -d -p 3000:3000 projects.registry.vmware.com/tkg/linux-resource-bundle:v1.27.5_vmware.1-tkg.1
```
Scaricare la directory di configurazione di Image Builder:
1. 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.27.5-on-TKG-v2.4.0-master.zip crea un'immagine di Kubernetes v1.27.5 per Tanzu Kubernetes Grid v2.4.0.
  - 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.4.0, la versione predefinita di Kubernetes è v1.27.5. Per i cluster del carico di lavoro, è inoltre possibile creare Kubernetes v1.26.8 o v1.25.13 oltre a v1.27.5.
  I passaggi seguenti illustrano come creare un'immagine di Kubernetes v1.27.5 per Tanzu Kubernetes Grid v2.4.0.
2. Scaricare il file ZIP del codice di configurazione e decomprimerne il contenuto.
3. cd nella directory TKG-Image-Builder-, in modo che il file tkg.json si trovi nella directory corrente.
vSphere Per vSphere, creare un file metadata.json nella directory di Image Builder che imposta una stringa di versione in modo che corrisponda a quella elencata nel TKr personalizzato nei passaggi successivi:
- Basato sulla classe: Utilizzare il valore recuperato nel passaggio precedente Recupero dela versione dell'immagine del sistema operativo, ad esempio:
```
{
"VERSION": "v1.27.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e"
}
```
- Basato su piano: Image Builder indica ai file OVA che crea una stringa di versione identica ai file OVA pubblicati in VMware, ad esempio v1.27.5+vmware.1-tkg.1. Per le immagini personalizzate, VMware consiglia di sostituire -tkg.1 con una stringa significativa per l'organizzazione, ad esempio:
```
{
"VERSION": "v1.27.5+vmware.1-myorg.0"
}
```
Modificare il file tkg.json per compilare le impostazioni e personalizzazioni <IP> e <PORT> per containerd_url e kubernetes_http_source, dove:
- 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.
Per includere le seguenti opzioni, continuare a modificare il file tkg.json:
- Photon: 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"
```
- Protezione avanzata STIG e CIS: Per proteggere l'immagine Ubuntu personalizzata al di sopra dei livelli predefiniti:
  1. Aggiungere una riga che imposta ansible_user_vars su alcune o tutte le variabili seguenti per true. Per impostazione predefinita, false:
  2. STIG:
    - install_aide - Attivazione di AIDE (Advanced Intrusion Detection Environment, ambiente di rilevamento delle intrusioni avanzato)
    - install_sshd_login_banner - Installazione del banner di accesso del Dipartimento della Difesa
    - remove_existing_ca_certs - Conservazione dell'infrastruttura PKI del Dipartimento della Difesa
    - install_audispd_plugins - Installazione dei plug-in multiplexor (audispd) dell'evento
  3. CIS:
    - install_aide - Attivazione di AIDE (Advanced Intrusion Detection Environment, ambiente di rilevamento delle intrusioni avanzato)
    - install_clamav - Attivazione dell'antivirus ClamAV
    - install_systemd_timesyncd - Utilizzare timesyncd anziché chrony
    - install_protect_kernel_defaults - Impostazione dei valori predefiniti a monte kernel-protect
  4. Modificare l'impostazione custom_role_names aggiungendo /home/imagebuilder/stig_ubuntu_2004 per STIG o /home/imagebuilder/cis_ubuntu_2004 per CIS.
  Ad esempio, per una protezione CIS avanzata aggiuntiva:
```
  "ansible_user_vars": "install_aide=true install_clamav=true install_systemd_timesyncd=true install_protect_kernel_defaults=true",
  "custom_role_names": "/home/imagebuilder/tkg /home/imagebuilder/cis_ubuntu_2004",
```
  Nota
  Le immagini Photon personalizzate non sono supportate per una protezione avanzata aggiuntiva tramite ansible_user_vars.
- FIPS: Per creare un'immagine abilitata per FIPS, rimuovere la seguente impostazione, se è presente:
```
"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:
```
"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 aggiungere quanto segue:
```
"vmx_version": "17"
```
È possibile aggiungere ulteriori personalizzazioni a tkg.json o inserirle in un file separato customizations.json.
Raccogliere le seguenti stringhe di parametri da collegare al comando docker 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. Utilizzare:
  - vSphere: /PATH/TO/CREDENTIALS.json:/home/imagebuilder/vsphere.json
  - AWS: ~/.aws:/home/imagebuilder/.aws
  - Azure: ~/.azure:/home/imagebuilder/.azure
- 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: La directory tkg del repository, che contiene i ruoli di Ansible richiesti da Image Builder.
  - Utilizzare /PATH/TO/tkg:/home/imagebuilder/tkg
- 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 di un file nella directory goss del repository.
  - Esempio: amazon-ubuntu-1.27.5+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

Omettere metadata.json se non si sta creando un'immagine per vSphere e env-file se non si sta creando un'immagine per Azure:

export ROLES="... the value for roles you created above"
export SOURCES="... ..." 
docker run -it --rm \
    -v $AUTHENTICATION \
    -v $SOURCES \
    -v $ROLES \
    -v /PATH/TO/goss/TESTS.yaml:/home/imagebuilder/goss/goss.yaml \
    -v /PATH/TO/metadata.json:/home/imagebuilder/metadata.json \
    -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
Per completare il comando, potrebbero essere necessari alcuni minuti.

Esempi

vSphere: 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.27.5+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

Cluster abilitati per GPU: 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.27.5+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.

AWS: creare un'immagine personalizzata con Ubuntu v20.04 e Kubernetes v1.27.5 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.27.5+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

Caricare l'immagine nel provider del cloud.
- Per le istruzioni di vSphere, vedere Importazione del modello di immagine di base in vSphere in Preparazione della distribuzione dei cluster di gestione in vSphere.
- Se il file OVA di Ubuntu predefinito per la versione di Kubernetes di destinazione è stato caricato in vSphere, eliminare il file OVA predefinito prima di caricare il file OVA personalizzato.

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.27.5+vmware.1-tkg.1.yaml per Kubernetes v1.27.5.

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.27.5+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.27.5+vmware.1-tkg.1 specificando v1.27.5+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.27.5---vmware.2-tkg.1-mycustomtkr.yaml.
base64: codificare il contenuto del file in una stringa binaria, ad esempio:
```
cat tkr-bom-v1.27.5---vmware.2-tkg.1-mycustomtkr.yaml | base64 -w 0
```
Creare un file YAML ConfigMap, ad esempio denominato configmap-v1.27.5---vmware.2-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.27.5---vmware.2-tkg.1-mycustomtkr.
- CUSTOM-TKR è un nome per TKr, che deve corrispondere al valore specificato per CUSTOM-TKG-BOM. Ad esempio, v1.27.5---vmware.2-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.27.5---vmware.2-tkg.1-mycustomtkr
 labels:
   tanzuKubernetesRelease: v1.27.5---vmware.2-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.27.5---vmware.2-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:

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.