Dimensionamento dinâmico em um contêiner - Processadores em segundo plano do Tableau Server

Introdução

O dimensionamento dinâmico do Processador em segundo plano em um contêiner permite que várias estratégias de dimensionamento sejam aplicadas ao processador em segundo plano e aos trabalhos agendados no Tableau Server. O dimensionamento automático nesse contexto significa que os serviços podem ser dimensionados independentemente para lidar com cargas de tarefas variáveis sem exigir intervenção humana ou afetar o tempo de atividade de outros sistemas de servidor. Os contêineres do Tableau Server que tiverem nós completos de processos do Tableau Server continuarão sendo executados como sistemas monolíticos. Em vez disso, um conjunto menor de serviços de contêiner independentes desacoplados que compõem a função de serviço "segundo plano" será dinamicamente escalonável e lidará com a carga computacional que normalmente seria tratada pelos contêineres do Tableau Server. Os serviços de segundo plano são responsáveis por processar tarefas do sistema que incluem atualização/criação de extrações, envio de assinaturas, verificação de alertas de dados e muitos trabalhos de manutenção. Se houver momentos, por exemplo, em que seria vantajoso atualizar um grande número de conjuntos de dados ou calcular uma série de alertas de dados computacionalmente caros, agora você pode aproveitar o Kubernetes para aumentar o poder de computação para concluir essas tarefas com eficiência. Este guia aborda os requisitos de configuração e implantação para Backgrounders de escalonamento automático no Kubernetes. Este documento é um suplemento da documentação do Tableau Server em um contêiner.

Pré-requisitos

O escalonamento automático em segundo plano só está disponível no Kubernetes e é baseado no Tableau Server em contêineres. Para usar o recurso de segundo plano de escalonamento automático, você deve atender a certos pré-requisitos:

Limitações

  • Esse recurso funciona apenas como parte de uma implantação baseada em Linux.
  • Os trabalhos de fluxo não são compatíveis com os fundos de escalonamento automático. Os trabalhos de fluxo serão tratados pelos serviços de segundo plano que continuam sendo executados no contêiner do Tableau Server.

Criação de imagens de pods do Tableau Server e Processador em segundo plano

A primeira etapa para usar processadores em segundo plano de escalonamento automático em contêineres é criar as imagens de serviço que compõem a instalação do Tableau Server. Essas imagens incluirão a imagem do Tableau Server, bem como imagens para o processador em segundo plano separado e os serviços de suporte. Você usa a mesma ferramenta de compilação usada para criar a imagem abrangente de contêiner do Tableau Server “tudo em um”, mas a ferramenta deve ser a versão 2022.3.0 ou posterior, você deve ter uma licença de Advanced Management e precisa usar uma licença especial sinalizar ao construir as imagens.

  1. Para criar as imagens de serviço, execute este comando:

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

    Isso cria o Tableau Server e quatro novas imagens. Essas imagens adicionais contêm serviços individuais que compõem o novo pod de plano de fundo escalonável automaticamente.

    O comando docker images lista as imagens criadas no repositório local do docker:

    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

    As imagens hyper, gateway, backgrounder e dataserver compõem o novo pod do processador em segundo plano. Drivers personalizados, scripts de instalação e propriedades serão compartilhados em todas essas cinco imagens. Para obter mais informações, consulte Personalização da imagem.

  2. Publique todas essas imagens em seu repositório de imagens interno para implantação.

Guia de Implantação

As informações a seguir fornecem contexto sobre como implantar o Tableau Server em um contêiner e com processadores em segundo plano de escalonamento automático. Essas informações pressupõem que você já entende e sabe como implantar o Tableau Server em um contêiner de autocontêiner. Para obter mais informações, consulte Tableau Server em um contêiner. Os três arquivos de configuração do Kubernetes na seção Configuração do Kubernetes são modelos que podem ser usados para configurar a implantação. As outras seções deste guia abrangem os requisitos e os detalhes da implantação.

A implantação do Tableau Server e dos Processadores em segundo plano de escalonamento automático deve ser tão simples quanto implantar os arquivos de configuração do Kubernetes preenchidos na parte inferior do guia:

kubectl apply -f <tableau-kubeconfig-dir>

Trabalhos do Processador em segundo plano

