Mise à l’échelle dynamique dans un conteneur - Gestionnaire de processus en arrière-plan Tableau Server

Introduction

La mise à l’échelle dynamique du gestionnaire de processus en arrière-plan dans un conteneur permet l’application de diverses stratégies de mise à l’échelle au gestionnaire de processus en arrière-plan et aux tâches planifiées dans Tableau Server. Dans un tel contexte, la mise à l’échelle automatique implique que les services peuvent être mis à l’échelle de manière indépendante afin de 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. En revanche, un ensemble plus petit de services de conteneurs indépendants découplés comprenant le rôle de service du « gestionnaire de processus en arrière-plan » sera dynamiquement évolutif et gérera la charge de calcul qui, en temps normal, aurait été gérée par les conteneurs Tableau Server. Les services du gestionnaire de processus en arrière-plan sont chargés du traitement des tâches système, notamment l’actualisation/la création d’extraits, l’envoi d’abonnements, la vérification des alertes basées sur les données et de nombreuses tâches de maintenance. Si par exemple, à certains moments, il serait avantageux d’actualiser un grand nombre d’ensembles de données ou de calculer une série d’alertes de données gourmandes en termes de calcul, vous pouvez désormais utiliser Kubernetes pour augmenter la puissance de calcul afin d’exécuter ces tâches efficacement. Ce guide couvre les exigences de configuration et de déploiement pour la mise à l’échelle automatique des gestionnaires de processus en arrière-plan dans Kubernetes. Le présent document complète la documentation sur le Tableau Server dans un conteneur.

Conditions préalables

La mise à l’échelle automatique des gestionnaires de processus en arrière-plan n’est disponible que dans Kubernetes et est basée sur Tableau Server dans des conteneurs. Pour utiliser la fonctionnalité de mise à l’échelle automatique des gestionnaires de processus en arrière-plan, vous devez remplir certains conditions préalables :

Limites

  • Cette fonctionnalité ne marche que dans le cadre d’un déploiement avec Linux.
  • Les tâches de flux ne sont pas prises en charge lors de la mise à l’échelle automatique des gestionnaires de processus en arrière-plan. Elles seront gérées par les services du gestionnaire de processus en arrière-plan qui continuent de s’exécuter dans le conteneur Tableau Server.

Créer des images de Tableau Server et du module de gestionnaire de processus en arrière-plan

La première étape pour l’utilisation de la mise à l’échelle automatique des gestionnaires de processus en arrière-plan dans des conteneurs consiste à créer les images de service intégrées à l’installation de Tableau Server. Il s’agit de l’image Tableau Server et des images du gestionnaire de processus en arrière-plan et des services d’assistance. Vous utilisez le même outil de génération que celui utilisé pour créer l’image complète et intégrante du conteneur Tableau Server. Toutefois, vous devez utiliser la version 2022.3.0 de l’outil ou des versions ultérieures, vous devez avoir une licence Advanced Management et vous devez utiliser un indicateur spécial pour créer les images.

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

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

    Cette action permet de créer l’image Tableau Server et quatre nouvelles images. Ces autres images contiennent des services individuels qui constituent le nouveau module du gestionnaire de processus en arrière-plan pouvant faire l’objet d’une mise à l’échelle automatiquement.

    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, passerelle indépendante, gestionnaire de processus en arrière-plan et serveur de données constituent le nouveau module du gestionnaire de processus en arrière-plan. Ces cinq images partagent les pilotes personnalisés, les scripts d’installation et les propriétés. Pour plus d’information, consultez Personnalisation de l’image.

  2. Publiez toutes ces images dans votre référentiel d’images interne en vue du déploiement.

Guide de déploiement

L’information suivante offre un contexte pour le déploiement de Tableau Server dans un conteneur et pour la mise à l’échelle automatique des gestionnaires de processus en arrière-plan. Cette information suppose que vous connaissez et savez déjà comment déployer Tableau Server dans un conteneur autonome. Pour plus d’informations, consultez Tableau Server dans un conteneur. Pour configurer le déploiement, vous pouvez utiliser les trois fichiers de configuration Kubernetes situés dans la section Configuration Kubernetes comme modèles. Les autres sections de ce guide traitent des exigences et des détails du déploiement.

Le déploiement de Tableau Server et la mise à l’échelle automatique des gestionnaires de processus en arrière-plan devraient être aussi simples que ceux des fichiers de configuration Kubernetes qui figurent au bas du guide :

kubectl apply -f <tableau-kubeconfig-dir>

Tâches du gestionnaire de processus en arrière-plan

