Imágenes de máquinas personalizadas de Linux

Este procedimiento le guiará por el proceso de creación de una imagen de máquina personalizada de Linux para usarla al crear clústeres en AWS, Azure o vSphere. Se divide en las siguientes secciones. Para obtener más información sobre los tipos de clústeres en Tanzu Kubernetes Grid, consulte Tipos de clústeres de carga de trabajo.

Requisitos previos de imagen de Linux muestra lo que necesita para compilar y utilizar correctamente una imagen de Linux personalizada.
Compilar una imagen de Linux muestra cómo utilizar Kubernetes Image Builder y Docker para personalizar y compilar una imagen.
Crear un TKr para la imagen de Linux muestra cómo convertir la imagen de Linux en una versión de Tanzu Kubernetes (TKr), lo que convertiría la imagen en la predeterminada para futuras versiones de Kubernetes y le ofrecería más opciones para usarla y administrarla.
Usar una imagen de Linux para un clúster de administración muestra cómo implementar un clúster de administración que utiliza la imagen personalizada como plantilla.
Usar una imagen de Linux para un clúster de carga de trabajo muestra cómo implementar un clúster de carga de trabajo que utiliza la imagen personalizada como plantilla.

Como se indica en los procedimientos, algunos pasos varían en función de si se está compilando una imagen para un clúster basado en clases o basado en planes (heredado).

Requisitos previos de imagen de Linux

Para crear una imagen de máquina personalizada de Linux, necesita:

Una cuenta en la infraestructura de destino, AWS, Azure o vSphere.
Una estación de trabajo macOS o Linux con lo siguiente instalado:
- Escritorio de Docker
- Para AWS: La interfaz de línea de comandos aws (CLI)
- Para Azure: La CLI az
- Para vSphere: Para crear una imagen RHEL 8, necesita una estación de trabajo Linux, no macOS.

(Basado en clases, vSphere) Recuperar la versión de imagen del sistema operativo

Antes de crear una imagen para usarla en clústeres basados en clases en vSphere, debe recuperar la versión de la imagen del sistema operativo que está asociada con el OVA de Ubuntu predeterminado para la versión de Kubernetes que desea usar para su imagen personalizada. Asignará esta versión de imagen del sistema operativo a la imagen personalizada en el paso Compilar una imagen de Linux a continuación.

Para recuperar la versión de imagen del sistema operativo, realice una de las siguientes acciones en función de su caso práctico:

Si tiene un clúster de administración en ejecución que se creó con la versión de Kubernetes predeterminada para la versión actual de Tanzu Kubernetes Grid, puede recuperar la versión de la imagen del sistema operativo del clúster:
1. Establezca el contexto kubectl en el clúster de administración.
2. En la lista de TKr disponibles, elija la versión de Tanzu Kubernetes (TKr) para la versión de Kubernetes que desea utilizar para la imagen personalizada. Por ejemplo, v1.26.8---vmware.2-tkg.1. Para enumerar las TKr disponibles, ejecute:
```
kubectl get tkr
```
3. Abra la TKr y registre la propiedad osImages. Esta propiedad especifica los nombres de los objetos OSImage asociados con la TKr.
4. Enumere objetos OSImage en Kubernetes:
```
kubectl get osimages
```
5. En el resultado, busque la lista de objetos OSImage que coincide con el nombre de TKr osImages para el archivo OVA de Ubuntu predeterminado.
6. Registre la propiedad NAME de la lista OSImage y reemplace su --- integrado por un carácter +. Por ejemplo, v1.26.8+vmware.1-tkg.1-0edd4dafbefbdb503f64d5472e500cf8.
Si no tiene un clúster de administración en ejecución que se creó con la versión de Kubernetes predeterminada para la versión actual de Tanzu Kubernetes Grid, puede recuperar la versión de la imagen del sistema operativo directamente desde el archivo OVA de Ubuntu predeterminado, ya sea de forma local o desde vSphere:
- Para recuperar la versión de imagen del sistema operativo de forma local:
  1. Descargue el archivo OVA de Ubuntu predeterminado para la versión de Kubernetes de destino desde Customer Connect:
    1. Vaya a VMware Customer Connect e inicie sesión con las credenciales de VMware Customer Connect.
    2. Vaya a Descargas de productos de Tanzu Kubernetes Grid v2.3.1.
    3. Descargue el OVA. Por ejemplo, Ubuntu 2004 Kubernetes v1.26.8 OVA.
  2. Descomprima el OVA descargado mediante la herramienta de extracción que desee.
  3. En el directorio descomprimido, busque el archivo .ofv.
  4. En el archivo .ofv, busque la propiedad VERSION de OVA y registre su valor. Por ejemplo, v1.26.8+vmware.1-tkg.1-0edd4dafbefbdb503f64d5472e500cf8. La propiedad debe ser similar al siguiente mensaje:
