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

 

Plusieurs versions de Kubernetes

Cette rubrique explique comment répertorier les versions de Kubernetes disponibles et déployer un cluster de charge de travail avec une version de Kubernetes autre que celle par défaut.

À propos des versions de Kubernetes

Chaque version de Tanzu Kubernetes Grid avec un cluster de gestion autonome fournit une version par défaut et deux versions non par défaut de Kubernetes, que vous pouvez répertorier en exécutant tanzu kubernetes-release get.

Tanzu Kubernetes Grid gère les versions de Kubernetes avec des objets de version de Tanzu Kubernetes (TKr). Une TKr spécifie les images de système d'exploitation, les composants Kubernetes principaux et les modules de démarrage compatibles avec la version de Kubernetes définie dans la TKr. Lorsque vous exécutez tanzu cluster create avec une TKr par défaut ou non par défaut, Tanzu Kubernetes Grid utilise les composants et les modules de démarrage spécifiés dans la TKr pour créer le cluster. Il lit également votre fichier de configuration de cluster pour déterminer les images de système d'exploitation compatibles à utiliser lors de la création du cluster.

Pour obtenir la liste complète des versions de Kubernetes prises en charge, reportez-vous à la section Versions de Kubernetes prises en charge dans Tanzu Kubernetes Grid v2.3 des Notes de mise à jour de VMware Tanzu Kubernetes Grid 2.3.

Répertorier les versions disponibles

Pour répertorier toutes les versions de Kubernetes disponibles avec leur état de compatibilité et de mise à niveau actuel, exécutez tanzu kubernetes-release get avec un argument de correspondance de version facultatif, par exemple :

  • Pour répertorier toutes les versions, exécutez tanzu kubernetes-release get.
  • Pour répertorier toutes les versions correspondant à la v1.24.17, exécutez tanzu kubernetes-release get v1.24.17.
tanzu kubernetes-release get
NAME                       VERSION                  COMPATIBLE  ACTIVE  UPDATES AVAILABLE
v1.24.17---vmware.1-tkg.1  v1.24.17+vmware.1-tkg.1  True        True
v1.25.13---vmware.1-tkg.1  v1.25.13+vmware.1-tkg.1  True        True
v1.26.8---vmware.2-tkg.1   v1.26.8+vmware.1-tkg.1   True        True

Répertorier les mises à niveau disponibles

Pour découvrir les versions de TKr disponibles pour un cluster de charge de travail spécifique, exécutez tanzu cluster available-upgrades get avec le nom complet du cluster. Par exemple :

tanzu cluster available-upgrades get my-cluster

Activer ou désactiver une version de Tanzu Kubernetes

Une TKR peut être activée ou désactivée. Pour activer une TKR :

tanzu kubernetes-release activate TKR-NAME

Par exemple :

tanzu kubernetes-release activate v1.25.13---vmware.1-tkg.1

Pour désactiver une TKr :

tanzu kubernetes-release deactivate TKR-NAME

Par exemple :

tanzu kubernetes-release deactivate v1.25.13---vmware.1-tkg.1

Déployer un cluster avec une version de Kubernetes non définie par défaut

Chaque version de Tanzu Kubernetes Grid fournit une version par défaut de Kubernetes. La version par défaut de Tanzu Kubernetes Grid v2.3 est Kubernetes v1.26.8.

Lorsque Kubernetes publie des correctifs ou de nouvelles versions en amont, VMware les publie dans un registre public et le contrôleur de version de Tanzu Kubernetes les importe dans le cluster de gestion. Cela permet à la CLI tanzu de créer des clusters basés sur les nouvelles versions.

  • Pour répertorier les versions de Kubernetes disponibles, reportez-vous à la section Versions de Kubernetes disponibles ci-dessus.
  • Pour déployer des clusters qui exécutent une version de Kubernetes non définie par défaut, suivez les étapes ci-dessous.

Publier la version de Kubernetes sur votre infrastructure

