Belangrijk: in deze documentatie wordt uitgegaan dat de gebruiker basiskennis heeft over Helm en Helm-grafieken. Er worden geen gedetailleerde, prescriptieve voorbeelden gegeven. De documentatie is ontworpen voor klanten die bekend zijn met zowel Tableau Server, Helm en Helm-grafieken.

In dit onderwerp worden de vereisten uitgelegd die nodig zijn om een Helm-grafiek te gebruiken voor de implementatie van Tableau Server.

Clustervereisten

• Ten minste één knooppunt met 16 GB RAM en 4 CPU-kernen (8 kernen aanbevolen).
• StorageClass geconfigureerd voor dynamische PersistentVolume-inrichting.
• Mogelijkheid om LoadBalancer-services of Ingress-resources te maken.

Vereiste informatie

Zorg ervoor dat u de volgende informatie hebt voordat u begint:

• Uw Tableau Server-licentiesleutel
• De TSM-beheerdersgegevens over username en password voor het initiële account
• De hostnaam van de Tableau Server voor toegang

Vereisten voor de Amazon Elastic Kubernetes Service (EKS)

efs-bootstrap StorageClass

Standaard wordt efs-bootstrap niet gemaakt in EKS. Voor het delen van bootstrap met meerdere knooppunten maakt u dit vóór de installatie van Helm.

Voor implementaties met meerdere knooppunten moet bootstrap-opslag kunnen worden ingericht voordat u pods kunt inplannen. Als uw efs-bootstrap StorageClass EFS-volumes geen ondersteuning bieden voor dynamische inrichting, moet u het volgende doen:

• Maak van tevoren een statische bootstrap-PV en bind deze aan tableau-server-bootstrap

  of

• Stel persistence.bootstrap.createPV: true in en geef valid persistence.bootstrap.pv.csi.volumeHandle op (echte EFS-ID, fs-...).

Als dit niet gebeurt, blijven de pods in de status In behandeling met ongebonden PVC's.

1. Zorg dat het EFS CSI-stuurprogramma in uw cluster is geïnstalleerd.

   kubectl get csidriver efs.csi.aws.com

   Een CSIDriver-object kan zelfs bestaan als de door EKS beheerde add-on niet is geïnstalleerd. Bevestig de add-on expliciet.

   Als u een ResourceNotFoundException-foutmelding krijgt (geen add-on) of als pods later mislukken met koppelingsfouten zoals driver name efs.csi.aws.com not found in the list of registered CSI drivers, installeert u de EKS-add-on en wacht u tot de status ACTIVE is. Controleer vervolgens de pods voor de knooppuntplug-in.

   Dit is nodig omdat de bootsstrap-functie voor meerdere knooppunten gebruikmaakt van een EFS-ondersteund volume (ReadWriteMany). Zonder de EFS CSI-knooppunt-plug-in op extra knooppunten kunnen bootstrap-PVC's binding maken, maar mislukken de koppelingen en blijven pods in de statussen Init/Pending.

   Als EFS-koppelingen mislukken met:

   is not authorized to perform: elasticfilesystem:DescribeMountTargets

   of

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

   Gebruik een van deze herstelmaatregelen:

   • IAM-fix op EKS-knooppuntrol (voorkeur): verleen EFS- en EC2-rechten voor alleen-lezen, dus koppel doel- en AZ-detectiewerk. Los de rolnaam van de knooppuntinstantie uit uw knooppuntgroep op:

     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

   • Gebruik de IAM **rolnaam** (laatste segment van de 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

     • De volgende machtigingen komen vaak voor:

       • elasticfilesystem:DescribeMountTargets, 
         elasticfilesystem:DescribeFileSystems

       • ec2:DescribeAvailabilityZones (vaak nodig wanneer DescribeAvailabilityZones verschijnt in koppelingsfouten)

   • Koppel het doel-IP expliciet: stel mounttargetip in op de bootstrap PV CSI-volumekenmerken wanneer DNS/detectie in uw omgeving beperkt is.

     • Helm-waarden (createPV: true-pad):

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

     • Handmatig PV-pad

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

2. efs-bootstrap StorageClass maken (voorbeeld):

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

3. Kies één bootstrap-inrichtingspad (vereist):

• Dynamisch EFS-inrichtingspad:

  Gebruik een dynamische EFS CSI StorageClass die is geconfigureerd voor toegangspunten (bijvoorbeeld provisioningMode: efs-ap, fileSystemId en permissions/basePath-parameters volgens uw platformstandaard).

• Statisch PV-pad:

  Maak tableau-bootstrap-pv handmatig met csi.driver: efs.csi.aws.com en csi.volumeHandle: fs-...

  Stel vervolgens het volgende in:

  • persistence.bootstrap.createPV: false

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

• Door Helm gemaakt statisch PV-pad:

  set:

  • persistence.bootstrap.createPV: true

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

Niet-EKS-vereiste

ReadWriteMany StorageClass

Voor clusters die niet op EKS worden gehost (of geen EFS gebruiken), is de kritieke vereiste voor het delen van bootstrap met meerdere knooppunten het bieden van een opslagklasse die de ReadWriteMany (RWX)-toegangsmodus voor het bootstrap-volume ondersteunt. Dit is vereist omdat bootstrap-opslag ingericht moet kunnen worden voordat pods kunnen worden gepland.

Veelgebruikte zelf-hostende RWX-opslagback-ends voor Kubernetes zijn onder meer:

• NFS (meest voorkomend, gemakkelijkst te testen)

• CephFS

• Longhorn (indien geïnstalleerd)

• GlusterFS

• NetApp/andere storage op ondernemingsniveau

U moet ervoor zorgen dat het bijbehorende CSI-stuurprogramma voor uw back-end is geïnstalleerd.

Om Tableau Server te configureren om uw aangepaste RWX StorageClass te gebruiken, werkt u uw Helm-waarden (bijvoorbeeld values-multinode.yaml) bij om persistence.bootstrap.storageClass in te stellen op de naam van uw 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

Aanvullende bronnen

• Tableau Server: Helm-grafiek - Overzicht
• Tableau Server: Helm-grafiek - Implementeren
• Tableau Server: Helm-grafiek - Problemen oplossen
• Helm-documentatie(Link wordt in een nieuw venster geopend)
• Tableau Server-documentatie(Link wordt in een nieuw venster geopend)