```
<Property ovf:key="VERSION" ovf:type="string" ovf:userConfigurable="false" ovf:value="v1.26.8+vmware.1-tkg.1-0edd4dafbefbdb503f64d5472e500cf8"/>
```
- Si ya cargó el archivo OVA de Ubuntu predeterminado para la versión de Kubernetes de destino en vSphere, puede recuperar la versión de la imagen del sistema operativo inspeccionando las propiedades de la máquina virtual de OVA en la interfaz de usuario de vSphere o mediante la CLI govc. Para utilizar este método, recupere la versión de la imagen del sistema operativo antes de convertir la máquina virtual de OVA en una plantilla.
  - Para recuperar la versión de imagen del sistema operativo de la interfaz de usuario de vSphere:
    1. Busque la máquina virtual de OVA y abra la pestaña Configurar (Configure) en la página de resumen de la máquina virtual de OVA.
    2. Vaya a Ajustes –> Opciones de vApp (Settings –> vApp Options).
    3. En la tabla Propiedades (Properties), busque la clave VERSIÓN (VERSION) y registre su Valor predeterminado (Default Value). Por ejemplo, v1.26.8+vmware.1-tkg.1-0edd4dafbefbdb503f64d5472e500cf8.
  - Para recuperar la versión de la imagen del sistema operativo mediante la CLI govc, ejecute el comando govc vm.info. Por ejemplo:
```
govc vm.info -json /dc0/vm/ubuntu-2004-kube-v1.26.8+vmware.1-tkg.1 | jq
```
    En el resultado, busque "Id": "VERSION" y registre el valor de la propiedad "DefaultValue". Por ejemplo:
```
{
"Key": 10,
"ClassId": "",
"InstanceId": "",
"Id": "VERSION",
"Category": "Cluster API Provider (CAPI)",
"Label": "VERSION",
"Type": "string",
"TypeReference": "",
"UserConfigurable": false,
"DefaultValue": "v1.26.8+vmware.1-tkg.1-0edd4dafbefbdb503f64d5472e500cf8",
"Value": "",
"Description": ""
}
```

Compilar una imagen de Linux

Configure la autenticación para su infraestructura:
- vSphere: Cree un archivo JSON de credenciales y rellene sus valores:
```
{
"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: Inicie sesión en la CLI de aws. Autentique y especifique su región, si se le solicita:
```
aws configure
```
- Azure: Inicie sesión en la CLI de az. A continuación, cree un archivo JSON de configuración azure-sig.json y rellene la información específica de Azure. Se puede encontrar un ejemplo de dicho archivo aquí.
Descargue el contenedor del paquete de recursos de Linux desde projects.registry.vmware.com:
1. Asegúrese de que la estación de trabajo pueda acceder al registro de imágenes VMware projects.registry.vmware.com.
2. Descargue y ejecute el contenedor con los archivos binarios de Kubernetes Linux que Image Builder necesita para compilar un archivo OVA de Linux:
```
docker pull projects.registry.vmware.com/tkg/linux-resource-bundle:v1.26.8_vmware.1-tkg.1

