---
schema_version: "1"
id: 1535532fe8392ecd30604d770ac097f9fa824e9d841abc456b1ec8011e29186b
title: Prerequisiti della carta Helm
collection: tableau
version: next
locale: it-it
portal_url: https://docs.salesforce.com/tableau/next/it-it/server/server-helm-prerequisites.md
canonical_url: https://help.tableau.com/v0.0/server/it-it/server-helm-prerequisites.htm
source_site: help.tableau.com
content_type: documentation
content_hash: d9d818985ac82fa7efcb2fdaf3bd54e9f3f520f8bfdd9ce04d8aa746741218eb
description: "Importante: questa documentazione presuppone la conoscenza di Helm e delle carte Helm e non intende fornire esempi dettagliati e prescrittivi"
---
[Passa al contenuto principale](#main-content)

# Carta Helm di Tableau Server - Prerequisiti

**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.

## Download e distribuzione delle carte Helm

Le carte Helm vengono fornite come parte dello strumento di configurazione di Tableau Server in un contenitore (`tableau-server-container-setup-tool-<version>.tar.gz`) e possono essere scaricate dalla pagina di [download di Tableau Server](http://tableau.com/it-it/support/releases/server/latest).

Dopo l’estrazione, i file delle carte Helm necessarie si trovano nella directory `helm/tableau`.

## Strumenti richiesti

- Interfaccia della riga di comando `kubectl` configurata per accedere al cluster Kubernetes
- Interfaccia della riga di comando `helm` versione 3.x o successiva
- Accesso a un cluster Kubernetes (1.19+)

## 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, fileSystemId`e 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](https://help.tableau.com/v0.0/server/it-it/server-in-container_helm-chart.htm)
- [Carta Helm di Tableau Server - Distribuzione](https://help.tableau.com/v0.0/server/it-it/server-helm-deploy.htm)
- [Carta Helm di Tableau Server - Risoluzione dei problemi](https://help.tableau.com/v0.0/server/it-it/server-helm-troubleshooting.htm)
- [Documentazione di Helm (in inglese)](https://helm.sh/docs/)
- [Documentazione di Tableau Server](https://help.tableau.com/current/server-linux/it-it/)