update thanos helm chart

*.swp

*.bak

*.tmp

*.orig

*~

# Various IDEs

.project

.idea/

*.tmproj

.vscode/

dependencies:

- name: common

  repository: https://charts.bitnami.com/bitnami

  version: 1.4.1

digest: sha256:ab2523dc922e638d76a7d7af09cdfaf93a7ae9b73a6eeaa4a7c59a04b69dd10c

generated: "2021-02-24T15:12:57.801463663Z"

- name: kube-prometheus-stack

  repository: https://prometheus-community.github.io/helm-charts

  version: 85.2.0

- name: rustfs

  repository: https://charts.rustfs.com/

  version: 0.3.0

digest: sha256:6b208778b630d09a55acd2fe48aa30eb90244091428cf276e41696860cabc84c

generated: "2026-05-20T10:21:43.40615492+02:00"

annotations:

  category: Analytics

apiVersion: v2

appVersion: 0.18.0

dependencies:

- name: common

  repository: https://charts.bitnami.com/bitnami

  tags:

  - bitnami-common

  version: 1.x.x

description: Thanos is a highly available metrics system that can be added on top

  of existing Prometheus deployments, providing a global query view across all Prometheus

  installations.

home: https://github.com/bitnami/charts/tree/master/bitnami/thanos

icon: https://bitnami.com/assets/stacks/thanos/img/thanos-stack-220x234.png

name: thanos

description: A helm chart to setup Thanos on Kubernetes, a highly available Prometheus setup with long term storage capabilities.

type: application

version: 0.18.0

appVersion: "v0.41.0"

keywords:

- analytics

- monitoring

- prometheus

  - thanos

maintainers:

- email: containers@bitnami.com

  name: Bitnami

name: thanos

  - prometheus

  - monitoring

  - metrics

  - alerting

  - observability

  - kube-prometheus-stack

home: https://thanos.io/

sources:

- https://github.com/bitnami/bitnami-docker-thanos

- https://thanos.io

version: 3.14.0

  - https://github.com/thanos-io/thanos

  - https://github.com/thanos-community/helm-charts

icon: https://raw.githubusercontent.com/thanos-io/thanos/master/docs/img/Thanos-logo_fullmedium.png

deprecated: false

kubeVersion: ">= 1.30.0-0"

maintainers:

  - name: hamdikh

    email: hamdi.khelil@kapheira.cloud

dependencies:

  - name: kube-prometheus-stack

    alias: kube-prometheus-stack

    version: 85.2.0

    repository: https://prometheus-community.github.io/helm-charts

    condition: kube-prometheus-stack.enabled

  - name: rustfs

    version: "0.3.0"

    repository: https://charts.rustfs.com/

    condition: rustfs.enabled

annotations:

  artifacthub.io/license: Apache-2.0

  artifacthub.io/operator: "false"

  artifacthub.io/prerelease: "false"

  artifacthub.io/containsSecurityUpdates: "false"

  artifacthub.io/signKey: |

    fingerprint: BEAD950E9E7EBFE8CEC7E3F29D8EA313A3D349D8

    url: https://keys.openpgp.org/vks/v1/by-fingerprint/BEAD950E9E7EBFE8CEC7E3F29D8EA313A3D349D8

  artifacthub.io/images: |

    - name: thanos

      image: quay.io/thanos/thanos:v0.41.0

  artifacthub.io/links: |

    - name: Documentation

      url: https://thanos.io/tip/thanos/getting-started.md/

    - name: GitHub

      url: https://github.com/thanos-io/thanos

    - name: Slack

      url: https://cloud-native.slack.com/archives/CL25937SP

  artifacthub.io/changes: |

    - kind: added

      description: Per-component podLabels to set extra labels on pods (e.g. for workload identity), rendered via a shared thanos.podLabels helper for all workloads (bucketweb, compactor, query, query-frontend, store gateway, receive, receive ingester/router, ruler)

# Thanos Helm Chart

{{ template "chart.deprecationWarning" . }}

{{ template "chart.badgesSection" . }}

<p align="center"><img src="../../docs/imgs/thanos_logo_full.svg" alt="Thanos Logo" width="300"/></p>

{{ template "chart.description" . }}

## TL;DR

```bash

helm install thanos oci://ghcr.io/thanos-community/helm-charts/thanos \

  --namespace monitoring \

  --create-namespace

```

