This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

Images de machines personnalisées Linux

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é).

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.

(Basé sur une classe, vSphere) : récupérer la version de l'image du système d'exploitation

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 :

    1. Définissez votre contexte kubectl sur le cluster de gestion.

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

    3. Ouvrez la TKr et localisez la propriété osImages. Cette propriété spécifie les noms des objets OSImage associés à la TKr.

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

    5. 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 :

      1. Téléchargez le fichier OVA Ubuntu par défaut correspondant à votre version de Kubernetes cible à partir de Customer Connect :
        1. Accédez à la page de téléchargements de Tanzu Kubernetes Grid, connectez-vous avec vos informations d'identification VMware Customer Connect, puis cliquez sur Accéder aux téléchargements (Go to Downloads).
        2. Téléchargez le fichier OVA. Par exemple, Fichier OVA Ubuntu 2004 Kubernetes v1.27.5 (Ubuntu 2004 Kubernetes v1.27.5 OVA).
      2. Décompressez le fichier OVA téléchargé à l'aide de l'outil d'extraction de votre choix.
      3. Dans le répertoire décompressé, recherchez le fichier .ofv.

      4. 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 :

        1. Localisez la VM OVA et ouvrez l'onglet Configurer (Configure) sur la page de résumé de la VM OVA.
        2. Accédez à Paramètres (Settings) –> Options de vApp (vApp Options).
        3. Dans le tableau Propriétés (Properties), recherchez la clé VERSION et enregistrez sa Valeur par défaut (Default Value). Par exemple, 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": ""
}

Créer une image Linux

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

  2. Téléchargez le conteneur de bundle de ressources Linux à partir de projects.registry.vmware.com :

    1. Assurez-vous que votre poste de travail peut accéder à l'adresse projects.registry.vmware.com du registre d'images VMware.

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

  3. Téléchargez le répertoire de configuration d'Image Builder :

    1. 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.27.5-on-TKG-v2.4.0-master.zip crée une image Kubernetes v1.27.5 pour Tanzu Kubernetes Grid v2.4.0.
      • 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 v2.4.0, la version par défaut de Kubernetes est v1.27.5. Pour les clusters de charge de travail, vous pouvez également créer une instance de Kubernetes v1.26.8 ou v1.25.13, en plus de la version v1.27.5.

      Les étapes ci-dessous expliquent comment créer une image Kubernetes v1.27.5 pour Tanzu Kubernetes Grid v2.4.0.

    2. Téléchargez le fichier ZIP du code de configuration et décompressez son contenu.

    3. cd dans le répertoire TKG-Image-Builder-, afin que le fichier tkg.json se trouve dans votre répertoire actuel.

  4. 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"
}

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

  6. 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 :

      1. 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:

      2. 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éfense
        • remove_existing_ca_certs : conserver l'infrastructure PKI du Département américain de la Défense
        • install_audispd_plugins : installer les plug-ins de multiplexeur d'événements (audispd)

      3. CIS :

        • install_aide : activer AIDE (Advanced Intrusion Detection Environment)
        • install_clamav : activer l'antivirus ClamAV
        • install_systemd_timesyncd : utiliser timesyncd au lieu de chrony
        • install_protect_kernel_defaults : définir les valeurs par défaut de protection des noyaux en amont

      4. Modifiez 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",
      Remarque

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

  7. 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 :
      • vSphere : /PATH/TO/CREDENTIALS.json:/home/imagebuilder/vsphere.json
      • AWS : ~/.aws:/home/imagebuilder/.aws
      • Azure : ~/.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 :
      • Utilisez /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.
      • Utilisez /PATH/TO/tkg:/home/imagebuilder/tkg
    • 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.
      • Exemple : amazon-ubuntu-1.27.5+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

  8. À 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
    Remarque

    Cette 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.
    • 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.

    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

  9. Téléchargez l'image vers votre fournisseur de cloud.

    • Pour obtenir des instructions relatives à vSphere, reportez-vous à la section Importer le modèle d'image de base dans vSphere du document Préparer le déploiement des clusters de gestion pour vSphere.
    • Si vous avez chargé le fichier OVA Ubuntu par défaut pour votre version de Kubernetes cible vers vSphere, supprimez le fichier OVA par défaut avant de télécharger votre fichier OVA personnalisé.

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 :

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

    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.27.5+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.27.5+vmware.1-tkg.1 par v1.27.5+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.27.5---vmware.2-tkg.1-mycustomtkr.yaml.

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

  3. 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...."

  4. 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 :

    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.

  5. 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 :

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

check-circle-line exclamation-circle-line close-line
Scroll to top icon