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.

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:

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 <installer> --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 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 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 <tableau-kubeconfig-dir>

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 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> # 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 <backgrounder-pod-name> -- 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 <backgrounder-pod-name>: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: <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

Maak een tar-bestand van de logboeken in de container:

kubectl exec -it <backgrounder-pod-name> -- 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-name>:/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 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), 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 poortStandaard
BACKGROUNDER_PORT8600
DATASERVER_PORT8400
HYPER_PORT8200
GATEWAY_PORT8080

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: <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

Configuratie Backgrounder-pod

---
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: {}

Configuratie gepland schalen

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-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: <nfs_ip> # IP for shared NFS directory for clone output
path: /clone