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.

Dieses Thema führt Sie durch die allgemeinen Schritte zum Bereitstellen von Tableau Server in Kubernetes mithilfe eines Helm-Diagramms.

Voraussetzungen

Stellen Sie sicher, dass Sie die Voraussetzungen erfüllt haben, bevor Sie beginnen. Weitere Informationen finden Sie unter Tableau Server-Helm-Diagramm – Voraussetzungen.

Schneller Überblick über die Verwendung eines Helm-Diagramms zum Bereitstellen von Tableau Server

Wichtig: Dies ist eine grundlegende allgemeine Beschreibung der Bereitstellung von Tableau Server mithilfe von Helm-Diagrammen. Es ist nicht als vollständiges Verfahren gedacht. Dabei wird vorausgesetzt, dass Sie über Kenntnisse zu Helm und Helm-Diagrammen verfügen.

Bevor Sie beginnen, stellen Sie sicher, dass die Voraussetzungen für die Bereitstellung von Tableau Server mithilfe von Helm-Diagrammen erfüllt sind. Weitere Informationen finden Sie unter Tableau Server-Helm-Diagramm – Voraussetzungen.

Bereitstellen von Tableau Server mit einem einzigen Knoten

Stellen Sie eine Instanz von Tableau Server mit einem einzigen Knoten bereit, indem Sie die folgenden Befehle in einer Eingabeaufforderung ausführen (wobei Sie <namespace> mit Ihrem Release-Namespace ersetzen, z. B. tableau oder default):

helm install tableau-server ./helm/tableau-server \
  -n <namespace> \
  --create-namespace \
  -f ./helm/tableau-server/values-single.yaml

Bereitstellen von Tableau Server mit mehreren Knoten

Stellen Sie eine Instanz von Tableau Server mit mehreren Knoten bereit, indem Sie die folgenden Befehle in einer Eingabeaufforderung ausführen (und dabei dieselbe Namespace-Konvention wie oben verwenden):

helm install tableau-server ./helm/tableau-server \
-n <namespace> \
--create-namespace \
-f ./helm/tableau-server/values-multinode.yaml

EKS-Runbook mit mehreren Knoten (Namespace plus Statisches Bootstrap-PV)

In diesem Abschnitt wird die Reihenfolge der Vorgänge für EKS beschrieben: dedizierter Namespace, EFS CSI-Add-On, IAM für die Knotenrolle, statische Bootstrap-PV (Persistent Volume) und Helm.

1. Erstellen Sie einen dedizierten Namespace.

   Dieser muss mit claimFef.namespace in dem Bootstrap-PV übereinstimmen. In diesem Beispiel wird tableau verwendet.

   kubectl create namespace tableau-server
   kubectl get namespace tableau

2. Vergewissern Sie sich, dass das EFS CSI-Add-on vorhanden ist.

   Wenn das Add-on fehlt, erstellen Sie es, und warten Sie, bis der Status zu ACTIVE wechselt:

   kubectl get csidriver efs.csi.aws.com
   aws eks describe-addon \
     --cluster-name <cluster-name> \  
     --addon-name aws-efs-csi-driver \
     --region <region> \
     --query 'addon.status'

3. Bestätigen Sie die Storageclass (Speicherklasse):

   efs-bootstrap Storageclass – Anwenden, falls noch nicht vorhanden. Ausführliche Informationen finden Sie unter Voraussetzungen für Amazon Elastic Kubernetes Service (EKS).

   kubectl get csidriver efs.csi.aws.com
   aws eks describe-addon \
     --cluster-name <cluster-name> \  
     --addon-name aws-efs-csi-driver \
     --region <region> \
     --query 'addon.status'

4. Bestätigen Sie das statische Bootstrap-PV.

   claimRef muss auf den gleichen Namespace und den gleichen PVC-Namen verweisen, den das Helm-Diagramm erstellt (tableau-server-bootstrap). Ersetzen Sie fs-... mit Ihrer EFS-Dateisystem-ID:

   cat > /tmp/tableau-bootstrap-pv.yaml <<'EOF'
   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: tableau-bootstrap-pv
   spec:
     capacity:
       storage: 1Gi
     volumeMode: Filesystem
     accessModes:
       - ReadWriteMany
   persistentVolumeReclaimPolicy: Retain
   storageClassName: efs-bootstrap
   claimRef:
     namespace: tableau
     name: tableau-server-bootstrap
   csi:
     driver: efs.csi.aws.com
     volumeHandle: <fs-xxxxxxxxxxxxxxxxx>
   EOF
   kubectl apply -f /tmp/tableau-bootstrap-pv.yaml
   kubectl get pv tableau-bootstrap-pv

