Hilfe zu Tableau Server für Linux

Einführung

Die dynamische Skalierung von Hintergrundprozesskomponenten in einem Container macht es möglich, dass verschiedene Skalierungsstrategien auf Hintergrund- und geplante Aufträge in Tableau Server angewendet werden. Automatische Skalierung bedeutet in diesem Kontext, dass Dienste unabhängig skaliert werden können, um variable Aufgabenlasten zu verarbeiten, ohne dass dazu manuelle Eingriffe erforderlich sind oder der Betrieb anderer Serversysteme beeinträchtigt wird. Die Tableau Server-Container, in denen komplette Knoten von Tableau Server-Prozessen enthalten sind, werden weiterhin als monolithische Systeme ausgeführt. Stattdessen wird eine kleinere Auswahl von entkoppelten unabhängigen Container-Diensten, die die Dienstrolle "Backgrounder" (Hintergrundprozesskomponente) bilden, dynamisch skalierbar sein und Rechenlasten verarbeiten, die normalerweise von Tableau Server-Containern übernommen werden. Hintergrundprozesskomponenten-Dienste sind für die Verarbeitung von Systemaufgaben zuständig, zu denen das Aktualisieren oder Erstellen von Extrakten, das Senden von Subscriptions, das Überprüfen von Benachrichtigungen und viele Wartungsaufgaben gehören. So können Sie beispielsweise in Situationen, in denen es vorteilhaft wäre, eine große Anzahl von Datensätzen zu aktualisieren oder Unmengen rechenintensiver Warnungen zu verarbeiten, nun Kubernetes einsetzen, um die Rechenleistung so hoch zu skalieren, dass solche Aufgaben effizient durchgeführt werden. Diese Anleitung behandelt die Konfigurations- und Bereitstellungsanforderungen für die automatische Skalierung von Hintergrundprozesskomponenten in Kubernetes. Dieses Dokument ist eine Ergänzung zu der Dokumentation Tableau Server in einem Container.

Voraussetzungen

Das automatische Skalieren von Hintergrundprozesskomponenten ist nur in Kubernetes verfügbar und basiert auf Tableau Server in einem Container. Um das Feature "Automatische Skalierung von Hintergrundprozesskomponenten" verwenden zu können, müssen die folgenden Voraussetzung erfüllt sein:

• Tableau Server muss über Advanced-Management-Funktionen verfügen. Weitere Informationen finden Sie unter Über Tableau Advanced Management in Tableau Server.
• Sie müssen das rollenbasierte Lizenzmodell verwenden. Core-Lizenzen werden nicht unterstützt. Einzelheiten zur Lizenzierung finden Sie unter Grundlegendes zu Lizenzmodellen und Produktschlüsseln.
• Die folgenden Features von Advanced Management müssen aktiviert sein:
  • Externer Tableau Server-Dateispeicher
  • Externes Repository von Tableau Server
• Sie müssen einen Kubernetes-Cluster der Version 1.20 (oder höher) haben und sich mit dessen Verwendung und Verwaltung auskennen.

Einschränkungen

• Dieses Feature funktioniert nur als Bestandteil einer Linux-basierten Bereitstellung.
• Schemaaufträge werden bei automatischen skalierten Hintergrundprozesskomponenten nicht unterstützt. Schemaaufträge werden von den Hintergrundprozesskomponenten-Diensten verarbeitet, die weiterhin in dem Tableau Server-Container ausgeführt werden.

Erstellen von Tableau Server- und Hintergrundprozesskomponenten-Pod-Images

Der erste Schritt für die Verwendung von automatisch skalierenden Hintergrundprozesskomponenten in Containern besteht darin, die Dienst-Images zu erstellen, die die Tableau Server-Installation enthalten. Diese Images werden das Tableau Server-Image sowie Images für die separaten Hintergrundprozesskomponenten- und unterstützenden Dienste enthalten. Sie können dasselbe Erstellungstool verwenden, mit dem das komplette Tableau Server-Container-Image erstellt wird, allerdings muss das Tool mindestens von der Version 2022.3.0 sein. Außerdem müssen Sie eine Lizenz für Advanced Management besitzen, und Sie müssen beim Erstellen der Images ein spezielles Flag verwenden.

1. Erstellen Sie die Dienst-Images mit dem folgenden Befehl:

   build-image --accepteula -i <installer> --backgrounder-images

   Dieser erstellt das Tableau Server-Image und vier neue Images. In den vier zusätzlichen Images befinden sich einzelne Dienste, aus die den neuen automatisch skalierbaren Hintergrundprozesskomponenten-Pod bilden.

   Der docker images-Befehl listet die Images auf, die im lokalen Docker-Repository erstellt sind:

   hyper                          20214.21.1117.1006             52fd9843c178   10 seconds ago
   gateway                        20214.21.1117.1006             2308e602a2a3   11 seconds ago
   backgrounder                   20214.21.1117.1006             4540e459cf23   12 seconds ago
   dataserver                     20214.21.1117.1006             c5345ed47f51   12 seconds ago
   tableau_server_image           20214.21.1117.1006             b27817047dd1   7 minutes ago

   Die Images namens "Hyper", "Gateway", "Backgrounder" (Hintergrundprozesskomponente) und "Dataserver" (Datenserver) bilden den neuen Hintergrundprozesskomponenten-Pod. Benutzerdefinierte Treiber, Installationsskripte und Eigenschaften werden über alle fünf Images freigegeben. Weitere Informationen finden Sie unter Anpassen des Images.