Sur vSphere et Azure, vous devez effectuer une étape supplémentaire avant de pouvoir déployer des clusters qui exécutent des versions de Kubernetes non définie par défaut :

  • vSphere : Importez le fichier OVA du modèle d'image de base approprié dans vSphere et convertissez-le en modèle de machine virtuelle. Pour plus d'informations sur l'importation de fichiers OVA de base dans vSphere, reportez-vous à la section Importez le modèle d'image de base dans vSphere.

  • Azure : Exécutez la commande CLI Azure pour accepter la licence pour la version du système d'exploitation de base. Une fois que vous avez accepté une licence, vous pouvez ignorer cette étape à l'avenir :

    1. Convertissez votre version cible de Kubernetes répertoriée dans la sortie de la commande tanzu kubernetes-release get en son SKU d'image Azure comme suit :
      • Remplacez le v du début par k8s-.
      • Remplacez . par dot dans le numéro de version.
      • Remplacez +vmware.* par -ubuntu-2004 pour désigner Ubuntu v20.04, la version du système d'exploitation par défaut pour toutes les machines virtuelles Tanzu Kubernetes Grid sur Azure.
      • Exemples : k8s-1dot26dot8-ubuntu-2004, k8s-1dot25dot13-ubuntu-2004.

    2. Exécutez az vm image terms accept. Par exemple :

      az vm image terms accept --publisher vmware-inc --offer tkg-capi-2022-06-24 --plan k8s-1dot26dot8-ubuntu-2004

  • Amazon Web Services (AWS) : Aucune action n'est requise. Les images de machine Amazon (AMI) Amazon Linux 2 qui incluent les versions de Kubernetes prises en charge sont disponibles publiquement pour tous les utilisateurs AWS, dans toutes les régions AWS prises en charge. Tanzu Kubernetes Grid utilise automatiquement l'AMI appropriée pour la version de Kubernetes que vous spécifiez.

Déployer le cluster Kubernetes

Pour déployer le cluster de charge de travail exécutant une version de Kubernetes autre que celle par défaut :

  1. Si vous déployez un cluster basé sur un plan, définissez une variable d'environnement ALLOW_LEGACY_CLUSTER sur true :

    export ALLOW_LEGACY_CLUSTER=true

  2. Si la version du correctif Kubernetes avec laquelle vous déployez le cluster est antérieure au dernier correctif pris en charge pour sa version mineure, comme indiqué dans la section Versions de Kubernetes prises en charge, créez un objet ConfigMap pour sa TKr dans l'espace de noms tkg-system :

    1. Créez une définition d'objet ConfigMap dans l'espace de noms tkg-system qui répertorie les anciennes TKr :

      apiVersion: v1
kind: ConfigMap
metadata:
  namespace: tkg-system
  name: TKR-CONFIG-NAME
  labels:
    run.tanzu.vmware.com/additional-compatible-tkrs: ""
data:
  tkrVersions: |
      - TKR-VERSON-1
      - TKR-VERSON-2

      TKR-CONFIG-NAME correspond au nom d'objet légal, tel que tkg-v2.3.1 et les valeurs TKR-VERSON-* sont les anciennes versions de TKr répertoriées par tanzu kubernetes-release get, par exemple v1.24.14--vmware.1-tkg.

    2. Créez l'objet ConfigMap :

      kubectl apply -f old-tkrs-config.yaml

  3. Pour déployer un cluster de charge de travail avec une version de Kubernetes qui n'est pas la version par défaut pour votre version de Tanzu Kubernetes Grid, spécifiez la version de Tanzu Kubernetes dans l'option --tkr. Par exemple, pour déployer un cluster Kubernetes v1.25.13, exécutez :

    tanzu cluster create my-1-25-13-cluster --tkr v1.25.13---vmware.1-tkg

Pour plus d'informations sur la création d'un cluster de charge de travail, reportez-vous à la section Créer des clusters de charge de travail.

Déployer un cluster avec une image de machine personnalisée

Pour les combinaisons courantes de version du système d'exploitation, de version de Kubernetes et d'infrastructure cible, Tanzu Kubernetes Grid avec un cluster de gestion autonome fournit des images de machine par défaut. Vous pouvez éventuellement spécifier des images de machine personnalisées, y compris des images que vous créez vous-même.

