Escalado dinámico en un contenedor: información básica de Tableau Server

Introducción

El escalado dinámico del procesador en segundo plano en un contenedor permite aplicar varias estrategias de escalado a trabajos programados y del procesador en segundo plano en Tableau Server. El escalado automático en este contexto significa que los servicios se pueden escalar de forma independiente para manejar cargas de tareas variables sin requerir intervención humana o afectar el tiempo de actividad de otros sistemas de servidores. Los contenedores de Tableau Server que contienen nodos completos de procesos de Tableau Server seguirán ejecutándose como sistemas monolíticos. En su lugar, un conjunto más pequeño de servicios de contenedores independientes desacoplados que comprenden la función de servicio "procesador en segundo plano" será dinámicamente escalable y manejará la carga computacional que normalmente manejarían los contenedores de Tableau Server. Los servicios en segundo plano son responsables de procesar tareas del sistema que incluyen actualizar/crear extracciones, enviar suscripciones, verificar alertas de datos y muchos trabajos de mantenimiento. Si hay momentos, por ejemplo, en los que sería ventajoso actualizar una gran cantidad de conjuntos de datos o calcular una franja de alertas de datos computacionalmente costosas, ahora puede aprovechar Kubernetes para escalar la potencia de cómputo para completar esas tareas de manera eficiente. Esta guía cubre los requisitos de configuración e implementación para los procesadores de segundo plano de ajuste de escala automático en Kubernetes. Este documento es un complemento de la documentación de Tableau Server en un contenedor.

Requisitos previos

El ajuste de escala automático en segundo plano solo está disponible en Kubernetes y se basa en Tableau Server en contenedores. Para utilizar la función de escalado automático en segundo plano, debe cumplir ciertos requisitos previos:

Limitaciones

  • Esta funcionalidad solo funciona como parte de una implementación basada en Linux.
  • Los trabajos de flujo no se admiten en los procesadores de segundo plano de ajuste de escala automático. Los trabajos de flujo serán manejados por los servicios del procesador en segundo plano que continúan ejecutándose en el contenedor de Tableau Server.

Creación de imágenes de pod de Tableau Server y procesador en segundo plano

El primer paso para usar los fondos de escalado automático en contenedores es crear las imágenes de servicio que componen la instalación de Tableau Server. Estas imágenes incluirán la imagen de Tableau Server, así como imágenes para los servicios de procesador en segundo plano y de soporte por separado. Utiliza la misma herramienta de compilación que se usa para crear la imagen integral de contenedor de Tableau Server todo en uno, pero la herramienta debe ser de la versión 2022.3.0 o posterior, debe tener una licencia de Advanced Management y debe usar un marcador especial al construir las imágenes.

  1. Para crear las imágenes de servicio, ejecute este comando:

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

    Esto crea la imagen de Tableau Server y cuatro imágenes nuevas. Estas imágenes adicionales contienen servicios individuales que comprenden el nuevo pod de fondo autoescalable.

    El comando docker images enumera las imágenes creadas en el repositorio 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

    Las imágenes hyper, de puerta de enlace, del procesador en segundo plano y de servidor de datos comprenden el nuevo pod del procesador en segundo plano. Los controladores personalizados, los scripts de instalación y las propiedades se compartirán en estas cinco imágenes. Para obtener más información, consulte Personalización de la imagen.

  2. Publique todas estas imágenes en su repositorio de imágenes interno para su implementación.

Guía de implementación

La siguiente información proporciona contexto sobre cómo implementar Tableau Server en un contenedor y con escalado automático en segundo plano. Esta información supone que ya comprende y sabe cómo implementar Tableau Server en un contenedor independiente. Para obtener más información, consulte Tableau Server en un contenedor. Los tres archivos de configuración de Kubernetes en la sección Configuración de Kubernetes son plantillas que se pueden usar para configurar la implementación. Las otras secciones de esta guía cubren los requisitos y los detalles de la implementación.

La implementación de Tableau Server y Procesadores en segundo plano de autoescalado debería ser tan simple como implementar los archivos de configuración de Kubernetes completos en la parte inferior de la guía:

kubectl apply -f <tableau-kubeconfig-dir>

Trabajos del procesador en segundo plano