2. Veröffentlichen Sie diese fünf Images in Ihrem internen Image-Repository für die Bereitstellung.

Bereitstellungshandbuch

Die folgenden Informationen stellen Kontextinformationen für die Vorgehensweise bereit, mit der Tableau Server in einem Container und mit automatisch skalierenden Hintergrundprozesskomponenten bereitgestellt wird. Dabei wird davon ausgegangen, dass Sie bereits damit vertraut sind, wie Tableau Server in einem eigenständigen Container bereitgestellt wird. Weitere Informationen finden Sie unter Tableau Server in einem Container. Die drei Kubernetes-Konfigurationsdateien im Abschnitt "Kubernetes-Konfiguration" sind Vorlagen, die Sie zum Einrichten der Bereitstellung nutzen können. In den anderen Abschnitte in dieser Anleitung werden die Anforderungen und Einzelheiten der Bereitstellung behandelt.

Die Bereitstellung von Tableau Server und automatisch skalierenden Hintergrundprozesskomponenten sollte so einfach sein, wie das Bereitstellen der aufgefüllten Kubernetes-Konfigurationsdateien ganz unten in dieser Anleitung:

kubectl apply -f <tableau-kubeconfig-dir>

Hintergrundprozesskomponenten-Aufträge

Hintergrundprozesskomponenten-Pods helfen dem Tableau-Server in einem Container, zusätzliche geplante Arbeitslasten parallel zu verarbeiten. Hintergrundprozesskomponenten verarbeiten Extraktaktualisierungs-, Subscriptions-, Benachrichtigungs-, Schema- und Systemarbeitslasten. Durch die Verteilung von Aufträgen auf Hintergrundprozesskomponenten-Pods werden mehr Rechenressourcen für Tableau Server frei, um andere Aufgaben zu übernehmen (z. B. interaktive Benutzeraktivitäten oder das Rendern von Arbeitsmappen oder Dashboards). Schemaaufträge sind der einzige Typ von Hintergrundprozesskomponenten-Aufträgen, die nicht in der Hintergrundprozesskomponente ausgeführt werden. Einzelheiten zu Hintergrundprozesskomponenten-Aufträgen finden Sie unter Verwalten von Hintergrundaufträgen in Tableau Server.

Hintergrundprozesskomponente-Pods können Arbeitslasten jeder Art übernehmen, mit Ausnahme von Schemaaufträgen, die in den Tableau Server-Hauptcontainern ausgeführt werden müssen, in denen weiterhin der Hintergrundprozesskomponenten-Dienst ausgeführt wird.

Das Feature "Knotenrollen" gibt Benutzern die Flexibilität, Hintergrundprozesskomponenten-Pods für bestimmte Typen von Aufträgen vorzusehen. Dieses Feature ist eine Erweiterung des "Knotenrollen"-Features auf dem Tableau-Server. Eine detaillierte Beschreibung der verschiedenen Knotenrollen finden Sie an dieser Stelle. Hinweis: Da Hintergrundprozesskomponenten-Pods nicht in der Lage sind, Schemaaufträge auszuführen, sind Schemaaufträge in den Hintergrundprozesskomponenten-Pods standardmäßig deaktiviert (d.h. die Rolle ist auf "no-flows" festgelegt).

Zum Einrichten von Knotenrollen für Hintergrundprozesskomponenten müssen Sie die Umgebungsvariable NODE_ROLES im Rahmen von "kubeconfig" für den Container festlegen, in dem der Hintergrundprozesskomponenten-Dienst ausgeführt wird. Ein Beispiel: Wenn Sie festlegen möchten, dass eine Hintergrundprozesskomponente nur Extrakaktualiserungsaufträge ausführen soll, legen Sie für die Umgebungsvariable NODE_ROLES nur "extract-refreshes" fest, wie nachfolgend gezeigt:

NODE_ROLE_CONFIG

containers:
      - name: backgrounder
        image: <backgrounder_image> # Backgrounder Image
        ports:
        - containerPort: 8600
        volumeMounts:
        - name: logmount
          mountPath: /var/log/tableau
        - name: clone-volume
          mountPath: /docker/clone
        - name: dataengine-volume
          mountPath: /docker/dataengine
        - name: temp
          mountPath: /var/opt/tableau/tableau_server/data/tabsvc/temp
        env:
          - name: ROOT_LOG_DIR
            value: /var/log/tableau
          - name: CLONE_ARTIFACT_DIR
            value: /docker/clone/clone-artifacts
          - name: FILESTORE_MOUNT_PATH
            value: /docker/dataengine
          - name: NODE_ROLES
            value: extract-refreshes

