Scalabilità dinamica in un contenitore - Gestione componenti in background di Tableau Server

Introduzione

La scalabilità dinamica di Gestione componenti in background in un contenitore consente l’applicazione di varie strategie di scalabilità alla gestione componenti in background e ai processi pianificati in Tableau Server. La scalabilità automatica in questo contesto significa che i servizi possono essere ridimensionati in modo indipendente per gestire carichi di attività variabili senza richiedere l’intervento umano o influire sui tempi di funzionamento di altri sistemi di server. I contenitori di Tableau Server che contengono nodi completi di processi di Tableau Server continueranno a essere eseguiti come sistemi monolitici. Al contrario, un insieme più piccolo di servizi per contenitore indipendenti disaccoppiati che comprende il ruolo del servizio di "gestione componenti in background" sarà scalabile dinamicamente e gestirà il carico di calcolo che normalmente verrebbe gestito dai contenitori di Tableau Server. I servizi di gestione componenti in background sono responsabili dell’elaborazione delle attività di sistema che includono estrazioni di aggiornamento/creazione, invio di sottoscrizioni, controllo di avvisi basati sui dati e molti processi di manutenzione. Se in alcuni casi, ad esempio, sarebbe vantaggioso aggiornare un numero elevato di insiemi di dati o elaborare una serie di avvisi basati sui dati molto costosi a livello di calcolo, ora è possibile sfruttare Kubernetes per incrementare la potenza di calcolo per completare queste attività in modo efficiente. Questa guida tratta i requisiti di configurazione e distribuzione per la gestione componenti in background con scalabilità automatica in Kubernetes. Questo documento è un supplemento alla documentazione per Tableau Server in un contenitore.

Prerequisiti

La gestione componenti in background con scalabilità automatica è disponibile solo in Kubernetes ed è basata su Tableau Server in contenitori. Per utilizzare la funzionalità di gestione componenti in background con scalabilità automatica, è necessario soddisfare alcuni prerequisiti:

Limitazioni

  • Questa funzionalità funziona solo come parte di una distribuzione basata su Linux.
  • I processi di flusso non sono supportati nella gestione componenti in background con scalabilità automatica. I processi di flusso vengono gestiti nei servizi di gestione componenti in background che continuano a essere eseguiti nel contenitore Tableau Server.

Creazione di immagini dei pod di Tableau Server e della gestione componenti in background

Il primo passo per l’utilizzo della gestione componenti in background con scalabilità automatica è la creazione di immagini del servizio che includono l’installazione di Tableau Server. Queste immagini includono l’immagine di Tableau Server e le immagini per i servizi separati di gestione componenti in background e supporto. Puoi utilizzare lo stesso strumento di compilazione utilizzato per creare l’immagine completa del contenitore di Tableau Server, ma la versione dello strumento deve essere la 2022.3.0 o successiva, devi disporre di una licenza Advanced Management e devi utilizzare un flag speciale durante la creazione delle immagini.

  1. Per creare le immagini del servizio, eseguire questo comando:

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

    In questo modo viene creato Tableau Server e quattro nuove immagini. Queste immagini aggiuntive contengono servizi individuali che includono il nuovo pod di gestione componenti in background con scalabilità automatica.

    Il comando docker images elenca le immagini create nel repository Docker locale:

    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

    Le immagini hyper, gateway, backgrounder e dataserver includono il nuovo pod di gestione componenti in background. Tutte e cinque queste immagini condividono driver personalizzati, script di installazione e proprietà. Per maggiori informazioni, consulta Personalizzazione dell’immagine.

  2. Pubblica tutte queste immagini nel tuo repository di immagini interno per la distribuzione.

Guida alla distribuzione

Le seguenti informazioni forniscono il contesto per la distribuzione di Tableau Server in un contenitore e con gestione componenti in background con scalabilità automatica. Queste informazioni presuppongono che tu comprenda e sappia già come distribuire Tableau Server in un contenitore autonomo. Per maggiori informazioni, consulta Tableau Server in un contenitore. I tre file di configurazione di Kubernetes nella sezione Configurazione di Kubernetes sono modelli che possono essere utilizzati per configurare la distribuzione. Le altre sezioni di questa guida trattano i requisiti e i dettagli della distribuzione.

L’implementazione di Tableau Server e della gestione componenti in background con scalabilità automatica deve essere semplice come l’implementazione dei file compilati della Configurazione di Kubernetes che si trovano in fondo a questa guida:

kubectl apply -f <tableau-kubeconfig-dir>

Processi di gestione componenti in background