5. IAM für die Knoteninstanzrolle.

   Fügen Sie EFS-Client- und EC2-Schreibschutz-Richtlinien hinzu. Unter Voraussetzungen für Amazon Elastic Kubernetes Service (EKS) erfahren Sie, wie <your-node-instance-role> aus der Knotengruppe aufgelöst wird.

   efs-bootstrap Storageclass – Anwenden, falls noch nicht vorhanden. Ausführliche Informationen finden Sie unter Voraussetzungen für Amazon Elastic Kubernetes Service (EKS).

   kubectl get csidriver efs.csi.aws.com
   aws eks describe-addon \
     --cluster-name <cluster-name> \  
     --addon-name aws-efs-csi-driver \
     --region <region> \
     --query 'addon.status'

6. Werte

   Legen Sie in values-multinode.yaml (oder einem Overlay) den manuellen statischen PV-Modus fest.

   persistence:
     bootstrap:
       createPV: false
       volumeName: tableau-bootstrap-pv
       storageClass: efs-bootstrap

7. Stellen Sie sicher, dass image.repository, image.tag und Geheimnisse/Lizenz wie erforderlich festgelegt sind.

8. Installieren des Helm-Diagramms

   Installieren Sie das Diagramm im gleichen Namensraum wie das PV claimRef:

   helm install tableau-server ./helm/tableau-server \
     -n tableau \
     -f ./helm/tableau-server/values-multinode.yaml

9. Überprüfen von Speicher und Pods:

   kubectl get pv,pvc -n tableau
   kubectl get pods -n tableau -w

10. Daten-PVC-Status

    Für Daten-PVCs wird möglicherweise kurz Pending (Ausstehend) angezeigt, bis EBS-Volumes angefügt werden. Alle PVCs sollten zu Bound (Angebunden), dann zu Running (Ausgeführt) und schließlich zu READY 1/1 (Bereit 1/1) wechseln.

11. Topologie (optional)

    Wenn der Post-Install-Hook deaktiviert ist, müssen Sie möglicherweise den Knoten clustercontroller festlegen und ausstehende Änderungen anwenden (siehe dazu „Topologie-Automatisierung nach der Installation (Hook)“ weiter unten in diesem Dokument). Der Befehl tsm pending-changes apply kann dazu führen, dass Warnungen bezüglich der Verteilung des Indizierungs- und Suchservers oder des Koordinationsdienst-Ensembles gemeldet werden, wenn Sie über mehrere Tableau-Knoten verfügen. Beheben Sie diese Warnungen, wie in Indizierungs- und Suchserver und Tableau Server-Koordinationsdienst aufgeführt.

Benutzerdefinierte Installation

1. Anpassen von Werten

   cp ./helm/tableau-server/values.yaml 
   ./helm/tableau-server/my-values.yaml
   # Edit ./helm/tableau-server/my-values.yaml with your configuration

2. Installieren mit benutzerdefinierten Werten

   helm install tableau-server ./helm/tableau-server -f ./helm/tableau-server/my-values.yaml

Konfiguration

Bereitstellungsmodi

deploymentMode: "single"
primary:
  replicaCount: 1
worker:
  replicaCount: 0

deploymentMode: "multinode"
primary:
  replicaCount: 1
worker:
  replicaCount: 3    # example: three workers

Topologieausrichtung: values-multinode.yaml wird mit einer config.configJson-Beispieltopologie ausgeliefert (Knoten-IDs, wie beispielsweise node1, node2, node3). Wenn Sie worker.replicaCount ändern oder Dienste neu anordnen, aktualisieren Sie diese Topologie (und alle zugehörigen Tableau-Prozesszuweisungen), damit die Anzahl und Rollen der TSM-Knoten mit Ihrer Bereitstellung übereinstimmen. Informationen zum Clustering und Prozesslayout finden Sie in der Tableau Server-Hilfe.