Os pods do Processador em segundo plano ajudam o Tableau Server em um contêiner a computar cargas de trabalho agendadas adicionais em paralelo. O Processador em segundo plano lida com a atualização de extração, assinatura, alerta, fluxo e cargas de trabalho do sistema. Distribuir trabalhos entre os pods do processador em segundo plano significa que haverá mais recursos de computação disponíveis para o Tableau Server lidar com outras tarefas, como atividades interativas do usuário, como renderização de pastas de trabalho e painéis. Os trabalhos de fluxo são o único tipo de trabalho de segundo plano que não é executado no processador em segundo plano. Para obter detalhes sobre trabalhos de segundo plano, consulte Gerenciar trabalhos do Processador em segundo plano no Tableau Server .

Os pods de segundo plano podem lidar com qualquer tipo de carga, exceto trabalhos de fluxo, que devem ser executados nos contêineres principais do Tableau Server, que continuam a executar o serviço do processador em segundo plano.

O recurso Funções de nó oferece aos usuários a flexibilidade de dedicar pods de backgrounder para tipos específicos de trabalhos. Esse recurso é uma extensão do recurso Funções de nó no Tableau Server. A descrição detalhada sobre diferentes funções de nó pode ser encontrada aqui. Observe que, por padrão, os trabalhos de fluxo são desabilitados nos pods do processador em segundo plano (ou seja, a função é definida como "sem fluxos"), pois os pods do processador em segundo plano não conseguem executar trabalhos de fluxo.

Para configurar funções de nó para o processador em segundo plano, você precisa definir a variável de ambiente NODE_ROLES como parte do kubeconfig para o contêiner que executa o serviço de processador em segundo plano. Por exemplo, para definir o processador em segundo plano para executar apenas trabalhos de extração e atualização, configure a variável de ambiente NODE_ROLES para extrair atualizações conforme mostrado abaixo:

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

Os pods do Tableau Server terão pelo menos um processador em segundo plano configurado em sua topologia, o que é necessário para garantir que sempre haja um local para executar trabalhos em segundo plano. Por padrão, o TSM exigirá que haja um processador em segundo plano capaz de lidar com todas as funções da tarefa em segundo plano. Em alguns cenários, você pode querer que os pods do processador em segundo plano lidem com todos os trabalhos de um tipo específico. Para fazer isso, você deve definir a chave de configuração do servidor topology.roles_handle_all_jobs_constraint_disabled para true, que desativará o requisito de que a topologia do TSM lide com todos os tipos de trabalho. Com esse parâmetro definido, a função de segundo plano para a instância de segundo plano do Tableau Server pode ser definida como no-extract-refreshes e a função dos pods do processador em segundo plano pode ser definida comoextract-refreshes, o que garantiria que todos os trabalhos de atualização de extração sejam executados apenas nos pods do processador em segundo plano.

Observação: desabilitar essa restrição permite configurar funções de forma que alguns tipos de trabalho nunca sejam agendados. A configuração da função de segundo plano e tarefas de segundo plano do TSM deve ser definida com cuidado porque o TSM não verificará mais se todos os tipos de trabalho de segundo plano podem ser planejados.

Pods do Tableau Server em um Contêiner

Os contêineres com o Tableau Server como parte dos pods do processador em segundo plano de escalonamento automático são implantados quase da mesma maneira que nosso Tableau Server existente em um contêiner. Existem algumas mudanças importantes nos requisitos:

  • Um compartilhamento de arquivos de rede é necessário para transferir a configuração entre o contêiner do Tableau Server e os pods do processador em segundo plano.
  • Você deve habilitar e usar o recurso Armazenamento de arquivos externo. Isso também requer um compartilhamento de arquivos de rede dedicado.

Pods de processador em segundo plano

Os pods do processador em segundo plano consistem em quatro contêineres de serviço independentes trabalhando juntos: gateway, hyper, dataserver e backgrounder. Você pode implantar esses pods como pods de contêiner independentes típicos do Kubernetes. Os pods têm os seguintes requisitos:

  • Os pods do processador em segundo plano devem ser capazes de alcançar o nó do Tableau Server usando a resolução DNS do nome do host.
  • Os compartilhamentos de arquivos de rede de armazenamento de arquivos e clones externos devem ser fornecidos.

