--- schema_version: "1" id: 0e6c4c2b0e583da42c11e5d27aeba129865b868691f163513d58d46746146376 title: "Escalado dinámico en un contenedor: información básica de Tableau Server" collection: tableau version: current locale: es-es portal_url: https://docs.salesforce.com/tableau/current/es-es/server-linux/server-backgrounder-autoscaling.md canonical_url: https://help.tableau.com/current/server-linux/es-es/server-backgrounder-autoscaling.htm source_site: help.tableau.com content_type: documentation content_hash: 37a3c4e26538698d0da39b061df61cc9f20990aea4ab8963c626c627c31a7bd1 description: Configure dynamic scaling of Backgrounders for Tableau Server in a container. --- [Saltar al contenido principal](#main-content) # 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](https://help.tableau.com/current/server-linux/es-es/server-in-container.htm). ## 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: - Tableau Server debe tener capacidades de administración avanzada. Para obtener más información , consulte [Acerca de Tableau Advanced Management en Tableau Server](https://help.tableau.com/current/server-linux/es-es/itm_intro.htm). - Debe utilizar licencias basadas en usuarios. Las licencias principales no son compatibles. Para obtener más información sobre las licencias, consulte [Conocer los modelos de licencia y las claves de producto](https://help.tableau.com/current/server-linux/es-es/license_product_keys.htm). - Las siguientes funcionalidades de Advanced Management deben estar habilitadas: - [Almacén de archivos externo de Tableau Server](https://help.tableau.com/current/server-linux/es-es/server_external_filestore_storage.htm) - [Repositorio externo de Tableau Server](https://help.tableau.com/current/server-linux/es-es/server_external_repo.htm) - Debe tener un clúster de Kubernetes versión 1.20 o posterior y comprender cómo usarlo y administrarlo. ## 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 --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](https://help.tableau.com/current/server-linux/es-es/server-in-container_setup-tool.htm#CustomizingImage). 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](https://help.tableau.com/current/server-linux/es-es/server-in-container.htm). 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 ### 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](https://help.tableau.com/current/server-linux/es-es/server_backgrounder_job_management.htm). 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 entorno`NODE_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 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 en`no-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 -- bash -c "tar -czf /docker/user/backgrounder-pod-logs.tar.gz /var/log/tableau" Copie el archivo tar fuera del contenedor: kubectl cp :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: 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 -- bash -c "tar -czf /backgrounder-pod-logs.tar.gz /var/log/tableau" Copie el archivo tar fuera del contenedor: kubectl cp :/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](https://help.tableau.com/current/server-linux/es-es/cli_settings_tsm.htm#TSMSettingsClone)` 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](https://help.tableau.com/current/server-linux/es-es/server-in-container_image.htm#InitialConfigOptions-container)), 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 puerto | Predeterminado | | --- | --- | | `BACKGROUNDER_PORT` | `8600` | | `DATASERVER_PORT` | `8400` | | `HYPER_PORT` | `8200` | | `GATEWAY_PORT` | `8080` | 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: namespace: spec: selector: app: ports: - protocol: TCP port: 8080 nodePort: name: http - protocol: TCP port: 8443 nodePort: name: https type: NodePort \--- apiVersion: v1 kind: ConfigMap metadata: name: configfile 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: data: config.json: |- { "flavor":"generic", "masterUsername":"", "masterPassword":"", "host":"", "port":5432, "prerequisiteCheckEnabled":false, "requireSsl":false } \--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: datadir1 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: spec: accessModes: - ReadWriteMany capacity: storage: 1Gi nfs: server: path: \--- \# This is required for multi-node tableau server in container apiVersion: v1 kind: PersistentVolumeClaim metadata: name: bootstrapnfs namespace: spec: accessModes: - ReadWriteMany storageClassName: "" resources: requests: storage: 1Mi \--- apiVersion: v1 kind: PersistentVolumn metadata: name: clonenfs namespace: spec: accessModes: - ReadWriteMany capacity: storage: 1Gi nfs: server: path: \--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: clonenfs namespace: spec: accessModes: - ReadWriteMany storageClassName: "" resources: requests: storage: 1Mi \--- apiVersion: v1 kind: PersistentVolume metadata: name: dataenginenfs namespace: spec: accessModes: - ReadWriteMany capacity: storage: 1Gi nfs: server: path: \--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: dataenginenfs namespace: spec: accessModes: - ReadWriteMany storageClassName: "" resources: requests: storage: 1Mi \--- apiVersion: v1 kind: Secret type: Opaque metadata: name: tableau-server-in-a-container-secrets namespace: stringData: license\_key: # Tableau License Key String tableau\_username: # Initial admin username in Tableau Server tableau\_password: # Initial admin password \--- apiVersion: apps/v1 kind: StatefulSet metadata: name: tableau-server namespace: labels: app: spec: selector: matchLabels: app: replicas: 1 serviceName: template: metadata: labels: app: spec: securityContext: runAsUser: 999 fsGroup: 998 fsGroupChangePolicy: "OnRootMismatch" terminationGracePeriodSeconds: 120 dnsPolicy: "None" dnsConfig: nameservers: - # DNS IP for resolving container hostnames searches: - ..svc.. # SRV Record - .svc.. # SRV Record - svc.. # SRV Record - . # 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: # Name of container 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: spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi \--- apiVersion: apps/v1 kind: Deployment metadata: name: backgrounder labels: app: backgrounder 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 for resolving container hostnames searches: - ..svc.. # SRV Record - .svc.. # SRV Record - svc.. # SRV Record - . # 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 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 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 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 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: path: - name: dataengine-volume nfs: server: 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 \--- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: scale-backgrounder-pods 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 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: 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: # IP for shared NFS directory for clone output path: /clone