Die Tableau Server-Pods werden in ihrer Topologie über mindestens eine konfigurierten Hintergrundprozesskomponenten verfügen – was erforderlich ist, um sicherzustellen, dass es immer genug Platz zum Ausführen von Hintergrundprozesskomponenten-Aufträgen gibt. In der Standardeinstellung ist es für TSM erforderlich, dass es eine Hintergrundprozesskomponente gibt, die jede Rolle von Hintergrundprozesskomponenten-Aufträgen übernehmen kann. In manchen Szenarien möchten Sie vielleicht Hintergrundprozesskomponenten-Pods haben, die alle Aufträge eines bestimmten Typs übernehmen können. Dazu müssen Sie den Server-Konfigurationsschlüssel topology.roles_handle_all_jobs_constraint_disabled auf true setzen, wodurch die Anforderung deaktiviert wird, dass die TSM-Topologie alle Auftragstypen verarbeitet. Wenn dieser Parameter gesetzt ist, könnte die Hintergrundprozesskomponenten-Rolle für die Tableau Server-Hintergrundprozesskomponenten-Instanz auf no-extract-refreshes und die Rolle für die Hintergrundprozesskomponenten-Pods auf extract-refreshes gesetzt werden, wodurch sichergestellt werden würde, dass sämtliche Extraktaktualisierungsaufträge nur in den Hintergrundprozesskomponenten-Pods ausgeführt werden.

Hinweis: Durch Deaktivieren dieser Einschränkung könnten Sie Rollen so konfigurieren, dass einige Auftragstypen nie geplant werden. Die Rollenkonfiguration von TSM-Hintergrundprozesskomponenten und Hintergrundprozesskomponenten-Aufträgen muss sorgfältig vorgenommen werden, da TSM nicht mehr überprüfen wird, dass alle Typen von Hintergrundprozesskomponenten-Aufträgen geplant werden können.

Tableau Server in einem Container-Pod

Die Containers mit Tableau Server als Bestandteil der automatisch skalierenden Hintergrundprozesskomponenten-Pods stellen Sie auf fast die gleiche Weise wie unsere vorhandenen Tableau Server in einem Container bereit. Bei den Anforderungen gibt es einige Änderungen:

• Zum Übertragen der Konfiguration zwischen dem Tableau Server-Container und den Hintergrundprozesskomponenten-Pods ist eine Netzwerkdateifreigabe erforderlich.
• Sie müssen das Feature "Externer Dateispeicher" aktivieren und verwenden. Dafür ist ebenfalls eine dedizierte Netzwerkdateifreigabe erforderlich.

Hintergrundprozesskomponenten-Pods

Hintergrundprozesskomponenten-Pods bestehen aus vier unabhängigen Dienstcontainern, die zusammen arbeiten: Gateway, Hyper, Dataserver und Backgrounder. Sie müssen diese Pods wie typische unabhängige Kubernetes-Container-Pods bereitstellen. Die Pods haben die folgenden Anforderungen:

• Hintergrundprozesskomponenten-Pods müssen in der Lage sein, den Tableau Server-Knoten mittels Hostname-DNS-Auflösung zu erreichen.
• Netzwerkdateifreigaben für den externen Dateispeicher und den Klon müssen bereitgestellt sein.

Hinweis: Netzwerkdateifreigaben-Pods werden mit einem "init-container" konfiguriert, damit mit der Ausführung so lange gewartet werden soll, bis der Tableau Server-Container die Ausgabe einer Klon-Konfiguration erfolgreich angefertigt hat.

Protokolle

Hintergrundprozesskomponenten-Pod-Dienste (wie Tableau Server) schreiben Protokolle weiterhin überwiegend auf die Festplatte. Da die Hintergrundprozesskomponenten-Pods hoch oder herunter skaliert werden können, sind sie vergänglicher Natur – daher ist es überaus wichtig, sicherzustellen, dass Protokolle außerhalb der Pods gespeichert werden. Viele Kunden mit bestehenden K8s-Umgebungen werden bereits eine bestimmte Art von Protokollsammeldienst einsetzen, um Protokolle aus den bei ihnen bereitgestellten Pods zu sammeln. Beispiele für solch einen Protokollsammeldienst wären Splunk und fluentd. Wie empfehlen Kunden dringend, einen Protokollsammeldienst beliebiger Art zu verwenden, um Protokolle aus ihren Hintergrundprozesskomponenten-Pods zu sammeln. Um die Protokollverwaltung zu vereinfachen, konfiguriert das von uns bereitgestellte "kubeconfig" jeden Dienst in dem Pod so, dass er auf ein freigegebenes Protokollvolume schreibt. Der Pfad zu dem Verzeichnis in jedem Dienstcontainer wird von der Umgebungsvariablen ROOT_LOG_DIR angegeben.

Wenn Sie einen Supportfall öffnen und Protokolle bereitstellen müssen, müssen Sie zwei Sätze von Protokollen übermitteln: gepackte Protokolle (.zip), die auf den Haupt-Server-Containern gesammelt wurden, und Protokolle aus den Hintergrundprozesskomponenten-Pods (die entweder von Ihrem Protokollsammeldienst abgerufen oder manuell wie unten beschrieben gesammelt wurden).