Los pods del procesador en segundo plano ayudan a Tableau Server en un contenedor a calcular cargas de trabajo programadas adicionales en paralelo. El procesador en segundo plano maneja las cargas de trabajo del sistema, la actualización, la suscripción, la alerta y el flujo. La distribución de trabajos entre los pods de antecedentes significa que habrá más recursos informáticos disponibles para que Tableau Server maneje otras tareas, como actividades interactivas de los usuarios, como la representación de libros de trabajo y dashboards. Los trabajos de flujo son el único tipo de trabajo del procesador en segundo plano que no se ejecuta en segundo plano. Para obtener detalles sobre los trabajos del procesador en segundo plano, consulte Gestionar trabajos del procesador en segundo plano en Tableau Server.

Los pods del procesador en segundo plano pueden manejar cualquier tipo de carga, excepto trabajos de flujo, que deben ejecutarse en los contenedores principales de Tableau Server, que continúan ejecutando el servicio del procesador en segundo plano.

La función de roles de nodo brinda a los usuarios la flexibilidad de dedicar pods del procesador en segundo plano para tipos específicos de trabajos. Esta funcionalidad es una extensión de la función Funciones de nodo en Tableau Server. La descripción detallada sobre los diferentes roles de nodo se puede encontrar aquí. Tenga en cuenta que, de manera predeterminada, los trabajos de flujo están deshabilitados en los pods del procesador en segundo plano (es decir, la función está configurada como "sin flujos") ya que los pods del procesador en segundo plano no pueden ejecutar trabajos de flujo.

Para configurar roles de nodo para el procesador en segundo plano, debe configurar la variable de entornoNODE_ROLES como parte de kubeconfig para el contenedor que ejecuta el servicio del procesador en segundo plano. Por ejemplo, para configurar el procesador en segundo plano para ejecutar solo trabajos de extracción y actualización, configure la variable de entorno NODE_ROLES para actualizaciones de extracción como se muestra a continuación:

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

Los pods de Tableau Server tendrán al menos un procesador en segundo plano configurado en su topología, lo cual es necesario para garantizar que siempre haya un lugar para ejecutar trabajos del procesador en segundo plano. De forma predeterminada, TSM requerirá que haya un procesador en segundo plano capaz de manejar todas las funciones del trabajo del procesador en segundo plano. En algunos escenarios, es posible que desee que los pods del procesador en segundo plano manejen todos los trabajos de un tipo particular. Para hacerlo, debe establecer la clave de configuración de Server topology.roles_handle_all_jobs_constraint_disabled en true, lo que desactivará el requisito de que la topología de TSM maneje todos los tipos de trabajo. Con este parámetro establecido, la función del procesador en segundo plano para la instancia del procesador en segundo plano de Tableau Server podría establecerse enno-extract-refreshes y la función de los pods del procesador en segundo plano podría establecerse en extract-refreshes, lo que garantizaría que todos los trabajos de actualización de extracción se ejecuten solo en los pods del procesador en segundo plano.

Nota: Deshabilitar esta restricción le permite configurar roles de modo que algunos tipos de trabajo nunca se programen. La configuración de funciones de los procesadores en segundo plano y los trabajos del procesador en segundo plano de TSM se debe establecer con cuidado porque TSM ya no verificará que todos los tipos de trabajos en segundo plano se puedan programar.

Tableau Server en pods de contenedor

Los contenedores con Tableau Server como parte de los pods de fondo de escalado automático se implementan casi de la misma manera que lo hace nuestro Tableau Server existente en un contenedor. Hay algunos cambios clave en los requisitos:

  • Se requiere un recurso compartido de archivos de red para transferir la configuración entre el contenedor de Tableau Server y los pods del procesador en segundo plano.
  • Debe habilitar y utilizar la función de almacenamiento de archivos externo. Esto también requiere un recurso compartido de archivos de red dedicado.

Pods del procesador en segundo plano

Los pods del procesador en segundo plano constan de cuatro contenedores de servicios independientes que funcionan juntos: puerta de enlace, hyper, servidor de datos y procesador en segundo plano. Puede implementar estos pods como los típicos pods de contenedores independientes de Kubernetes. Los pods tienen los siguientes requisitos:

  • Los pods del procesador en segundo plano deben poder llegar al nodo de Tableau Server mediante la resolución DNS del nombre de host.
  • Se deben proporcionar recursos compartidos de archivos de red de Clonación y almacenamiento de archivos externo.

