Importante: questa documentazione presuppone la conoscenza di Helm e delle carte Helm e non intende fornire esempi dettagliati e prescrittivi. È destinata ai clienti che hanno familiarità sia con Tableau Server che con Helm e le carte Helm.

Questo argomento illustra i prerequisiti necessari per utilizzare una carta Helm per la distribuzione di Tableau Server.

Requisiti del cluster

• Almeno un nodo con 16 GB di RAM e 4 core della CPU (8 core consigliati).
• Configurazione di StorageClass per il provisioning dinamico di PersistentVolume.
• Possibilità di creare servizi LoadBalancer o risorse Ingress.

Informazioni richieste

Assicurati di disporre di quanto segue prima di iniziare:

• Codice prodotto di Tableau Server
• username e password dell’amministratore TSM per l’account iniziale
• hostname di Tableau Server per l’accesso

Prerequisiti di Amazon Elastic Kubernetes Service (EKS)

StorageClass efs-bootstrap

Per impostazione predefinita non viene eseguita la creazione di efs-bootstrap in EKS. Per la condivisione del bootstrap multi-nodo, creala prima dell’installazione di Helm.

Per la distribuzione multi-nodo, il provisioning dell’archiviazione di bootstrap deve essere possibile perché i pod possano eseguire la pianificazione. Se StorageClass efs-bootstrap non esegue il provisioning dinamico dei volumi EFS, devi:

• Creare in anticipo un PV di bootstrap statico e associarlo a tableau-server-bootstrap

  oppure

• Impostare persistence.bootstrap.createPV: true e fornire valid persistence.bootstrap.pv.csi.volumeHandle (ID EFS reale, fs-...).

In caso contrario, i pod rimangono In sospeso con PVC non associate.

1. Assicurati che il driver CSI EFS sia installato nel cluster.

   kubectl get csidriver efs.csi.aws.com

   Un oggetto CSIDriver può esistere anche quando l’add-on gestito EKS non è installato. Conferma esplicitamente l’add-on.

   Se ottieni un errore ResourceNotFoundException (nessun add-on) o i pod in seguito generano errori di montaggio come driver name efs.csi.aws.com not found in the list of registered CSI drivers, installa l’add-on EKS e attendi che lo stato diventi ACTIVE, quindi verifica i pod del plug-in del nodo.

   Ciò è necessario perché il bootstrap multi-nodo utilizza un volume supportato da EFS (ReadWriteMany). Senza il plug-in del nodo CSI EFS sui nodi aggiuntivi, le PVC di bootstrap possono eseguire il binding, ma il montaggio non riesce e i pod rimangono nello stato Init/Pending.

   Se il montaggio EFS non riesce con:

   is not authorized to perform: elasticfilesystem:DescribeMountTargets

   oppure

   Failed to resolve "fs-....efs.<region>.amazonaws.com"

   Utilizza una di queste soluzioni:

   • Correzione IAM sul ruolo del nodo EKS (opzione preferita): concedi a EFS e a EC2 autorizzazioni di lettura, in modo che la destinazione di montaggio e l’individuazione AZ funzionino. Risolvi il nome del ruolo dell’istanza del nodo dal gruppo di nodi:

     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

   • Utilizza il **nome ruolo** IAM (ultimo segmento dell’ARN) in 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

     • Le autorizzazioni tipiche prevedevano:

       • elasticfilesystem:DescribeMountTargets, 
         elasticfilesystem:DescribeFileSystems

       • ec2:DescribeAvailabilityZones (spesso necessario quando DescribeAvailabilityZones appare negli errori di montaggio)

   • Monta in modo esplicito l’IP di destinazione: imposta mounttargetip negli attributi del volume CSI del PV di bootstrap quando il DNS o l’individuazione è limitata nel tuo ambiente.

     • Valori Helm (percorso createPV: true):

       persistence:
         bootstrap:
           pv:
             csi:
               volumeAttributes:
       mounttargetip: "10.x.x.x"

     • Percorso PV manuale

       spec:
         csi:
           driver: efs.csi.aws.com
           volumeHandle: fs-xxxxxxxx
           volumeAttributes:
             mounttargetip: 10.x.x.x

2. Crea StorageClass efs-bootstrap (esempio):

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: efs-bootstrap
   provisioner: efs.csi.aws.com
   reclaimPolicy: Retain
   volumeBindingMode: Immediate
   allowVolumeExpansion: true

3. Scegli un percorso di provisioning di bootstrap (obbligatorio):

• Percorso di provisioning EFS dinamico:

  utilizza una StorageClass dinamica CSI EFS configurata per i punti di accesso (ad esempio provisioningMode: efs-ap, fileSystemIde autorizzazioni/parametri basePath in base allo standard della piattaforma).

• Percorso PV statico:

  crea tableau-bootstrap-pv manualmente con csi.driver: efs.csi.aws.com e csi.volumeHandle: fs-...

  quindi imposta:

  • persistence.bootstrap.createPV: false

  • persistence.bootstrap.volumeName: tableau-bootstrap-pv

• Percorso PV statico creato da Helm:

  imposta:

  • persistence.bootstrap.createPV: true

  • persistence.bootstrap.pv.csi.volumeHandle: fs-...

Prerequisito non EKS

StorageClass ReadWriteMany

Per i cluster non ospitati in EKS (o se non utilizzi EFS), il requisito fondamentale per la condivisione di bootstrap multi-nodo è fornire un oggetto StorageClass che supporti la modalità di accesso ReadWriteMany (RWX) per il volume di bootstrap. Ciò è necessario perché, il provisioning dell’archiviazione di bootstrap deve essere possibile affinché i pod possano eseguire la pianificazione.

I back-end di archiviazione RWX self-hosted più comuni per Kubernetes includono:

• NFS (il più comune, molto facile da testare)

• CephFS

• Longhorn (se installato)

• GlusterFS

• NetApp o un altro tipo di archiviazione aziendale

Devi verificare che sia installato il driver CSI corrispondente al back-end scelto.

Per configurare Tableau Server per l’utilizzo della StorageClass RWX personalizzata, aggiorna i valori Helm (ad esempio, values-multinode.yaml) per impostare persistence.bootstrap.storageClass sul nome di 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

Risorse aggiuntive

• Carta Helm di Tableau Server - Panoramica
• Carta Helm di Tableau Server - Distribuzione
• Carta Helm di Tableau Server - Risoluzione dei problemi
• Documentazione di Helm (in inglese)
• Documentazione di Tableau Server