Sizing And Overrides

XTrinode uses layered runtime configuration. Start with typed fields, then move to lower-level override surfaces only when a workload has a clear reason.

Configuration Layers

Layer	Field	Use for
Size preset	spec.size	Standard coordinator and worker CPU, memory, limits, default worker guidance, and recommended machine types.
Node-pool override	spec.nodePool	Provider, machine type, min/max nodes, disk, zones, spot, labels, taints, and prewarm behavior.
Privileged overlay	spec.valuesOverlay	Advanced pod, image, scheduling, service, Trino config, auth, sidecar, HPA, and resource settings read by native resource builders.

Supported size presets are xs, s, m, l, and xl. Presets use larger limits than requests because Trino workloads are bursty: requests drive scheduling, while limits define burst and failure boundaries.

Preset First

Use the smallest preset that fits steady-state query demand.

apiVersion: analytics.xtrinode.io/v1
kind: XTrinode
metadata:
  name: analytics
  namespace: team-a
spec:
  size: s
  minWorkers: 0
  maxWorkers: 8

Increase pod limits only when queries hit memory or CPU ceilings. Lower limits only when predictable bin-packing matters more than burst capacity.

Override Node Shape

Override the node-pool machine type when the preset pod resources are acceptable but node capacity, I/O, worker density, or system overhead needs a different machine.

spec:
  size: s
  nodePool:
    name: analytics-nodes
    provider: gcp
    providerMode: managed
    clusterName: xtrinode-gke-test
    kubernetesVersion: v1.35.3
    minNodes: 1
    maxNodes: 10
    gcp:
      machineType: e2-standard-8

For AWS and Azure, the experimental provider-validation paths use provider-specific machine fields such as instanceType and vmSize. Live CAPA/CAPZ parity remains a tracked validation item.

Changing machine type can recreate provider capacity. Use the documented break-glass annotation flow for disruptive machine-type updates.

Use valuesOverlay Sparingly

valuesOverlay is not a raw Helm values pass-through. The operator reads a known chart-shaped surface through native resource builders. Unsupported keys are ignored unless a builder handles them.

Common supported areas include:

Overlay key	Behavior
image	Overrides Trino image repository, tag, and pull policy.
server, server.config	Applies selected Trino server configuration.
server.autoscaling	Creates worker HPA settings from CPU or memory targets.
coordinator, worker	Sets role-specific resources, probes, lifecycle, labels, annotations, ports, scheduling, volumes, and mounts.
auth	Supports password and group file authentication through inline Secret generation or existing Secret references.
env, envFrom	Adds environment variables and environment sources.
securityContext, containerSecurityContext, shareProcessNamespace	Applies pod or container security settings.
sidecarContainers	Adds sidecars to Trino pods.
configMounts, secretMounts	Adds global config and secret volumes and mounts.
sessionProperties, kafka, resourceGroups, jmx	Creates and mounts those Trino configuration areas when configured.
networkPolicy, service	Applies selected network policy and Service settings such as port.

Treat overlays as privileged input. They can alter images, security context, volumes, environment sources, networking, and Trino behavior.

Control Auth

When Trino HTTP authentication is enabled, configure spec.trinoControlAuth so the operator and worker shutdown hooks can call internal Trino control APIs.

spec:
  trinoControlAuth:
    username: xtrinode-operator
    passwordSecret:
      name: trino-control-auth
      key: password

The referenced Secret must live in the same namespace as the runtime, and the same user must exist in Trino password auth configuration.

Native Trino HTTPS server mode is not supported for managed runtimes yet. Use TLS termination outside Trino until native HTTPS coordinator and control support is implemented.

Choosing The Mechanism

Need	Prefer
Standard runtime sizing	spec.size
Different node capacity with the same pod resources	spec.nodePool machine type
More or fewer workers	minWorkers, maxWorkers, and KEDA settings
Different coordinator or worker requests and limits	spec.valuesOverlay.coordinator.resources or spec.valuesOverlay.worker.resources
Advanced Trino config, sidecars, service settings, or worker HPA	spec.valuesOverlay with platform-level authorization