Wichtige Konfigurationsoptionen

image:
  repository: tableau_server_image
  tag: "latest"
  pullPolicy: IfNotPresent
  pullSecrets: []

secrets:
  licenseKey: "YOUR-LICENSE-KEY"
  tsmRemotePassword: "password"
  tableauUsername: "admin"
  tableauPassword: "password"

Alternativ dazu können Sie diese auch mithilfe von Umgebungsvariablen festlegen:

env:
  LICENSE_KEY: "YOUR-LICENSE-KEY"
  TSM_REMOTE_PASSWORD: "password"
  TABLEAU_USERNAME: "admin"
  TABLEAU_PASSWORD: "password"

Es wird empfohlen, eine separate Datei (z. B. secrets.yaml) zu verwenden und diese mit dem Schalter -f zu übergeben.

secrets.yaml:

secrets:
  licenseKey: "YOUR-LICENSE-KEY"
  tsmRemotePassword: "YOUR-TSM-PASSWORD"
  tableauUsername: "YOUR-ADMIN-USER"
  tableauPassword: "YOUR-ADMIN-PASSWORD"

Beispiel für Installation/Aktualisierung mit secrets.yaml:

helm upgrade --install tableau-server ./helm/tableau-server \
  -n default \
  -f ./helm/tableau-server/values-multinode.yaml \
  -f ./helm/tableau-server/secrets.yaml

Hinweis: Das Verweisen auf ein bereits vorhandenes Kubernetes-Geheimnis (z. B. secrets.existingSecret) wird derzeit nicht unterstützt. Die einzige unterstützte Methode ist die Verwendung von Diagrammwerten mit einer separaten Geheimniswertdatei.

# Discover command syntax for your Tableau version
kubectl exec -n default tableau-server-primary-0 -- sh -lc 'tsm topology external-services repository enable --help'
# After enabling external repository with Tableau-supported args/options:
kubectl exec -n default tableau-server-primary-0 -- sh -lc 'tsm pending-changes apply -iw --ignore-prompt'
kubectl exec -n default tableau-server-primary-0 -- sh -lc 'tsm status -v'

Persistenter Speicher

persistence:
  enabled: true
  storageClass: "standard"
  accessMode: ReadWriteOnce
  size: 100Gi

  # Bootstrap volume (required for multi-node)
  bootstrap:
    enabled: true
    storageClass: "standard"
    accessMode: ReadWriteMany
    size: 1Gi
    createPV: false

Für Cluster, die statisches EFS CSI verwenden (z. B. mit mounttargetip), kann Helm sowohl Bootstrap-PV als auch PVC verwalten:

persistence:
  bootstrap:
    enabled: true
    storageClass: "efs-bootstrap"
    accessMode: ReadWriteMany
    size: 1Gi
    createPV: true
    permissionsFix:
      enabled: true
    pv:
      name: "tableau-bootstrap-pv"
      csi:
        driver: efs.csi.aws.com
        volumeHandle: "fs-xxxxxxxx"
        volumeAttributes:
          mounttargetip: "10.x.x.x"

permissionsFix.enabled fügt einen Init-Container zu chown/chmods /docker/config/bootstrap hinzu, damit der Tableau-Prozess (UID/GID 999:998) bootstrap.json auf freigegebene EFS-Mounts schreiben kann, die standardmäßig auf root:root festgelegt sind.

Wenn createPV: true ist, erstellt das Diagramm das Bootstrap-PV aus Werten (z. B tableau-bootstrap-pv), und bindet tableau-server-bootstrap PVC daran.

Wenn Sie Bootstrap PV manuell verwalten, erstellen Sie zuerst tableau-bootstrap-pv, und installieren Sie dann Helm mit createPV: false und volumeName: tableau-bootstrap-pv:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: tableau-bootstrap-pv
spec:
  capacity:
    storage: 1Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: efs-bootstrap
  csi:
    driver: efs.csi.aws.com
    volumeHandle: fs-xxxxxxxx
    volumeAttributes:
      mounttargetip: 10.x.x.x

kubectl apply -f tableau-bootstrap-pv.yaml
kubectl get pv tableau-bootstrap-pv

Ressourcenlimits

primary:
  resources:
    limits:
      cpu: "4"
      memory: "8Gi"
    requests:
      cpu: "2"
      memory: "4Gi"