docker run -d -p 3000:3000 projects.registry.vmware.com/tkg/linux-resource-bundle:v1.26.8_vmware.1-tkg.1
```
Descargue el directorio de configuración de Image Builder:
1. Determine la versión de configuración de Image Builder a partir de la que desea compilar.
  - Busque el VMware {code} Sample Exchange para TKG Image Builder para ver una lista de las versiones disponibles.
  - Cada versión de Image Builder corresponde a sus versiones compatibles de Kubernetes y Tanzu Kubernetes Grid. Por ejemplo,TKG-Image-Builder-for-Kubernetes-v1_26_8---vmware_1-tkg_v2_3_1.zip crea una imagen de Kubernetes v1.26.8 para Tanzu Kubernetes Grid v2.3.1.
  - Si necesita crear un clúster de administración, que debe hacer cuando instale Tanzu Kubernetes Grid por primera vez, elija la versión de Kubernetes predeterminada de la versión de Tanzu Kubernetes Grid. Por ejemplo, en Tanzu Kubernetes Grid v2.3.1, la versión predeterminada de Kubernetes es la 1.26.8. Para los clústeres de carga de trabajo, también puede crear una imagen de Kubernetes v1.25.13 o v1.24.17, además de la v1.26.8.
  Los siguientes pasos explican cómo crear una imagen de Kubernetes v1.26.8 para Tanzu Kubernetes Grid v2.3.1.
2. Descargue el archivo zip del código de configuración y desempaquete su contenido.
3. cd en el directorio TKG-Image-Builder-, de modo que el archivo tkg.json se encuentre en el directorio actual.
vSphere Para obtener vSphere, cree un archivo metadata.json en el directorio de Image Builder que establezca una cadena de versión que coincida con lo que se muestra en el TKr personalizado en los pasos posteriores:
- Basado en clases: Utilice el valor que recuperó en el paso anterior Recuperar la versión de imagen del sistema operativo, por ejemplo:
```
{
"VERSION": "v1.26.8+vmware.1-tkg.1-0edd4dafbefbdb503f64d5472e500cf8"
}
```
- Basado en planes: Image-Builder proporciona los archivos OVA que crea una cadena de versión idéntica a los archivos OVA publicados por VMware, como v1.26.8+vmware.1-tkg.1. Para las imágenes personalizadas, VMware recomienda reemplazar la -tkg.1 por una cadena significativa para su organización, por ejemplo:
```
{
"VERSION": "v1.26.8+vmware.1-myorg.0"
}
```
Edite el archivo tkg.json para rellenar la configuración y personalizaciones <IP> y <PORT> de containerd_url y kubernetes_http_source, donde:
- IP corresponde a la dirección IP de la máquina que ejecuta el contenedor de Docker.
- PORT asocia un puerto no utilizado en el host Docker con el puerto 3000 en el contenedor, por ejemplo, 3001:3000. El contenedor expone los artefactos a través del puerto 3000.
Para incluir las siguientes opciones, continúe editando el archivo tkg.json:
- Photon: Si crea un archivo OVA en Photon-3, edite "extra_rpms" en tkg.json para reflejar los paquetes personalizados adicionales compatibles:
```
"extra_rpms": "sysstat nfs-utils ethtool apparmor-parser"
```
- Protección de STIG y CIS: Para proteger la imagen de Ubuntu personalizada por encima de los niveles predeterminados:
  1. Agregue una línea que establezca ansible_user_vars para que algunas o todas las variables siguientes estén en true. Estos valores predeterminados son false:
  2. STIG:
    - install_aide: activar AIDE (entorno de detección avanzada de intrusiones)
    - install_sshd_login_banner: banner de inicio de sesión del DoD de instalación
    - remove_existing_ca_certs: mantener la infraestructura de PKI de DoD
    - install_audispd_plugins: instalar complementos de multiplexor de eventos (audispd)
  3. CIS:
    - install_aide: activar AIDE (entorno de detección avanzada de intrusiones)
    - install_clamav: Activar el antivirus ClamAV
    - install_systemd_timesyncd: utilizar sincronizada en lugar de cronocrónica
    - install_protect_kernel_defaults: establecer valores predeterminados de protección de kernel ascendentes
  4. Modifique la configuración de custom_role_names agregando /home/imagebuilder/stig_ubuntu_2004 para STIG o /home/imagebuilder/cis_ubuntu_2004 para CIS.
  Por ejemplo, para la protección adicional de CIS:
```
  "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
  Las imágenes de Photon personalizadas no son compatibles con la protección adicional a través de ansible_user_vars.