Observação: os pods do processador em segundo plano são configurados com um contêiner de inicialização para aguardar até que o contêiner do Tableau Server tenha produzido com êxito a saída de configuração de clone antes de continuar a execução.

Registros:

Os serviços de pod do processador em segundo plano (como o Tableau Server) ainda gravam registros predominantemente no disco. Como os pods do processador em segundo plano podem ser ampliados e reduzidos, eles são efêmeros, portanto, é essencial garantir que os registros sejam armazenados fora dos pods. Muitos clientes com ambientes K8s existentes já usarão um serviço de agregação de registro de algum tipo para coletar os registros dos pods que eles implantam. Exemplos de serviços de agregação de log são Splunk e fluentd. É altamente recomendável que os clientes usem algum tipo de serviço de agregação de registros para coletar os registros de seus pods de backgrounder. Para facilitar o gerenciamento de registros, o kubeconfig que fornecemos configura cada serviço no pod para gravar em um volume de registros compartilhado. O caminho do diretório em cada contêiner de serviço é especificado pela variável de ambiente ROOT_LOG_DIR.

Se precisar abrir um caso de suporte e fornecer registros, você fornecerá dois conjuntos de registros: ziplogs coletados dos principais contêineres do servidor e registros dos pods do processador em segundo plano (recuperados de seu serviço de agregação de registros ou usando o processo manual abaixo) .

Para clientes que não podem usar um serviço de agregação de registros, os registros podem ser recuperados manualmente dos pods.

Observação: os registros de qualquer pod, que não usou uma reivindicação de volume persistente para o volume que contém os registros, serão perdidos quando o pod tiver o dimensionamento reduzido!

Todos os registros relevantes estão disponíveis no diretório /var/log/tableau (configurável através da variável de ambiente ROOT_LOG_DIR) dentro do pod do processador em segundo plano. É altamente recomendável que você monte um PersistantVolumeClaim nesse local para que os registros fiquem disponíveis quando o pod morrer.

Coletando registros quando o pod do processador em segundo plano está em execução:

Crie um arquivo tar dos registros dentro do container:

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

Copie o tarfile para fora do container:

kubectl cp <backgrounder-pod-name>:docker/user/backgrounder-pod-logs.tar.gz ./backgrounder-pod-logs.tar.gz
Coletando registros quando o pod do processador em segundo plano saiu (ou não foi iniciado)

Anexe qualquer pod de longa duração com a montagem PersistantVolumeClaim que é usada para registros de implantação de pod do processador em segundo plano. Um exemplo de configuração:

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

Crie um arquivo tar dos registros dentro do container:

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

Copie o tarfile para fora do container:

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

Alterações de configuração dinâmicas

Se você fizer alterações de configuração no Tableau Server em um contêiner (por exemplo, usando a linha de comando tsm) e quiser que essas alterações de configuração sejam representadas em pods do processador em segundo plano, será necessário executar o comando tsm settings clone para produzir um novo conjunto de arquivos de configuração clone ("carga útil do clone").

  1. Use o TSM para fazer alterações de configuração no Tableau Server em um pod de contêiner e aplique as alterações de configuração ao servidor.
  2. Execute os seguintes comandos no Tableau Server em um pod de Contêiner.

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

    Este comando cria um novo conjunto de arquivos de configuração e o grava no local da unidade Clone NFS.

  3. Reimplemente seus pods do processador em segundo plano. Os pods devem ser configurados para usar a unidade Clone NFS e selecionarão a nova configuração.

Estratégias de dimensionamento

Os pods do processador em segundo plano podem ser dimensionados no Kubernetes usando uma variedade de técnicas e estratégias. Fornecemos um exemplo de estratégia de dimensionamento que altera o tamanho do pool de pods do processador em segundo plano com base em um cronograma.

Observe que a utilização de CPU e memória não são boas métricas para dimensionar pods do processador em segundo plano. A utilização de memória e CPU não retrata com precisão a demanda de carga geral no cluster. Por exemplo, um pod do processador em segundo plano pode estar na utilização máxima para atualizar uma extração, mas não há trabalhos adicionais aguardando na fila de trabalhos do processador em segundo plano. Nesse caso, o escalonamento automático não melhoraria o rendimento do trabalho.

Escalonamento agendado

Os mecanismos padrão do Kubernetes que usam trabalhos cron permitem agendar uma solução de dimensionamento.

