Skip to content

Overview

Tunables overview⚓︎

Hydrolix uses tunables, a set of YAML key-value pairs, to configure Hydrolix cluster and secrets behavior, referred to as Hydrolix tunables.

In version 5.0, Hydrolix added the Hydrolix Tunable Names (HTN) naming convention to give a more granular level of control over cluster behavior. These HTN tunables work in conjunction with the existing Hydrolix tunables.

Hydrolix defines all tunables in the hydrolixcluster.yaml file, under spec:.

Hydrolix tunables⚓︎

Hydrolix tunables are used to provide global Hydrolix cluster control, and affect all levels of the cluster. See the Hydrolix Tunables List for more information.

Examples of Hydrolix tunables⚓︎

  • decay_reap_batch_size
  • http_response_timeout_ms
  • prometheus_scrape_interval

HTN tunables⚓︎

HTN tunables can be set at different levels: service, pool, and container. The HTN convention provides a clear naming structure and fine control over cluster behavior.

Format structure for HTN tunables⚓︎

HTN tunables follow a specific naming convention:

htn:tunable_name:service_name:pool_name:container_name: value

The key components for each HTN tunable are:

  • htn: Prefix indicates the tunable uses the HTN naming structure
  • tunable_name: The tunable parameter name
  • service_name: (Optional) The service where the tunable is applied, can be omitted by using an empty string
  • pool_name: (Optional) The pool in the service, can be left empty
  • container_name: (Optional) The specific container in the pool and service, can be left empty
  • value: The tunable value

Omit levels⚓︎

Use HTN tunables for more flexibility when defining specific levels isn't needed. For example, leave any optional component of the HTN blank if there's no need to specify it.

Set empty values with consecutive colons, ::.

Empty value examples⚓︎

  • htn:tunable_name::: 0 applies 0 globally (derivative case, equivalent to Hydrolix tunable)
  • htn:tunable_name:service_name:: 0 applies 0 only to a specific service
  • htn:tunable_name:service_name:pool_name:: 0 applies 0 to a service and a pool, but not a specific container

Tunable precedence order⚓︎

HTN tunables take precedence over Hydrolix tunables. If no HTN tunable exists in the hydrolixcluster.yaml file, Hydrolix uses the non-HTN tunable. If neither an HTN or Hydrolix tunable exists, Hydrolix uses the system default.

Tunables precedence Tunables precedence (dark)

Scheduled overrides⚓︎

You can automate temporary overrides for any tunable using scheduled overrides.

Overrides are specified within the Hydrolix spec configuration and take effect when the container's current time falls within the schedule block specified for an override. The HDX custom resource definition itself is never mutated by the contents of the overrides block. Instead, overrides live only in the operator memory.

Example scheduled overrides⚓︎

The following are example configuration blocks to create schedule overrides. For configuration information, scale-related examples, limitations, and verification steps, see the scheduled overrides page.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
spec:
  overrides:
    linode-quiet-weekends:
      timezone: America/Los_Angeles
      weekly:
        days: ["Fri..Mon"]
        start: "17:00"
        end: "08:00"
      patch:
        silence_linode_alerts: true # turn off Linode alerts for LKE nodes

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
# reduce ingest (intake-head) to 1 replica with minimal CPU and memory allocation and disable intake spill functionality
# gameday an overwhelmed intake-head replica 
spec:
  overrides:
    gameday-reduce-ingest-disable-spill:
      timezone: Europe/Vatican
      window:
        start: "2025-07-30T10:00:00Z"
        end: "2025-07-30T10:30:00Z"
      patch:
        pools:
          intake-head:
            replicas: 1
            cpu: 1
            memory: 2Gi
        intake_head_catalog_spill_config:
          enabled: false
        intake_head_raw_data_spill_config:
          enabled: false

1
2
3
4
5
6
7
8
9
spec:
  overrides:
    november-no-prometheus:
      timezone: Brazil/East
      cron:
        expression: "0 11 11 11 11 ?" # Fire every November 11 at 11:11 AM
        duration: "11h"
      patch:
        prometheus_enabled: false # disable prometheus