Advanced Helm configuration

These settings go beyond the install described in Install with Helm: placing workloads on particular nodes, adding labels and annotations, mounting extra volumes, and trusting your own certificate authorities. All of them go in the values file you installed with, and take effect when you run the install command again.

Place workloads on node pools

Each workload takes the standard Kubernetes scheduling settings, nodeSelector, tolerations and affinity, under its own key in the values file:

Workload	Values
Server	gravitino.nodeSelector, gravitino.tolerations, gravitino.affinity, gravitino.topologySpreadConstraints
UI and metrics service	nodeSelector, tolerations, affinity at the top level of the values file; the two share them
MCP server	mcp.nodeSelector, mcp.tolerations, mcp.affinity
Lineage API and web view	marquez.nodeSelector, marquez.tolerations, marquez.affinity
OpenSearch	opensearch.nodeSelector, opensearch.tolerations, opensearch.affinity
Registry-token renewal job	global.pullSecrets.ecrRefresh.nodeSelector, .tolerations, .affinity

The in-cluster metadata database has no scheduling values, so it runs wherever the scheduler places it. On a cluster where every node pool is tainted, use an external database; see Metadata database.

The example puts every workload on a node pool labelled pool: datastrato and tainted dedicated=datastrato:NoSchedule:

my-values.yaml

nodeSelector:
  pool: datastrato
tolerations:
  - key: dedicated
    operator: Equal
    value: datastrato
    effect: NoSchedule

gravitino:
  nodeSelector:
    pool: datastrato
  tolerations:
    - key: dedicated
      operator: Equal
      value: datastrato
      effect: NoSchedule

mcp:
  nodeSelector:
    pool: datastrato
  tolerations:
    - key: dedicated
      operator: Equal
      value: datastrato
      effect: NoSchedule

marquez:
  nodeSelector:
    pool: datastrato
  tolerations:
    - key: dedicated
      operator: Equal
      value: datastrato
      effect: NoSchedule

opensearch:
  nodeSelector:
    pool: datastrato
  tolerations:
    - key: dedicated
      operator: Equal
      value: datastrato
      effect: NoSchedule

The server needs a node with 8Gi of memory free for its request; see the workloads and resources table in Install with Helm.

Labels and annotations

Pod annotations carry settings for tools that read them, such as a service mesh, a log collector or a backup operator. Pod labels let policies and monitoring select the pods.

Workload	Pod annotations	Pod labels
Server	gravitino.podAnnotations	gravitino.podLabels
UI	enterpriseWeb.podAnnotations
Metrics service	metrics.podAnnotations
MCP server	mcp.podAnnotations
Lineage API	marquez.marquez.podAnnotations

To give the server's Kubernetes service account a cloud identity, such as an IAM role on EKS or a Google service account on GKE, annotate it with gravitino.serviceAccount.annotations.

Extra volumes and containers

The server takes extra volumes, containers and init containers:

Value	Adds
gravitino.extraVolumes	Volumes on the server pod
gravitino.extraVolumeMounts	Mounts of those volumes in the server container
gravitino.extraInitContainers	Containers that run before the server starts
gravitino.extraContainers	Containers that run beside the server, such as a log shipper

The chart refuses to render a mount of a Secret that does not exist yet, so create the Secret first. /opt/gravitino/logs is always the chart's logs volume and cannot be remounted. The Google Cloud credentials section shows a complete example. The MCP server takes mcp.extraVolumes and mcp.extraVolumeMounts the same way.

Trust your own certificate authorities

When the server connects to a database, metastore, identity provider or other service whose certificate is signed by an internal certificate authority, import that authority into the server's Java trust store:

Store the CA certificates in a Secret

kubectl -n "$NAMESPACE" create secret generic internal-ca --from-file=ca.crt=./internal-ca.crt

my-values.yaml

gravitino:
  ssl:
    trustStore:
      enabled: true
      existingSecrets:
        - name: internal-ca

Every .crt and .pem file in each Secret listed is imported. existingSecret takes a single Secret instead. ssl.trustStore.javaOptions adds Java system properties for TLS, such as -Djavax.net.debug=ssl:handshake while troubleshooting a handshake.

The UI makes its own TLS connections, to your identity provider for sign-in. When the identity provider's certificate comes from an internal authority, mount the same Secret into the UI and point Node.js at it:

my-values.yaml

enterpriseWeb:
  volumes:
    - name: internal-ca
      secret:
        secretName: internal-ca
  volumeMounts:
    - name: internal-ca
      mountPath: /etc/internal-ca
      readOnly: true
  env:
    - name: NEXTAUTH_URL
      value: ""
    - name: NODE_EXTRA_CA_CERTS
      value: /etc/internal-ca/ca.crt

enterpriseWeb.env replaces the chart's list, so keep the NEXTAUTH_URL entry with the value you installed with.

Environment variables

Environment variables for the server go in gravitino.env, and for the UI in enterpriseWeb.env. See Configuration files and environment.

Related

• Install with Helm
• Secrets
• Ports and network
• Start, stop and restart