Images de machines personnalisées Linux (héritées)

Cette procédure vous explique comment créer une image de machine personnalisée Linux à utiliser lors de la création de clusters (hérités) basés sur un plan 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.

Conditions préalables à l'image Linux répertorie les éléments dont vous avez besoin pour créer et utiliser une image Linux personnalisée.
Créer une image Linux indique comment utiliser Kubernetes Image Builder et Docker pour personnaliser et créer une image.
Créer une TKr pour l'image Linux indique comment convertir votre image Linux en une version de Tanzu Kubernetes (TKr, Tanzu Kubernetes release), qui permettra de définir votre image comme image par défaut pour les futures versions de Kubernetes et de vous offrir plus d'options pour son utilisation et sa gestion.
Utiliser une image Linux pour un cluster de gestion indique comment déployer un cluster de gestion qui utilise votre image personnalisée comme modèle.
Utiliser une image Linux pour un cluster de charge de travail indique comment déployer un cluster de charge de travail qui utilise votre image personnalisée comme modèle.

Conditions préalables à l'image Linux

Pour créer une image de machine personnalisée Linux, vous avez besoin des éléments suivants :

Un compte sur votre infrastructure cible, AWS, Azure ou vSphere.
Un poste de travail macOS ou Linux sur lequel les éléments suivants sont installés :
- Docker Desktop
- Pour AWS : interface de ligne de commande aws
- Pour Azure : interface de ligne de commande az
- Pour vSphere : pour créer une image RHEL 8, vous avez besoin d'un poste de travail Linux, pas macOS.

Créer une image Linux

Sur AWS et Azure, connectez-vous à l'interface de ligne de commande de votre infrastructure. Authentifiez-vous et spécifiez votre région, si vous y êtes invité :
- AWS : Exécutez aws configure.
- Azure : Exécutez az login.
Sur Azure, 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.

Sur 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": ""
}

Déterminez la version de configuration d'Image Builder à partir de laquelle vous souhaitez effectuer la création.
- Recherchez l'échantillon d'échange VMware {code} pour TKG Image Builder afin de répertorier les versions disponibles.
- Chaque version d'Image Builder correspond à ses versions compatibles de Kubernetes et de Tanzu Kubernetes Grid. Par exemple, TKG-Image-Builder-for-Kubernetes-v1.24.10-on-TKG-v2.1.1-master.zip crée une image Kubernetes v1.24.10 pour Tanzu Kubernetes Grid v2.1.1.
- Si vous devez créer un cluster de gestion, ce que vous devez faire lorsque vous installez Tanzu Kubernetes Grid pour la première fois, choisissez la version de Kubernetes par défaut de votre version de Tanzu Kubernetes Grid. Par exemple, dans Tanzu Kubernetes Grid 2.1.1, la version par défaut de Kubernetes est 1.24.10. Pour les clusters de charge de travail, vous pouvez également créer une image Kubernetes de version 1.23.16 ou 1.22.17, en plus de la version 1.24.10.
Les étapes ci-dessous expliquent comment créer une image Kubernetes de version 1.24.10 pour Tanzu Kubernetes Grid 2.1.1.
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.
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 d'artefacts souhaité à partir de l'adresse projects.registry.vmware.com.

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

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

Modifiez tkg.json pour remplir <IP> et <PORT>, 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.
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"
```
Pour créer une image compatible FIPS, supprimez la ligne suivante dans tkg.json :
```
"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 ce qui suit au fichier tkg.json :
```
{
  "http_proxy": "http://proxy.acme.com:80",
  "https_proxy": "http://proxy.acme.com:80",
  "no_proxy": "localhost, 127.0.0.1, acme.com, 10.0.0.0/8"
}
```
Clusters compatibles GPU : Pour créer une image pour un cluster compatible GPU pour vSphere, créez un fichier nommé customizations.json et ajoutez les éléments suivants :
```
{
"vmx_version": "17"
}
```
Enregistrez le fichier customizations.json dans le même répertoire que le fichier tkg.json, que vous avez modifié à l'étape précédente.
Collectez les chaînes de paramètre suivantes à intégrer dans la commande à 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 :
  - AWS : Utilisez ~/.aws:/home/imagebuilder/.aws
  - Azure : Utilisez ~/.azure:/home/imagebuilder/.azure
  - vSphere : /PATH/TO/CREDENTIALS.json:/home/imagebuilder/vsphere.json
- 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 :
  - Utilisez /PATH/TO/tkg.json:/home/imagebuilder/tkg.json
- ROLES : Copie le répertoire tkg du référentiel, qui contient les rôles Ansible requis par Image Builder.
  - Utilisez /PATH/TO/tkg:/home/imagebuilder/tkg
  - Pour ajouter des rôles Ansible personnalisés, modifiez le fichier tkg.json pour reformater le paramètre custom_role_names avec des guillemets d'échappement (\") afin de produire une liste comportant plusieurs rôles. Par exemple :
    "custom_role_names": "\"/home/imagebuilder/tkg /home/imagebuilder/mycustomrole\"",
- 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 :
  - Utilisez le nom d'un fichier dans le répertoire goss du référentiel (par exemple, amazon-ubuntu-1.24.10+vmware.1-goss-spec.yaml).