Für Kunden, bei denen die Verwendung eines Protokollsammeldienstes nicht möglich ist, können Protokolle manuell aus den Pods abgerufen werden.

Hinweis: Protokolle aus einem beliebigen Pod, das kein mit "PersistantVolumeClaim" eingebundenes Volume verwendet hat, auf dem die Protokolle enthalten sind, gehen verloren, wenn das Pod herunter skaliert wird!

Alle relevanten Protokolle sind in dem Verzeichnis /var/log/tableau (was über die Umgebungsvariable ROOT_LOG_DIR konfigurierbar ist) innerhalb des Hintergrundprozesskomponenten-Pods verfügbar. Wie empfehlen Ihnen dringend, an diesem Speicherort ein mit "PersistantVolumeClaim" eingebundenes Volume zu konfigurieren, damit Protokolle auch nach dem Ende des Pods noch verfügbar sind.

Sammeln von Protokollen, während das Hintergrundprozesskomponenten-Pod ausgeführt wird:

Erstellen Sie eine tar-Datei der Protokolle innerhalb des Containers:

kubectl exec -it <backgrounder-pod-name> -- bash -c "tar -czf /docker/user/backgrounder-pod-logs.tar.gz /var/log/tableau"

Kopieren Sie die tar-Datei nach außerhalb des Containers:

kubectl cp <backgrounder-pod-name>:docker/user/backgrounder-pod-logs.tar.gz ./backgrounder-pod-logs.tar.gz

Sammeln von Protokollen, nachdem das Hintergrundprozesskomponenten-Pod beendet wurde (oder nicht gestartet werden konnte):

Binden Sie ein beliebiges, seit längerem ausgeführtes Pod mit PersistantVolumeClaim-Einbindung ein, das für Hintergrundprozesskomponenten-Pod-Bereitstellungsprotokolle verwendet wird. Eine Beispielkonfiguration:

apiVersion: v1
kind: Pod
metadata:
  name: <name>
  namespace: <namespace>
spec:
  containers:
  - name: get-logs-pod
    image: busybox:1.28
    securityContext:
      runAsUser: 0
      allowPrivilegeEscalation: true
    command: ['sh', '-c', "while :; do sleep 5; done"]
    volumeMounts:
    - name: logmount
      mountPath: /var/log/tableau
restartPolicy: Never
volumes:
  - name: logmount
    persistentVolumeClaim:
      claimName: logvolume

Erstellen Sie eine tar-Datei der Protokolle innerhalb des Containers:

kubectl exec -it <backgrounder-pod-name> -- bash -c "tar -czf /backgrounder-pod-logs.tar.gz /var/log/tableau"

Kopieren Sie die tar-Datei nach außerhalb des Containers:

kubectl cp <backgrounder-pod-name>:/backgrounder-pod-logs.tar.gz ./backgrounder-pod-logs.tar.gz

Konfigurationsänderungen im laufenden Betrieb

Wenn Sie an einem in einem Container laufenden Tableau Server Konfigurationsänderungen vornehmen (z. B. über die tsm-Befehlszeile) und möchten, dass diese Konfigurationsänderungen in Hintergrundprozesskomponenten-Pods vorhanden sein sollen, müssen Sie den Befehl tsm settings clone ausführen, um einen neuen Satz von Klonkonfigurationsdateien ("Clone-Nutzlast") zu erstellen.

1. Verwenden Sie TSM, um Konfigurationsänderungen in dem "Tableau Server in einem Container"-Pod vorzunehmen und diese dann auf den Server anzuwenden.

2. Führen Sie den folgenden Befehl in dem "Tableau Server in einem Container"-Pod aus:

   ## Run this command in the Tableau Server in a Container pod.
   tsm settings clone -d $CLONE_ARTIFACT_DIR

   Dieser Befehl erstellt einen neuen Satz von Konfigurationsdateien und schreibt ihn an den Speicherort "Clone-NFS-Laufwerk".

3. Stellen Sie Ihre Hintergrundprozesskomponenten-Pods wieder bereit. Die Pods sollten für die Verwendung des Clone-NFS-Laufwerks konfiguriert werden, wo sie die neue Konfiguration einlesen sollen.

Skalierungsstrategien

Hintergrundprozesskomponenten-Pods können in Kubernetes mithilfe eine Vielzahl von Techniken und Strategien skaliert werden. Wie zeigen ein Beispiel für eine Skalierungsstrategie, die die Größe des Hintergrundprozesskomponenten-Pod-Pools anhand eines Zeitplans ändert.

Beachten Sie, dass die Auslastung von CPU und RAM keine guten Metriken für das Skalieren von Hintergrundprozesskomponenten-Pods sind. Die CPU- und RAM-Auslastung spiegelt nicht exakt den gesamten Lastbedarf in einem Cluster wieder. So kann zum Beispiel ein Hintergrundprozesskomponenten-Pod beim Aktualisieren eines Extraktes bei maximaler Auslastung liegen, während es jedoch in der Warteschlange für Hintergrundprozesskomponenten-Aufträge keine weiteren Aufträge gibt, die warten. In diesem Fall würde eine automatische Skalierung den Durchsatz bei Aufträgen nicht verbessern.

