Skip to content

Thanos

Overview

Thanos extends a Prometheus deployment with a global query view and long-term metric storage. This package wraps the Bitnami Thanos chart and adds Big Bang routes, network policies, monitoring integration, and Gluon health, object-store, and SSO tests.

Big Bang integration

Use the Thanos integration in the selected Big Bang release. Releases supporting packageConfiguration.version: v1 accept packages.thanos with that explicit opt-in; Big Bang 3.x configurations that have not opted into that contract use the legacy addons.thanos path. The umbrella owns Flux source and release wiring, global credentials, and cross-package values; this chart owns the rendered Thanos resources.

A usable deployment needs the surrounding integrations to be configured:

  • Prometheus: the monitoring package configures its Prometheus sidecar and discovery service for Thanos. Deploy and configure Monitoring with Thanos; validate Sidecar and Store endpoints after installation.
  • Grafana: when enabled in Big Bang, Grafana receives a Thanos data source. Grafana ownership and dashboard configuration remain in the Grafana package.
  • Object storage: configure an S3-compatible endpoint, bucket, region, and credentials through the Big Bang package configuration. For in-cluster storage, deploy and configure Big Bang Garage separately; this chart does not provision it. Bundled MinIO is no longer supported, and the Bitnami subchart’s MinIO dependency must remain disabled. Keep access keys and secrets in encrypted secret values rather than documentation or plain-text values files.
  • Ingress and authentication: package routes expose the query frontend through the selected Istio gateway. Enable SSO only with the required Big Bang Authservice and identity-provider configuration; the SSO client secret is owned by the umbrella configuration, not this chart’s documentation.

The package defaults to disabled. See the Big Bang Values Reference for the exact umbrella contract, including the object-storage and SSO entry points.

Dependencies

Configuration

Big Bang-specific values such as routes, istio, and networkPolicies now live under the bb-common key in the generated package README. Existing standalone chart overlays must migrate these paths when upgrading to 17.6.0-bb.6:

  • routes → bb-common.routes
  • istio → bb-common.istio
  • networkPolicies → bb-common.networkPolicies

The package schema rejects the old root-level paths rather than silently ignoring them. The bb-common dependency owns nested Istio and route-host validation; these package checks run when Helm validates this chart, not the umbrella. monitoring and bbtests remain at the package root. Standalone chart users who set the Thanos route host should now configure global.domain; the obsolete top-level domain value has been removed. The upstream parent passes values to the vendored Bitnami chart; use the version-matched Bitnami Thanos values for 17.6.0 for that configuration surface rather than copying nested upstream values into this guide.

The wrapper sets Iron Bank image overrides and preserves the thanos resource name used by routes, policies, monitoring, and tests. Keep those package-owned overrides aligned when upgrading the dependency; general Thanos and Bitnami configuration belongs upstream.

Starting with package version 17.6.0-bb.4, the bundled minio-instance dependency has been removed. Omit the top-level minio package-values key entirely, even when set to enabled: false: the chart schema rejects its presence, as well as upstream.minio.enabled: true. Before upgrading, migrate old values overlays and ensure the selected umbrella release no longer injects that removed key. Configure an existing S3-compatible store or Garage instead.

Operations and validation

For existing external object storage, these package values show the configuration Secret reference and the components that consume it:

upstream:
  minio:
    enabled: false
  existingObjstoreSecret: thanos-object-storage
  storegateway:
    enabled: true
  compactor:
    enabled: true

Provision thanos-object-storage in the Thanos namespace with key objstore.yml through an approved secret-management workflow. Its contents are the Thanos provider configuration (for S3: type, endpoint, bucket, region, authentication, and TLS settings), not Helm values. Use the Thanos storage reference for that format, and never commit static access keys in the configuration. upstream.existingObjstoreSecret overrides inline upstream.objstoreConfig; it does not create the Secret, bucket, permissions, or network access.

In umbrella v1 configuration, place this fragment under packages.thanos.values with packageConfiguration.version: v1. Keep upstream Bitnami MinIO disabled. Configure Prometheus block shipping with the matching object-store contract and review query discovery, storage egress, and the single intended compactor before enabling these components. Store Gateway reads and Compactor rewrites/deletes metric blocks; a successful render is not durability or recovery evidence.

Object storage holds metric blocks. Before production use, plan durability, capacity, retention, encryption, recovery, compaction, credential rotation, and rollback. Test a clean installation and upgrade with the intended Prometheus, Grafana, Istio, and object-store integrations. A local chart render cannot prove block shipping, compaction, query results, SSO trust, or metric continuity.

The package’s Cypress suites cover the Thanos UI/query path, optional Prometheus sidecar checks, and the SSO redirect/login flow. The optional S3 script test uses authenticated bucket listing to check for Thanos block metadata in Garage when bbtests.scripts.envs.THANOS_S3_ENDPOINT and the required credentials are configured. These tests require a disposable integrated Big Bang environment and are not local unit tests.

For upstream behavior, architecture, and release notes, use the Thanos v0.42.4 release and the Bitnami Thanos chart.