Les modules de gestionnaires de processus en arrière-plan aident Tableau Server dans un conteneur à calculer les autres charges de travail programmées en parallèle. Le gestionnaire de processus en arrière-plan gère l’actualisation des extraits, l’abonnement, l’alerte, le flux et les charges de travail du système. La répartition des tâches entre les modules de gestionnaires de processus en arrière-plan implique la mise à disposition d’un plus grand nombre de ressources informatiques pour permettre à Tableau Server de gérer d’autres tâches, comme les activités interactives des utilisateurs, notamment le rendu des classeurs et des tableaux de bord. Les tâches de flux sont le seul type de tâche du gestionnaire de processus en arrière-plan qui ne s’exécute pas dans le gestionnaire de processus en arrière-plan. Pour plus d’information sur les tâches du gestionnaire de processus en arrière-plan, consultez Gérer les tâches du gestionnaire de processus en arrière-plan dans Tableau Server.

Les modules de gestionnaires de processus en arrière-plan peuvent gérer tout type de charge, à l’exception des tâches de flux, qui doivent être exécutées dans les principaux conteneurs de Tableau Server; ces derniers continuent d’exécuter le service du gestionnaire de processus en arrière-plan.

La fonctionnalité Rôles de nœud donne aux utilisateurs la possibilité de dédier des modules de gestionnaires de processus en arrière-plan à un type de tâche 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 est disponible ici. Notez que, par défaut, les tâches de flux sont désactivées sur les modules de gestionnaires de processus en arrière-plan (c’est-à-dire que le rôle est défini sur « no-flows ») car les modules de gestionnaires de processus en arrière-plan ne peuvent pas exécuter de tâches de flux.

Pour configurer les rôles de nœud pour le gestionnaire de processus en arrière-plan, vous devez définir la variable d’environnement NODE_ROLES comme partie du fichier de configuration kubeconfig pour le conteneur qui exécute le service du gestionnaire de processus en arrière-plan. Par exemple, pour configurer le gestionnaire de processus en arrière-plan de manière à ce qu’il n’exécute que les tâches d’actualisation d’extraits, configurez la variable d’environnement NODE_ROLES pour l’actualisation d’extraits tel qu’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

Les modules de Tableau Server auront au moins un gestionnaire de processus en arrière-plan configuré de la même manière, ce qui est nécessaire pour s’assurer qu’il y a toujours un emplacement pour l’exécution des tâches du gestionnaire de processus en arrière-plan. Par défaut, TSM exigera qu’un gestionnaire de processus en arrière-plan capable de gérer chaque rôle de la tâche du gestionnaire de processus en arrière-plan soit disponible. Dans certains scénarios, vous voudrez peut-être que les modules du gestionnaire de processus en arrière-plan gèrent toutes les tâches d’un certain type. Pour cela, vous devez définir la clé de configuration du serveur topology.roles_handle_all_jobs_constraint_disabled sur true; cette action désactivera l’exigence selon laquelle la topologie TSM doit gérer tous les types de travaux. Lorsque ce paramètre est activé, le rôle du gestionnaire de processus en arrière-plan pour son instance sur Tableau Server peut être défini sur no-extract-refreshes et le rôle des modules de gestionnaires de processus en arrière-plan peut être défini sur extract-refreshes; cette action garantirait que toutes les tâches d’actualisation d’extraits ne s’exécutent que sur les modules de gestionnaires de processus en arrière-plan.

Remarque : la désactivation de cette contrainte vous permet de configurer des rôles de manière à ce que certains types de travaux ne seront jamais programmés. Il est important de bien définir la configuration des rôles et des tâches des gestionnaires de processus en arrière-plan dans TSM car TSM ne vérifiera plus que tous les types de tâches du gestionnaire de processus en arrière-plan peuvent être programmés.

Modules Tableau Server dans un conteneur

Les conteneurs Tableau Server utilisés dans le cadre de la mise à l’échelle automatique des modules de gestionnaires de processus en arrière-plan se déploient presque de la même manière que le Tableau Server dans un conteneur que nous utilisons. On note cependant quelques changements dans les principales exigences :

  • Un partage de fichiers réseau est nécessaire pour un transfert de configuration entre le conteneur Tableau Server et les modules de gestionnaires de processus en arrière-plan.
  • Vous devez activer et utiliser la fonctionnalité Stockage de fichiers externe. Cette action nécessite également un partage de fichiers réseau dédié.

Modules de gestionnaires de processus en arrière-plan

Les modules de gestionnaires de processus en arrière-plan sont quatre conteneurs de services indépendants qui fonctionnent ensemble : passerelle, hyper, serveur de données et gestionnaire de processus en arrière-plan. Vous pouvez déployer ces modules comme des modules authentiques du conteneur Kubernetes. Les exigences des modules sont les suivantes :

  • Les modules de gestionnaires de processus en arrière-plan devraient pouvoir atteindre le nœud Tableau Server à l’aide de la résolution DNS du nom d’hôte.
  • Il est impératif d’ouvrir les partages de fichiers réseau Stockage externe et Clonage.