Geplante Skalierung

Standardmäßige Kubernetes-Mechanismen, die Cron-Aufträge verwenden, ermöglichen Ihnen das Planen einer Skalierungslösung.

Eine Kubernetes-Beispielkonfiguration dafür wird nachfolgend in dem Abschnitt "Kubernetes-Konfiguration" gezeigt.

Kubernetes-Konfiguration

Neue Umgebungsvariablen

Zusätzlich zu den standardmäßigen Umgebungsvariablen für Tableau Server-Container (siehe Optionen für die Erstkonfiguration) sind einige neue Umgebungsvariablen erforderlich, die in der Kubernetes-Konfiguration festgelegt werden müssen.

Ports von Hintergrundprozesskomponenten-Pods

Hintergrundprozesskomponenten-Pods bestehen aus vier Diensten, von denen jeder zur Ausführung an einem bestimmten Port eingestellt ist. Wenn Sie den Port ändern möchten, an den der Dienst innerhalb des Containers angebunden ist, müssen Sie den Schlüssel angeben, der zu der Portzuweisung des Dienstes gehört. Eine Konfiguration dieser Art sollte in den meisten Fällen nicht nötig sein, es sei denn, es gibt einen Sidecar-Container oder eine andere weitere Komponente, die dem Port hinzugefügt wirdshould not be necessary in most cases, unless there is a sidecar container or some other additional component that is being added to the pod and conflicts with a service's port.

Dataserver verwendet auch den Port 8300, was nicht umkonfiguriert werden kann.

Freigegebenes Netzwerkverzeichnis

Diese Bereitstellung von Tableau Server benötigt zwei Netzwerkfreigaben, um ordnungsgemäß zu funktionieren. Hinweis: In allen Tableau Server- und Hintergrundprozesskomponenten- oder Kubernetes-Konfigurationsvorlagen sind die folgenden Netzwerkverzeichnisse vorhanden:

• Dataengine-Verzeichnis (FILESTORE_MOUNT_PATH): Hintergrundprozesskomponenten-Pods benötigen das Feature "Externer Dateispeicher". Diese Netzwerkfreigabe enthält Extrakte und andere dateibasierte Artefakte, die zwischen Tableau Server und Hintergrundprozesskomponenten-Pods freigegeben werden.
• Clone-Verzeichnis (CLONE_ARTIFACT_DIR): Tableau Server schreibt statische Verbindungs- und Konfigurationsinformationen in eine Netzwerkfreigabe. Hintergrundprozesskomponenten-Pods werden diese Informationen verwenden, um in dem Tableau Server-Cluster Mitglied zu werden. In künftigen Vorabversionen wird diese Konfiguration im Standardlebenszyklus der Kubernetes-Konfiguration enthalten sein.

Wichtig: Wenn Sie den Cluster komplett neu erstellen möchten (inklusive einem Tableau Server-Container), müssen Sie die Inhalte der Clone-NFS-Anbindung bereinigen (andernfalls werden Hintergrundprozesskomponenten-Pods versuchen, sich an den alten Server anzubinden).

Kubernetes-Konfigurationsbeispiele

Hinweis: Die Konfigurationsbeispiele umfassen die Verwendung einer Bereitschaftsprüfung. Sie können den Bereitschaftstest verwenden, wenn es sich bei Ihrer Tableau Server-Container-Bereitstellung um eine TSM-Bereitstellung mit einem Knoten handelt (die Bereitstellung kann mehrere Backgrounder-Pods umfassen). Sie können keine Bereitschaftsprüfung mit Tableau Server mit mehreren Knoten in Containerbereitstellungen verwenden.

Konfiguration eines Tableau Server-Containers

---
apiVersion: v1
kind: Service
metadata:
  name: <service_name>
  namespace: <namespace>
spec:
  selector:
    app: <service_name>
  ports:
    - protocol: TCP
      port: 8080
      nodePort: <nodeport-number>
      name: http
    - protocol: TCP
      port: 8443
      nodePort: <nodeport-number>
      name: https
  type: NodePort
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: configfile
  namespace: <namespace>
data:
  config.json: |-
    {
      "configEntities": {
      "identityStore": {
        "_type": "identityStoreType",
        "type": "local"
      }
    },
    "configKeys" : {
      "tabadmincontroller.init.smart_defaults.enable" : "false",
      "wgserver.domain.ldap.starttls.enabled" : "false"
    },
    "daysLeftForMaintenanceExpiring" : 0
  }
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: extrepojsonfile
  namespace: <namespace>
data:
  config.json: |-
    {
      "flavor":"generic",
      "masterUsername":"<admin-name>",
      "masterPassword":"<password>",
      "host":"<hostname>",
      "port":5432,
      "prerequisiteCheckEnabled":false,
      "requireSsl":false
    }
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: datadir1
  namespace: <namespace>
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
    storage: 50Gi
---
# This is required for multi-node tableau server in container
apiVersion: v1
kind: PersistentVolume
metadata:
  name: bootstrapnfs
  namespace: <namespace>