worker:
  resources:
    limits:
      cpu: "4"
      memory: "8Gi"
    requests:
      cpu: "2"
      memory: "4Gi"

Dienstkonfiguration

service:
  primary:
    type: ClusterIP  # or NodePort, LoadBalancer
    ports:
      http: 80
      https: 8080
      tsm: 8850

Ingress

ingress:
  enabled: true
  className: "nginx"
  hosts:
    - host: tableau.example.com
      paths:
        - path: /
          pathType: Prefix
  tls:
    - secretName: tableau-tls
      hosts:
        - tableau.example.com

Ingress-Einrichtungs-Runbook (Beispiel: NGINX Ingress Controller)

1. Installieren Sie einen Ingress-Controller in dem Cluster (erforderlich, bevor Diagrammeingang aktiviert wird).

2. Legen Sie Eingangswerte in Ihrer Wertedatei fest:

   ingress:
     enabled: true
     className: "nginx"
     annotations:
       nginx.ingress.kubernetes.io/proxy-body-size: "64m"
       nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
       nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
     hosts:
       - host: tableau.example.com
         paths:
           - path: /
             pathType: Prefix
     tls:
       - secretName: tableau-tls
         hosts:
           - tableau.example.com

3. Erstellen Sie einen DNS-Eintrag, der „tableau.example.com“ auf Ihren Eingangs-/Lastenausgleichs-Endpunkt verweist.

4. Erstellen Sie ein TLS-Geheimnis (oder verwenden Sie cert-manager) im Release-Namespace.

5. Bereitstellen/Aktualisieren des Diagramms und Überprüfen des Eingangs:

   helm upgrade --install tableau-server ./helm/tableau-server -n default -f ./helm/tableau-server/values.yaml
   kubectl get ingress -n default
   kubectl describe ingress tableau-server

Weitere Informationen finden Sie unter:

• Konzept von Kubernetes Ingress(Link wird in neuem Fenster geöffnet)

• ingress-nginx Deployment Guide (Bereitstellungshandbuch für ingress-nginx)(Link wird in neuem Fenster geöffnet)

• cert-manager Getting Started (Erste Schritte mit cert-manager)(Link wird in neuem Fenster geöffnet)

Integritätsprüfungen

Das Diagramm unterstützt Start-, Aktivitäts- und Bereitschaftstests. Der Starttest erlaubt eine lange Erstinitialisierung (z. B. failureThreshold: 200 × periodSeconds), bevor Aktivitäts- und Bereitschaftstests ausgeführt werden:

healthChecks:
  startup:
    enabled: true
    initialDelaySeconds: 300
    periodSeconds: 15
    timeoutSeconds: 30
    failureThreshold: 200
  liveness:
    enabled: true
    initialDelaySeconds: 300
    periodSeconds: 30
    timeoutSeconds: 10
    failureThreshold: 3
  readiness:
    enabled: true
    initialDelaySeconds: 300
    periodSeconds: 10
    timeoutSeconds: 5
    failureThreshold: 3

Bei Worker-Pods mit mehreren Knoten verwendet das Diagramm standardmäßig worker.healthChecks.enabled: false, um Testfehlalarme zu vermeiden, wenn Worker begrenzte Prozesssätze ausführen (z. B. nur Admin Agent + Cluster-Controller).

Verwendung

# Get pod name
POD_NAME=$(kubectl get pods -l app.kubernetes.io/component=primary -o jsonpath='{.items[0].metadata.name}')

# Run tabcmd
kubectl exec -it $POD_NAME -- tsm status
kubectl exec -it $POD_NAME -- tsm configuration get

# Get pod name
POD_NAME=$(kubectl get pods -l app.kubernetes.io/component=primary -o jsonpath='{.items[0].metadata.name}')

# Run tabcmd
kubectl exec -it $POD_NAME -- tabcmd login -u admin -p password
kubectl exec -it $POD_NAME -- tabcmd sites

# Primary node logs
kubectl logs -l app.kubernetes.io/component=primary -f

# Worker node logs (multi-node)
kubectl logs -l app.kubernetes.io/component=worker -f

# All logs
kubectl logs -l app.kubernetes.io/instance=tableau-server -f

