Skip to main content
Version 3.0

General Configuration

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

TDP component configuration​

Configuration is the step in which a TDP Kubernetes component is adapted to the environment and the chosen mode of operation.
It defines how the component will be deployed, which resources it will use, how it will be exposed, which dependencies it needs, and how it will integrate with other platform services.

In practice, configuration allows adjusting parameters such as namespace, CPU, memory, storage, secrets, external access, persistence, and shared integrations — such as databases, object storage, and supporting services.
This means the same component can be used in different contexts, such as lab, staging, and production, without changing its main function.

Examples:

  • Connecting Airflow to the cluster's PostgreSQL instead of using the built-in database
  • Telling Kafka how many broker replicas and what minimum replication factor to use
  • Telling NiFi where the LDAP server is for authentication
  • Configuring the Ozone S3 Gateway with the correct credentials so Spark can write data

Configuration parameters apply regardless of the installation method used.
The goal of this page is to explain what can normally be configured in a TDP component and how those adjustments work in practice.

Throughout this section, the most common configuration patterns across TDP components are presented:

AreaWhat it definesExamples
Cluster executionWhere and with which resources the component will run.Namespace, CPU, memory, replicas, and limits.
PersistenceHow data will be stored.Volumes, disk, storage class, and retention.
Service exposureHow the component will be accessed.Service, port, ingress, hostname, and TLS.
Security and accessHow credentials and sensitive data will be provided.Secrets, users, passwords, tokens, and secret references.
IntegrationsHow the component connects to other services.PostgreSQL, S3/Ozone, endpoints, and shared services.
Application methodHow configuration reaches the cluster.Helm, Argo CD/GitOps, and future tdpctl.

Where to find available parameters​

Before customizing a component's configuration, there are three main sources:

  • The component page in this guide — each component has a page with supported parameters, examples, and component-specific notes.
  • The chart's values.yaml — contains all accepted parameters with their default values and explanatory comments; accessible via helm show values.
  • The chart's README — available in the registry, provides an overview of options and use cases.
info

Run helm show values oci://registry.tecnisys.com.br/tdp/charts/<CHART_NAME> to export all available parameters with their default values and explanatory comments.

Figure 1 — Export default values
Figure 1 — Export default values

This command exports the chart's default values to a local file values-padrao.yaml.
This file can be used as a reference to identify which parameters to adjust for the environment.

Custom values file​

Component configuration is done through a YAML file containing only the parameters that need to differ from the chart's defaults.
There is no need to copy the entire chart values file — include only the keys you want to override.

The values file defines what will be configured. Helm or Argo CD define how that configuration will be applied to the cluster — in both flows, the format and parameters are identical.

Minimal values file example:

meu-values.yaml
# Include only what needs to differ from the default
resources:
  requests:
    cpu: "500m"
    memory: "1Gi"
  limits:
    cpu: "2"
    memory: "2Gi"

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

The procedures below show how to apply the values to the cluster via Helm or Argo CD.

note

Helm automatically merges your values with the chart defaults — include only the keys you want to customize.

Ways to provide values​

Values file (recommended) — create a YAML with the keys to change and pass it with -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

--set flag — for one-off changes directly on the command line:

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

File combination — multiple files merged in order, with later files taking precedence:

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-production.yaml

Step by step​

Discover available parameters

Before starting, export the values accepted by the chart. See Where to find available parameters.

  1. Create the values file (e.g.: meu-values.yaml):
PowerShell
code .\meu-values.yaml
  1. Adjust the desired parameters, such as namespace, resources, or integrations:
meu-values.yaml
resources:
  requests:
    cpu: "500m"
    memory: "1Gi"
  limits:
    cpu: "1"
    memory: "2Gi"
  1. Apply the configuration with the created file:
Terminal input
helm upgrade --install <RELEASE_NAME> oci://registry.tecnisys.com.br/tdp/charts/<CHART_NAME> \
  -n <NAMESPACE> --create-namespace \
  -f meu-values.yaml
Figure 3 - Configuration of the created file
Figure 3 - Configuration of the created file
  1. Verify that the configured values were applied:
Terminal input
helm get values <RELEASE_NAME> -n <NAMESPACE>
Figure 4 - Checking configured values
Figure 4 - Checking configured values
  1. Check the pods:
Terminal input
kubectl get pods -n <NAMESPACE>
Figure 5 - Checking pods
Figure 5 - Checking pods
note

For stateful components, such as PostgreSQL, also validate:

kubectl get statefulset -n <NAMESPACE>
Figure 6 - Validating stateful components
Figure 6 - Validating stateful components

For components using Deployment, also validate:

kubectl get deploy -n <NAMESPACE>
  1. Confirm that the release has deployed status and the revision is updated:
Terminal input
helm list -n <NAMESPACE>
Figure 7 - Helm list
Figure 7 - Helm list
Next step

To access a specific component configuration, go back to the configuration index.