spec:
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 1Gi
  nfs:
    server: <nfs-ip>
    path: <mount-path>
---
# This is required for multi-node tableau server in container
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: bootstrapnfs
  namespace: <namespace>
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  resources:
    requests:
      storage: 1Mi
---
apiVersion: v1
kind: PersistentVolumn
metadata:
  name: clonenfs
  namespace: <namespace>
spec:
  accessModes:
    - ReadWriteMany
capacity:
  storage: 1Gi
nfs:
  server: <nfs-ip>
  path: <mount-path>
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: clonenfs
  namespace: <namespace>
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  resources:
    requests:
      storage: 1Mi
---
apiVersion: v1
kind: PersistentVolume
metadata:
    name: dataenginenfs
    namespace: <namespace>
spec:
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 1Gi
  nfs:
    server: <nfs-ip>
    path: <namespace>
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dataenginenfs
  namespace: <namespace>
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  resources:
    requests:
      storage: 1Mi
---
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: tableau-server-in-a-container-secrets
  namespace: <namespace>
stringData:
  license_key: <license_key> # Tableau License Key String
  tableau_username: <tableau_username> # Initial admin username in Tableau Server
  tableau_password: <tableau_password> # Initial admin password
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: tableau-server
  namespace: <namespace>
  labels:
    app: <service_name>
spec:
  selector:
    matchLabels:
      app: <service_name>
  replicas: 1
  serviceName: <service_name>
  template:
    metadata:
      labels:
        app: <service_name>
    spec:
      securityContext:
        runAsUser: 999
        fsGroup: 998
        fsGroupChangePolicy: "OnRootMismatch"
      terminationGracePeriodSeconds: 120
      dnsPolicy: "None"
      dnsConfig:
        nameservers:
          - <dns_ip> # DNS IP for resolving container hostnames
        searches:
          - <service_name>.<namespace>.svc.<cluster_domain>.<example> # SRV Record
          - <namespace>.svc.<cluster_domain>.<example> # SRV Record
          - svc.<cluster_domain>.<example> # SRV Record
          - <cluster_domain>.<example> # SRV Record
        options:
          - name: ndots
            value: "5"
      initContainers: # init containers are optional, to clear directory content if already exists
        - name: clean-bootstrap-dir
          image: busybox:1.28
          securityContext:
            runAsUser: 0
            allowPrivilegeEscalation: true
          volumeMounts:
          - name: bootstrap
            mountPath: /docker/config/bootstrap
          command: ['sh', '-c', 'rm -rf /docker/config/bootstrap/* || true']
        - name: clean-clone-artifacts-dir
          image: busybox:1.28
          securityContext:
            runAsUser: 0
            allowPrivilegeEscalation: true
          volumeMounts:
          - name: clone
            mountPath: /docker/clone
          command: ['sh', '-c', 'rm -rf /docker/clone/clone-artifacts || true']
      containers:
      - name: <container_name> # Name of container
        image: <tableau_server_image> # Tableau Server in Container Image
        env:
        - name: LICENSE_KEY
          valueFrom:
            secretKeyRef:
              name: tableau-server-in-a-container-secrets
              key: license_key
        - name: FILESTORE_MOUNT_PATH
          value: /docker/dataengine
        - name: CLONE_ARTIFACT_DIR_FOR_INDEPENDENT_CONTAINERS
          value: /docker/clone/clone-artifacts
        - name: SERVER_FOR_INDEPENDENT_SERVICE_CONTAINERS
          value: "1"
        - name: EXT_REP_JSON_FILE
          value: /docker/external-repository/config.json
        - name: TABLEAU_USERNAME
          valueFrom:
            secretKeyRef:
              name: tableau-server-in-a-container-secrets
              key: tableau_username
        - name: TABLEAU_PASSWORD
          valueFrom:
            secretKeyRef:
              name: tableau-server-in-a-container-secrets
              key: tableau_password
        resources:
          requests:
            memory: 40Gi
            cpu: 15
          limits:
            memory: 40Gi
            cpu: 15
        ports:
        - containerPort: 8080
        volumeMounts:
        - name: configmount
          mountPath: /docker/config/config.json
          subPath: config.json
        - name: externalrepomount
          mountPath: /docker/external-repository
        - name: datadir1
          mountPath: /var/opt/tableau
        - name: bootstrap
          mountPath: /docker/config/bootstrap
        - name: clone
          mountPath: /docker/clone
        - name: dataengine
          mountPath: /docker/dataengine
        imagePullPolicy: IfNotPresent
        startupProbe:
          exec:
            command:
            - /bin/sh
            - -c
            - /docker/server-ready-check
          initialDelaySeconds: 300
          periodSeconds: 15
          timeoutSeconds: 30
          failureThreshold: 200
        readinessProbe:
          exec:
            command:
            - /bin/sh
            - -c
            - /docker/server-ready-check
          periodSeconds: 30
          timeoutSeconds: 60
        livenessProbe:
          exec:
            command:
            - /bin/sh
            - -c
            - /docker/alive-check
          initialDelaySeconds: 600
          periodSeconds: 60
          timeoutSeconds: 60
      volumes:
      - name: configmount
        configMap:
          name: configfile
      - name: externalrepomount
        configMap:
          name: extrepojsonfile
      - name: datadir1
        persistentVolumeClaim:
          claimName: datadir1
      - name: bootstrap
        persistentVolumeClaim:
          claimName: bootstrapnfs
      - name: clone
        persistentVolumeClaim:
          claimName: clonenfs
      - name: dataengine
        persistentVolumeClaim:
          claimName: dataenginenfs

