Mise à l’échelle dynamique dans un conteneur – Backgrounders Tableau Server

Introduction

La mise à l’échelle dynamique d’un backgrounder dans un conteneur permet d’appliquer diverses stratégies de mise à l’échelle au backgrounder et aux tâches planifiées dans Tableau Server. Dans ce contexte, la mise à l’échelle automatique signifie que les services peuvent être mis à l’échelle indépendamment pour gérer des charges de tâches variables sans nécessiter d’intervention humaine ni affecter la disponibilité d’autres systèmes de serveurs. Les conteneurs Tableau Server qui contiennent des nœuds complets de processus Tableau Server continueront à fonctionner comme des systèmes monolithiques. Au lieu de cela, un ensemble plus petit de services de conteneurs indépendants découplés qui comprend le rôle de service « backgrounder » sera évolutif de ma manière dynamique et gérera la charge de calcul qui serait normalement gérée par les conteneurs Tableau Server. Les services de fond d’écran sont responsables du traitement des tâches système qui incluent l’actualisation/la création d’extraits, l’envoi d’abonnements, la vérification des alertes de données et de nombreux travaux de maintenance. Si parfois, par exemple, il serait avantageux d’actualiser un grand nombre d’ensembles de données ou de calculer une série d’alertes de données coûteuses en calcul, vous pouvez désormais tirer parti de Kubernetes pour augmenter la puissance de calcul et réaliser ces tâches efficacement. Ce guide couvre les exigences de configuration et de déploiement pour les backgrounders à mise à l’échelle automatique dans Kubernetes. Ce document vient compléter la documentation de Tableau Server dans un conteneur.

Conditions préalables

Les backgrounders à mise à l’échelle automatique ne sont disponibles que dans Kubernetes et sont basés sur Tableau Server dans des conteneurs. Pour utiliser la fonctionnalité de mise à l’échelle automatique des backgrounders, vous devez remplir certains prérequis :

Limites

  • Cette fonctionnalité ne fonctionne que dans le cadre d’un déploiement basé sur Linux.
  • Les travaux de flux ne sont pas pris en charge sur les backgrounders à mise à l’échelle automatique. Les travaux de flux seront gérés par les services backgrounder qui continuent de s’exécuter dans le conteneur Tableau Server.

Création d’images de Tableau Server et de pod backgrounder

La première étape pour utiliser les backgrounders à mise à l’échelle automatique dans les conteneurs consiste à créer les images de service qui composent l’installation de Tableau Server. Ces images incluront l’image de Tableau Server, ainsi que des images pour le backgrounder séparé et les services de support. Vous utilisez le même outil de génération que celui ayant servi à créer l’image complète tout-en-un du conteneur Tableau Server, mais l’outil doit être la version 2022.3.0 ou ultérieure. Vous devez aussi disposer d’une licence Advanced Management et vous devez utiliser un indicateur spécial lors de la création des images.

  1. Pour créer les images de service, exécutez cette commande :

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

    Cette commande crée le Tableau Server et quatre nouvelles images. Ces images supplémentaires contiennent des services individuels qui composent le nouveau module de backgrounder à mise à l’échelle automatique.

    La commande docker images répertorie les images créées dans le référentiel Docker local :

    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

    Les images hyper, gateway, backgrounder et dataserver constituent le nouveau pod backgrounder. Les pilotes personnalisés, les scripts d’installation et les propriétés seront partagés entre ces cinq images. Pour plus d’informations, consultez Personnalisation de l’image.

  2. Publiez toutes ces images dans votre référentiel d’images interne pour le déploiement.

Guide de déploiement

Les informations suivantes fournissent un contexte pour le déploiement de Tableau Server dans un conteneur et avec des backgrounders à mise à l’échelle automatique. Ces informations supposent que vous compreniez et sachiez déjà comment déployer Tableau Server dans un conteneur autonome. Pour plus d’informations, consultez Tableau Server dans un conteneur. Les trois fichiers de configuration Kubernetes de la section Configuration de Kubernetes sont des modèles qui peuvent être utilisés pour configurer le déploiement. Les autres sections de ce guide couvrent les exigences et les détails du déploiement.

Le déploiement de Tableau Server et des backgrounders à mise à l’échelle automatique devrait être aussi simple que le déploiement des fichiers de configuration Kubernetes remplis au bas du guide :

kubectl apply -f <tableau-kubeconfig-dir>

Travaux d’un backgrounder

