---
schema_version: "1"
id: bb44a8632b61eded6303a6dbccd4a8a6caddec90dbc57f558bd31fc8c2a3eb9b
title: Requisitos previos del gráfico de Helm
collection: tableau
version: next
locale: es-es
portal_url: https://docs.salesforce.com/tableau/next/es-es/server-linux/server-helm-prerequisites.md
canonical_url: https://help.tableau.com/v0.0/server-linux/es-es/server-helm-prerequisites.htm
source_site: help.tableau.com
content_type: documentation
content_hash: 38adfd8024c37f5eb23d4c570fe4595970291becdf607eed229cd302c9a8d866
description: "Importante: Esta documentación asume un conocimiento de Helm y los gráficos de Helm y no intenta proporcionar ejemplos detallados y prescriptivos"
---
[Saltar al contenido principal](#main-content)

# Gráfico de Helm de Tableau Server: requisitos previos

**Importante**: Esta documentación asume un conocimiento de Helm y los gráficos de Helm y no intenta proporcionar ejemplos detallados y prescriptivos. Está diseñado para clientes que están familiarizados con Tableau Server y Helm y con los gráficos de Helm.

En este tema se explican los requisitos previos necesarios para usar un gráfico de Helm para implementar Tableau Server.

## Descarga y distribución de gráficos de Helm

Los gráficos de Helm se enviarán como parte de la herramienta de configuración de Tableau Server en un contenedor (`tableau-server-container-setup-tool-<version>.tar.gz`) y se puede descargar desde la página [Descargar Tableau Server](http://tableau.com/es-es/support/releases/server/latest).

Después de la extracción, los archivos de gráfico de Helm necesarios se encuentran en el directorio `helm/tableau`.

## Herramientas necesarias

- CLI de `kubectl` configurada para acceder a su clúster de Kubernetes
- CLI en la versión 3.x y posteriores de `helm`
- Acceso a un clúster de Kubernetes (1.19+)

## Requisitos del clúster

- Al menos un nodo con 16 GB de RAM y 4 núcleos de CPU (se recomiendan 8 núcleos).
- StorageClass configurado para el aprovisionamiento dinámico de PersistentVolume.
- Capacidad para crear servicios de LoadBalancer o recursos de ingreso.

## Información requerida

Asegúrese de tener lo siguiente antes de comenzar:

- Su **clave de producto** de Tableau Server
- Los valores de **Administrador de TSM `username` y** `**password**` para la cuenta inicial
- El valor **hostname** de Tableau Server para acceder

## Requisitos previos de Amazon Elastic Kubernetes Service (EKS)

### `efs-bootstrap` StorageClass

De forma predeterminada `efs-bootstrap` no se crea en EKS. Para compartir el arranque de varios nodos, créelo antes de la instalación de Helm.

Para la implementación de varios nodos, el almacenamiento de arranque debe estar aprovisionado antes de que los pods puedan programarse. Si su `efs-bootstrap` StorageClass no aprovisiona dinámicamente volúmenes EFS, debe:

- Crear un PV de arranque estático por adelantado y vincularlo a `tableau-server-bootstrap`
    
    o
- Establecer `persistence.bootstrap.createPV: true` y proporcionar `valid persistence.bootstrap.pv.csi.volumeHandle` (ID de EFS real, fs-...).

Si no se hace esto, los pods permanecen en estado Pending con los PVC sin enlazar.

1. Asegúrese de que el controlador CSI de EFS esté instalado en el clúster.
    
    kubectl get csidriver efs.csi.aws.com
    
    Un objeto `CSIDriver` puede existir incluso cuando el complemento administrado por EKS no está instalado. Confirme el complemento explícitamente.
    
    Si obtiene un `ResourceNotFoundException` (sin complemento) o los pods fallan más tarde con errores de montaje como `driver name efs.csi.aws.com not found in the list of registered CSI drivers`, instale el complemento de EKS y espere hasta que el estado sea ACTIVE y luego verifique los pods del complemento del nodo.
    
    Esto es necesario porque el arranque multinodo usa un volumen respaldado por EFS (ReadWriteMany). Sin el complemento de nodo CSI de EFS en los nodos adicionales, los PVC de arranque pueden enlazarse, pero los montajes fallan y los pods permanecen en los estados `Init/Pending`.
    
    Si los montajes de EFS fallan con:
    
    is not authorized to perform: elasticfilesystem:DescribeMountTargets
    
    o
    
    Failed to resolve "fs-....efs.<region>.amazonaws.com"
    
    Utilice una de estas soluciones:
    
    - **Corrección de IAM en el rol de nodo de EKS** (Preferido): otorgue permisos de lectura de EFS y EC2 para que el destino de montaje y el descubrimiento AZ funcionen. Resuelva el nombre del rol de instancia de nodo de su grupo de nodos:
        
        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
    - **Usar el \*\*nombre de rol\*\* de IAM** (último segmento del ARN) en `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
        
        - Permisos típicos implicados:
            
            - elasticfilesystem:DescribeMountTargets, 
                elasticfilesystem:DescribeFileSystems
            - `ec2:DescribeAvailabilityZones` (a menudo necesario cuando `DescribeAvailabilityZones` aparece en los errores de montaje)
    - **Montar explícitamente la IP de destino**: establezca `mounttargetip` en los atributos de volumen CSI de PV de arranque cuando DNS/descubrimiento está restringido en su entorno.
        
        - Valores de Helm (ruta de `createPV: true`):
            
            persistence:  
              bootstrap:  
                pv:  
                  csi:  
                    volumeAttributes:  
            mounttargetip: "10.x.x.x"
        - Ruta de PV manual
            
            spec:  
              csi:  
                driver: efs.csi.aws.com  
                volumeHandle: fs-xxxxxxxx  
                volumeAttributes:  
                  mounttargetip: 10.x.x.x
2. Cree `efs-bootstrap` StorageClass (ejemplo):
    
    apiVersion: storage.k8s.io/v1  
    kind: StorageClass
    metadata:  
      name: efs-bootstrap  
    provisioner: efs.csi.aws.com  
    reclaimPolicy: Retain  
    volumeBindingMode: Immediate  
    allowVolumeExpansion: true
3. Elija una ruta de aprovisionamiento de arranque (obligatorio):

- **Ruta de aprovisionamiento de EFS dinámico**:
    
    use un StorageClass dinámico CSI de EFS configurado para puntos de acceso (por ejemplo `provisioningMode: efs-ap, fileSystemId` y permisos/basePath según el estándar de su plataforma).
- **Ruta PV estática**:
    
    cree `tableau-bootstrap-pv` manualmente con `csi.driver: efs.csi.aws.com` y `csi.volumeHandle: fs-...`
    
    luego establezca:
    
    - `persistence.bootstrap.createPV: false`
    - `persistence.bootstrap.volumeName: tableau-bootstrap-pv`
- **Ruta PV estática creada por Helm**:
    
    establezca:
    
    - `persistence.bootstrap.createPV: true`
    - `persistence.bootstrap.pv.csi.volumeHandle: fs-...`

## Requisito previo no EKS

### `ReadWriteMany` StorageClass

Para los clústeres no alojados en EKS (o si no usan EFS), el requisito fundamental para el uso compartido de arranque de varios nodos es proporcionar un StorageClass que admita el modo de acceso `ReadWriteMany (RWX)` para el volumen de arranque. Esto es necesario porque el almacenamiento de arranque debe ser aprovisionable antes de que los pods puedan programarse.

Los backends de almacenamiento RWX autohospedados comunes para Kubernetes incluyen:

- NFS (más común, más fácil de probar)
- CephFS
- Longhorn (si está instalado)
- GlusterFS
- NetApp/otro almacenamiento empresarial

Debe asegurarse de que esté instalado el controlador CSI correspondiente para el backend elegido.

Para configurar Tableau Server para que use su RWX StorageClass personalizada, actualice sus valores de Helm (por ejemplo, `values-multinode.yaml`) para establecer `persistence.bootstrap.storageClass` al nombre de su 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

## Recursos adicionales

- [Gráfico de Helm de Tableau Server: descripción general](https://help.tableau.com/v0.0/server-linux/es-es/server-in-container_helm-chart.htm)
- [Gráfico de Helm de Tableau Server: Implementar](https://help.tableau.com/v0.0/server-linux/es-es/server-helm-deploy.htm)
- [Gráfico de Helm de Tableau Server: solución de problemas](https://help.tableau.com/v0.0/server-linux/es-es/server-helm-troubleshooting.htm)
- [Documentación de Helm](https://helm.sh/docs/)
- [Documentación de Tableau Server](https://help.tableau.com/current/server-linux/es-es/)