I pod di gestione componenti in background assistono Tableau Server in un contenitore a calcolare carichi di lavoro pianificati aggiuntivi in parallelo. La gestione componenti in background gestisce i carichi di lavoro di aggiornamento delle estrazioni, sottoscrizione, avviso, flusso e sistema. La distribuzione dei processi tra i pod di gestione componenti in background significa che saranno disponibili maggiori risorse di calcolo per consentire a Tableau Server di gestire altre attività, ad esempio attività utente interattive come il rendering di cartelle di lavoro e dashboard. I processi di flusso sono l’unico tipo d processo di gestione componenti in background che non viene eseguito nella gestione componenti in background. Per informazioni dettagliate sui processi di gestione componenti in background, consulta Gestire i processi in background in Tableau Server.

I pod di gestione componenti in background possono gestire qualunque tipo di carico, ad eccezione dei processi di flusso, che devono essere eseguiti nei contenitori Tableau Server principali, che continuano ad eseguire il servizio di gestione componenti in background.

La funzionalità dei ruoli dei nodi offre agli utenti la possibilità di dedicare i pod di gestione componenti in background a tipi di processi specifici. Questa funzionalità è un’estensione della funzionalità dei ruoli dei nodi su Tableau server. La descrizione dettagliata dei diversi ruoli dei nodi è disponibile qui. Per impostazione predefinita, i processi di flusso sono disabilitati sui pod di gestione componenti in background (ovvero il ruolo è impostato su "no-flows") poiché i pod di gestione componenti in background non sono in grado di eseguire i processi di flusso.

Per configurare i ruoli dei nodi per la gestione componenti in background, devi impostare la variabile di ambiente NODE_ROLES come parte di kubeconfig per il contenitore che esegue il servizio di gestione componenti in background. Ad esempio, per impostare la gestione componenti in background affinché esegua solo processi di aggiornamento delle estrazioni, configura la variabile di ambiente NODE_ROLES per gli aggiornamenti delle estrazioni come illustrato di seguito:

NODE_ROLE_CONFIG

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

I pod di Tableau Server avranno almeno una gestione componenti in background configurata nella loro topologia, che è richiesta per garantire che ci sia sempre una posizione per l’esecuzione dei processi di gestione componenti in background. Per impostazione predefinita, TSM richiede che sia sempre presente una gestione componenti in background in grado di gestire qualunque ruolo di processo in background. In alcuni scenari, puoi fare in modo che i pod di gestione componenti in background gestiscano tutti i processi di un tipo particolare. A tale scopo, devi impostare la chiave di configurazione del server topology.roles_handle_all_jobs_constraint_disabled su true, per disabilitare il requisito che prevede che la topologia TSM gestisca tutti i tipi di processo. Con questo parametro impostato, il ruolo della gestione componenti in background per l’istanza di gestione componenti in background di Tableau Server potrebbe essere impostato su no-extract-refreshes e il ruolo per i pod di gestione componenti in background potrebbe essere impostato su extract-refreshes, che garantirebbe che tutti i processi di aggiornamento delle estrazioni siano eseguiti solo sui pod di gestione componenti in background.

Nota: la disabilitazione di questo vincolo consente di configurare ruoli in base ai quali alcuni tipi di processi non vengono mai pianificati. La configurazione del ruolo della gestione componenti in background TSM e dei processi di gestione componenti in background deve essere impostato con attenzione perché TSM non verificherà più che tutti i tipi di processi di gestione componenti in background possano essere pianificati.

Pod di Tableau Server in un contenitore

I contenitori con Tableau Server come parte dei pod di gestione componenti in background con scalabilità automatica vengono distribuiti quasi nello stesso modo di Tableau Server in un contenitore esistente. Ci sono alcune modifiche ai requisiti:

  • È necessaria una condivisione file di rete per trasferire la configurazione tra il contenitore di Tableau Server e i pod di gestione componenti in background.
  • Devi abilitare e utilizzare la funzionalità Archivio file esterno. Anche in questo caso è necessaria una condivisione file di rete.

Pod di gestione componenti in background

I pod di gestione componenti in background consistono di quattro contenitori di servizi indipendenti utilizzati congiuntamente: gateway, hyper, dataserver e backgrounder. Puoi distribuire questi pod come tipici pod di container Kubernetes indipendenti. I pod hanno i seguenti requisiti:

  • I pod di gestione componenti in background devono essere in grado di raggiungere il nodo di Tableau Server utilizzando la risoluzione DNS del nome host.
  • È necessario fornire condivisioni file di rete Archivio file esterno e Clone.

