Wichtig: In dieser Dokumentation wird davon ausgegangen, dass Sie sich mit Helm und Helm-Diagrammen auskennen, und es wird nicht versucht, detaillierte, präskriptive Beispiele zu liefern. Die Dokumentation ist für Kunden gedacht, die sowohl mit Tableau Server als auch mit Helm und Helm-Diagrammen vertraut sind.

In diesem Thema werden die Voraussetzungen erläutert, die für die Verwendung eines Helm-Diagramms zum Bereitstellen von Tableau Server erforderlich sind.

Cluster-Anforderungen

• Mindestens ein Knoten mit 16 GB RAM und 4 CPU-Kernen (empfohlen werden 8 Kerne).
• StorageClass, für dynamische Bereitstellung von PersistentVolumes konfiguriert.
• Die Fähigkeit zum Erstellen von LoadBalancer-Diensten oder Ingress-Ressourcen.

Erforderliche Informationen

Stellen Sie sicher, dass Sie über Folgendes verfügen, bevor Sie beginnen:

• Ihren Tableau Server-Lizenzschlüssel
• Den TSM-Administrator-username und password für das Anfangskonto
• Den Tableau Server-Hostnamen für den Zugriff

Voraussetzungen für Amazon Elastic Kubernetes Service (EKS)

efs-bootstrap StorageClass

In der Standardeinstellung wird efs-bootstrap nicht in EKS erstellt. Für die gemeinsame Nutzung von Bootstrap mit mehreren Knoten erstellen Sie diese vor der Helm-Installation.

Für eine Bereitstellung mit mehreren Knoten muss der Bootstrap-Speicher bereitstellbar sein, bevor Pods planen können. Wenn Ihre efs-bootstrap-StorageClass EFS-Volumes nicht dynamisch bereitstellt, müssen Sie eine der folgenden Aktionen durchführen:

• Erstellen Sie im Voraus ein statisches Bootstrap-PV, und binden Sie es an tableau-server-bootstrap.

  oder

• Legen Sie persistence.bootstrap.createPV: true fest, und geben Sie valid persistence.bootstrap.pv.csi.volumeHandle (reale EFS-ID, fs-...) an.

Geschieht dies nicht, verbleiben Pods im Status „Ausstehend“ mit ungebundenen PVCs.

1. Stellen Sie sicher, dass der EFS CSI-Treiber in Ihrem Cluster installiert ist.

   kubectl get csidriver efs.csi.aws.com

   Ein CSIDriver-Objekt kann auch dann vorhanden sein, wenn das verwaltete EKS-Add-on nicht installiert ist. Bestätigen Sie das Add-on ausdrücklich.

   Wenn Sie einen Fehler vom Typ ResourceNotFoundException (kein Add-on) erhalten oder Pods später mit Mount-Fehlern fehlschlagen (z. B driver name efs.csi.aws.com not found in the list of registered CSI drivers), installieren Sie das EKS-Add-on, warten Sie, bis der Status „AKTIV“ lautet, und überprüfen Sie dann die Knoten-Plugin-Pods.

   Dies ist notwendig, da Bootstrap auf mehreren Knoten (Multinode-Bootstrap) ein EFS-gestütztes Volume (ReadWriteMany) verwendet. Ohne das EFS CSI-Knoten-Plugin auf zusätzlichen Knoten können Bootstrap-PVCs zwar gebunden werden, aber Mount-Versuche schlagen fehl und Pods bleiben im Status Init/Pending.

   Wenn EFS-Mounts fehlschlagen mit:

   is not authorized to perform: elasticfilesystem:DescribeMountTargets

   oder

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

   Versuchen Sie es auf eine der folgenden Weisen:

   • IAM-Fix auf EKS-Knotenrolle (bevorzugt): Erteilen Sie EFS- und EC2-Leseberechtigungen, damit das Mount-Ziel und die AZ-Erkennung funktionieren. Lösen Sie den Namen der Knoteninstanzrolle aus Ihrer Knotengruppe auf:

     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

   • Verwenden Sie den IAM-**Rollennamen** (letztes Segment des 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

     • Typische involvierte Berechtigungen:

       • elasticfilesystem:DescribeMountTargets, 
         elasticfilesystem:DescribeFileSystems

       • ec2:DescribeAvailabilityZones (wird oft benötigt, wenn DescribeAvailabilityZones in Mount-Fehlern auftaucht)

   • Explizite Mount-Ziel-IP: Legen Sie mounttargetip in den Bootstrap-Attributen des PV CSI-Volumes fest, wenn DNS/Erkennung in Ihrer Umgebung eingeschränkt ist.

     • Helm-Werte (createPV: true Pfad):

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

     • Manueller PV-Pfad

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

2. Erstellen Sie efs-bootstrap StorageClass (Beispiel):

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

3. Wählen Sie einen Bootstrap-Bereitstellungspfad (erforderlich):

• Dynamischer EFS-Bereitstellungspfad:

  Verwenden Sie eine dynamische EFS CSI-StorageClass, die für Zugriffspunkte konfiguriert ist (z. B provisioningMode: efs-ap, fileSystemId, und permissions/basePath-Parameter gemäß Ihrem Plattformstandard).

• Statischer PV-Pfad:

  Erstellen Sie tableau-bootstrap-pv manuell mit csi.driver: efs.csi.aws.com und csi.volumeHandle: fs-...

  Legen Sie dann Folgendes fest:

  • persistence.bootstrap.createPV: false

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

• Vom Helm erstellter statischer PV-Pfad:

  Legen Sie Folgendes fest:

  • persistence.bootstrap.createPV: true

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

Nicht-EKS-Voraussetzung

ReadWriteMany StorageClass

Für Cluster, die nicht auf EKS gehostet werden (oder wenn EFS nicht verwendet wird), ist die entscheidende Voraussetzung für die gemeinsame Nutzung von Bootstraps mit mehreren Knoten die Bereitstellung einer StorageClass, die den Zugriffsmodus ReadWriteMany (RWX) für das Bootstrap-Volume unterstützt. Dies ist erforderlich, da Bootstrap-Speicher bereitstellbar sein muss, bevor Pods planen können.

Zu den gängigen selbstgehosteten RWX-Speicher-Backends für Kubernetes gehören:

• NFS (am gebräuchlichsten, am einfachsten zu testen)

• CephFS

• Longhorn (falls installiert)

• GlusterFS

• NetApp/anderer Enterprise-Speicher

Sie müssen sicherstellen, dass der zugehörige CSI-Treiber für das von Ihnen gewählte Backend installiert ist.

Um Tableau Server für die Verwendung Ihrer benutzerdefinierten RWX-StorageClass zu konfigurieren, aktualisieren Sie Ihre Helm-Werte (z. B. values-multinode.yaml), sodass persistence.bootstrap.storageClass auf den Namen Ihrer StorageClass festgelegt wird:

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

Zusätzliche Ressourcen

• Tableau Server-Helm-Diagramm – Übersicht
• Tableau Server-Helm-Diagramm – Bereitstellen
• Tableau Server-Helm-Diagramm – Fehlerbehebung
• Helm-Dokumentation
• Tableau Server-Dokumentation