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.

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 passwordde 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
• Graphique Helm de Tableau Server - Déploiement
• Graphique Helm de Tableau Server - Résolution des problèmes
• 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)