Les pods backgrounder aident Tableau Server dans un conteneur à calculer des charges de travail planifiées supplémentaires en parallèle. Le backgrounder gère les actualisations d’extraits, les abonnements, les alertes, les flux et les charges de travail système. La répartition des tâches entre les pods backgrounder signifie que Tableau Server ne disposera plus de ressources de calcul pour gérer d’autres tâches, par exemple les activités interactives des utilisateurs comme le rendu des classeurs et des tableaux de bord. Les travaux de flux sont le seul type de travail de backgrounder qui ne s’exécute pas dans le backgrounder. Pour plus d’informations sur les travaux des backgrounders, consultez Gestion des travaux d’arrière-plan dans Tableau Server.

Les pods backgrounder peuvent gérer n’importe quel type de charge, à l’exception des travaux de flux, lesquels doivent être exécutés dans les principaux conteneurs Tableau Server, qui continuent d’exécuter le service Backgrounder.

La fonctionnalité Rôles de nœud donne aux utilisateurs la possibilité de dédier des pods backgrounder à un type de travail spécifique. Cette fonctionnalité est une extension de la fonctionnalité Rôles de nœud sur Tableau Server. La description détaillée des différents rôles de nœud peut être trouvée ici. Notez que, par défaut, les travaux de flux sont désactivés sur les pods backgrounder (c’est-à-dire que le rôle est défini sur « no-flows ») car les pods backgrounder ne peuvent pas exécuter des travaux de flux.

Pour configurer les rôles de nœud pour le backgrounder, vous devez définir la variable d’environnement NODE_ROLES dans le cadre de kubeconfig pour le conteneur exécutant le service backgrounder. Par exemple, pour configurer le backgrounder afin qu’il n’exécute que des travaux d’actualisation d’extrait, configurez la variable d’environnement NODE_ROLES pour extraire des actualisations comme indiqué ci-dessous :

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

Au moins un backgrounder sera configuré dans la topologie des pods Tableau Server, soit le minimum nécessaire pour qu’il y ait toujours un emplacement d’exécution des travaux de backgrounder. Par défaut, TSM exigera qu’il y ait un backgrounder capable de gérer chaque rôle de travail de backgrounder. Dans certains scénarios, vous souhaiterez peut-être que les pods backgrounder gèrent tous les travaux d’un type particulier. Pour ce faire, vous devez définir la clé de configuration Tableau Server topology.roles_handle_all_jobs_constraint_disabled sur true, ce qui désactivera l’exigence selon laquelle la topologie TSM doit gérer tous les types de travaux. Avec ce jeu de paramètres, le rôle backgrounder pour l’instance backgrounder de Tableau Server peut être défini sur no-extract-refreshes et le rôle des pods backgrounder peut être défini surextract-refreshes. De cette manière, toutes les tâches d’actualisation d’extrait s’exécuteraient uniquement sur les pods backgrounder.

Remarque : la désactivation de cette contrainte vous permet de configurer des rôles de sorte que certains types de travaux ne soient jamais planifiés. La configuration des rôles des backgrounders TSM et des travaux backgrounder doit être définie avec soin car TSM ne vérifiera plus que tous les types de travaux backgrounder peuvent être planifiés.

Pods Tableau Server dans un conteneur

Vous pouvez déployer les conteneurs avec Tableau Server comme partie intégrante des pods backgrounder à mise à l’échelle automatique presque de la même manière que notre instance Tableau Server dans un conteneur. Cette opération requiert quelques modifications essentielles :

  • Un partage de fichiers réseau est requis pour transférer la configuration entre le conteneur Tableau Server et les pods backgrounder.
  • Vous devez activer et utiliser la fonctionnalité de répertoire de fichiers externe. Cela nécessite également un partage de fichiers réseau dédié.

Pods backgrounder

Les pods backgrounder se composent de quatre conteneurs de services indépendants fonctionnant ensemble : gateway, hyper, dataserver et backgrounder. Vous pouvez déployer ces pods comme des pods de conteneur Kubernetes indépendants typiques. Les pods ont les exigences suivantes :

  • Les pods backgrounder doivent pouvoir joindre le nœud Tableau Server à l’aide de la résolution DNS du nom d’hôte.
  • Les partages de fichiers réseau Répertoire de fichiers et Clone doivent être fournis.

Remarque : les pods Backgrounder sont configurés avec un init-container pour attendre que le conteneur Tableau Server ait réussi à produire une sortie de configuration de clonage avant de procéder à l’exécution.