Les sections ci-dessous expliquent comment déployer un cluster avec une image de machine alternative ou personnalisée :

Utiliser une autre image de machine

Dans un fichier de configuration de cluster, définissez OS_NAME, OS_VERSION et OS_ARCH pour spécifier l'image de la machine de base, par exemple ubuntu, 20.04 ou photon, 3 et amd64. Ces images de système d'exploitation sont par défaut distribuées par VMware, mais vous pouvez également spécifier votre propre image de système d'exploitation alternative à utiliser pour les nœuds de cluster :

  1. Chargez l'image vers vSphere, comme décrit dans la section Importer le modèle d'image de base dans vSphere.

  2. Effectuez l'une des opérations suivantes, selon que votre image partage ou non la même version du système d'exploitation qu'une image de machine existante distribuée par VMware :

    • Si vous spécifiez une autre image avec le même nom de système d'exploitation, la même version et la même architecture qu'une TKr et une image existantes que VMware distribue, modifiez son objet OSImage, par exemple :

      kubectl edit OSImage v1.26.4---vmware.1-tkg.1-6c92aa1cbb96b644085e6229f41ef14d

    • Sinon, créez et appliquez un objet OSImage en utilisant une définition d'objet OSImage existante comme modèle. Définissez ses valeurs metadata.name et spec.image.ref.version sur le nom de fichier OVA.

  3. Dans le bloc spec.image.ref de l'objet OSImage, ajoutez un champ et une valeur d'identifiant. Par exemple, pour permettre une alternative à Kubernetes v1.26.4 sur l'image Ubuntu 20.04 que VMware distribue :

    apiVersion: run.tanzu.vmware.com/v1alpha3
kind: OSImage
metadata:
  creationTimestamp: "2023-06-02T06:08:35Z"
  generation: 2
  labels:
    image-type: ova
    os-arch: amd64
    os-name: ubuntu
    os-type: linux
    ...
spec:
  image:
    ref:
      MY-FIELD: MY-VALUE
      version: v1.26.4---vmware.1-tkg.1-6c92aa1cbb96b644085e6229f41ef14d
    type: ova
  kubernetesVersion: v1.26.4+vmware.1
  os:
    arch: amd64
    name: ubuntu
    type: linux
    version: "2004"

    MY-FIELD et MY-VALUE correspondent au champ et à la valeur de l'identifiant que vous définissez pour les inclure dans les spécifications de l'objet Cluster.

    • MY-VALUE doit comporter entre 0 et 63 caractères et peut être vide, ou doit commencer et se terminer par des caractères alphanumériques et contenir des caractères alphanumériques, des tirets (-), des traits de soulignement (_) ou des points (.).
    • TKG copie ces valeurs dans les paramètres metadata.labels de l'objet OSImage suivant le modèle ova-MY-FIELD: MY-VALUE.

  4. Pour utiliser l'autre image de machine dans un cluster, modifiez l'objet Cluster pour ajouter le paramètre ova-MY-FIELD=MY-VALUE aux metadata.annotations pour les nœuds de cluster qui utiliseront l'image.

    • Pour les nœuds de plan de contrôle, modifiez les metadata.annotations sous topology.controlPlane.
    • Pour les nœuds worker, modifiez les metadata.annotations sous topology.workers.machineDeployments pour les déploiements de machines qui utiliseront l'image.

    • Par exemple :

      metadata:
  annotations:
    run.tanzu.vmware.com/resolve-os-image: image-type=ova,ova-my-field=my-value

Créer et utiliser une image de machine personnalisée

Vous pouvez créer votre propre image de machine à utiliser pour les nœuds de cluster. Voici quelques raisons d'effectuer cette opération :

  • Créer des clusters sur un système d'exploitation de base que VMware prend en charge, mais ne distribue pas, tel que Red Hat Enterprise Linux (RHEL) v8.
  • Installer des modules supplémentaires dans l'image de la machine de base ou la personnaliser comme décrit dans la section Personnalisation de la documentation d'Image Builder.

Pour obtenir des instructions, reportez-vous à la section Créer des images de machine.

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