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.

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
• Diagramme de Helm de Tableau Server - Déploiement
• Diagramme de Helm de Tableau Server - Dépannage
• Documentation de Helm(Le lien s’ouvre dans une nouvelle fenêtre)
• Documentation de Tableau Server(Le lien s’ouvre dans une nouvelle fenêtre)