- FIPS: Para crear una imagen compatible con FIPS, elimine el siguiente ajuste, si está presente:
```
"ansible_user_vars": "install_fips=no"
```
- Restringido por Internet: Para crear imágenes para un entorno restringido por Internet que acceda a Internet a través de un servidor proxy HTTP, agregue lo siguiente:
```
"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"
```
- Clústeres habilitados para GPU: Para compilar una imagen para un clúster habilitado para GPU agregue lo siguiente:
```
"vmx_version": "17"
```
Puede agregar personalizaciones adicionales a tkg.json o colocarlas en un archivo independiente customizations.json.
Recopile las siguientes cadenas de parámetros para conectarse al comando docker en el siguiente paso. Muchos de estos especifican los parámetros docker run -v que copian los directorios de trabajo actuales en el directorio /home/imagebuilder del contenedor utilizado para compilar la imagen:
- AUTHENTICATION: Copia el directorio de la CLI local. Utilice:
  - vSphere: /PATH/TO/CREDENTIALS.json:/home/imagebuilder/vsphere.json
  - AWS: ~/.aws:/home/imagebuilder/.aws
  - Azure: ~/.azure:/home/imagebuilder/.azure
- SOURCES: Copia el archivo tkg.json del repositorio, que enumera los orígenes de descarga del sistema operativo con versiones, Kubernetes y la interfaz de red de contenedor (Container Network Interface, CNI) Imágenes:
  - Utilice /PATH/TO/tkg.json:/home/imagebuilder/tkg.json
- ROLES: El directorio tkg del repositorio, que contiene las funciones de Ansible requeridas por Image Builder.
  - Utilice /PATH/TO/tkg:/home/imagebuilder/tkg
- TESTS: Copia un directorio de prueba goss diseñado para la infraestructura de destino de la imagen, el sistema operativo y la versión de Kubernetes:
  - Utilice el nombre de archivo de un archivo en el directorio goss del repositorio.
  - Ejemplos: amazon-ubuntu-1.26.8+vmware.1-goss-spec.yaml
- CUSTOMIZATIONS: Copia un archivo de personalización en formato JSON.
  - Consulte Personalización en la documentación de Image Builder.
  - Antes de realizar modificaciones, consulte con VMware Customer Reliability Engineering (CRE) para conocer las prácticas recomendadas y las recomendaciones.
- PACKER_VAR_FILES: Una lista delimitada por espacios de los archivos JSON anteriores que contiene variables para Packer.
- (Azure) AZURE-CREDS: Ruta de acceso a un archivo de credenciales de Azure, como se describe en la documentación de Image Builder.
- COMMAND: Use un comando como uno de los siguientes, en función del sistema operativo de imagen personalizado. Para las imágenes de Azure y vSphere, los comandos comienzan con build-node-ova- y 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: Clústeres habilitados para GPU

Con las cadenas anteriores, ejecute Image Builder en un contenedor docker extraído del registro VMware projects.registry.vmware.com:

Omita metadata.json si no crea una imagen para vSphere y env-file si no crea una imagen para 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
Este comando puede tardar varios minutos en completarse.

Ejemplos

vSphere: El archivo OVA .ova se guarda en el sistema de archivos local de la estación de trabajo. La carpeta en la que desee que se guarden los archivos OVA debe montarse en /home/imagebuilder/output dentro del contenedor. A continuación, cree el archivo OVA mediante la imagen del contenedor:

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.26.8+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

Para los clústeres habilitados para GPU: necesario incluir el archivo customizations.json creado en los pasos anteriores al ejecutar el comando para crear el archivo 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.26.8+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: Para crear un archivo OVA de RHEL, debe usar una máquina Linux, no macOS, ya que Docker en macOS no admite la opción --network host.
También debe registrar el sistema operativo como con licencia con Red Hat y registrarse para las actualizaciones agregando lo siguiente al comando docker run anterior:

  -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

Donde:

RHSM_USER y RHSM_PASS son el nombre de usuario y la contraseña para su cuenta de Red Hat Subscription Manager.
Asigne la ruta ISO de RHEL local en $(pwd)/isos/rhel-8.4-x86-64-dvd.iso en el ejemplo anterior, como un volumen adicional.

AWS: para crear una imagen personalizada con Ubuntu v20.04 y Kubernetes v1.26.8 para ejecutarse en AWS, ejecutándose desde el directorio que 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.26.8+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