# Get pod name
POD_NAME=$(kubectl get pods -l app.kubernetes.io/component=primary -o jsonpath='{.items[0].metadata.name}')

# Open shell
kubectl exec -it $POD_NAME -- /bin/bash

Aktualisieren

Aktualisieren des Tableau Server-Helm-Diagramms

helm upgrade tableau-server ./helm/tableau-server -f ./helm/tableau-server/values.yaml

Aktualisieren mit neuen Werten

helm upgrade tableau-server ./helm/tableau-server -f ./helm/tableau-server/new-values.yaml

Topologieautomatisierung nach der Installation (Hook)

Bei Installationen mit mehreren Knoten kann dieses Diagramm nach der Installation/Aktualisierung einen Hook-Auftrag ausführen, der:

• Wartet, bis sich Worker-Knoten in TSM registrieren

• Die Worker-clustercontroller-Prozesszuweisung festlegt

• Den Befehl tsm pending-changes apply -iw --ignore-prompt ausführt, wenn Änderungen ausstehen

Konfiguration:

hooks:
  autoApplyWorkerTopology:
    enabled: true
    kubectlImage: "bitnami/kubectl:latest"
    timeoutSeconds: 3600

Standardeinstellungen:

• In values.yaml deaktiviert

• In values-multinode.yaml überprüfen Sie hooks.autoApplyWorkerTopology.enabled (kann true oder false sein, je nach der Version. Aktivieren Sie diese Einstellung für Hands-off-Worker-clustercontroller-Einrichtung.)

Überprüfen der Hook-Ausführung:

kubectl get jobs -n default
kubectl get pods -n default -l job-name=tableau-server-hook-topology
kubectl logs -n default job/tableau-server-hook-topology

Manueller Fallback, wenn der Hook deaktiviert ist oder fehlschlägt – Führen Sie tsm topology set-process für jeden Worker-TSM-Knoten aus (normalerweise node2 bis node(1+N), wenn Sie N Worker haben; bestätigen Sie die IDs mit tsm topology list-nodes -v):

kubectl exec -n default tableau-server-primary-0 -- sh -lc '
tsm topology set-process -n node2 -pr clustercontroller -c 1
tsm topology set-process -n node3 -pr clustercontroller -c 1
# Add one line per additional worker node, e.g. for four workers:
# tsm topology set-process -n node4 -pr clustercontroller -c 1
# tsm topology set-process -n node5 -pr clustercontroller -c 1
tsm pending-changes apply -iw --ignore-prompt
tsm topology list-nodes -v

tsm status -v

Hinweis: Verwenden Sie -iw bei tsm pending-changes apply. Die Option -ig ist in dieser Umgebung ungültig.

Deinstallieren

helm uninstall tableau-server

Warnung: Dadurch werden alle Ressourcen einschließlich persistenter Volumes (PVs) gelöscht. Stellen Sie sicher, dass Sie Ihre Daten vor dem Deinstallieren sichern.

Validierungsschritte

Führen Sie vor dem Release oder beim Ändern des Diagramms die folgenden Befehle aus:

1. Lint:

   helm lint helm/tableau-server -f helm/tableau-server/values-single.yaml
   helm lint helm/tableau-server -f helm/tableau-server/values-multinode.yaml

2. Vorlage (Probelauf):

   helm template tableau-server helm/tableau-server -f helm/tableau-server/values-single.yaml
   helm template tableau-server helm/tableau-server -f helm/tableau-server/values-multinode.yaml

3. Installationstest (optional):

   1. Führen Sie in einem Testnamespace helm install mit Werten für einzelne oder mehrere Knoten aus.

   2. Führen Sie kubectl rollout status aus (bei „StatefulSet“ warten Sie, bis Pod bereit ist), und führen Sie allgemeine „Smoke-Checks“ aus (z. B. tsm status oder HTTP zu dem Dienst).

Detaillierte Informationen zur Fehlerbehebung finden Sie unter Tableau Server-Helm-Diagramm – Fehlerbehebung.

Zusätzliche Ressourcen

• Tableau Server-Dokumentation(Link wird in neuem Fenster geöffnet)
• Helm-Dokumentation(Link wird in neuem Fenster geöffnet)
• Helm-Diagramm-Aktualisierung(Link wird in neuem Fenster geöffnet)