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.
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).
Para crear una imagen de máquina personalizada de Linux, necesita:
aws
(CLI)az
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:
Establezca el contexto kubectl
en el clúster de administración.
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.27.5---vmware.2-tkg.1
. Para enumerar las TKr disponibles, ejecute:
kubectl get tkr
Abra la TKr y busque la propiedad osImages
. Esta propiedad especifica los nombres de los objetos OSImage
asociados con la TKr.
Busque y abra el objeto OSImage
para el archivo OVA de Ubuntu predeterminado. El nombre del objeto OSImage
coincide con uno de los nombres osImages
de la TKr.
kubectl get osimages
En el objeto OSImage
para el archivo OVA de Ubuntu predeterminado, busque y registre el valor de la propiedad version
en spec.image.ref
. Por ejemplo, v1.27.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e
.
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:
.ofv
.En el archivo .ofv
, busque la propiedad VERSION
de OVA y registre su valor. Por ejemplo, v1.27.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e
. La propiedad debe ser similar al siguiente mensaje:
<Property ovf:key="VERSION" ovf:type="string" ovf:userConfigurable="false" ovf:value="v1.27.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e"/>
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:
v1.27.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e
.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.27.5+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.27.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e",
"Value": "",
"Description": ""
}
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
:
Asegúrese de que la estación de trabajo pueda acceder al registro de imágenes VMware projects.registry.vmware.com
.
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.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
Descargue el directorio de configuración de Image Builder:
Determine la versión de configuración de Image Builder a partir de la que desea compilar.
TKG Image Builder
para ver una lista de las versiones disponibles.TKG-Image-Builder-for-Kubernetes-v1.27.5-on-TKG-v2.4.0-master.zip
crea una imagen de Kubernetes v1.27.5 para Tanzu Kubernetes Grid v2.4.0.Los siguientes pasos explican cómo compilar una imagen de Kubernetes v1.27.5 para Tanzu Kubernetes Grid v2.4.0.
Descargue el archivo zip del código de configuración y desempaquete su contenido.
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.27.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e"
}
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.27.5+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.27.5+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:
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
:
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ónremove_existing_ca_certs
: mantener la infraestructura de PKI de DoDinstall_audispd_plugins
: instalar complementos de multiplexor de eventos (audispd)CIS:
install_aide
: activar AIDE (entorno de detección avanzada de intrusiones)install_clamav
: Activar el antivirus ClamAVinstall_systemd_timesyncd
: utilizar sincronizada en lugar de cronocrónicainstall_protect_kernel_defaults
: establecer valores predeterminados de protección de kernel ascendentesModifique 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",
NotaLas 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:
/PATH/TO/CREDENTIALS.json:/home/imagebuilder/vsphere.json
~/.aws:/home/imagebuilder/.aws
~/.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:
/PATH/TO/tkg.json:/home/imagebuilder/tkg.json
ROLES
: El directorio tkg
del repositorio, que contiene las funciones de Ansible requeridas por Image Builder.
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:
goss
del repositorio.amazon-ubuntu-1.27.5+vmware.1-goss-spec.yaml
CUSTOMIZATIONS
: Copia un archivo de personalización en formato JSON.
PACKER_VAR_FILES
: Una lista delimitada por espacios de los archivos JSON anteriores que contiene variables para Packer.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.04build-ami-ubuntu-1804
: Ubuntu v18.04build-ami-amazon-2
: Amazon Linux 2build-node-ova-vsphere-ubuntu-2004
: Clústeres habilitados para GPUCon 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
NotaEste 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.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
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.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: 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.$(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.27.5 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.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
Cargue la imagen en el proveedor de nube.
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.
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.27.5+vmware.1-tkg.1.yaml
para Kubernetes v1.27.5.
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.
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
.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.27.5+vmware.1-myorg.0
.NotaLa
version
debe coincidir exactamente con la mismaVERSION
enmetadata.json
.
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.
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.27.5+vmware.1-tkg.1
a v1.27.5+vmware.1-tkg.1-mycustomtkr
.
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.27.5---vmware.2-tkg.1-mycustomtkr.yaml
.
base64
codificar el contenido del archivo en una cadena binaria, por ejemplo:
cat tkr-bom-v1.27.5---vmware.2-tkg.1-mycustomtkr.yaml | base64 -w 0
Cree un archivo YAML de ConfigMap, por ejemplo denominado configmap-v1.27.5---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.27.5---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.27.5---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.27.5---vmware.2-tkg.1-mycustomtkr
labels:
tanzuKubernetesRelease: v1.27.5---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.27.5---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:
Lista de pods en el espacio de nombres tkr-system
:
kubectl get pod -n tkr-system
Recupere el nombre del pod de TKr Controller, que tiene el aspecto tkr-controller-manager-f7bbb4bd4-d5lfd
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.
Para crear un clúster de administración que utilice la imagen personalizada como sistema operativo base para sus nodos:
Para obtener más información, consulte Cómo se generan las opciones de imagen del sistema operativo base.
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:
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.
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.
Implemente un clúster de carga de trabajo como se describe en Crear clústeres de carga de trabajo.