- CUSTOMIZATIONS : Copie un fichier de personnalisations au format JSON. Reportez-vous à la section Personnalisation dans la documentation d'Image Builder. Avant d'effectuer des modifications, consultez VMware CRE (Customer Reliability Engineering) pour connaître les meilleures pratiques et les recommandations.
- PACKER_VAR_FILES : Liste délimitée par des espaces des fichiers JSON ci-dessus qui contiennent des variables pour Packer.
- (Azure) 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.04
  - build-ami-ubuntu-1804 : Ubuntu v18.04
  - build-ami-amazon-2 : Amazon Linux 2
  - build-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 :

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

Remarque
omettez env-file si vous ne créez pas d'image pour Azure. Cette commande peut prendre plusieurs minutes pour se terminer.

À titre d'exemple, voici la marche à suivre pour créer une image personnalisée avec Ubuntu 20.04 et Kubernetes 1.24.10 qui sera utilisée sur AWS et qui s'exécutera à partir du répertoire contenant tkg.json :

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

Pour vSphere, vous devez utiliser l'image de conteneur personnalisée créée ci-dessus. Vous devez également définir une chaîne de version qui correspondra à ce que vous avez transmis dans votre TKr personnalisée dans les étapes ultérieures. Bien que les images OVA publiées par VMware disposent d'une chaîne de version telle que v1.24.10+vmware.1-tkg.1, il est recommandé de remplacer -tkg.1 par une chaîne explicite pour votre organisation. Pour définir cette chaîne de version, définissez-la dans un fichier metadata.json comme suit :

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

Lors de la création d'images OVA, le fichier .ova est enregistré dans le système de fichiers local de votre poste 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.24.10+vmware.1-goss-spec.yaml:/home/imagebuilder/goss/goss.yaml \
  -v $(pwd)/metadata.json:/home/imagebuilder/metadata.json \
  -v /PATH/TO/OVA/DIR:/home/imagebuilder/output \
  --env PACKER_VAR_FILES="tkg.json vsphere.json" \
  --env OVF_CUSTOM_PROPERTIES=/home/imagebuilder/metadata.json \
  --env IB_OVFTOOL=1 \
  projects.registry.vmware.com/tkg/image-builder:v0.1.13_vmware.2 \
  build-node-ova-vsphere-ubuntu-2004

Pour les clusters compatibles GPU, vous devez inclure 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.24.10+vmware.1-goss-spec.yaml:/home/imagebuilder/goss/goss.yaml \
  -v $(pwd)/metadata.json:/home/imagebuilder/metadata.json \
  -v $(pwd)/customizations.json:/home/imagebuilder/customizations.json \
  -v /PATH/TO/OVA/DIR:/home/imagebuilder/output \
  --env PACKER_VAR_FILES="tkg.json vsphere.json customizations.json" \
  --env OVF_CUSTOM_PROPERTIES=/home/imagebuilder/metadata.json \
  --env IB_OVFTOOL=1 \
  projects.registry.vmware.com/tkg/image-builder:v0.1.13_vmware.2 \
  build-node-ova-vsphere-ubuntu-2004

RHEL : Pour créer une image 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.
Vous mappez votre chemin ISO RHEL local, dans $(pwd)/isos/rhel-8.4-x86-64-dvd.iso dans l'exemple ci-dessus, en tant que volume supplémentaire.

Créer une TKr pour l'image Linux

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.

Créer une TKr

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.24.10+vmware.1-tkg.1.yaml pour Kubernetes 1.24.10.

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.
1. 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.
2. 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.24.10+vmware.1-myorg.0.
    Remarque
    La version doit correspondre exactement à la même VERSION dans le fichier metadata.json.
  - AWS : Pour chaque région dans laquelle vous prévoyez d'utiliser l'image personnalisée, suivez le format de valeur 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.
3. 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.24.10+vmware.1-tkg.1 par v1.24.10+vmware.1-tkg.1-mycustomtkr.
4. 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.24.10---vmware.1-tkg.1-mycustomtkr.yaml.
base64 - codez le contenu du fichier dans une chaîne binaire, par exemple :
```
cat tkr-bom-v1.24.10---vmware.1-tkg.1-mycustomtkr.yaml | base64 -w 0
```
Créez un fichier YAML ConfigMap (nommé configmap-v1.24.10---vmware.1-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.24.10---vmware.1-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.24.10---vmware.1-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.24.10---vmware.1-tkg.1-mycustomtkr
 labels:
   tanzuKubernetesRelease: v1.24.10---vmware.1-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.24.10---vmware.1-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 :
1. Répertoriez les espaces dans l'espace de noms tkr-system :
```
kubectl get pod -n tkr-system
```
2. Récupérez le nom de l'espace du contrôleur TKr, qui ressemble à tkr-controller-manager-f7bbb4bd4-d5lfd
3. 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.

Utiliser une image Linux pour un cluster de gestion

Pour créer un cluster de gestion qui utilise votre image personnalisée comme système d'exploitation de base pour ses nœuds :

Téléchargez l'image vers votre fournisseur de cloud.
Lorsque vous exécutez l'interface du programme d'installation, sélectionnez l'image personnalisée dans le volet Image de système d'exploitation (OS Image), comme décrit dans Sélectionner l'image de système d'exploitation de base.

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 ?.

Utiliser une image Linux pour un cluster de charge de travail

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 :
1. 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.
2. 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.
3. Déployez un cluster de charge de travail comme décrit dans la section Créer des clusters de charge de travail.