Nota: Los pods del procesador en segundo plano están configurados con un contenedor de inicio para esperar hasta que el contenedor de Tableau Server haya producido correctamente una salida de configuración de clonación antes de continuar con la ejecución.

Registros

Los servicios de pods del procesador en segundo plano (como Tableau Server) todavía escriben registros predominantemente en el disco. Debido a que los pods del procesador en segundo plano se pueden escalar hacia adentro y hacia afuera, son efímeros, por lo que es esencial asegurarse de que los registros se almacenen fuera de los pods. Muchos clientes con entornos K8 existentes ya utilizarán un servicio de agregación de registros de algún tipo para recopilar los registros de los pods que implementan. Ejemplos de servicios de agregación de registros son Splunk y fluentd. Recomendamos encarecidamente que los clientes utilicen algún tipo de servicio de agregación de registros para recopilar los registros de sus pods del procesador en segundo plano. Para facilitar la administración de registros, el kubeconfig que proporcionamos configura cada servicio en el pod para escribir en un volumen de registro compartido. La ruta del directorio en cada contenedor de servicios se especifica mediante la variable de entorno ROOT_LOG_DIR.

Si necesita abrir un caso de soporte y proporcionar registros, proporcionará dos conjuntos de registros: ziplogs recopilados de los contenedores del servidor principal y registros de los pods del procesador en segundo plano (ya sea recuperados de su servicio de agregación de registros o usando el proceso manual a continuación).

Para los clientes que no pueden usar un servicio de agregación de registros, los registros se pueden recuperar manualmente desde los pods.

Nota: Los registros de cualquier pod que no haya utilizado una reclamación de volumen persistente para el volumen que contiene los registros se perderán cuando se reduzca la escala del pod.

Todos los registros relevantes están disponibles en el directorio /var/log/tableau (configurable mediante la variable de entorno ROOT_LOG_DIR) dentro del pod del procesador en segundo plano. Le recomendamos encarecidamente que monte un PersistantVolumeClaim en esta ubicación para que los registros estén disponibles cuando el pod muera.

Recopilación de registros cuando se esté ejecutando el pod del procesador en segundo plano:

Cree un archivo tar de los registros dentro del contenedor:

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

Copie el archivo tar fuera del contenedor:

kubectl cp <backgrounder-pod-name>:docker/user/backgrounder-pod-logs.tar.gz ./backgrounder-pod-logs.tar.gz
Recopilación de registros cuando el pod del procesador en segundo plano ha salido (o no se pudo iniciar)

Adjunte cualquier pod de ejecución prolongada con el montaje PersistantVolumeClaim que se usa para los registros de implementación del pod del procesador en segundo plano. Una configuración de ejemplo:

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

Cree un archivo tar de los registros dentro del contenedor:

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

Copie el archivo tar fuera del contenedor:

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

Cambios de configuración en tiempo real

Si realiza cambios de configuración en Tableau Server en un contenedor (por ejemplo, mediante la línea de comando tsm) y desea que esos cambios de configuración se representen en los pods del procesador en segundo plano, debe ejecutar el comando tsm settings clone para producir un nuevo conjunto de archivos de configuración de clonación ("carga útil de clonación").

  1. Utilice TSM para realizar cambios de configuración en Tableau Server en un pod de contenedor y aplicar los cambios de configuración al servidor.
  2. Ejecute el siguiente comando en Tableau Server en un pod de contenedor:

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

    Este comando crea un nuevo conjunto de archivos de configuración y los escribe en la ubicación de la unidad Clone NFS.

  3. Vuelva a implementar sus pods del procesador en segundo plano. Los pods deben configurarse para usar la unidad Clone NFS y recogerán la nueva configuración.

Estrategias de escalado

Los pods del procesador en segundo plano se pueden escalar en Kubernetes mediante una variedad de técnicas y estrategias. Proporcionamos un ejemplo de estrategia de escalado que cambia el tamaño del grupo de pods del procesador en segundo plano en función de un cronograma.

Tenga en cuenta que la utilización de la CPU y la memoria no son buenas métricas para escalar los pods del procesador en segundo plano. La utilización de la memoria y la CPU no representa con precisión la demanda de carga general en el clúster. Por ejemplo, un pod del procesador en segundo plano podría estar en uso máximo para actualizar una extracción, pero no hay trabajos adicionales esperando en la cola de trabajos del procesador en segundo plano. En este caso, el ajuste de escala automático no mejoraría el rendimiento del trabajo.