Nota: i pod di gestione componenti in background sono configurati con un contenitore di inizializzazione per attendere fino a quando il contenitore di Tableau Server ha prodotto correttamente l’output di configurazione del clone prima di proseguire con l’esecuzione.

Log

I servizi dei pod di gestione componenti in background (come Tableau Server) scrivono ancora i log principalmente sul disco. Poiché i pod di gestione componenti in background possono essere ridimensionati o espansi, sono temporanei perciò è essenziale assicurarsi che i log siano memorizzati fuori dai pod. Molti clienti con ambienti K8s esistenti utilizzano già un servizio di aggregazione dei log di qualche tipo per raccogliere i log dai pod distribuiti. Esempi di servizi di aggregazione dei log sono Splunk e fluentd. È vivamente consigliabile che i clienti utilizzino qualche tipo di servizio di aggregazione dei log per raccogliere i log dai loro pod di gestione componenti in background. Per semplificare la gestione dei log, la kubeconfig che forniamo configura ciascun servizio nel pod per la scrittura in un volume di log condiviso. Il percorso della directory in ciascun contenitore di servizi è specificato dalla variabile di ambiente ROOT_LOG_DIR.

Se devi aprire un caso di supporto e fornire i log, dovrai fornire due insiemi di log: ziplog raccolti dai contenitori principali di Server e i log dei pod di gestione componenti in background (recuperati dal servizio di aggregazione dei log o mediante il processo manuale indicato di seguito).

I clienti che non sono in grado di utilizzare un servizio di aggregazione dei log, possono recuperarli manualmente dai pod.

Nota:i log dei pod che non hanno utilizzato una Persistent Volume Claim per il volume che contiene i log andranno persi quando il pod viene ridimensionato.

Tutti i pod pertinenti sono disponibili nella directory /var/log/tableau (configurabile tramite la variante di ambiente ROOT_LOG_DIR) all’interno del pod di gestione componenti in background. È consigliabile montare un PersistantVolumeClaim in questa posizione in modo che i log siano disponibili quando il pod viene eliminato.

Raccogliere i log quando il pod di gestione componenti in background è in esecuzione:

Crea un file tar dei log all’interno del contenitore:

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

Copia il file tar all’esterno del contenitore:

kubectl cp <backgrounder-pod-name>:docker/user/backgrounder-pod-logs.tar.gz ./backgrounder-pod-logs.tar.gz
Raccogliere i log quando il pod di gestione componenti in background si è chiuso (o non si è avviato)

Allega i pod di lunga durata con montaggio PersistantVolumeClaim utilizzato per i log di distribuzione dei pod di gestione componenti in background. Un esempio di configurazione:

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

Crea un file tar dei log all’interno del contenitore:

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

Copia il file tar all’esterno del contenitore:

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

Modifiche live alla configurazione

Se apporti modifiche a Tableau Server in un contenitore (ad esempio utilizzando la riga di comando tsm) e desideri che quelle modifiche alla configurazione siano rappresentate nei pod di gestione componenti in background, devi eseguire il comando tsm settings clone per produrre un nuovo insieme di file di configurazione del clone ("payload del clone").

  1. Utilizza TSM per apportare modifiche al pod di Tableau Server in un contenitore e applica le modifiche di configurazione al server.
  2. Esegui il comando indicato di seguito sul pod di Tableau Server in un contenitore:

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

    Questo comando crea un nuovo insieme di file di configurazione e lo scrive nella posizione dell’unità NFS del clone.

  3. Ridistribuisci i pod di gestione componenti in background. I pod devono essere configurati per l’utilizzo dell’unità NFS del clone e raccoglieranno la nuova configurazione.

Strategie di scalabilità

I pod di gestione componenti in background possono essere scalati in Kubernetes con numerose tecniche e strategie. Forniamo un esempio di strategia di scalabilità che modifica la dimensione del pool dei pod di gestione componenti in background in base a una pianificazione temporale.

Tieni presente che l’utilizzo di CPU e memoria non sono buone metriche per la scalabilità dei pod di gestione componenti in background. L’utilizzo di memoria e CPU non illustrano in modo accurato il carico complessivo sul cluster. Ad esempio, l’utilizzo di un pod di gestione componenti in background potrebbe essere massimo durante l’aggiornamento di un’estrazione, ma potrebbero non esserci ulteriori processi in attesa nella coda dei processi della gestione componenti in background. In questo caso la scalabilità automatica non migliorerebbe la velocità effettiva dei processi.

Scalabilità pianificata

