Cette procédure vous guide à travers la création d'une image de machine personnalisée Linux à utiliser lors de la création de clusters sur AWS, Azure ou vSphere. Elle se divise selon les sections ci-dessous. Pour plus d'informations sur les types de clusters dans Tanzu Kubernetes Grid, reportez-vous à la section Types de clusters de charge de travail.
Comme indiqué dans les procédures, certaines étapes diffèrent selon que vous créez une image pour un cluster basé sur une classe ou sur un plan (hérité).
Pour créer une image de machine personnalisée Linux, vous avez besoin des éléments suivants :
aws
az
Avant de créer une image à utiliser pour les clusters basés sur une classe sur vSphere, vous devez récupérer la version de l'image du système d'exploitation associée au fichier OVA Ubuntu par défaut pour la version de Kubernetes que vous souhaitez utiliser pour votre image personnalisée. Vous attribuerez cette version de l'image du système d'exploitation à votre image personnalisée dans l'étape Créer une image Linux ci-dessous.
Pour récupérer la version de l'image du système d'exploitation, effectuez l'une des opérations suivantes en fonction de votre cas d'utilisation :
Si vous disposez d'un cluster de gestion en cours d'exécution qui a été créé à l'aide de la version par défaut de Kubernetes pour la version actuelle de Tanzu Kubernetes Grid, vous pouvez récupérer la version de l'image du système d'exploitation à partir du cluster :
Définissez votre contexte kubectl
sur le cluster de gestion.
Dans la liste des TKr disponibles, choisissez la version de Tanzu Kubernetes (TKr) pour la version de Kubernetes que vous souhaitez utiliser pour votre image personnalisée. Par exemple, v1.27.5---vmware.2-tkg.1
. Pour répertorier les TKr disponibles, exécutez :
kubectl get tkr
Ouvrez la TKr et localisez la propriété osImages
. Cette propriété spécifie les noms des objets OSImage
associés à la TKr.
Localisez l'objet OSImage
et ouvrez-le pour le fichier OVA par défaut Ubuntu. Le nom de l'objet OSImage
correspond à l'un des noms osImages
de la TKr.
kubectl get osimages
Dans l'objet OSImage
du fichier OVA Ubuntu par défaut, recherchez la valeur de la propriété version
et enregistrez-la sous spec.image.ref
. Par exemple, v1.27.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e
.
Si vous ne disposez pas d'un cluster de gestion en cours d'exécution qui a été créé à l'aide de la version par défaut de Kubernetes pour la version actuelle de Tanzu Kubernetes Grid, vous pouvez récupérer la version de l'image du système d'exploitation directement à partir du fichier OVA Ubuntu par défaut, localement ou à partir de vSphere :
Pour récupérer la version de l'image du système d'exploitation localement :
.ofv
.Dans le fichier .ofv
, recherchez la propriété VERSION
du fichier OVA et consignez sa valeur. Par exemple, v1.27.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e
. La propriété est semblable à l'exemple suivant :
<Property ovf:key="VERSION" ovf:type="string" ovf:userConfigurable="false" ovf:value="v1.27.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e"/>
Si vous avez déjà chargé le fichier OVA Ubuntu par défaut pour votre version de Kubernetes cible vers vSphere, vous pouvez également récupérer la version de l'image du système d'exploitation en inspectant les propriétés de la VM OVA dans l'interface utilisateur de vSphere ou à l'aide de l'interface de ligne de commande govc
. Pour utiliser cette méthode, récupérez la version de l'image du système d'exploitation avant de convertir la VM OVA en modèle.
Pour récupérer la version de l'image du système d'exploitation à partir de l'interface utilisateur de vSphere :
v1.27.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e
.Pour récupérer la version de l'image du système d'exploitation à l'aide de l'interface de ligne de commande govc
, exécutez la commande govc vm.info
. Par exemple :
govc vm.info -json /dc0/vm/ubuntu-2004-kube-v1.27.5+vmware.1-tkg.1 | jq
Dans la sortie, recherchez "Id": "VERSION"
et enregistrez la valeur de la propriété "DefaultValue"
. Par exemple :
{
"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": ""
}
Configurez l'authentification pour votre infrastructure :
vSphere : Créez un fichier JSON d'informations d'identification et renseignez ses valeurs :
{
"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 : Connectez-vous à l'interface de ligne de commande aws
. Authentifiez-vous ensuite et spécifiez votre région, si vous y êtes invité :
aws configure
Azure : Connectez-vous à l'interface de ligne de commande az
. Ensuite, créez un fichier JSON de configuration azure-sig.json
et renseignez les informations spécifiques à Azure. Vous trouverez un exemple de ce type de fichier ici.
Téléchargez le conteneur de bundle de ressources Linux à partir de projects.registry.vmware.com
:
Assurez-vous que votre poste de travail peut accéder à l'adresse projects.registry.vmware.com
du registre d'images VMware.
Téléchargez et exécutez le conteneur avec les fichiers binaires Linux dans Kubernetes dont Image Builder a besoin pour créer un fichier OVA 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
Téléchargez le répertoire de configuration d'Image Builder :
Déterminez la version de configuration d'Image Builder à partir de laquelle vous souhaitez effectuer la création.
TKG Image Builder
afin de répertorier les versions disponibles.TKG-Image-Builder-for-Kubernetes-v1.27.5-on-TKG-v2.4.0-master.zip
crée une image Kubernetes v1.27.5 pour Tanzu Kubernetes Grid v2.4.0.Les étapes ci-dessous expliquent comment créer une image Kubernetes v1.27.5 pour Tanzu Kubernetes Grid v2.4.0.
Téléchargez le fichier ZIP du code de configuration et décompressez son contenu.
cd
dans le répertoire TKG-Image-Builder-
, afin que le fichier tkg.json
se trouve dans votre répertoire actuel.
vSphere : pour vSphere, créez un fichier metadata.json
dans le répertoire d'Image Builder qui définit une chaîne de version afin qu'elle corresponde à ce que vous répertoriez dans votre TKr personnalisée aux étapes suivantes
Basé sur une classe (Class-based) : Utilisez la valeur que vous avez récupérée à l'étape Récupérer la version de l'image du système d'exploitation ci-dessus, par exemple :
{
"VERSION": "v1.27.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e"
}
Basé sur un plan (Plan-based) : Le module image-builder fournit les fichiers OVA pour lesquels il crée une chaîne de version identique aux fichiers OVA publiés par VMware, par exemple v1.27.5+vmware.1-tkg.1
. Pour les images personnalisées, VMware recommande de remplacer -tkg.1
par une chaîne ayant du sens pour votre organisation, par exemple :
{
"VERSION": "v1.27.5+vmware.1-myorg.0"
}
Modifiez le fichier tkg.json
pour renseigner les paramètres <IP>
et <PORT>
, ainsi que les personnalisations pour containerd_url
et kubernetes_http_source
, où :
IP
correspond à l'adresse IP de la machine exécutant le conteneur Docker.PORT
associe un port inutilisé sur l'hôte Docker au port 3000 sur le conteneur (par exemple 3001:3000
). Le conteneur expose les artefacts sur le port 3000.Pour inclure les options suivantes, continuez à modifier le fichier tkg.json
:
Photon : Si vous créez un fichier OVA Photon-3, modifiez "extra_rpms"
dans tkg.json
pour refléter les modules personnalisés supplémentaires pris en charge :
"extra_rpms": "sysstat nfs-utils ethtool apparmor-parser"
Sécurisation renforcée STIG et CIS : Pour renforcer votre image Ubuntu personnalisée au-dessus des niveaux par défaut :
Ajoutez une ligne qui définit ansible_user_vars
sur une partie ou la totalité des variables suivantes sur true
. Celles-ci utilisent par défaut false
:
STIG :
install_aide
: activer AIDE (Advanced Intrusion Detection Environment)install_sshd_login_banner
: installer la bannière de connexion du Département américain de la Défenseremove_existing_ca_certs
: conserver l'infrastructure PKI du Département américain de la Défenseinstall_audispd_plugins
: installer les plug-ins de multiplexeur d'événements (audispd)CIS :
install_aide
: activer AIDE (Advanced Intrusion Detection Environment)install_clamav
: activer l'antivirus ClamAVinstall_systemd_timesyncd
: utiliser timesyncd au lieu de chronyinstall_protect_kernel_defaults
: définir les valeurs par défaut de protection des noyaux en amontModifiez le paramètre custom_role_names
en ajoutant /home/imagebuilder/stig_ubuntu_2004
pour STIG ou /home/imagebuilder/cis_ubuntu_2004
pour CIS.
Par exemple, pour une sécurisation renforcée CIS supplémentaire :
"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",
RemarqueLes images Photon personnalisées ne sont pas prises en charge pour une sécurisation renforcée supplémentaire via
ansible_user_vars
.
FIPS : pour créer une image compatible FIPS, supprimez le paramètre suivant, s'il est présent :
"ansible_user_vars": "install_fips=no"
Accès restreint à Internet (Internet-Restricted) : Pour créer des images pour un environnement à accès restreint à Internet qui accède à Internet via un serveur proxy HTTP, ajoutez les éléments suivants :
"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"
Clusters compatibles GPU : pour créer une image pour un cluster compatible GPU, ajoutez les éléments suivants :
"vmx_version": "17"
Vous pouvez ajouter des personnalisations supplémentaires à tkg.json
ou les placer dans un fichier customizations.json
distinct.
Collectez les chaînes de paramètres suivantes à intégrer dans la commande docker
à l'étape suivante. Plusieurs d'entre elles spécifient les paramètres docker run -v
qui copient vos répertoires de travail actuels dans le répertoire /home/imagebuilder
du conteneur utilisé pour créer l'image :
AUTHENTICATION
: Copie votre répertoire d'interface de ligne de commande local. Utilisez :
/PATH/TO/CREDENTIALS.json:/home/imagebuilder/vsphere.json
~/.aws:/home/imagebuilder/.aws
~/.azure:/home/imagebuilder/.azure
SOURCES
: Copie le fichier tkg.json
du référentiel, qui répertorie les sources de téléchargement pour les images du système d'exploitation, de Kubernetes et d'interface réseau de conteneur (CNI) avec leur version :
/PATH/TO/tkg.json:/home/imagebuilder/tkg.json
ROLES
: Répertoire tkg
du référentiel qui contient les rôles Ansible requis par Image Builder.
TESTS
: Copie un répertoire de test goss
conçu pour la version d'infrastructure cible, de système d'exploitation et Kubernetes de l'image :
goss
du référentiel.amazon-ubuntu-1.27.5+vmware.1-goss-spec.yaml
CUSTOMIZATIONS
: Copie un fichier de personnalisations au format JSON.
PACKER_VAR_FILES
: Liste délimitée par des espaces des fichiers JSON ci-dessus qui contiennent des variables pour Packer.AZURE-CREDS
: Chemin d'accès à un fichier d'informations d'identification Azure, comme décrit dans la documentation d'Image Builder.COMMAND
: Utilisez une commande semblable à l'une des suivantes, en fonction de l'image de système d'exploitation personnalisée. Pour les images vSphere et Azure, les commandes commencent par build-node-ova-
et 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
: Clusters compatibles GPUÀ l'aide des chaînes ci-dessus, exécutez Image Builder dans un conteneur Docker extrait du registre VMware projects.registry.vmware.com
Omettez metadata.json
si vous ne créez pas d'image pour vSphere et env-file
si vous ne créez pas d'image pour 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
RemarqueCette commande peut prendre plusieurs minutes pour se terminer.
Exemples
vSphere : le fichier .ova
est enregistré dans le système de fichiers local de votre station de travail. Le dossier dans lequel vous souhaitez enregistrer ces images OVA doit être monté sur /home/imagebuilder/output
dans le conteneur. Créez ensuite l'image OVA à l'aide de l'image de conteneur :
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
Clusters compatibles GPU : incluez le fichier customizations.json
créé dans les étapes ci-dessus lors de l'exécution de la commande de création du fichier 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 : pour créer un fichier OVA de RHEL, vous devez utiliser une machine Linux et non macOS, car Docker sur macOS ne prend pas en charge l'option --network host
.
Vous devez également enregistrer le système d'exploitation comme étant sous licence avec Red Hat et vous inscrire aux mises à jour en ajoutant ce qui suit à la commande docker run
ci-dessus :
-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
Où :
RHSM_USER
et RHSM_PASS
sont le nom d'utilisateur et le mot de passe de votre compte Red Hat Subscription Manager.$(pwd)/isos/rhel-8.4-x86-64-dvd.iso
dans l'exemple ci-dessus, en tant que volume supplémentaire.AWS : créez une image personnalisée avec Ubuntu v20.04 et Kubernetes v1.27.5 pour l'exécuter sur AWS à partir du répertoire qui contient 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
Téléchargez l'image vers votre fournisseur de cloud.
Pour faire de votre image Linux la valeur par défaut pour les futures versions de Kubernetes, créez une TKr basée sur celle-ci. Sinon, passez à l'étape Utiliser une image Linux pour un cluster de charge de travail.
Le diagramme ci-dessous fournit une présentation générale de la création d'une TKr pour une image Linux personnalisée sur vSphere.
Pour créer une TKr :
Dans le répertoire ~/.config/tanzu/tkg/bom/
, ouvrez la nomenclature TKr correspondant à la version de Kubernetes de votre image personnalisée. Par exemple, avec un nom de fichier tel que tkr-bom-v1.27.5+vmware.1-tkg.1.yaml
pour Kubernetes v1.27.5.
Si le répertoire ne contient pas le fichier de nomenclature TKr dont vous avez besoin, vous pouvez l'intégrer en déployant un cluster avec la version de Kubernetes souhaitée, comme décrit dans Déployer un cluster avec une version de Kubernetes non définie par défaut.
Dans le fichier de nomenclature, recherchez les blocs de définition d'image pour votre infrastructure : ova
pour vSphere, ami
pour AWS et azure
pour Azure. Chaque bloc de définition d'image contient osinfo.name
, osinfo.version
et osinfo.arch
, où :
osinfo.name
est le nom du système d'exploitation. Par exemple, ubuntu
. Pour afficher la liste des systèmes d'exploitation pris en charge, reportez-vous à la section Systèmes d'exploitation cibles.osinfo.version
est la version du système d'exploitation. Par exemple, 20.04
. Pour afficher la liste des systèmes d'exploitation pris en charge, reportez-vous à la section Systèmes d'exploitation cibles.osinfo.arch
est l'architecture du système d'exploitation. La valeur prise en charge est amd64
.Pour ajouter une référence à votre nouvelle image de système d'exploitation, ajoutez un bloc de définition d'image sous ova
, ami
ou azure
, en fonction de votre infrastructure cible. Votre bloc de définition d'image doit contenir osinfo.name
, osinfo.version
et osinfo.arch
, comme décrit ci-dessus. En outre, lors de l'ajout d'un bloc de définition d'image sur :
vSphere :
name:
est un nom unique pour votre image OVA qui inclut la version du système d'exploitation, par exemple, my-ova-ubuntu-2004
.version:
utilisez la VERSION
unique attribuée dans metadata.json
lorsque vous avez créé l'image OVA, par exemple, v1.27.5+vmware.1-myorg.0
.RemarqueLa
version
doit correspondre exactement à la mêmeVERSION
dans le fichiermetadata.json
.
id
existant, mais utilisez une chaîne hexadécimale unique à la fin, par exemple, ami-693a5e2348b25e428
.Si le fichier de nomenclature définit les images selon les régions, votre bloc de définition d'image personnalisé doit d'abord être répertorié dans sa région. Dans chaque région, le processus de création de cluster sélectionne la première image appropriée qui est répertoriée.
Dans la valeur release.version
, définissez une version personnalisée en ajoutant un suffixe. Ne personnalisez pas la version en ajoutant un préfixe. Par exemple, remplacez v1.27.5+vmware.1-tkg.1
par v1.27.5+vmware.1-tkg.1-mycustomtkr
.
Enregistrez le fichier de nomenclature avec le même suffixe personnalisé que vous avez spécifié pour release.version
à l'étape précédente.
Si le nom de fichier inclut un caractère plus (+
), remplacez le +
par un triple tiret (---
).
Par exemple, enregistrez le fichier de nomenclature sous la forme tkr-bom-v1.27.5---vmware.2-tkg.1-mycustomtkr.yaml
.
base64
- codez le contenu du fichier dans une chaîne binaire, par exemple :
cat tkr-bom-v1.27.5---vmware.2-tkg.1-mycustomtkr.yaml | base64 -w 0
Créez un fichier YAML ConfigMap (nommé configmap-v1.27.5---vmware.2-tkg.1-mycustomtkr.yaml
, par exemple) avec les valeurs comme suit :
apiVersion: v1
kind: ConfigMap
metadata:
name: CUSTOM-TKG-BOM
labels:
tanzuKubernetesRelease: CUSTOM-TKR
binaryData:
bomContent: "BOM-BINARY-CONTENT"
Où :
CUSTOM-TKG-BOM
est le nom du fichier ConfigMap
qui doit inclure la valeur release.version
de la TKr que vous avez spécifiée dans le fichier de nomenclature et remplacez tous les symboles + par un triple tiret (—). Par exemple, définissez v1.27.5---vmware.2-tkg.1-mycustomtkr
.CUSTOM-TKR
est un nom pour votre TKr, qui doit correspondre à la valeur que vous spécifiez pour CUSTOM-TKG-BOM
. Par exemple, v1.27.5---vmware.2-tkg.1-mycustomtkr
.BOM-BINARY-CONTENT
est le contenu codé en base64
de votre fichier de nomenclature personnalisé que vous avez généré à l'étape précédente.Par exemple :
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...."
Enregistrez le fichier ConfigMap
, définissez le contexte kubectl
sur un cluster de gestion auquel vous souhaitez ajouter la TKr et appliquez le fichier au cluster, par exemple :
kubectl -n tkr-system apply -f configmap-v1.27.5---vmware.2-tkg.1-mycustomtkr.yaml
Le contrôleur TKr rapproche le nouvel objet ConfigMap
en créant une TanzuKubernetesRelease
. La période de rapprochement par défaut est de 600 secondes. Vous pouvez éviter ce retard en supprimant l'espace du contrôleur TKr, ce qui restaure et rapproche l'espace immédiatement :
Répertoriez les espaces dans l'espace de noms tkr-system
:
kubectl get pod -n tkr-system
Récupérez le nom de l'espace du contrôleur TKr, qui ressemble à tkr-controller-manager-f7bbb4bd4-d5lfd
Supprimez l'espace :
kubectl delete pod -n tkr-system TKG-CONTROLLER
Où TKG-CONTROLLER
est le nom de l'espace du contrôleur TKr.
Pour vérifier que la TKr personnalisée a été ajoutée, exécutez tanzu kubernetes-release get
ou kubectl get tkr
et recherchez la valeur CUSTOM-TKR
définie ci-dessus dans la sortie.
Une fois que votre TKr personnalisée est répertoriée par les interfaces de ligne de commande kubectl
et tanzu
, vous pouvez l'utiliser pour créer des clusters de gestion ou de charge de travail comme décrit ci-dessous.
Pour créer un cluster de gestion qui utilise votre image personnalisée comme système d'exploitation de base pour ses nœuds :
Pour plus d'informations, reportez-vous à la section Comment les choix d'image de système d'exploitation de base sont-ils générés ?.
La procédure de création d'un cluster de charge de travail à partir de votre image Linux varie selon que vous avez créé ou non une TKr dans la section Créer une TKr pour l'image Linux ci-dessus.
Si vous avez créé une TKr, transmettez le nom de la TKr tel que répertorié par tanzu kubernetes-release get
à l'option --tkr
de tanzu cluster create
.
Si vous n'avez pas créé de TKr, procédez comme suit :
Copiez le fichier de configuration du cluster de gestion et enregistrez-le avec un nouveau nom en suivant la procédure décrite dans la section Fichiers de configuration et spécifications d'objet.
Dans le nouveau fichier de configuration, ajoutez ou modifiez les éléments suivants :
VSPHERE_TEMPLATE: LINUX-IMAGE
Où LINUX-IMAGE
est le nom de l'image Linux que vous avez créée dans Créer une image Linux.
Supprimez CLUSTER_NAME
et son paramètre, s'il existe.
Déployez un cluster de charge de travail comme décrit dans la section Créer des clusters de charge de travail.