Importante: esta documentação pressupõe um conhecimento do Helm e de Helm Charts e não tenta fornecer exemplos prescritivos detalhados. Ele foi criado para clientes que estão familiarizados com o Tableau Server e com o Helm e Helm Charts.

Este tópico explica os pré-requisitos necessários para usar um Helm Chart para implantar o Tableau Server.

Requisitos do cluster

• Pelo menos um nó com 16 GB de RAM e 4 núcleos de CPU (8 núcleos é o recomendado).
• StorageClass configurado para provisionamento dinâmico de PersistantVolume.
• Capacidade de criar serviços de Load Balancer ou recursos Ingress.

Informações necessárias

Certifique-se de que você tenha o seguinte antes de começar:

• Sua chave de ativação de licença do Tableau Server
• O Administrador do TSM username e password para a conta inicial
• O hostname do Tableau Server para acesso

Pré-requisitos do Amazon Elastic Kubernetes Service (EKS)

StorageClass efs-bootstrap

Por padrão, efs-bootstrap não é criado no EKS. Para compartilhamento de bootstrap com múltiplos nós, crie-o antes da instalação do Helm.

Para uma implantação com múltiplos nós, o armazenamento de bootstrap deve ser provisionado antes que os pods possam ser agendados. Se o seu StorageClass efs-bootstrap não provisiona dinamicamente volumes de EFS, você deve:

• Criar um PV de bootstrap estático com antecedência e vinculá-lo a tableau-server-bootstrap

  ou

• Defina persistence.bootstrap.createPV: true e forneça valid persistence.bootstrap.pv.csi.volumeHandle (ID do EFS real, fs...).

Se isso não for feito, os pods permanecerão em um estado Pending com os PVCs não associados.

1. Verifique se o driver CSI do EFS está instalado no seu cluster.

   kubectl get csidriver efs.csi.aws.com

   Um objeto CSIDriver pode existir mesmo quando o complemento gerenciado pelo EKS não estiver instalado. Confirme o complemento explicitamente.

   Se você receber um erro ResourceNotFoundException (sem complemento) ou se os pods falharem posteriormente com erros de montagem, como driver name efs.csi.aws.com not found in the list of registered CSI drivers, instale o complemento EKS e aguarde até que o status seja ACTIVE e, em seguida, verifique os pods de plugin do nó.

   Isso é necessário porque o bootstrap com múltiplos nós usa um volume com EFS (readWrateMany). Sem o plugin de nó do CSI do EFS em nós adicionais, os PVCs de bootstrap podem ser associados, mas as montagens falham e os pods permanecem com estado Init/Pending.

   Se as montagens EFS falharem com:

   is not authorized to perform: elasticfilesystem:DescribeMountTargets

   ou

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

   Use uma destas remediações:

   • Correção IAM na função de nó EKS (Preferencial): conceda permissões de leitura de EFS e EC2 para montar o trabalho de descoberta de destino e AZ. Resolva o nome da função da instância do nó no grupo de nós:

     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

   • Use o **nome da função** IAM (último segmento do ARN) em 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

     • Permissões comuns envolvidas:

       • elasticfilesystem:DescribeMountTargets, 
         elasticfilesystem:DescribeFileSystems

       • ec2:DescribeAvailabilityZones (muitas vezes necessário quando DescribeAvailabilityZones aparece em erros de montagem)

   • montar explicitamente o IP de destino: defina mounttargetip nos atributos de volume PV CSI de bootstrap quando DNS/descoberta é restrito no seu ambiente.

     • Valores do Helm (caminho createPV: true):

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

     • Caminho manual de PV

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

2. Criar StorageClass efs-bootstrap (exemplo):

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

3. Escolha um caminho de provisionamento de bootstrap (obrigatório):

• Caminho de provisionamento do EFS dinâmico:

  use um StorageClass dinâmico do EFS CSI configurado para pontos de acesso (por exemplo, provisioningMode: efs-ap, fileSystemId, e permissões/parâmetros basePath de acordo com o padrão da sua plataforma).

• Caminho de PV estático:

  crie tableau-bootstrap-pv manualmente usando csi.driver: efs.csi.aws.com e csi.volumeHandle: fs-...

  em seguida, defina:

  • persistence.bootstrap.createPV: false

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

• Caminho de PV estático criado via Helm:

  defina:

  • persistence.bootstrap.createPV: true

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

Pré-requisitos não relacionados a EKS

StorageClass ReadWriteMany

Para clusters não hospedados no EKS (ou se não estiverem usando EFS), o requisito essencial para o compartilhamento de bootstrap com múltiplos nós é fornecer um StorageClass que suporte o modo de acesso ReadWriteMany (RWX) para o volume de bootstrap. Isso é necessário porque o armazenamento de bootstrap deve ser provisionado antes que os pods possam ser agendados.

Alguns dos back-ends de armazenamento RWX auto-hospedado comuns para Kubernetes:

• NFS (mais comum, mais fácil de testar)

• CephFS

• Longhorn (se instalado)

• GlusterFS

• NetApp/outro armazenamento corporativo

Você deve garantir que o driver CSI correspondente ao back-end escolhido esteja instalado.

Para configurar o Tableau Server para usar seu StorageClass RWX personalizado, atualize seus valores do Helm (por exemplo, values-multinode.yaml) para definir persistence.bootstrap.storageClass como o nome do seu 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 adicionais

• Tableau Server Helm Chart - Visão geral
• Tableau Server Helm Chart - Implantação
• Tableau Server Helm Chart - Solução de problemas
• Documentação do Helm
• Documentação do Tableau Server