---
schema_version: "1"
id: 65d4b3c6ec6c7b9a46d461764b0bec68f767b66370ce5fcb6955693b01934ad8
title: Conditions préalables pour le graphique Helm
collection: tableau
version: next
locale: fr-fr
portal_url: https://docs.salesforce.com/tableau/next/fr-fr/server/server-helm-prerequisites.md
canonical_url: https://help.tableau.com/v0.0/server/fr-fr/server-helm-prerequisites.htm
source_site: help.tableau.com
content_type: documentation
content_hash: 87e159ba128fb812de4b3882287f46f13f7578f52d4799965a24950ee982fceb
description: "Important : cette documentation présuppose une connaissance de Helm et des graphiques de Helm et ne prétend pas fournir des exemples détaillés et prescriptifs"
---
[Passer au contenu principal](#main-content)

# Graphique Helm de Tableau Server - Conditions préalables

**Important** : cette documentation présuppose une connaissance de Helm et des graphiques de Helm et ne prétend pas fournir des exemples détaillés et prescriptifs. Elle s’adresse aux clients qui connaissent à la fois Tableau Server, Helm et les graphiques Helm.

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

## Téléchargement et distribution de graphique Helm

Les graphiques Helm sont fournis avec Tableau Server dans un outil d’installation de 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-fr/support/releases/server/latest).

Une fois extraits, les fichiers de graphiques Helm requis se trouvent dans le répertoire `helm/tableau`.

## Outils requis

- Interface en ligne de commande `kubectl` configurée pour accéder à votre cluster Kubernetes
- CLI `helm` version 3.x ou ultérieure
- Accès à un cluster Kubernetes (1.19+)

## Exigences relatives au cluster

- Au moins un nœud avec 16 Go de RAM et 4 cœurs de processeur (8 cœurs recommandés).
- StorageClass configuré pour le provisionnement dynamique de PersistentVolume.
- Possibilité de créer des services LoadBalancer ou des ressources Ingress.

## Informations requises

Assurez-vous d’avoir les éléments suivants avant de commencer :

- Votre **clé produit** Tableau Server
- Les paramètres **`username` et** `**password**`de l’ **administrateur TSM** pour le compte initial
- Le **nom d’hôte** Tableau Server pour l’accès

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

### StorageClass `efs-bootstrap`

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

Pour le déploiement multi-nœud, le stockage bootstrap doit être provisionnable pour que les pods puissent être planifiés. Si votre StorageClass `efs-bootstrap` ne provisionne pas de volumes EFS de manière dynamique, vous devez :

- Créer à l’avance un fichier PV bootstrap statique et le lier à `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 opération n’est pas effectuée, les pods restent dans un état En attente avec des PVC non liés.

1. Vérifiez que le pilote EFS CSI est installé sur votre cluster.
    
    kubectl get csidriver efs.csi.aws.com
    
    Un objet `CSIDriver` peut exister même lorsque le module complémentaire géré EKS n’est pas installé. Vérifiez explicitement le module complémentaire.
    
    Si vous obtenez une erreur `ResourceNotFoundException` (pas de module complémentaire), ou si les pods échouent ultérieurement avec 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 et attendez que l’état affiche « ACTIVE », puis vérifiez les modules de plug-in de nœud.
    
    Cette opération est nécessaire car le fichier bootstrap multi-nœud utilise un volume sauvegardé par EFS (ReadWriteMany). Sans le plug-in de nœud EFS CSI sur les nœuds supplémentaires, les PVC de bootstrap peuvent être liés, mais les montages échouent et les pods restent dans les états `Init/Pending`.
    
    Si les montages EFS échouent avec :
    
    is not authorized to perform: elasticfilesystem:DescribeMountTargets
    
    ou
    
    Failed to resolve "fs-....efs.<region>.amazonaws.com"
    
    Utilisez l’une de ces mesures correctives :
    
    - **Correctif IAM sur le rôle de nœud EKS** (préféré) : accordez des autorisations de lecture EFS et EC2 afin de monter la cible et le travail de découverte AZ. Résolvez 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 lorsque `DescribeAvailabilityZones` apparaît dans les erreurs de montage)
    - **Monter explicitement l’adresse IP cible :** définissez `mounttargetip` sur les attributs de volume PV CSI bootstrap lorsque DNS/découverte est restreint dans votre environnement.
        
        - Valeurs de Helm (chemin `createPV: true`) :
            
            persistence:  
              bootstrap:  
                pv:  
                  csi:  
                    volumeAttributes:  
            mounttargetip: "10.x.x.x"
        - Chemin PV manuel
            
            spec:  
              csi:  
                driver: efs.csi.aws.com  
                volumeHandle: fs-xxxxxxxx  
                volumeAttributes:  
                  mounttargetip: 10.x.x.x
2. Créez une 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 provisionnement bootstrap (obligatoire) :

- **Chemin d’accès dynamique de provisionnement EFS** :
    
    utilisez une StorageClass dynamique EFS CSI configurée pour les points d’accès (par exemple `provisioningMode: efs-ap, fileSystemId` et les paramètres autorisations/basePath en fonction de la norme de votre plate-forme).
- **Chemin PV statique** :
    
    Créez `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 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 clusters qui ne sont pas hébergés sur EKS (ou si vous n’utilisez pas EFS), l’exigence critique pour le partage bootstrap multi-nœud est de fournir une StorageClass qui prend en charge le mode d’accès `ReadWriteMany (RWX)` pour le volume bootstrap. Cette opération est obligatoire parce que le stockage bootstrap doit pouvoir être provisionné pour que les pods puissent être planifiés.

Les backends de stockage RWX auto-hébergés courants pour Kubernetes incluent :

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

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

Pour configurer Tableau Server de manière à utiliser votre StorageClass RWX personnalisée, mettez à jour vos valeurs Helm (par exemple `values-multinode.yaml`) pour définir `persistence.bootstrap.storageClass` sur 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

- [Graphique Helm de Tableau Server - Présentation](https://help.tableau.com/v0.0/server/fr-fr/server-in-container_helm-chart.htm)
- [Graphique Helm de Tableau Server - Déploiement](https://help.tableau.com/v0.0/server/fr-fr/server-helm-deploy.htm)
- [Graphique Helm de Tableau Server - Résolution des problèmes](https://help.tableau.com/v0.0/server/fr-fr/server-helm-troubleshooting.htm)
- [Documentation de Helm](https://helm.sh/docs/)
- [Documentation de Tableau Server](https://help.tableau.com/current/server-linux/fr-fr/)