Remarque : les modules de gestionnaires de processus en arrière-plan sont configurés avec init-container pour attendre que le conteneur Tableau Server ait réussi à produire une sortie de configuration de clonage avant l’exécution.

Fichiers journaux

Les services des modules de gestionnaires de processus en arrière-plan (comme Tableau Server) continuent d’écrire les fichiers journaux principalement sur le disque. Étant donné que les modules de gestionnaires de processus en arrière-plan peuvent être mis à l’échelle, ils sont éphémères. Il est donc essentiel de s’assurer que les fichiers journaux sont stockés en dehors des modules. De nombreux clients qui disposent d’environnements K8 existants utilisent déjà un service d’agrégation des fichiers journaux d’un certain type pour collecter les fichiers journaux des modules qu’ils déploient. Splunk et fluentd sont par exemples des services d’agrégation de fichiers journaux. Nous recommandons vivement aux clients d’utiliser n’importe quel service d’agrégation des fichiers journaux pour collecter les fichiers journaux de leurs modules de gestionnaires de processus en arrière-plan. Pour faciliter la gestion des fichiers journaux, le kubeconfig que nous fournissons configure chaque service du module de manière à écrire sur un volume de fichiers journaux partagé. Le chemin du répertoire dans chaque conteneur de services est spécifié par la variable d’environnement ROOT_LOG_DIR .

Si vous avez besoin d’ouvrir une demande d’assistance et de fournir des fichiers journaux, vous devez proposer deux ensembles de fichiers journaux : les fichiers journaux auto-décompressables collectés à partir des principaux conteneurs Server et les fichiers journaux des modules de gestionnaires de processus en arrière-plan (soit récupérés à partir de votre service d’agrégation de fichiers journaux, soit en suivant le processus manuel ci-dessous) .

Pour les clients qui ne peuvent pas utiliser un service d’agrégation de fichier journaux, il est possible de récupérer les fichiers journaux manuellement à partir des modules.

Remarque : les fichiers journaux provenant de tout module qui n’a pas utilisé de demande de volume persistant pour le volume contenant les fichiers journaux seront perdus lorsque le module sera mis à l’échelle!

Tous les fichiers journaux concernés sont disponibles dans le répertoire /var/log/tableau (configurable par l’intermédiaire de la variable d’environnement ROOT_LOG_DIR) située à dans le module de gestionnaires de processus en arrière-plan. Nous vous recommandons vivement de monter une demande de volume persistant à cet emplacement afin que les fichiers journaux soient disponibles lorsque le module est effacé.

Collecter des fichiers journaux lorsque le module de gestionnaires de processus en arrière-plan est en cours d’exécution :

Créez un fichier tar des fichiers journaux dans le 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 à l’extérieur du conteneur :

kubectl cp <backgrounder-pod-name>:docker/user/backgrounder-pod-logs.tar.gz ./backgrounder-pod-logs.tar.gz
Collecter des fichiers journaux lorsque le module de gestionnaires de processus en arrière-plan s’est fermé (ou n’a pas pu démarrer)

Associez n’importe quel module de longue durée à la demande de volume persistant montée qui est utilisée pour les fichiers journaux de déploiement du module de gestionnaires de processus en arrière-plan. Voici un 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 fichiers journaux dans le conteneur :

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

Copiez le fichier tar à l’extérieur du conteneur :

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

Changements de configuration en direct

Si vous modifiez des configurations dans Tableau Server dans un conteneur (par exemple en utilisant la ligne de commande tsm) et que vous souhaitez que ces changements de configuration soient représentées dans les modules de gestionnaires de processus en arrière-plan, vous devez exécuter la commande tsm settings clone pour créer un nouvel ensemble de fichiers de configuration clonés (« cloner la charge utile »).

  1. Utilisez TSM pour modifier des configurations dans le module Tableau Server dans un conteneur et appliquez les changements de configuration au serveur.
  2. Exécutez la commande suivante dans le module 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 modules de gestionnaires de processus en arrière-plan. Les modules doivent être configurés de manière à utiliser le lecteur Clone NFS et adopteront la nouvelle configuration.

Stratégies de mise à l’échelle

Les modules de gestionnaires de processus en arrière-plan peuvent être mis à l’échelle dans Kubernetes grâce à diverses techniques et stratégies. Nous proposons un exemple de stratégie de mise à l’échelle qui modifie la taille du pool du module de gestionnaires de processus en arrière-plan en fonction d’une programmation.

