---
schema_version: "1"
id: d31e998db0d0f8bfa82578603a1afa2973a6973d08f383c8b5f3c122c97455a6
title: Conditions préalables du diagramme de Helm
collection: tableau
version: current
locale: fr-ca
portal_url: https://docs.salesforce.com/tableau/current/fr-ca/server/server-helm-prerequisites.md
canonical_url: https://help.tableau.com/current/server/fr-ca/server-helm-prerequisites.htm
source_site: help.tableau.com
content_type: documentation
content_hash: b89baf781dac0286aa59352cdb9cb3ecbcd66fe621ff3e1be27af62ebf0cca63
description: "Important : Cette documentation suppose une connaissance de Helm et des diagrammes de Helm"
---
[Passer au contenu principal](#main-content)

# Diagramme de Helm de Tableau Server - Conditions préalables

**Important** : Cette documentation suppose une connaissance de Helm et des diagrammes de Helm. Elle ne cherche pas à fournir d’exemples détaillés et prescriptifs. Elle est destinée aux clients qui maîtrisent à la fois Tableau Server, Helm et les diagrammes de Helm.

Cette rubrique décrit les conditions préalables à l’utilisation d’un diagramme de Helm pour le déploiement de Tableau Server.

## Téléchargement et distribution du diagramme de Helm

Les diagrammes de Helm sont inclus dans l’outil d’installation de Tableau Server dans un conteneur (`tableau-server-container-setup-tool-<version>.tar.gz`) et peuvent être téléchargés depuis la page de [téléchargement de Tableau Server](http://tableau.com/fr-ca/support/releases/server/latest).

Après l’extraction, les fichiers de diagrammes de Helm requis se trouvent dans le répertoire `helm/tableau`.

## Outils requis

- Interface en ligne de commande `kubectl` configurée pour accéder à votre groupement Kubernetes
- Version 3.x et versions ultérieures de l’interface en ligne de commande `helm`
- Accès à un groupement Kubernetes (1.19+)

## Exigences du groupement

- Au moins un nœud avec 16 Go de RAM et 4 cœurs de processeur (8 cœurs recommandés).
- StorageClass configuré pour la mise en service dynamique de PersistentVolume.
- Possibilité de créer des services LoadBalancer ou des ressources d’entrée.

## Informations requises

Avant de commencer, vérifiez que vous avez :

- Votre **clé produit** Tableau Server
- Le **`username` et** `**password**` d’**administrateur TSM** pour le compte initial
- Le **nom d’hôte** permettant d’accéder à Tableau Server

## Conditions préalables pour Elastic Kubernetes Service (EKS) d’Amazon

### StorageClass `efs-bootstrap`

Par défaut, `efs-bootstrap` n’est pas créé dans EKS. Pour un partage de bootstrap multinœuds, créez-le avant l’installation de Helm.

Pour un déploiement multinœuds, le stockage de bootstrap doit être mis en service avant la programmation des pods. Si votre StorageClass `efs-bootstrap` n’effectue pas une mise en service dynamique des volumes EFS, vous devez :

- créer à l’avance un fichier PV de bootstrap statique et liez-le à `tableau-server-bootstrap`
    
    ou
- définir `persistence.bootstrap.createPV: true` et fournir `valid persistence.bootstrap.pv.csi.volumeHandle` (identifiant EFS réel, fs-...).

Si cette condition n’est pas remplie, les pods restent à l’état En attente avec des PVC non liés.

1. Vérifiez que le pilote EFS CSI est installé dans votre groupement.
    
    kubectl get csidriver efs.csi.aws.com
    
    Un objet `CSIDriver` peut exister même lorsque le module complémentaire géré par EKS n’est pas installé. Vérifiez explicitement le module complémentaire.
    
    Si une erreur `ResourceNotFoundException` (absence de module complémentaire) se produit, ou si les pods rencontrent par la suite des erreurs de montage telles que `driver name efs.csi.aws.com not found in the list of registered CSI drivers`, installez le module complémentaire EKS, attendez que son état devienne ACTIF, puis vérifiez les pods du module d’extension du nœud.
    
    Cette opération est nécessaire, car le fichier bootstrap multinœuds utilise un volume sauvegardé sur EFS (ReadWriteMany). Sans le module d’extension du nœud EFS CSI sur les nœuds supplémentaires, les PVC de bootstrap peuvent bien se lier, mais les volumes ne se montent pas et les pods restent à l’état `Init/Pending`.
    
    Si une erreur de montage EFS se produit avec :
    
    is not authorized to perform: elasticfilesystem:DescribeMountTargets
    
    ou
    
    Failed to resolve "fs-....efs.<region>.amazonaws.com"
    
    Utilisez l’une des mesures correctives suivantes :
    
    - **Correctif IAM sur le rôle de nœud EKS** (préférée) : accordez les autorisations de lecture EFS et EC2 pour permettre la découverte des cibles de montage et des zones de disponibilité. Identifiez le nom du rôle d’instance de nœud à partir de votre groupe de nœuds :
        
        aws eks list-nodegroups --cluster-name <cluster-name>  
        aws eks describe-nodegroup \\  
        \--cluster-name <cluster-name> \\  
        \--nodegroup-name <nodegroup-name> \\  
        \--query "nodegroup.nodeRole" \\  
        \--output text
    - **Utilisez le \*\*nom de rôle\*\* IAM** (dernier segment de l’ARN) dans `attach-role-policy` :
        
        aws iam attach-role-policy \\  
        \--role-name <your-node-instance-role> \\  
        \--policy-arn arn:aws:iam::aws:policy/AmazonElasticFileSystemClientReadWriteAccess
        
        aws iam attach-role-policy \\  
        \--role-name <your-node-instance-role> \\  
        \--policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
        
        - Autorisations typiques concernées :
            
            - elasticfilesystem:DescribeMountTargets, 
                elasticfilesystem:DescribeFileSystems
            - `ec2:DescribeAvailabilityZones` (souvent nécessaire lorsqu’apparaît `DescribeAvailabilityZones` dans les erreurs de montage)
    - **Spécifiez explicitement l’IP de la cible de montage** : définissez `mounttargetip` dans les attributs de volume CSI du PV de bootstrap lorsque le DNS et la découverte sont limités dans votre environnement.
        
        - Valeurs de Helm (chemin `createPV: true`) :
            
            persistence:  
              bootstrap:  
                pv:  
                  csi:  
                    volumeAttributes:  
            mounttargetip: "10.x.x.x"
        - Chemin du PV manuel
            
            spec:  
              csi:  
                driver: efs.csi.aws.com  
                volumeHandle: fs-xxxxxxxx  
                volumeAttributes:  
                  mounttargetip: 10.x.x.x
2. Créez un StorageClass `efs-bootstrap` (exemple) :
    
    apiVersion: storage.k8s.io/v1  
    kind: StorageClass
    metadata:  
      name: efs-bootstrap  
    provisioner: efs.csi.aws.com  
    reclaimPolicy: Retain  
    volumeBindingMode: Immediate  
    allowVolumeExpansion: true
3. Choisissez un chemin de mise en service du bootstrap (obligatoire) :

- **Chemin de mise en service dynamique de l’EFS** :
    
    utilisez un StorageClass dynamique EFS CSI configuré pour les points d’accès (par exemple `provisioningMode: efs-ap, fileSystemId`, ainsi que les paramètres des autorisations ou basePath en fonction de la norme de votre plateforme).
- **Chemin du PV statique** :
    
    créez un `tableau-bootstrap-pv` manuellement avec `csi.driver: efs.csi.aws.com` et `csi.volumeHandle: fs-...`
    
    puis définissez :
    
    - `persistence.bootstrap.createPV: false`
    - `persistence.bootstrap.volumeName: tableau-bootstrap-pv`
- **Chemin du PV statique créé par Helm** :
    
    définissez
    
    - `persistence.bootstrap.createPV: true`
    - `persistence.bootstrap.pv.csi.volumeHandle: fs-...`

## Conditions préalables non EKS

### StorageClass `ReadWriteMany`

Pour les groupements qui ne sont pas hébergés sur EKS (ou qui n’utilisent pas EFS), la condition essentielle pour le partage du bootstrap multinœuds est de fournir un StorageClass prenant en charge le mode d’accès `ReadWriteMany (RWX)` pour le volume de bootstrap. Cette opération est nécessaire, car le stockage de bootstrap doit être mis en service avant la programmation des pods.

Les backends de stockage RWX auto-hébergés les plus fréquemment utilisés avec Kubernetes comprennent :

- NFS (le plus répandu, le plus facile à tester)
- CephFS
- Longhorn (si installé)
- GlusterFS
- NetApp / autres stockages d’entreprise

Vous devez vous assurer que le pilote CSI associé au backend que vous avez choisi est installé.

Pour configurer Tableau Server de manière à utiliser votre StorageClass RWX personnalisé, mettez à jour vos valeurs Helm (par exemple, `values-multinode.yaml`) et attribuez à `persistence.bootstrap.storageClass` le nom de votre StorageClass :

persistence:
  # ... other persistence settings ...

  # Bootstrap volume (required for multi-node)
  bootstrap:
    enabled: true
    storageClass: "my-rwx-storage" # <--- Replace with your StorageClass name
    accessMode: ReadWriteMany
    size: 1Gi
    createPV: false

## Ressources supplémentaires

- [Diagramme de Helm de Tableau Server - Présentation](https://help.tableau.com/current/server/fr-ca/server-in-container_helm-chart.htm)
- [Diagramme de Helm de Tableau Server - Déploiement](https://help.tableau.com/current/server/fr-ca/server-helm-deploy.htm)
- [Diagramme de Helm de Tableau Server - Dépannage](https://help.tableau.com/current/server/fr-ca/server-helm-troubleshooting.htm)
- [Documentation de Helm](https://helm.sh/docs/)
- [Documentation de Tableau Server](https://help.tableau.com/current/server-linux/fr-ca/)