--- schema_version: "1" id: 97cc26422883a2bf786e8e709a173c09e82ba580f8b91446c42c5ea35750cd53 title: Dynamisch schalen in een container - Tableau Server Backgrounders collection: tableau version: next locale: nl-nl portal_url: https://docs.salesforce.com/tableau/next/nl-nl/server-linux/server-backgrounder-autoscaling.md canonical_url: https://help.tableau.com/v0.0/server-linux/nl-nl/server-backgrounder-autoscaling.htm source_site: help.tableau.com content_type: documentation content_hash: eac5d047fed89469f170c725591cbfd339cbdfcf4cf8697efd0af4d96ce7c7d3 description: Configure dynamic scaling of Backgrounders for Tableau Server in a container. --- [Doorgaan naar hoofdinhoud](#main-content) # Dynamisch schalen in een container - Tableau Server Backgrounders ## Inleiding Dankzij de dynamische schaalbaarheid van Backgrounder in een container kunnen verschillende schaalstrategieën worden toegepast op backgrounder en geplande jobs in Tableau Server. In deze context betekent automatisch schalen dat services onafhankelijk van elkaar kunnen worden geschaald om variabele taakbelastingen te verwerken, zonder dat menselijke tussenkomst nodig is of de inzetbaarheid van andere serversystemen wordt beïnvloed. De Tableau Server-containers die volledige knooppunten van Tableau Server-processen bevatten, blijven als monolithische systemen draaien. In plaats daarvan wordt een kleinere set van losgekoppelde, onafhankelijke containerservices gebruikt die de backgrounder-servicerol vormen. Deze servicerol is dynamisch schaalbaar en verwerkt de rekenlast die normaal gesproken door Tableau Server-containers wordt afgehandeld. Backgrounder-services zijn verantwoordelijk voor het verwerken van systeemtaken, zoals het vernieuwen/maken van extracten, het verzenden van abonnementen, het controleren van datameldingen en vele onderhoudstaken. Als het bijvoorbeeld handig is om een groot aantal datasets te vernieuwen of een groot aantal rekenintensieve datameldingen te berekenen, kunt u nu Kubernetes gebruiken om de rekenkracht op te schalen en deze taken efficiënt uit te voeren. Deze gids behandelt de configuratie- en implementatievereisten voor het automatisch schalen van Backgrounders in Kubernetes. Dit document is een aanvulling op de documentatie [Tableau Server in een container](https://help.tableau.com/v0.0/server-linux/nl-nl/server-in-container.htm). ## Vereisten Automatisch schalen van Backgrounders is alleen beschikbaar in Kubernetes en is gebaseerd op Tableau Server in containers. Om de functie voor automatisch schalen van backgrounders te kunnen gebruiken, moet u aan bepaalde voorwaarden voldoen: - Tableau Server moet Advanced Management-mogelijkheden hebben. Zie [Over Tableau Advanced Management in Tableau Server](https://help.tableau.com/v0.0/server-linux/nl-nl/itm_intro.htm) voor meer informatie. - U moet gebruikmaken van rolgebaseerde licentiëring. Kernlicenties worden niet ondersteund. Zie [Inzicht in licentiemodellen en productcodes](https://help.tableau.com/v0.0/server-linux/nl-nl/license_product_keys.htm) voor details over licentieverlening. - De volgende Advanced Management-functies moeten zijn ingeschakeld: - [Extern bestandsarchief Tableau Server](https://help.tableau.com/v0.0/server-linux/nl-nl/server_external_filestore_storage.htm) - [Externe opslagplaats Tableau Server](https://help.tableau.com/v0.0/server-linux/nl-nl/server_external_repo.htm) - U moet over een Kubernetes-clusterversie 1.20 of hoger beschikken en weten hoe u deze kunt gebruiken en beheren. ## Beperkingen - Deze functie werkt alleen als onderdeel van een op Linux gebaseerde implementatie. - Flow-jobs worden niet ondersteund op de backgrounders met automatisch schalen. Flow-jobs worden afgehandeld door de backgrounder-services die in de Tableau Server-container blijven draaien. ## Tableau Server- en Backgrounder Pod-afbeeldingen maken De eerste stap voor het gebruik van backgrounders met automatisch schalen in containers is het maken van de service-afbeeldingen die deel uitmaken van de Tableau Server-installatie. Deze afbeeldingen bevatten de Tableau Server-afbeelding, evenals afbeeldingen voor de afzonderlijke backgrounder en ondersteunende services. U gebruikt dezelfde opbouwtool die wordt gebruikt om de uitgebreide alles-in-één Tableau Server-containerafbeelding te maken, maar de tool moet versie 2022.3.0 of hoger zijn, u moet een Advanced Management-licentie hebben en u moet een speciale vlag gebruiken bij het bouwen van de afbeeldingen. 1. Voer deze opdracht uit om de service-afbeeldingen te maken: build-image --accepteula -i --backgrounder-images Hiermee worden de Tableau Server en vier nieuwe afbeeldingen gemaakt. Deze extra afbeeldingen bevatten afzonderlijke services die deel uitmaken van de nieuwe automatisch schaalbare backgrounder-pod. Met de opdracht `docker images` worden de afbeeldingen weergegeven die in de lokale docker-opslagplaats zijn gemaakt: 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 De hyper-, gateway-, backgrounder- en dataserver-afbeeldingen vormen de nieuwe Backgrounder-pod. Aangepaste drivers, installatiescripts en eigenschappen worden gedeeld tussen deze vijf afbeeldingen. Zie [De afbeelding aanpassen](https://help.tableau.com/v0.0/server-linux/nl-nl/server-in-container_setup-tool.htm#CustomizingImage) voor meer informatie. 2. Publiceer al deze afbeeldingen in uw interne afbeeldingsopslagplaats voor implementatie. ## Implementatiegids De volgende informatie biedt context voor het implementeren van Tableau Server in een container en met automatisch schalen van Backgrounders. In deze informatie wordt ervan uitgegaan dat u Tableau Server al begrijpt en weet hoe u deze in een zelfstandige container kunt implementeren. Zie [Tableau Server in een container](https://help.tableau.com/v0.0/server-linux/nl-nl/server-in-container.htm) voor meer informatie. De drie Kubernetes-configuratiebestanden in de sectie Kubernetes-configuratie zijn sjablonen die kunnen worden gebruikt om de implementatie in te stellen. In de andere secties van deze gids worden de vereisten en details van de implementatie behandeld. De implementatie van Tableau Server en het automatisch schalen van Backgrounders zou net zo eenvoudig moeten zijn als het implementeren van de ingevulde Kubernetes-configuratiebestanden onderaan de gids: kubectl apply -f ### Backgrounder-jobs Backgrounder-pods helpen de Tableau Server in een container om aanvullende geplande workloads parallel te berekenen. Backgrounder verwerkt workloads voor extractvernieuwingen, abonnementen, meldingen, flows en systemen. Door jobs te verdelen over backgrounder-pods zijn er meer rekenbronnen beschikbaar voor Tableau Server om andere taken uit te voeren, zoals interactieve gebruikersactiviteiten als de rendering van werkmappen en dashboards. Flow-jobs zijn het enige type backgrounder-job dat niet in de backgrounder wordt uitgevoerd. Zie [Achtergrondjobs beheren in Tableau Server](https://help.tableau.com/v0.0/server-linux/nl-nl/server_backgrounder_job_management.htm) voor details over Backgrounder-jobs. Backgrounder-pods kunnen elk type belasting verwerken, met uitzondering van flow-jobs. Deze moeten worden uitgevoerd in de hoofdcontainers van Tableau Server die de backgrounder-service blijven uitvoeren. Met de functie Knooppuntrollen hebben gebruikers de flexibiliteit om backgrounder-pods toe te wijzen aan specifieke soorten jobs. Deze functie is een uitbreiding van de Knooppuntrollen-functie op Tableau Server. Een gedetailleerde beschrijving van de verschillende knooppuntrollen vindt u hier. Opmerking: Standaard zijn flow-jobs uitgeschakeld op de backgrounder-pods (de rol is ingesteld op 'geen flows'), omdat de backgrounder-pods geen flow-jobs kunnen uitvoeren. Om knooppuntrollen voor backgrounder in te stellen, moet u de omgevingsvariabele `NODE_ROLES` instellen als onderdeel van kubeconfig voor de container die de backgrounder-service uitvoert. Om backgrounder bijvoorbeeld zo in te stellen dat alleen extractvernieuwing-jobs worden uitgevoerd, stelt u de omgevingsvariabele `NODE_ROLES` in voor extractvernieuwingen zoals hieronder weergegeven: #### NODE\_ROL\_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 De Tableau Server-pods hebben minimaal één backgrounder geconfigureerd in de topologie. Dit is nodig om ervoor te zorgen dat er altijd een plek is om backgrounder-jobs uit te voeren. Standaard vereist TSM dat er een backgrounder moet zijn die elke rol van de backgrounder-job kan afhandelen. In sommige scenario's wilt u wellicht dat backgrounder-pods alle jobs van een bepaald type afhandelen. Hiervoor moet u de Server-configuratiesleutel `topology.roles_handle_all_jobs_constraint_disabled` instellen op `true`, waarmee de vereiste wordt uitgeschakeld dat de TSM-topologie alle jobtypen moet verwerken. Met deze parameter ingesteld, kan de backgrounder-rol voor de Tableau Server-backgrounder worden ingesteld op `no-extract-refreshes` en de rol voor de backgrounder-pods op `extract-refreshes`, wat ervoor zorgt dat alle extractvernieuwing-jobs alleen op de backgrounder-pods worden uitgevoerd. **Opmerking:** Als u deze beperking uitschakelt, kunt u rollen zo configureren dat bepaalde jobtypen nooit worden gepland. De rolconfiguratie van TSM-backgrounders en backgrounder-jobs moet zorgvuldig worden ingesteld, omdat TSM niet langer controleert of alle backgrounder-jobtypen kunnen worden gepland. ### Tableau Server in een container-pods De containers met Tableau Server als onderdeel van het automatisch schalen van backgrounder-pods worden op vrijwel dezelfde manier geïmplementeerd als onze bestaande Tableau Server in een container. Er zijn een paar belangrijke wijzigingen in de vereisten: - Een netwerkbestandsshare is _vereist_ om de configuratie over te dragen tussen de Tableau Server-container en de backgrounder-pods. - U moet de functie Extern bestandsarchief inschakelen en gebruiken. Hiervoor is ook een speciale netwerkbestandsshare nodig. ### Backgrounder-pods Backgrounder-pods bestaan uit vier onafhankelijke servicecontainers die samenwerken: **gateway**, **hyper**, **dataserver** en **backgrounder**. U kunt deze pods implementeren als typische onafhankelijke Kubernetes-container-pods. De pods hebben de volgende vereisten: - Backgrounder-pods moeten het Tableau Server-knooppunt kunnen bereiken met behulp van DNS-resolutie van de hostnaam. - Er moeten Extern bestandsarchief- en Kloon-netwerkbestandsshares worden aangeboden. **Opmerking:** Backgrounder-pods worden geconfigureerd met een eerste container om te wachten tot de Tableau Server-container met succes kloonconfiguratie-uitvoer heeft geproduceerd voordat ze doorgaan met de uitvoering. #### Logboeken Backgrounder-podservices (zoals Tableau Server) schrijven logboeken nog steeds voornamelijk naar de schijf. Omdat de backgrounder-pods in- en uitgeschaald kunnen worden, zijn ze tijdelijk. Daarom is het belangrijk om ervoor te zorgen dat de logboeken niet buiten de pods worden opgeslagen. Veel klanten met bestaande K8s-omgevingen maken al gebruik van een logboek-aggregatieservice om de logboeken te verzamelen van de pods die ze implementeren. Voorbeelden van logboek-aggregatieservices zijn Splunk en Fluentd. Wij raden klanten ten zeerste aan om een logboek-aggregatieservice te gebruiken om de logboeken van hun backgrounder-pods te verzamelen. Om het beheer van logboeken eenvoudiger te maken, configureert de door ons geleverde kubeconfig elke service in de pod om naar een gedeeld logboekvolume te schrijven. Het pad van de directory in elke servicecontainer wordt opgegeven door de omgevingsvariabele `ROOT_LOG_DIR`. Als u een ondersteuningscase moet openen en logboeken moet aanleveren, moet u twee sets logboeken aanleveren: ziplogs verzameld uit de hoofdcontainers van de Server en logboeken van de backgrounder-pods (opgehaald uit uw logboek-aggregatieservice of via het onderstaande handmatige proces). Voor klanten die geen logboek-aggregatieservice kunnen gebruiken, kunnen logboeken handmatig uit de pods worden opgehaald. **Opmerking:** Logboeken van pods die geen Persistent Volume Claim hebben gebruikt voor het volume met de logboeken, gaan verloren wanneer de schaal van de pod wordt verkleind! Alle relevante logboeken zijn beschikbaar in de directory `/var/log/tableau` (configureerbaar via de omgevingsvariabele `ROOT_LOG_DIR`) in de backgrounder-pod. Wij raden u ten zeerste aan om op deze locatie een PersistantVolumeClaim te koppelen, zodat de logboeken beschikbaar zijn wanneer de pod uitvalt. ##### Logboeken verzamelen wanneer de backgrounder-pod actief is: Maak een tar-bestand van de logboeken in de container: kubectl exec -it -- bash -c "tar -czf /docker/user/backgrounder-pod-logs.tar.gz /var/log/tableau" Kopieer het tar-bestand naar een locatie buiten de container: kubectl cp :docker/user/backgrounder-pod-logs.tar.gz ./backgrounder-pod-logs.tar.gz ##### Logboeken verzamelen wanneer de backgrounder-pod is afgesloten (of niet is gestart) Koppel elke langlopende pod met de PersistantVolumeClaim-koppeling die wordt gebruikt voor de implementatielogboeken van backgrounder-pods. Een voorbeeldconfiguratie: 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 Maak een tar-bestand van de logboeken in de container: kubectl exec -it -- bash -c "tar -czf /backgrounder-pod-logs.tar.gz /var/log/tableau" Kopieer het tar-bestand naar een locatie buiten de container: kubectl cp :/backgrounder-pod-logs.tar.gz ./backgrounder-pod-logs.tar.gz #### Live-configuratiewijzigingen Als u configuratiewijzigingen aanbrengt in Tableau Server in een container (bijvoorbeeld met behulp van de tsm-opdrachtregel) en u wilt dat deze configuratiewijzigingen worden weergegeven in Backgrounder-pods, moet u de opdracht `[tsm settings clone](https://help.tableau.com/v0.0/server-linux/nl-nl/cli_settings_tsm.htm#TSMSettingsClone)` uitvoeren om een nieuwe set kloon-configuratiebestanden ('kloon-payload') te produceren. 1. Gebruik TSM om configuratiewijzigingen aan te brengen in de Tableau Server in een container-pod en de configuratiewijzigingen toe te passen op de server. 2. Voer de volgende opdracht uit in de Tableau Server in een container-pod: \## Run this command in the Tableau Server in a Container pod. tsm settings clone -d $CLONE\_ARTIFACT\_DIR Met deze opdracht wordt een nieuwe set configuratiebestanden gemaakt en naar de locatie van de Kloon NFS-schijf geschreven. 3. Implementeer uw backgrounder-pods opnieuw. De pods moeten worden geconfigureerd voor gebruik van de Kloon NFS-schijf en zullen de nieuwe configuratie overnemen. ### Strategieën voor schalen Backgrounder-pods kunnen in Kubernetes worden geschaald met behulp van verschillende technieken en strategieën. We geven een voorbeeld van een strategie voor schalen waarmee de grootte van de Backgrounder-podpool wordt gewijzigd op basis van een tijdschema. Houd er rekening mee dat CPU- en geheugengebruik **geen** goede statistieken zijn voor het schalen van Backgrounder-pods. Het geheugen- en CPU-gebruik geven geen nauwkeurig beeld van de totale belastingvraag op het cluster. Een Backgrounder-pod kan bijvoorbeeld maximaal worden gebruikt om een extract te vernieuwen, maar er staan geen andere jobs in de wachtrij voor Backgrounder-jobs. In dit geval zou automatisch schalen de doorvoer van jobs niet verbeteren. #### Gepland schalen Met standaard Kubernetes-mechanismen die gebruikmaken van cron-jobs kunt u een schaalbare oplossing plannen. Een voorbeeld van een Kubernetes-configuratie hiervoor vindt u in de onderstaande sectie Kubernetes-configuratie. ## Kubernetes-configuratie ### Nieuwe omgevingsvariabelen Naast de standaard omgevingsvariabelen voor de Tableau Server-container (zie [Initiële configuratieopties](https://help.tableau.com/v0.0/server-linux/nl-nl/server-in-container_image.htm#InitialConfigOptions-container)), zijn er enkele nieuwe vereiste omgevingsvariabelen die moeten worden ingesteld in de Kubernetes-configuratie.
OmgevingsvariabeleAanbevolen waardeBeschrijving
FILESTORE_MOUNT_PATH/docker/dataengineKoppellocatie voor directory Extern bestandsarchief. Deze directory moet verwijzen naar de data engine NFS-directory die in elke geïmplementeerde Tableau-container is gekoppeld. Zie Extern bestandsarchief Tableau Server voor meer informatie over het externe bestandsarchief. De waarde moet hetzelfde zijn voor de Tableau Server in een container-pod en de Backgrounder-pod.
CLONE_ARTIFACT_DIR/docker/clone/clone-artifactsKoppellocatie voor directory kloonconfiguratie. Deze directory moet verwijzen naar een NFS-directory die in elke Tableau-container is gekoppeld. Tableau Server voert configuratiedata uit die Backgrounder-pods gebruiken om lid te worden van het cluster.
ROOT_LOG_DIR/var/log/tableau(Alleen Backgrounder-pods)