I meccanismi standard di Kubernetes che utilizzano i processi cron consentono di pianificare una soluzione di scalabilità.

Un esempio di configurazione di Kubernetes di questo tipo è disponibile nella sezione Configurazione di Kubernetes riportata di seguito.

Configurazione di Kubernetes

Nuove variabili di ambiente

Oltre alle variabili di ambiente standard del contenitore di Tableau Server (vedi Opzioni di configurazione iniziali), vi sono alcune nuove variabili di ambiente necessarie da impostare nella Configurazione di Kubernetes.

Variabile di ambienteValore consigliatoDescrizione
FILESTORE_MOUNT_PATH/docker/dataenginePercorso di montaggio della directory dell’archivio file esterno. Questa directory deve puntare alla directory NFS dataengine montata all’interno di ciascun contenitore Tableau distribuito. Per maggiori informazioni sull’archivio file esterno, consulta Archivio file esterno di Tableau Server. Il valore dovrebbe essere lo stesso per l’istanza di Tableau Server in un pod Contenitore e nel pod Gestione componenti in background.
CLONE_ARTIFACT_DIR/docker/clone/clone-artifactsPercorso di montaggio della directory di configurazione del clone. Questa directory deve puntare a un directory NFS montata all’interno di ciascun contenitore Tableau. Tableau Server emetterà dati di configurazione che i pod di gestione componenti in background utilizzano per diventare membri del cluster.
ROOT_LOG_DIR/var/log/tableau(Solo pod di gestione componenti in background)

Percorso della directory dei log comuni per tutti i servizi in esecuzione in un pod di gestione componenti in background.

Porte dei pod di gestione componenti in background

I pod di gestione componenti in background sono costituiti da quattro servizi, ciascuno dei quali è impostato per impostazione predefinita per l’esecuzione su una porta specifica. Se desideri modificare la porta a cui si collega il servizio all’interno del contenitore, devi fornire la chiave che corrisponde all’assegnazione della porta del servizio. Nella maggior parte dei casi questo tipo di configurazione non dovrebbe essere necessario, a meno che non sia presente un contenitore sidecar o qualche altro tipo di componente aggiunto al pod e che entra in conflitto con una delle porte dei servizi.

Variabile di ambiente per la portaImpostazione predefinita
BACKGROUNDER_PORT8600
DATASERVER_PORT8400
HYPER_PORT8200
GATEWAY_PORT8080

Dataserver inoltre utilizza la porta 8300, che non può essere riconfigurata.

Directory di rete condivisa

Questa distribuzione di Tableau Server richiede due condivisioni di rete per il corretto funzionamento. In tutti i modelli di configurazione Tableau Server e gestione componenti in background o Kubernetes sono presenti queste directory:

  • Directory Dataengine (FILESTORE_MOUNT_PATH): i pod di gestione componenti in background richiedono la funzionalità Archivio file esterno. Questa condivisione di rete contiene estrazioni e altri artefatti basati su file che vengono condivisi tra Tableau Server e i pod di gestione componenti in background.
  • Directory Clone (CLONE_ARTIFACT_DIR): Tableau Server scrive la connessione statica e le informazioni di configurazione su una condivisione di rete. I pod di gestione componenti in background utilizzano queste informazioni per diventare membri del cluster di Tableau Server. Nelle future versioni non definitive questa configurazione sarà incorporata nel ciclo di vita standard della configurazione di Kubernetes.

Importante: se intendi ridistribuire l’intero cluster (incluso un nuovo contenitore di Tableau Server), devi eliminare i contenuti del montaggio NFS del clone (in caso contrario i pod di gestione componenti in background tenteranno di collegarsi al server precedente).

Esempi di configurazione di Kubernetes

Nota: gli esempi di configurazione includono l’uso di una sonda di preparazione. Puoi utilizzare la sonda di preparazione quando la distribuzione del contenitore di Tableau Server è una distribuzione TSM a nodo singolo (la distribuzione può includere più pod di gestione componenti in background). Non puoi utilizzare una sonda di preparazione nelle distribuzioni di Tableau Server in un contenitore a più nodi.

Configurazione del contenitore di Tableau Server

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

Configurazione del pod di gestione componenti in background

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

Configurazione della scalabilità pianificata

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

Processo di Kubernetes per pulire la configurazione del clone (facoltativo)

Questo è un comodo processo di Kubernetes che è possibile utilizzare durante i test. Se desideri eliminare la configurazione del clone prodotta da Tableau Server in un contenitore tra distribuzioni distinte, puoi eseguire un processo simile a questo per pulire l’NFS.

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