Escalado programado

Los mecanismos estándar de Kubernetes que utilizan trabajos cron le permiten programar una solución de escalado.

Se proporciona un ejemplo de configuración de Kubernetes para esto en la sección Configuración de Kubernetes a continuación.

Configuración de Kubernetes

Nuevas variables de entorno

Además de las variables de entorno estándar del contenedor de Tableau Server (consulte Opciones de configuración de iniciales), hay algunas variables de entorno nuevas requeridas que se deben establecer en la configuración de Kubernetes.

Variable de entornoValor recomendadoDescripción
FILESTORE_MOUNT_PATH/docker/dataengineUbicación de montaje del directorio externo del almacén de archivos. Este directorio debe apuntar al directorio NFS del motor de datos montado dentro de cada contenedor de Tableau implementado. Para obtener más información sobre el Almacén de archivos externo, consulte Almacén de archivos externo de Tableau Server. El valor debe ser el mismo para Tableau Server en un pod de contenedor y el pod de segundo plano.
CLONE_ARTIFACT_DIR/docker/clone/clone-artifactsClone la ubicación de montaje del directorio de configuración. Este directorio debe apuntar a un directorio NFS montado dentro de cada contenedor de Tableau. Tableau Server generará datos de configuración que consumen los pods en segundo plano para convertirse en miembros del clúster.
ROOT_LOG_DIR/var/log/tableau(solo pods del procesador en segundo plano)

Ubicación del directorio de registro común para todos los servicios que se ejecutan en un pod del procesador en segundo plano.

Puertos de pod del procesador en segundo plano

Los pods del procesador en segundo plano constan de cuatro servicios, cada uno de los cuales está configurado de forma predeterminada para ejecutarse en un puerto específico. Si desea cambiar el puerto al que se conecta el servicio dentro del contenedor, debe proporcionar la clave que corresponde a la asignación de puerto del servicio. Este tipo de configuración no debería ser necesaria en la mayoría de los casos, a menos que haya un contenedor sidecar o algún otro componente adicional que se agregue al pod y entre en conflicto con el puerto de un servicio.

Variable de entorno de puertoPredeterminado
BACKGROUNDER_PORT8600
DATASERVER_PORT8400
HYPER_PORT8200
GATEWAY_PORT8080

Dataserver también usa el puerto 8300, que no se puede reconfigurar.

Directorio de red compartido

Esta implementación de Tableau Server requiere dos recursos compartidos de red para funcionar correctamente. Tenga en cuenta que en todas las plantillas de configuración de Tableau Server y Kubernetes del pod del procesador en segundo plano están presentes estos directorios de red:

  • Directorio del motor de datos (FILESTORE_MOUNT_PATH): los pods del procesador en segundo plano requieren la funcionalidad de almacén de archivos externo. Este recurso compartido de red contiene extracciones y otros artefactos basados en archivos que se compartirán entre Tableau Server y los pods del procesador en segundo plano.
  • Clonar directorio (CLONE_ARTIFACT_DIR): Tableau Server escribe información de configuración y conexión estática en un recurso compartido de red. Los pods del procesador en segundo plano consumirán esta información para convertirse en miembros del clúster de Tableau Server. En versiones preliminares futuras, esta configuración se incorporará al ciclo de vida estándar de la configuración de Kubernetes.

Importante: Si desea volver a implementar el clúster por completo (incluido un nuevo contenedor de Tableau Server), debe purgar el contenido del montaje de NFS clonado (de lo contrario, los pods en segundo plano intentarán conectarse al servidor anterior).

Ejemplos de configuración de Kubernetes

Nota: Los ejemplos de configuración incluyen el uso de una sonda de preparación. Puede usar la sonda de preparación cuando la implementación del contenedor de Tableau Server es una implementación de TSM de un solo nodo (la implementación puede incluir varios pods en segundo plano). No puede usar una sonda de preparación con Tableau Server de varios nodos en implementaciones de contenedores.

Configuración de contenedor de 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

Configuración de pod del procesador en segundo plano

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

Configuración de escalado programado

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

Trabajo de Kubernetes para limpiar la configuración de clonación (opcional)

Este es un trabajo de conveniencia de Kubernetes que puede usar durante las pruebas. Si desea borrar la configuración de clonación producida por Tableau Server en un contenedor entre distintas ejecuciones de implementación, puede ejecutar un trabajo como este para limpiar el 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