Konfiguration eines Hintergrundprozesskomponenten-Pods

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: logvolume
  namespace: <namespace>
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backgrounder
  labels:
    app: backgrounder
  namespace: <namespace> 
spec:
  replicas: 2
  selector:
    matchLabels:
      app: backgrounder
  template:
    metadata:
      labels:
        app: backgrounder
    spec:
      securityContext:
        runAsUser: 999
        runAsGroup: 998
        fsGroup: 998
        fsGroupChangePolicy: "OnRootMismatch"
      hostname: backgrounder
      dnsPolicy: "None"
      dnsConfig:
        nameservers:
          - <dns_ip> # DNS IP for resolving container hostnames
        searches:
          - <service_name>.<namespace>.svc.<cluster_domain>.<example> # SRV Record
          - <namespace>.svc.<cluster_domain>.<example> # SRV Record
          - svc.<cluster_domain>.<example> # SRV Record
          - <cluster_domain>.<example> # SRV Record
        options:
          - name: ndots
            value: "5"
      initContainers:
        - name: init-myservice
          image: busybox # This init-container is optional (as long as there is a mechanism to set the log volume directory permissions and the pod waits for clone artifacts)
          securityContext:
            runAsUser: 0
            allowPrivilegeEscalation: true
          env:
            - name: CLONE_ARTIFACT_DIR_FOR_INDEPENDENT_CONTAINERS
            value: /docker/clone/clone-artifacts
          volumeMounts:
          - name: logmount
            mountPath: /var/log/tableau
          - name: clone-volume
            mountPath: /docker/clone
          command: ['sh', '-c', "chmod 777 /var/log/tableau && while [ ! -d ${CLONE_ARTIFACT_DIR_FOR_INDEPENDENT_CONTAINERS} ]; do sleep 5; done"]
      containers:
      - name: backgrounder
        image: <backgrounder_image> # Backgrounder Image
        ports:
        - containerPort: 8600
        imagePullPolicy: IfNotPresent
        readinessProbe:
          exec:
            command:
              - /bin/sh
              - -c
              - /tsm_docker_utils/status_check.sh | grep -E 'ACTIVE|BUSY'
          periodSeconds: 30
          timeoutSeconds: 60
        livenessProbe:
          exec:
            command:
              - /bin/sh
              - -c
              - /tsm_docker_utils/status_check.sh | grep -E 'ACTIVE|BUSY'
          initialDelaySeconds: 600
          periodSeconds: 60
          timeoutSeconds: 60
        volumeMounts:
        - name: logmount
          mountPath: /var/log/tableau
        - name: clone-volume
          mountPath: /docker/clone
        - name: dataengine-volume
          mountPath: /docker/dataengine
        - name: temp
          mountPath: /var/opt/tableau/tableau_server/data/tabsvc/temp
        env:
          - name: ROOT_LOG_DIR
            value: /var/log/tableau
          - name: CLONE_ARTIFACT_DIR_FOR_INDEPENDENT_CONTAINERS
            value: /docker/clone/clone-artifacts
          - name: FILESTORE_MOUNT_PATH
            value: /docker/dataengine
      - name: dataserver
        image: <dataserver_image> # Dataserver Image
        ports:
        - containerPort: 8400
        imagePullPolicy: IfNotPresent
        readinessProbe:
          exec:
            command:
              - /bin/sh
              - -c
              - /tsm_docker_utils/status_check.sh | grep -E 'ACTIVE|BUSY'
          periodSeconds: 30
          timeoutSeconds: 60
        livenessProbe:
          exec:
            command:
              - /bin/sh
              - -c
              - /tsm_docker_utils/status_check.sh | grep -E 'ACTIVE|BUSY'
          initialDelaySeconds: 600
          periodSeconds: 60
          timeoutSeconds: 60
        volumeMounts:
        - name: logmount
          mountPath: /var/log/tableau
        - name: clone-volume
          mountPath: /docker/clone
        - name: dataengine-volume
          mountPath: /docker/dataengine
        - name: temp
          mountPath: /var/opt/tableau/tableau_server/data/tabsvc/temp
        env:
          - name: ROOT_LOG_DIR
            value: /var/log/tableau
          - name: CLONE_ARTIFACT_DIR_FOR_INDEPENDENT_CONTAINERS
            value: /docker/clone/clone-artifacts
          - name: FILESTORE_MOUNT_PATH
            value: /docker/dataengine
      - name: gateway
        image: <gateway_image> # Gateway Image
        ports:
        - containerPort: 8080
        imagePullPolicy: IfNotPresent
        readinessProbe:
          exec:
            command:
              - /bin/sh
              - -c
              - /tsm_docker_utils/status_check.sh | grep -E 'ACTIVE|BUSY'
          periodSeconds: 30
          timeoutSeconds: 60
        livenessProbe:
          exec:
            command:
              - /bin/sh
              - -c
              - /tsm_docker_utils/status_check.sh | grep -E 'ACTIVE|BUSY'
          initialDelaySeconds: 600
          periodSeconds: 60
          timeoutSeconds: 60
        volumeMounts:
        - name: logmount
          mountPath: /var/log/tableau
        - name: clone-volume
          mountPath: /docker/clone
        - name: dataengine-volume
          mountPath: /docker/dataengine
        - name: temp
          mountPath: /var/opt/tableau/tableau_server/data/tabsvc/temp
        env:
          - name: ROOT_LOG_DIR
            value: /var/log/tableau
          - name: CLONE_ARTIFACT_DIR_FOR_INDEPENDENT_CONTAINERS
            value: /docker/clone/clone-artifacts
          - name: FILESTORE_MOUNT_PATH
            value: /docker/dataengine
    - name: hyper
      image: <hyper_image> # Hyper Image
      ports:
      - containerPort: 8200
      imagePullPolicy: IfNotPresent
      readinessProbe:
        exec:
          command:
            - /bin/sh
            - -c
            - /tsm_docker_utils/status_check.sh | grep -E 'ACTIVE|BUSY'
        periodSeconds: 30
        timeoutSeconds: 60
      livenessProbe:
        exec:
          command:
          - /bin/sh
          - -c
          - /tsm_docker_utils/status_check.sh | grep -E 'ACTIVE|BUSY'
        initialDelaySeconds: 600
        periodSeconds: 60
        timeoutSeconds: 60
      volumeMounts:
        - name: logmount
          mountPath: /var/log/tableau
        - name: clone-volume
          mountPath: /docker/clone
        - name: dataengine-volume
          mountPath: /docker/dataengine
        - name: temp
          mountPath: /var/opt/tableau/tableau_server/data/tabsvc/temp
      env:
        - name: ROOT_LOG_DIR
          value: /var/log/tableau
        - name: CLONE_ARTIFACT_DIR_FOR_INDEPENDENT_CONTAINERS
          value: /docker/clone/clone-artifacts
        - name: FILESTORE_MOUNT_PATH
          value: /docker/dataengine
    volumes:
      - name: clone-volume
        nfs:
          server: <nfs_ip> 
          path: <mount_path>
      - name: dataengine-volume
        nfs:
          server: <nfs_ip> 
          path: /dataengine
      - name: logmount
        persistentVolumeClaim:
          claimName: logvolume
      - name: temp
        emptyDir: {}