## Architecture

![Thanos High Level Architecture](../../docs/imgs/thanos_hld_arch.png)

Thanos extends Prometheus with global query view, long-term storage, and high availability. It is composed of several independently deployable components that each serve a specific role.

Refer to the [Thanos component docs](https://thanos.io/tip/thanos/quick-tutorial.md/#components) for an in-depth explanation.

{{ template "chart.maintainersSection" . }}

{{ template "chart.sourcesSection" . }}

## Prerequisites

- Kubernetes `{{ template "chart.kubeVersion" . }}`

- Helm >= 3.8 (OCI registry support)

- An object store bucket — GCS, S3, Azure Blob, or any S3-compatible store

{{ template "chart.requirementsSection" . }}

## Component Overview

The chart deploys each Thanos component as an independent workload. Enable only what you need.

| Component | Enabled by Default | Workload | Purpose |

|-----------|--------------------|----------|---------|

| **query** | Yes | Deployment | Fan-out query engine. Queries multiple Store API endpoints and deduplicates results. This is the Prometheus-compatible query entrypoint. |

| **receive** | Yes | StatefulSet | Remote-write endpoint. Accepts Prometheus `remote_write` traffic, stores samples locally, and ships blocks to the object store. |

| **storegateway** | Yes | StatefulSet | Serves historical blocks from the object store over the Store API. Required for querying data older than what Prometheus/Receive holds locally. |

| **compactor** | Yes | StatefulSet | Compacts and downsamples blocks in the object store. Runs as a singleton — do not scale above 1 replica. |

| **query-frontend** | No | Deployment | Optional caching and query-splitting layer in front of Query. Reduces load for repeated or heavy queries. |

| **ruler** | No | StatefulSet | Evaluates alerting and recording rules by querying the Query component. Sends alerts to Alertmanager. |

| **bucket (bucketweb)** | No | Deployment | Read-only web UI for inspecting blocks in the object store. Useful for debugging, not needed in production. |

## Installation

### 1. Add the Helm repository (optional, for non-OCI installs)

```bash

helm repo add thanos-community https://thanos-community.github.io/helm-charts

helm repo update

```

### 2. Configure object store credentials

All stateful Thanos components (Receive, Store Gateway, Compactor, Ruler) need access to an object store.

Create a `values.yaml` file with your object store configuration:

```yaml

global:

  objstore:

    # Set createSecret: true to let the chart create the Secret from the inline config below.

    # Set createSecret: false (default) if you manage the Secret externally.

    createSecret: true

    secretName: thanos-objstore

    secretKey: objstore.yml

    config: |

      type: S3

      config:

        bucket: my-thanos-bucket

        endpoint: s3.eu-west-1.amazonaws.com

        region: eu-west-1

        access_key: <ACCESS_KEY>

        secret_key: <SECRET_KEY>

```

### 3. Install the chart

```bash

helm install thanos oci://ghcr.io/thanos-community/helm-charts/thanos \

  --namespace monitoring \

  --create-namespace \

  -f values.yaml

```

### 4. Verify the installation

```bash

kubectl get pods -n monitoring -l app.kubernetes.io/instance=thanos

```

## Object Store Configuration

The object store config is shared by all components that write to or read from the object store. It follows the [Thanos object store YAML format](https://thanos.io/tip/thanos/storage.md/).

### Providing credentials

**Option A — let the chart create the Secret** (suitable for development):

```yaml

global:

  objstore:

    createSecret: true

    config: |

      type: GCS

      config:

        bucket: my-bucket

```

**Option B — bring your own Secret** (recommended for production):

Create the Secret externally (e.g. via Vault, External Secrets Operator, or `kubectl`):

```bash

kubectl create secret generic thanos-objstore \

  --from-file=objstore.yml=./objstore.yml \

  -n monitoring

```

Then reference it in values:

```yaml

global:

  objstore:

    createSecret: false

    secretName: thanos-objstore

    secretKey: objstore.yml

```

### Provider examples

<details>

<summary>Google Cloud Storage (GCS)</summary>

```yaml

type: GCS

config:

  bucket: my-thanos-bucket

  service_account: |-

    {

      "type": "service_account",

      ...

    }

```

</details>

<details>

<summary>Amazon S3 / S3-compatible</summary>

```yaml

type: S3

config:

  bucket: my-thanos-bucket

  endpoint: s3.eu-west-1.amazonaws.com

  region: eu-west-1

  access_key: AKIAIOSFODNN7EXAMPLE

  secret_key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

```

</details>

<details>

<summary>Azure Blob Storage</summary>

```yaml

type: AZURE

config:

  storage_account: mystorageaccount

  storage_account_key: <BASE64_ENCODED_KEY>

  container: thanos

  endpoint_suffix: core.windows.net

```

</details>

## Key Configuration Sections

### Global defaults

Settings under `global` apply to **all components** unless overridden at the component level. This avoids repeating common values (image, security context, node selectors, etc.).

```yaml

global:

  image:

    repository: quay.io/thanos/thanos

    tag: v0.39.2

    pullPolicy: IfNotPresent

  # Applied to every pod

  containerSecurityContext:

    allowPrivilegeEscalation: false

    readOnlyRootFilesystem: true

    capabilities:

      drop: [ALL]

    runAsNonRoot: true

  # Shared resource defaults (override per component as needed)

  resources: {}

  nodeSelector: {}

  tolerations: []

```

### Query

The Query component is the main entrypoint for PromQL queries. It fans out to all registered Store API endpoints and deduplicates results using replica labels.

```yaml

query:

  enabled: true

  replicaCount: 2

  # Labels that identify replica identity — used for deduplication

  replicaLabels:

    - prometheus_replica

    - receive_replica

  # gRPC --endpoint arguments. The in-chart components (Receive, Store Gateway, Ruler) are auto-wired

  # when autogen.enabled is true. Endpoints defined in static[] are always appended; set

  # autogen.enabled to false to take full control of what endpoint arguments are passed.

  endpoints:

    autogen:

      enabled: true

    static: []

    # Example:

    # static:

    #   - thanos-storegateway.cluster1.internal:443

    #   - thanos-receive.cluster1.internal:443

  # Deprecated. Use query.endpoints.static[] instead.

  stores: []

  ingress:

    http:

      enabled: false

      className: nginx

      hosts:

        - host: thanos-query.example.com

          paths:

            - path: /

              pathType: Prefix

```

### Receive

The Receive component accepts Prometheus `remote_write` traffic and stores samples locally in a TSDB WAL before shipping blocks to the object store.

```yaml

receive:

  enabled: true

  replicaCount: 3           # Minimum 3 for a replication factor of 2

  tsdb:

    retention: 24h          # How long to keep data locally before it is uploaded

    walCompression: true    # Reduces IO and disk usage

  persistence:

    enabled: true

    size: 10Gi

  # Hashring topology — defaults to auto-generating a single ring

  hashrings:

    autogen:

      enabled: true

      name: default

    # static: []            # Set to override autogen with a custom hashring config

```

Configure Prometheus to remote-write to the Receive service:

```yaml

# In your Prometheus / kube-prometheus-stack values

prometheus:

  prometheusSpec:

    remoteWrite:

      - url: http://thanos-receive.monitoring.svc.cluster.local:10908/api/v1/receive

```

#### Split mode (separate Router and Ingester)

For high-availability and horizontal scalability, Receive can be deployed as

two separate workloads following the [receive split proposal](https://thanos.io/tip/proposals-accepted/202012-receive-split.md):

- **Router** — stateless `Deployment` that terminates client `remote_write`

  traffic and forwards each request to the correct Ingester(s) according to the

  hashring config (with optional replication).

- **Ingester** — stateful `StatefulSet` that stores samples in a local TSDB WAL

  and ships blocks to the object store, just like standalone Receive.

Set `receive.mode: split` to opt in. In `split` mode the top-level `receive.*`

fields are **ignored**: configure the Ingester StatefulSet (renamed to

`<release>-thanos-receive-ingester`) via `receive.ingester.*`, and the Router

Deployment (`<release>-thanos-receive-router`) via `receive.router.*`. The

schema enforces that both `ingester` and `router` are populated when

`mode: split`.

```yaml

receive:

  enabled: true

  mode: split             # standalone (default) | split

  ingester:

    replicaCount: 3       # Minimum 3 for replication factor 2

    tsdb:

      retention: 24h

      walCompression: true

    service:

      grpcPort: 10901

      httpPort: 10902

      remoteWritePort: 10908

    persistence:

      enabled: true

      size: 10Gi

    hashrings:

      autogen:

        enabled: true

  router:

    replicaCount: 2

    replicationFactor: 2  # Each write fans out to N ingesters

```

In standalone mode (default), leave `receive.ingester` and `receive.router`

empty — all configuration lives directly under `receive.*`.

In split mode clients should remote-write to the Router service:

```

http://<release>-thanos-receive-router.<namespace>.svc.cluster.local:10908/api/v1/receive

```

### Store Gateway

The Store Gateway exposes historical blocks from the object store over the Store API. Query routes requests for older data to this component.

```yaml

storegateway:

  enabled: true

  replicaCount: 2

  persistence:

    enabled: true

    size: 10Gi              # Used for index cache and chunk downloads

  # Optional: add a caching bucket layer (memcached/redis) to reduce object store calls

  cachingBucketConfig: ""

```

### Compactor

The Compactor runs as a **singleton** (one instance). It compacts blocks uploaded by Receive into larger blocks and downsamples them for faster long-range queries.

```yaml

compactor:

  enabled: true

  replicaCount: 1           # Do NOT increase — compactor must run as a singleton

  # Retention is exposed as typed values. Set any of these to "" to disable.

  retention:

    resolutionRaw: 30d      # Keep raw samples for 30 days

    resolution5m: 90d       # Keep 5m-downsampled data for 90 days

    resolution1h: 365d      # Keep 1h-downsampled data for 1 year

  # --wait is always passed by the chart so the compactor keeps running as a

  # long-lived StatefulSet pod. Use extraArgs for everything else.

  extraArgs:

    - --consistency-delay=30m

  persistence:

    enabled: true

    size: 10Gi              # Used as a working directory during compaction

```

### Query Frontend (optional)

Sits in front of the Query component. Splits large time-range queries, caches results, and reduces load for repeated queries.

```yaml

queryFrontend:

  enabled: false            # Enable when query load is significant

  # Downstream URL of the Query component (auto-resolved when both are in the same chart)

  downstreamUrl: ""

  # Optional: inline caching config (Memcached, Redis, in-memory)

  cacheConfig: ""

```

### Ruler (optional)

Evaluates alerting and recording rules on a schedule by querying the Query component, mirroring how Prometheus rules work.

```yaml

ruler:

  enabled: false

  query:

    urls:

      - http://thanos-query.monitoring.svc.cluster.local:9090

  alertmanagers:

    config: |

      static_configs:

        - targets: ["alertmanager.monitoring.svc.cluster.local:9093"]

  # Inline rule files (key = filename, value = YAML content)

  rules:

    my-alerts.yaml: |

      groups:

        - name: example

          rules:

            - alert: MyAlert

              expr: up == 0

              for: 5m

  # Auto-import PrometheusRule CRDs from the cluster (requires kube-prometheus-stack)

  autoImportPrometheusRules:

    enabled: true

    labelSelector: {}

```

### Monitoring (ServiceMonitor)

Enable Prometheus scraping for each component by enabling its `serviceMonitor`:

```yaml

global:

  serviceMonitor:

    enabled: true           # Enables ServiceMonitor for all components at once

    namespace: monitoring   # Namespace where ServiceMonitors are created

```

Or enable per component:

```yaml

query:

  serviceMonitor:

    enabled: true

receive:

  serviceMonitor:

    enabled: true

```

### Built-in alerting rules

The chart ships with a set of PrometheusRules for Thanos components. They are enabled by default:

```yaml

global:

  thanosRules:

    enabled: true

    severity:

      critical: critical

      warning: warning

    forDefaults:

      default: 2m

      short: 1m

      componentDown: 5m

```

## Upgrading

Before upgrading, review the [chart changelog](https://github.com/thanos-community/helm-charts/releases) and the [Thanos release notes](https://github.com/thanos-io/thanos/releases).

```bash

helm upgrade thanos oci://ghcr.io/thanos-community/helm-charts/thanos \

  --namespace monitoring \

  -f values.yaml

```

## Values Reference

The table below documents all available values. Top-level keys group settings by component. Component-level keys always take precedence over `global` defaults.

{{ template "chart.valuesSection" . }}

---

{{ template "helm-docs.versionFooter" . }}