Saltar para o conteúdo principal
Versão 3.0

Configuração Geral

CompatibilidadeKubernetes1.32+OpenShift4.19+Rancher2.10.x+Helm3.2.0+

Configuração de componentes TDP​

A configuração é a etapa em que um componente TDP Kubernetes é adaptado ao ambiente e ao modo de operação adoptado.
Define como o componente será implantado, quais os recursos que utilizará, como será exposto, de quais dependências necessita e como se integrará com os restantes serviços da plataforma.

Na prática, a configuração permite ajustar parâmetros como namespace, CPU, memória, armazenamento, secrets, acesso externo, persistência e integrações partilhadas — como base de dados, armazenamento de objectos e serviços de apoio.
Assim, o mesmo componente pode ser utilizado em contextos distintos, como laboratório, homologação e produção, sem alterar a sua função principal.

Exemplos:

  • Ligar o Airflow à base de dados PostgreSQL do cluster em vez de utilizar a base de dados interna
  • Indicar ao Kafka quantas réplicas de broker e qual o factor de replicação mínimo
  • Informar o NiFi do endereço do servidor LDAP para autenticação
  • Configurar o S3 Gateway do Ozone com as credenciais correctas para que o Spark possa gravar dados

Os parâmetros de configuração aplicam-se independentemente do método de instalação utilizado.
O objectivo desta página é explicar o que pode normalmente ser configurado num componente TDP e como esses ajustes funcionam na prática.

Ao longo desta secção, são apresentados os padrões de configuração mais comuns entre os componentes TDP:

ÁreaO que defineExemplos
Execução no clusterOnde e com que recursos o componente será executado.Namespace, CPU, memória, réplicas e limites.
PersistênciaComo os dados serão armazenados.Volumes, disco, storage class e retenção.
Exposição do serviçoComo o componente será acedido.Service, porta, ingress, hostname e TLS.
Segurança e acessoComo as credenciais e dados sensíveis serão fornecidos.Secrets, usuários, palavras-passe, tokens e referências a secrets.
IntegraçõesComo o componente se liga a outros serviços.PostgreSQL, S3/Ozone, endpoints e serviços partilhados.
Forma de aplicaçãoComo a configuração chega ao cluster.Helm, Argo CD/GitOps e futuramente tdpctl.

Onde consultar os parâmetros disponíveis​

Antes de personalizar a configuração de um componente, existem três fontes principais:

  • A página do componente neste guia — cada componente tem uma página com os parâmetros suportados, exemplos e observações específicas do componente.
  • O values.yaml do chart — contém todos os parâmetros aceites com os seus valores predefinidos e comentários explicativos; acessível via helm show values.
  • O README do chart — disponível no registry, oferece uma visão geral das opções e casos de utilização.
informação

Execute helm show values oci://registry.tecnisys.com.br/tdp/charts/<CHART_NAME> para exportar todos os parâmetros disponíveis com os seus valores predefinidos e comentários explicativos.

Figura 1 — Exportar os valores padrão do chart
Figura 1 — Exportar os valores padrão do chart

Este comando exporta os valores predefinidos do chart para um ficheiro local values-padrao.yaml.
Este ficheiro pode ser utilizado como referência para identificar quais os parâmetros a ajustar para o ambiente.

Ficheiro de valores personalizado​

A configuração de um componente é feita por meio de um ficheiro YAML com apenas os parâmetros que precisam de ser alterados em relação ao padrão do chart.
Não é necessário copiar o ficheiro completo de valores do chart — inclua apenas as chaves que pretende substituir.

O ficheiro de valores define o que será configurado. O Helm ou o Argo CD definem como essa configuração será aplicada ao cluster — em ambos os fluxos, o formato e os parâmetros são idênticos.

Exemplo mínimo de ficheiro de valores:

meu-values.yaml
# Inclua apenas o que precisa ser diferente do padrão
resources:
  requests:
    cpu: "500m"
    memory: "1Gi"
  limits:
    cpu: "2"
    memory: "2Gi"

persistence:
  size: 20Gi
  storageClassName: "nfs-fast"

Os procedimentos a seguir mostram como aplicar os valores ao cluster via Helm ou Argo CD.

nota

O Helm faz merge automático dos seus valores com os predefinidos do chart — inclua apenas as chaves que pretende personalizar.

Formas de fornecer valores​

Ficheiro de valores (recomendado) — crie um YAML com as chaves a alterar e passe com -f:

Terminal input
helm upgrade --install <RELEASE_NAME> oci://registry.tecnisys.com.br/tdp/charts/<CHART_NAME> \
  -n <NAMESPACE> --create-namespace \
  -f meu-values.yaml

Flag --set — para alterações pontuais directamente na linha de comando:

Terminal input
helm upgrade --install <RELEASE_NAME> oci://registry.tecnisys.com.br/tdp/charts/<CHART_NAME> \
  -n <NAMESPACE> --create-namespace \
  --set parametro.chave=valor

Combinação de ficheiros — múltiplos ficheiros mesclados por ordem, com os últimos a ter precedência:

Terminal input
helm upgrade --install <RELEASE_NAME> oci://registry.tecnisys.com.br/tdp/charts/<CHART_NAME> \
  -n <NAMESPACE> --create-namespace \
  -f values-base.yaml \
  -f values-producao.yaml

Passo a passo​

Descobrir parâmetros disponíveis

Antes de começar, exporte os valores aceites pelo chart. Consulte Onde consultar os parâmetros disponíveis.

  1. Crie o ficheiro de valores (exemplo: meu-values.yaml):
PowerShell
code .\meu-values.yaml
  1. Ajuste os parâmetros pretendidos, como namespace, recursos ou integrações:
meu-values.yaml
resources:
  requests:
    cpu: "500m"
    memory: "1Gi"
  limits:
    cpu: "1"
    memory: "2Gi"
  1. Aplique a configuração com o ficheiro criado:
Terminal input
helm upgrade --install <RELEASE_NAME> oci://registry.tecnisys.com.br/tdp/charts/<CHART_NAME> \
  -n <NAMESPACE> --create-namespace \
  -f meu-values.yaml
Figura 3 - Configuração do ficheiro criado
Figura 3 - Configuração do ficheiro criado
  1. Verifique se os valores configurados foram aplicados:
Terminal input
helm get values <RELEASE_NAME> -n <NAMESPACE>
Figura 4 - Verificação dos valores configurados
Figura 4 - Verificação dos valores configurados
  1. Verifique os pods:
Terminal input
kubectl get pods -n <NAMESPACE>
Figura 5 - Verificação dos pods
Figura 5 - Verificação dos pods
nota

Para componentes stateful, como PostgreSQL, valide também:

kubectl get statefulset -n <NAMESPACE>
Figura 6 - Validação de componentes stateful
Figura 6 - Validação de componentes stateful

Para componentes que utilizam Deployment, valide também:

kubectl get deploy -n <NAMESPACE>
  1. Confirme que o release tem o estado deployed e que a revisão foi actualizada:
Terminal input
helm list -n <NAMESPACE>
Figura 7 - Helm list
Figura 7 - Helm list
Próximo passo

Para aceder à configuração de um componente específico, volte ao índice de configuração.