Journaux

Les services de pod Backgrounder (comme Tableau Server) écrivent toujours les journaux principalement sur le disque. Étant donné que les pods backgrounder peuvent être mis à l’échelle, ils sont éphémères. Il est donc essentiel de s’assurer que les journaux sont stockés hors des pods. De nombreux clients disposant d’environnements K8s existants utilisent déjà un service d’agrégation de journaux d’un certain type pour collecter les journaux des pods qu’ils déploient. Parmi les services d’agrégation de journaux, citons par exemple Splunk et fluentd. Nous recommandons vivement aux clients d’utiliser un service d’agrégation de journaux pour collecter les journaux de leurs pods backgrounder. Pour faciliter la gestion des journaux, le kubeconfig que nous fournissons configure chaque service du pod pour écrire sur un volume de journal partagé. Le chemin du répertoire dans chaque conteneur de service est spécifié par les variables d’environnement ROOT_LOG_DIR.

Si vous avez besoin d’ouvrir une demande d’assistance et de fournir des journaux, vous fournirez deux ensembles de journaux : les ziplogs collectés à partir des principaux conteneurs de serveur et les journaux des pods backgrounder (soit récupérés à partir de votre service d’agrégation de journaux, soit à l’aide du processus manuel ci-dessous).

Pour les clients qui ne peuvent pas utiliser un service d’agrégation de journaux, les journaux peuvent être récupérés manuellement à partir des pods.

Remarque : les journaux de tout pod qui n’a pas utilisé de demande de volume persistant pour le volume contenant les journaux seront perdus en cas de scale-down du pod.

Tous les journaux pertinents sont disponibles sur le répertoire /var/log/tableau (configurable via la variable d’environnement ROOT_LOG_DIR) à l’intérieur du pod backgrounder. Nous vous recommandons vivement de monter un PersistantVolumeClaim à cet emplacement afin que les journaux soient disponibles en fin de service du pod.

Collecte des journaux lorsque le pod backgrounder est en cours d’exécution :

Créez un fichier tar des journaux à l’intérieur du conteneur :

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

Copiez le fichier tar en dehors du conteneur :

kubectl cp <backgrounder-pod-name>:docker/user/backgrounder-pod-logs.tar.gz ./backgrounder-pod-logs.tar.gz
Collecte des journaux lorsque le pod backgrounder s’est fermé (ou n’a pas pu démarrer)

Joignez un pod de longue durée avec le montage PersistantVolumeClaim qui est utilisé pour les journaux de déploiement de pod backgrounder. Exemple de configuration :

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

Créez un fichier tar des journaux à l’intérieur du conteneur :

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

Copiez le fichier tar en dehors du conteneur :

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

Modifications de configuration en direct

Si vous apportez des modifications de configuration dans Tableau Server dans un conteneur (par exemple à l’aide de la ligne de commande tsm) et souhaitez que ces modifications de configuration soient représentées dans les pods backgrounder, vous devez exécuter la commandetsm settings clone pour produire un nouvel ensemble de fichiers de configuration clone (« clone payload »).

  1. Utilisez TSM pour apporter des modifications de configuration dans le pod Tableau Server dans un conteneur et appliquer les modifications de configuration au serveur.
  2. Exécutez la commande suivante dans le pod Tableau Server dans un conteneur :

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

    Cette commande crée un nouvel ensemble de fichiers de configuration et l’écrit à l’emplacement du lecteur Clone NFS.

  3. Redéployez vos pods de backgrounder. Les pods doivent être configurés pour utiliser le lecteur Clone NFS et adopteront la nouvelle configuration.

Stratégies de mise à l’échelle

Les pods de backgrounder peuvent être mis à l’échelle dans Kubernetes à l’aide de diverses techniques et stratégies. Nous fournissons un exemple de stratégie de mise à l’échelle qui modifie la taille du pool de pods backgrounder en fonction d’un calendrier.

Notez que l’utilisation du processeur et de la mémoire ne sont pas de bonnes métriques pour la mise à l’échelle des pods backgrounder. L’utilisation de la mémoire et du processeur ne représente pas avec précision la demande de charge globale sur le cluster. Par exemple, un pod backgrounder peut être utilisé au maximum pour actualiser un extrait, mais aucun travail supplémentaire n’est en attente dans la file d’attente des travaux du backgrounder. Dans ce cas, la mise à l’échelle automatique n’améliorerait pas le débit des travaux.

