--- schema_version: "1" id: d50fc73d906e6c66d09e24549fbaf1f1fca715ff34b4d9f9d72a85618ef85d68 title: Pré-requisitos do Helm Chart collection: tableau version: current locale: pt-br portal_url: https://docs.salesforce.com/tableau/current/pt-br/server-linux/server-helm-prerequisites.md canonical_url: https://help.tableau.com/current/server-linux/pt-br/server-helm-prerequisites.htm source_site: help.tableau.com content_type: documentation content_hash: 49ab0056ada5ab1ce4e26fed7ab65862ca6a8b50c386d8db5c036e298a8607f4 description: "Importante: esta documentação pressupõe um conhecimento do Helm e de Helm Charts e não tenta fornecer exemplos prescritivos detalhados" --- [Pular para o conteúdo principal](#main-content) # Tableau Server Helm Chart - Pré-requisitos **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. ## Download e distribuição do Helm Chart Os Helm Charts serão enviados como parte da ferramenta de configuração Tableau Server em um contêiner (`tableau-server-container-setup-tool-.tar.gz`) e pode ser baixado na página [Download do Tableau Server](http://tableau.com/pt-br/support/releases/server/latest). Após a extração, os arquivos dos Helm Charts necessários ficam em `helm/tableau` . ## Ferramentas necessárias - CLI `kubectl` configurado para acessar seu cluster Kubernetes - CLI `helm` versão 3.x e posterior - Acesso a um cluster Kubernetes (1.19+) ## 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..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 aws eks describe-nodegroup \\ \--cluster-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 \\ \--policy-arn arn:aws:iam::aws:policy/AmazonElasticFileSystemClientReadWriteAccess aws iam attach-role-policy \\ \--role-name \\ \--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](https://help.tableau.com/current/server-linux/pt-br/server-in-container_helm-chart.htm) - [Tableau Server Helm Chart - Implantação](https://help.tableau.com/current/server-linux/pt-br/server-helm-deploy.htm) - [Tableau Server Helm Chart - Solução de problemas](https://help.tableau.com/current/server-linux/pt-br/server-helm-troubleshooting.htm) - [Documentação do Helm](https://helm.sh/docs/) - [Documentação do Tableau Server](https://help.tableau.com/current/server-linux/en-us/)