Cargue la imagen en el proveedor de nube.
- Para obtener instrucciones de vSphere, consulte Importar la plantilla de imagen base en vSphere en Preparar para implementar clústeres de administración para vSphere.
- Si cargó el archivo OVA de Ubuntu predeterminado para la versión de Kubernetes de destino en vSphere, elimine el OVA predeterminado antes de cargar el OVA personalizado.

Crear un TKr para la imagen de Linux

Para que la imagen de Linux sea la predeterminada para futuras versiones de Kubernetes, cree un TKr basado en ella. De lo contrario, vaya a Usar una imagen de Linux para un clúster de carga de trabajo.

El siguiente diagrama proporciona una descripción general de alto nivel de cómo crear un TKr para una imagen de Linux personalizada en vSphere.

Crear un TKr

Para crear un TKr:

En el directorio ~/.config/tanzu/tkg/bom/, abra TKr BoM correspondiente a la versión de Kubernetes de la imagen personalizada. Por ejemplo con un nombre de archivo como tkr-bom-v1.26.8+vmware.1-tkg.1.yaml para Kubernetes v1.26.8.

Si el directorio no tiene el archivo TKr BoM que necesita, puede introducirlo implementando un clúster con la versión de Kubernetes deseada, como se describe en Implementar un clúster con una versión de Kubernetes no predeterminada.
1. En el archivo de BoM, busque los bloques de definición de imagen para la infraestructura: ova para vSphere, ami para AWS y azure para Azure. Cada bloque de definiciones de imágenes contiene osinfo.name, osinfo.version y osinfo.arch, donde:
  - osinfo.name es el nombre del sistema operativo. Por ejemplo, ubuntu. Para ver la lista de sistemas operativos compatibles, consulte Sistemas operativos principales.
  - osinfo.version es la versión del sistema operativo. Por ejemplo, 20.04. Para ver la lista de versiones compatibles, consulte Sistemas operativos principales.
  - osinfo.arch es el arco del SO. El valor compatible es amd64.
2. Para agregar una referencia a la nueva imagen de SO, agregue un bloque de definición de imagen en ova, ami o azure, según la infraestructura de destino. El bloque de definición de imagen debe contener osinfo.name, osinfo.version y osinfo.arch, como se describe anteriormente. Además, al agregar un bloque de definición de imagen en:
  - vSphere:
    - name: es un nombre único para su OVA que incluye la versión del sistema operativo, por ejemplo, my-ova-ubuntu-2004.
    - version: use la VERSION única asignada en metadata.json cuando creó el archivo OVA, por ejemplo, v1.26.8+vmware.1-myorg.0.
    Nota
    La version debe coincidir exactamente con la misma VERSION en metadata.json.
  - AWS: Para cada región en la que tenga pensado utilizar la imagen personalizada, siga el formato de valor id existente, pero utilice una cadena hexadecimal única al final, por ejemplo, ami-693a5e2348b25e428.
  Si el archivo de BoM define imágenes en regiones, el bloque de definición de imágenes personalizadas debe aparecer en primer lugar en su región. Dentro de cada región, el proceso de creación del clúster selecciona la primera imagen adecuada que aparece en la lista.
3. En el valor release.version, agregue un sufijo para establecer una versión personalizada. No personalice la versión agregando un prefijo. Por ejemplo, cambie v1.26.8+vmware.1-tkg.1 a v1.26.8+vmware.1-tkg.1-mycustomtkr.
4. Guarde el archivo de BoM con el mismo sufijo personalizado que especificó para release.version en el paso anterior.
  
  Si el nombre de archivo incluye un carácter más (+), reemplace el + por un guion triple (---).
  
  Por ejemplo, guarde el archivo BoM como tkr-bom-v1.26.8---vmware.2-tkg.1-mycustomtkr.yaml.