Notez que l’utilisation de l’unité centrale de traitement et de la mémoire ne sont pas des indicateurs appropriés pour la mise à l’échelle des modules de gestionnaires de processus en arrière-plan. L’utilisation de la mémoire et de l’unité centrale de traitement ne représente pas avec précision la demande de charge globale sur le groupement. Par exemple, un module de gestionnaires de processus en arrière-plan peut être utilisé tout au plus pour actualiser un extrait, mais aucune autre tâche n’est en attente dans la file d’attente des tâches du gestionnaire de processus en arrière-plan. Dans ce cas, la mise à l’échelle automatique ne permettra pas d’améliorer le débit des tâches.

Mise à l’échelle programmée

Les mécanismes Kubernetes standard qui utilisent des tâches cron vous permettent de programmer une solution de mise à l’échelle.

La section Configuration Kubernetes ci-dessous présente un exemple de configuration Kubernetes pour ce type de tâche.

Configuration Kubernetes

Nouvelles variables d’environnement

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

Variable d’environnementValeur recommandéeDescription
FILESTORE_MOUNT_PATH/docker/dataengineEmplacement de montage du répertoire de stockage de fichiers externe. Ce répertoire doit pointer sur le répertoire NFS du moteur de données monté dans chaque conteneur Tableau déployé. Pour plus d’information sur le stockage de fichiers externe, consultez Stockage de fichiers externe Tableau Server. La valeur doit être la même pour Tableau Server dans un module Conteneur et le module de gestionnaire de processus en arrière-plan.
CLONE_ARTIFACT_DIR/docker/clone/clone-artifactsEmplacement de montage du répertoire de la configuration du clonage. Ce répertoire doit pointer sur un répertoire NFS monté dans chaque conteneur Tableau. Tableau Server va générer les données de configuration que les modules de gestionnaires de processus en arrière-plan utilisent avant de devenir membres du groupement.
ROOT_LOG_DIR/var/log/tableau(Modules de gestionnaires de processus en arrière-plan uniquement)

Emplacement du répertoire de fichiers journaux courant pour tous les services exécutés dans un module de gestionnaires de processus en arrière-plan.

Ports du module de gestionnaires de processus en arrière-plan

Les modules de gestionnaires de processus en arrière-plan se composent de quatre services. Chacun est par défaut configuré pour s’exécuter sur un port spécifié. Si vous souhaitez modifier le port sur lequel le service se connecte à l’intérieur du conteneur, vous devez fournir la clé qui correspond à l’affectation du port du service. Dans la plupart des cas, ce type de configuration ne devrait pas être nécessaire, sauf si un conteneur side-car ou un composant supplémentaire est ajouté au module et entre en conflit avec le port d’un service

Variable d’environnement du portPar défaut
BACKGROUNDER_PORT8600
DATASERVER_PORT8400
HYPER_PORT8200
GATEWAY_PORT8080

Dataserver utilise également le port 8300 qui ne peut pas être reconfiguré.

Répertoire de réseau partagé

Ce déploiement Tableau Server a besoin de deux partages réseau pour fonctionner correctement. Notez que ces répertoires de réseau sont présents dans tous les modèles de configuration Tableau Server, d gestionnaire de processus en arrière-plan ou de Kubernetes :

  • Répertoire Dataengine (FILESTORE_MOUNT_PATH) : les modules de gestionnaires de processus en arrière-plan nécessitent la fonctionnalité de stockage 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 modules de gestionnaires de processus en arrière-plan.
  • Répertoire de clonage (CLONE_ARTIFACT_DIR) : Tableau Server écrit les données statiques de connexion et de configuration sur un partage réseau. Les modules de gestionnaires de processus en arrière-plan utiliseront ces données pour devenir membres du groupement Tableau Server. Dans les futures pré-versions, cette configuration sera intégrée au cycle de vie standard de la configuration Kubernetes.

Important : si vous souhaitez redéployer entièrement le groupement (notamment un nouveau conteneur Tableau Server), vous devez purger le contenu du montage NFS cloné (sinon les modules du gestionnaire de processus en arrière-plan tenteront 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 Tableau Server Container est un déploiement TSM à nœud unique (le déploiement peut inclure plusieurs modules de gestionnaire de processus en arrière-plan). Vous ne pouvez pas utiliser une sonde de préparation avec Tableau Server à plusieurs nœuds dans un déploiement 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 module de gestionnaires de processus en arrière-plan

---
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 la mise à l’échelle programmé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

Tâche Kubernetes pour nettoyer une 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 générée par Tableau Server dans un conteneur entre plusieurs exécutions de déploiement, vous pouvez exécuter une tâche comme 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