Konfiguration von geplanter Skalierung

apiVersion: v1
kind: ServiceAccount
metadata:
name: backgrounder-scaler-service-account
namespace: <namespace> # Namespace
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: scale-backgrounder-pods
namespace: <namespace> # Namespace
subjects:
- kind: ServiceAccount
name: backgrounder-scaler-service-account
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
---
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: scale-up-job
namespace: <namespace> # Namespace
spec:
schedule: "0 7 * * *" # Cron Job timing to scale up deployment replicas
jobTemplate:
spec:
template:
spec:
serviceAccountName: backgrounder-scaler-service-account
restartPolicy: OnFailure
containers:
- name: scale
image: bitnami/kubectl:1.21
imagePullPolicy: IfNotPresent
args:
- scale
- --replicas=4
- deployment/backgrounder
---
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: scale-down-job
namespace: <namespace>
spec:
schedule: "0 9 * * *" # Cron Job timing to scale down deployment replicas
jobTemplate:
spec:
template:
spec:
serviceAccountName: backgrounder-scaler-service-account
restartPolicy: OnFailure
containers:
- name: scale
image: bitnami/kubectl:1.21
imagePullPolicy: IfNotPresent
args:
- scale
- --replicas=2
- deployment/backgrounder

Kubernetes-Auftrag zum Bereinigen der Klon-Konfiguration (Optional)

Das ist ein praktischer Kubernetes-Auftrag, den Sie vielleicht beim Testen verwenden werden. Wenn Sie die Klonkonfiguration, die von Tableau Server in einem Container stammt, zwischen einzelnen Bereitstellungsdurchgängen löschen möchten, können Sie einen Auftrag wie diesen ausführen, um das NFS zu bereinigen.

apiVersion: batch/v1
kind: Job
metadata:
name: delete-clone-artifacts-job
namespace: manatee-cluster
spec:
template:
spec:
containers:
- name: delete-clone-artifacts
image: busybox:1.28
command: ['sh', '-c', "rm -rf ${CLONE_ARTIFACT_DIR}"]
env:
- name: CLONE_ARTIFACT_DIR
value: /docker/clone/clone-artifacts
securityContext:
runAsUser: 0
allowPrivilegeEscalation: true
volumeMounts:
- name: clone-volume
mountPath: /docker/clone
restartPolicy: Never
volumes:
- name: clone-volume
nfs:
server: <nfs_ip> # IP for shared NFS directory for clone output
path: /clone