Algemene directory-locatie van logboeken voor alle services die in een backgrounder-pod worden uitgevoerd.

### Poorten Backgrounder-pod Backgrounder-pods bestaan uit vier services die standaard allemaal op een specifieke poort worden uitgevoerd. Als u de poort wilt wijzigen waaraan de service in de container wordt gekoppeld, moet u de sleutel opgeven die overeenkomt met de poorttoewijzing van de service. In de meeste gevallen is een dergelijke configuratie niet nodig, tenzij er een sidecar-container of een andere extra component aan de pod wordt toegevoegd die in conflict komt met de poort van een service. | Omgevingsvariabele poort | Standaard | | --- | --- | | `BACKGROUNDER_PORT` | `8600` | | `DATASERVER_PORT` | `8400` | | `HYPER_PORT` | `8200` | | `GATEWAY_PORT` | `8080` | Dataserver gebruikt ook poort 8300, die niet opnieuw kan worden geconfigureerd. ### Gedeelde netwerk-directory Voor deze implementatie van Tableau Server zijn twee netwerkshares nodig om goed te kunnen functioneren. Opmerking: In alle Tableau Server- en Backgrounder- of Kubernetes-configuratiesjablonen zijn de volgende netwerk-directory's aanwezig: - **Data Engine-directory** (`FILESTORE_MOUNT_PATH`): Backgrounder-pods vereisen de functie Extern bestandsarchief. Deze netwerkshare bevat extracten en andere op bestanden gebaseerde artefacten die worden gedeeld tussen Tableau Server en Backgrounder-pods. - **Kloon-directory** (`CLONE_ARTIFACT_DIR`): Tableau Server schrijft statische verbindings- en configuratiegegevens naar een netwerkshare. Backgrounder-pods gebruiken deze informatie om lid te worden van het Tableau Server-cluster. In toekomstige pre-releases wordt deze configuratie opgenomen in de standaardlevenscyclus van de Kubernetes-configuratie. **Belangrijk:** Als u het cluster volledig opnieuw wilt implementeren (inclusief een nieuwe Tableau Server-container), moet u de inhoud van de Kloon NFS-koppeling wissen (anders proberen backgrounder-pods verbinding te maken met de oude server). ### Voorbeelden Kubernetes-configuratie **Opmerking:** De configuratievoorbeelden omvatten het gebruik van een gereedheidstest. U kunt de gereedheidstest gebruiken wanneer de implementatie van uw Tableau Server-container een TSM-implementatie met één knooppunt is (de implementatie kan meerdere backgrounder-pods bevatten). U kunt geen gereedheidstest gebruiken voor implementaties van meerdere knooppunten met Tableau Server in een container. #### Configuratie Tableau Server-container \--- 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 #### Configuratie Backgrounder-pod \--- 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: {} #### Configuratie gepland schalen 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-job om kloonconfiguratie op te schonen (optioneel) Dit is een handige Kubernetes-job die u tijdens het testen kunt gebruiken. Als u de kloonconfiguratie tussen verschillende implementaties wilt wissen die door Tableau Server in een container is geproduceerd, kunt u een job als deze uitvoeren om de NFS op te schonen. 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