--- schema_version: "1" id: 009d6c70dde8100a2ed42708bd30e3ff8f5b4b83adec5c5debbba574af3e1cfb title: Dynamische Skalierung in einem Container – Tableau Server-Hintergrundprozesskomponenten collection: tableau version: current locale: de-de portal_url: https://docs.salesforce.com/tableau/current/de-de/server-linux/server-backgrounder-autoscaling.md canonical_url: https://help.tableau.com/current/server-linux/de-de/server-backgrounder-autoscaling.htm source_site: help.tableau.com content_type: documentation content_hash: 0bd4329d4832c057cdd6d844921083389ac580d4c6976f34b369e01cc6bac9aa description: Configure dynamic scaling of Backgrounders for Tableau Server in a container. --- [Zum Hauptinhalt springen](#main-content) # Dynamische Skalierung in einem Container – Tableau Server-Hintergrundprozesskomponenten ## 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](https://help.tableau.com/current/server-linux/de-de/server-in-container.htm). ## 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](https://help.tableau.com/current/server-linux/de-de/itm_intro.htm). - 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](https://help.tableau.com/current/server-linux/de-de/license_product_keys.htm). - Die folgenden Features von Advanced Management müssen aktiviert sein: - [Externer Tableau Server-Dateispeicher](https://help.tableau.com/current/server-linux/de-de/server_external_filestore_storage.htm) - [Externes Repository von Tableau Server](https://help.tableau.com/current/server-linux/de-de/server_external_repo.htm) - 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 --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](https://help.tableau.com/current/server-linux/de-de/server-in-container_setup-tool.htm#CustomizingImage). 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](https://help.tableau.com/current/server-linux/de-de/server-in-container.htm). 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 ### 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](https://help.tableau.com/current/server-linux/de-de/server_backgrounder_job_management.htm). 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 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 -- 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 :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: 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 -- 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-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](https://help.tableau.com/current/server-linux/de-de/cli_settings_tsm.htm#TSMSettingsClone)` 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](https://help.tableau.com/current/server-linux/de-de/server-in-container_image.htm#InitialConfigOptions-container)) sind einige neue Umgebungsvariablen erforderlich, die in der Kubernetes-Konfiguration festgelegt werden müssen.
UmgebungsvariableEmpfohlener WertBeschreibung
FILESTORE_MOUNT_PATH/docker/dataengineDer Speicherort des Verzeichnisses für den externen Dateispeicher. Dieses Verzeichnis sollte auf das NFS-Verzeichnis "dataengine" zeigen, das in jedem bereitgestellten Tableau-Container eingebunden ist. Weitere Informationen über den externen Dateispeicher finden Sie unter Externer Tableau Server-Dateispeicher. Der Wert sollte für den "Tableau Server in einem Container"-Pod und den Hintergrundprozesskomponenten-Pod gleich sein.
CLONE_ARTIFACT_DIR/docker/clone/clone-artifactsDer Speicherort, an dem das Verzeichnis für die Klon-Konfiguration eingebunden ist. Dieses Verzeichnis sollte auf ein NFS-Verzeichnis zeigen, das in jedem bereitgestellten Tableau-Container eingebunden ist. Tableau Server wird Konfigurationsdaten ausgeben, die Hintergrundprozesskomponenten-Pods verwenden, um Mitglied des Clusters zu werden.
ROOT_LOG_DIR/var/log/tableau(Nur Hintergrundprozesskomponenten-Pods)

Gemeinsamer Speicherort für das Protokollverzeichnis für alle Dienste, die in einem Hintergrundprozesskomponenten-Pods ausgeführt werden.

### 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. | Port-Umgebungsvariable | Standard | | --- | --- | | `BACKGROUNDER_PORT` | `8600` | | `DATASERVER_PORT` | `8400` | | `HYPER_PORT` | `8200` | | `GATEWAY_PORT` | `8080` | 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: namespace: spec: selector: app: ports: - protocol: TCP port: 8080 nodePort: name: http - protocol: TCP port: 8443 nodePort: name: https type: NodePort \--- apiVersion: v1 kind: ConfigMap metadata: name: configfile 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: data: config.json: |- { "flavor":"generic", "masterUsername":"", "masterPassword":"", "host":"", "port":5432, "prerequisiteCheckEnabled":false, "requireSsl":false } \--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: datadir1 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: spec: accessModes: - ReadWriteMany capacity: storage: 1Gi nfs: server: path: \--- \# This is required for multi-node tableau server in container apiVersion: v1 kind: PersistentVolumeClaim metadata: name: bootstrapnfs namespace: spec: accessModes: - ReadWriteMany storageClassName: "" resources: requests: storage: 1Mi \--- apiVersion: v1 kind: PersistentVolumn metadata: name: clonenfs namespace: spec: accessModes: - ReadWriteMany capacity: storage: 1Gi nfs: server: path: \--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: clonenfs namespace: spec: accessModes: - ReadWriteMany storageClassName: "" resources: requests: storage: 1Mi \--- apiVersion: v1 kind: PersistentVolume metadata: name: dataenginenfs namespace: spec: accessModes: - ReadWriteMany capacity: storage: 1Gi nfs: server: path: \--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: dataenginenfs namespace: spec: accessModes: - ReadWriteMany storageClassName: "" resources: requests: storage: 1Mi \--- apiVersion: v1 kind: Secret type: Opaque metadata: name: tableau-server-in-a-container-secrets namespace: stringData: license\_key: # Tableau License Key String tableau\_username: # Initial admin username in Tableau Server tableau\_password: # Initial admin password \--- apiVersion: apps/v1 kind: StatefulSet metadata: name: tableau-server namespace: labels: app: spec: selector: matchLabels: app: replicas: 1 serviceName: template: metadata: labels: app: spec: securityContext: runAsUser: 999 fsGroup: 998 fsGroupChangePolicy: "OnRootMismatch" terminationGracePeriodSeconds: 120 dnsPolicy: "None" dnsConfig: nameservers: - # DNS IP for resolving container hostnames searches: - ..svc.. # SRV Record - .svc.. # SRV Record - svc.. # SRV Record - . # 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: # Name of container 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: spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi \--- apiVersion: apps/v1 kind: Deployment metadata: name: backgrounder labels: app: backgrounder 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 for resolving container hostnames searches: - ..svc.. # SRV Record - .svc.. # SRV Record - svc.. # SRV Record - . # 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 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 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 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 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: path: - name: dataengine-volume nfs: server: 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 \--- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: scale-backgrounder-pods 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 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: 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: # IP for shared NFS directory for clone output path: /clone