Mise à l’échelle planifiée

Les mécanismes Kubernetes standard utilisant des travaux cron vous permettent de planifier une solution de mise à l’échelle.

Un exemple de configuration Kubernetes est fourni à ce titre dans la section Configuration de Kubernetes ci-dessous.

Configuration de Kubernetes

Nouveaux variables d’environnement

En plus des variables d’environnement de conteneur Tableau Server standard (voir Options de configuration initiale), il existe de nouvelles variables d’environnement requises qui doivent être définies dans la configuration de Kubernetes.

Variable d’environnementValeur recommandéeDescription
FILESTORE_MOUNT_PATH/docker/dataengineEmplacement de montage du répertoire de fichiers externe. Ce répertoire doit pointer vers le répertoire NFS du moteur de données monté dans chaque conteneur Tableau déployé. Pour plus d’informations sur le répertoire de fichiers externe, consultez Répertoire de fichiers externe Tableau Server. La valeur doit être la même pour Tableau Server dans un pod Conteneur et le module Backgrounder.
CLONE_ARTIFACT_DIR/docker/clone/clone-artifactsClonez l’emplacement de montage du répertoire de configuration. Ce répertoire doit pointer vers un répertoire NFS monté dans chaque conteneur Tableau. Tableau Server sortira les données de configuration que les pods backgrounder consomment pour devenir membres du cluster.
ROOT_LOG_DIR/var/log/tableau(pods backgrounder uniquement)

Emplacement du répertoire de journaux commun pour tous les services exécutés dans un pod backgrounder.

Ports de pod backgrounder

Les pods backgrounder se composent de quatre services, chacun étant par défaut configuré pour s’exécuter sur un port spécifié. Si vous souhaitez modifier le port auquel le service se connecte à l’intérieur du conteneur, vous devez fournir la clé correspondant à l’attribution du port du service. En général, ce type de configuration n’est pas nécessaire, sauf si un conteneur side-car ou un autre composant supplémentaire est ajouté au pod et entre en conflit avec le port d’un service.

Port de variable d’environnementPar défaut
BACKGROUNDER_PORT8600
DATASERVER_PORT8400
HYPER_PORT8200
GATEWAY_PORT8080

Le serveur de données utilise également le port 8300, qui ne peut pas être reconfiguré.

Répertoire réseau partagé

Ce déploiement de Tableau Server nécessite deux partages réseau pour fonctionner correctement. Notez que dans tous les modèles de configuration Tableau Server et Backgrounder de Kubernetes, ces répertoires réseau sont présents :

  • Répertoire du moteur de données (FILESTORE_MOUNT_PATH) : les pods backgrounder nécessitent la fonctionnalité de magasin de fichiers externe. Ce partage réseau contient des extraits et d’autres artefacts basés sur des fichiers qui seront partagés entre Tableau Server et les pods backgrounder.
  • Répertoire Clone (CLONE_ARTIFACT_DIR) : Tableau Server écrit des informations de connexion et de configuration statiques sur un partage réseau. Les pods backgrounder utiliseront ces informations pour devenir membres du cluster Tableau Server. Dans les futures versions préliminaires, cette configuration sera intégrée au cycle de vie standard de la configuration Kubernetes.

Important : si vous souhaitez redéployer entièrement le cluster (y compris un nouveau conteneur Tableau Server), vous devez vider le contenu du montage NFS clone. Les pods backgrounder tenteront sinon de se connecter à l’ancien serveur.

Exemples de configuration Kubernetes

Remarque : les exemples de configuration incluent l’utilisation d’une sonde de préparation. Vous pouvez utiliser la sonde de préparation lorsque votre déploiement de conteneur Tableau Server est un déploiement TSM à nœud unique (le déploiement peut inclure plusieurs pods backgrounder). Vous ne pouvez pas utiliser une sonde de préparation avec Tableau Server à plusieurs nœuds dans les déploiements de conteneur.

Configuration du conteneur 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

Configuration du pod backgrounder

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

Configuration de mise à l’échelle planifiée

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

Travail Kubernetes de nettoyage de la configuration de clonage (facultatif)

Il s’agit d’une tâche Kubernetes pratique que vous pouvez utiliser lors des tests. Si vous souhaitez effacer la configuration de clonage produite par Tableau Server dans un conteneur entre des exécutions de déploiement distinctes, vous pouvez exécuter une tâche telle que celle-ci pour nettoyer le 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