base64 codificar el contenido del archivo en una cadena binaria, por ejemplo:
```
cat tkr-bom-v1.26.8---vmware.2-tkg.1-mycustomtkr.yaml | base64 -w 0
```
Cree un archivo YAML de ConfigMap, por ejemplo denominado configmap-v1.26.8---vmware.2-tkg.1-mycustomtkr.yaml, con valores como se muestra:
```
apiVersion: v1
kind: ConfigMap
metadata:
 name: CUSTOM-TKG-BOM
 labels:
   tanzuKubernetesRelease: CUSTOM-TKR
binaryData:
 bomContent: "BOM-BINARY-CONTENT"
```
Donde:
- CUSTOM-TKG-BOM es el nombre de ConfigMap, que debe incluir el valor de TKr release.version que especificó en el archivo DE MATERIALES y reemplazar cualquier símbolo + por un guion triple (—). Por ejemplo, establezca v1.26.8---vmware.2-tkg.1-mycustomtkr.
- CUSTOM-TKR es un nombre para la TKr, que debe coincidir con el valor que especifique para CUSTOM-TKG-BOM. Por ejemplo, v1.26.8---vmware.2-tkg.1-mycustomtkr.
- BOM-BINARY-CONTENT es el contenido codificado en base64 del archivo de BoM personalizado que generó en el paso anterior.
Por ejemplo:
```
apiVersion: v1
kind: ConfigMap
metadata:
 name: v1.26.8---vmware.2-tkg.1-mycustomtkr
 labels:
   tanzuKubernetesRelease: v1.26.8---vmware.2-tkg.1-mycustomtkr
binaryData:
 bomContent: "YXBpVmVyc2lvbjogcnVuLnRhbnp1...."
```
Guarde el archivo ConfigMap, establezca el contexto kubectl en un clúster de administración al que desee agregar TKr y aplique el archivo al clúster, por ejemplo:
```
kubectl -n tkr-system apply -f configmap-v1.26.8---vmware.2-tkg.1-mycustomtkr.yaml
```
El controlador de TKr concilia el nuevo objeto ConfigMap creando un TanzuKubernetesRelease. El período de conciliación predeterminado es de 600 segundos. Para evitar este retraso, elimine el pod de TKr Controller, lo que hace que el pod se restaure y se concilia inmediatamente:
1. Lista de pods en el espacio de nombres tkr-system:
```
kubectl get pod -n tkr-system
```
2. Recupere el nombre del pod de TKr Controller, que tiene el aspecto tkr-controller-manager-f7bbb4bd4-d5lfd
3. Elimine el pod:
```
kubectl delete pod -n tkr-system TKG-CONTROLLER
```
  Donde TKG-CONTROLLER es el nombre del pod de TKr Controller.
Para comprobar que se agregó el TKr personalizado, ejecute tanzu kubernetes-release get o kubectl get tkr o y busque el valor CUSTOM-TKR establecido anteriormente en el resultado.

Una vez que el TKr personalizado aparezca en la lista de CLI de kubectl y tanzu, puede utilizarlo para crear clústeres de administración o de carga de trabajo, como se describe a continuación.

Usar una imagen de Linux para un clúster de administración

Para crear un clúster de administración que utilice la imagen personalizada como sistema operativo base para sus nodos:

Al ejecutar la interfaz del instalador, seleccione la imagen personalizada en el panel de imagen de sistema operativo, tal como se describe en Seleccionar imagen del sistema operativo base.

Para obtener más información, consulte Cómo se generan las opciones de imagen del sistema operativo base.

Usar una imagen de Linux para un clúster de carga de trabajo

El procedimiento para crear un clúster de carga de trabajo a partir de la imagen de Linux varía en función de si creó un TKr en Crear un TKr para la imagen de Linux anterior.

Si creó un TKr, pase el nombre de TKr como aparece en tanzu kubernetes-release get a la opción --tkr de tanzu cluster create.
Si no creó un TKr, siga estos pasos:
1. Copie el archivo de configuración del clúster de administración y guárdelo con un nombre nuevo siguiendo el procedimiento descrito en Especificaciones de objetos y archivos de configuración.
2. En el nuevo archivo de configuración, agregue o modifique lo siguiente:
```
VSPHERE_TEMPLATE: LINUX-IMAGE
```
  Donde LINUX-IMAGE es el nombre de la imagen de Linux que creó en Compilar una imagen de Linux.
  
  Elimine CLUSTER_NAME y su configuración, si existe.
3. Implemente un clúster de carga de trabajo como se describe en Crear clústeres de carga de trabajo.