Um exemplo de configuração do Kubernetes para isso é fornecido na seção Configuração do Kubernetes abaixo.

Configuração de kubernetes

Variáveis de ambiente novas

Além das variáveis de ambiente de contêiner padrão do Tableau Server (consulte Opções de configuração inicial), há algumas novas variáveis de ambiente necessárias que devem ser definidas na configuração do Kubernetes.

Variáveis de ambienteValor recomendadoDescrição
FILESTORE_MOUNT_PATH/docker/dataengineLocal de montagem do diretório do Armazenamento de arquivos externo. Esse diretório deve apontar para o diretório NFS do dataengine montado dentro de cada contêiner do Tableau implantado. Para obter mais informações sobre o Armazenamento de arquivos externo, consulte Armazenamento de arquivos externo do Tableau Server. O valor deve ser o mesmo para o Tableau Server em um pod de Contêiner e o pod de Processador em segundo plano.
CLONE_ARTIFACT_DIR/docker/clone/clone-artifactsLocalização de montagem do diretório de configuração do clone. Esse diretório deve apontar para um diretório NFS montado dentro de cada contêiner do Tableau. O Tableau Server gerará dados de configuração que os pods do processador em segundo plano consomem para se tornarem membros do cluster.
ROOT_LOG_DIR/var/log/tableau(Somente pods do processador em segundo plano)

Local do diretório de registro comum para todos os serviços executados em um pod do processador em segundo plano.

Porta do pod do processador em segundo plano

Os pods do processador em segundo plano consistem em quatro serviços, cada um, por padrão, configurado para ser executado em uma porta especificada. Se você deseja alterar a porta à qual o serviço se conecta dentro do contêiner, é necessário fornecer a chave que corresponde à atribuição de porta do serviço. Esse tipo de configuração não deve ser necessário na maioria dos casos, a menos que haja um contêiner sidecar ou algum outro componente adicional que esteja sendo adicionado ao pod e entre em conflito com a porta de um serviço.

Variável de ambiente da portaPadrão
BACKGROUNDER_PORT8600
DATASERVER_PORT8400
HYPER_PORT8200
GATEWAY_PORT8080

O Dataserver também usa a porta 8300, que não pode ser reconfigurada.

Diretório de rede compartilhada

Essa implantação do Tableau Server requer dois compartilhamentos de rede para funcionar corretamente. Observe que em todos os modelos de configuração do Tableau Server e Processador em segundo plano do Kubernetes esses diretórios de rede estão presentes:

  • Diretório de mecanismo de dados (FILESTORE_MOUNT_PATH ): Os pods do processador em segundo plano requerem o recurso Armazenamento de arquivos externo. Esse compartilhamento de rede contém extrações e outros artefatos baseados em arquivo que serão compartilhados entre o Tableau Server e os pods do processador em segundo plano.
  • Clonar diretório (CLONE_ARTIFACT_DIR ): o Tableau Server grava informações estáticas de conexão e configuração em um compartilhamento de rede. Os pods do processador em segundo plano consumirão essas informações para se tornarem membros do cluster do Tableau Server. Em futuros pré-lançamentos, essa configuração será inserida ao ciclo de vida padrão da configuração do Kubernetes.

Importante: se você quiser reimplantar o cluster inteiramente (incluindo um novo contêiner do Tableau Server), deverá limpar o conteúdo da montagem NFS do clone (caso contrário, os pods do processador em segundo plano tentarão se conectar ao servidor antigo).

Exemplos de configuração do Kubernetes

Observação: os exemplos de configuração incluem o uso de uma sondagem de prontidão. Você pode usar a investigação de prontidão quando a implantação do Tableau Server Container for uma implantação TSM de nó único (a implantação pode incluir vários pods de segundo plano). Você não pode usar uma investigação de prontidão com implantações de vários nós do Tableau Server em um contêiner.

Configuração de contêiner do 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

Configuração do pod do processador em 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: {}

Configuração de escalonamento agendado

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

Trabalho do Kubernetes para limpar a configuração do clone (opcional)

Este é um trabalho de conveniência do Kubernetes que você pode usar durante o teste. Se quiser limpar a configuração de clone produzida pelo Tableau Server em um contêiner entre execuções de implantação distintas, você pode executar um trabalho como este para limpar o 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