InfluxDB on Kubernetes with the Official Helm Chart
The most surprising thing about running InfluxDB on Kubernetes isn’t that it works, but how much of its operational complexity just vanishes when you do it right.
Let’s see it in action. We’ll deploy InfluxDB, write some data, and query it back.
First, add the InfluxDB Helm repository:
helm repo add influxdata https://helm.influxdata.com/
helm repo update
Now, we can install InfluxDB. We’ll keep it simple for now, but you’ll want to customize values.yaml for production.
helm install my-influxdb influxdata/influxdb --version 7.0.0 --namespace influxdb --create-namespace
This deploys a stateful InfluxDB instance. Kubernetes handles the persistent storage, networking, and even basic health checks.
To access it, we’ll port-forward:
kubectl port-forward --namespace influxdb svc/my-influxdb 8086:8086
Now, open your browser to http://localhost:8086 or use influx CLI:
influx --host http://localhost:8086
Let’s create a bucket and write some data:
> CREATE DATABASE telegraf
> USE telegraf
> INSERT cpu,host=server01 usage_user=10,usage_system=20,usage_idle=70
And query it:
> SELECT * FROM cpu
name: cpu
time host usage_idle usage_system usage_user
---- ---- ---------- ------------ ------------
2023-10-27T10:00:00Z server01 70 20 10
That’s InfluxDB running, managed by Kubernetes. The Helm chart abstracts away the details of setting up StatefulSets, PersistentVolumeClaims, Services, and Secrets. It’s designed to give you a robust, production-ready InfluxDB instance with minimal fuss.
The core mental model is the StatefulSet. Unlike a regular Deployment, a StatefulSet guarantees stable, unique network identifiers, stable persistent storage, and ordered, graceful deployment and scaling. For InfluxDB, this means each replica gets its own persistent volume, ensuring data durability. The Service provides a stable endpoint to access your InfluxDB cluster, even if pods restart or are rescheduled.
One of the most powerful, yet often overlooked, aspects of the Helm chart is its integration with InfluxDB’s multi-tenancy features. By default, the chart doesn’t expose user management or organization creation directly through the Helm values. Instead, it assumes you’ll use InfluxDB’s API or UI after deployment to set up your organizations, users, and permissions. This separation of concerns allows the chart to focus on reliable deployment while leaving the fine-grained security and access control to InfluxDB itself. You can, however, pre-seed certain configurations like initial buckets or users by mounting custom configuration files into the InfluxDB pods via the extraConfigmap or extraSecret values, which is crucial for automated bootstrapping.
The next step is to explore how to integrate InfluxDB with Telegraf for metrics collection and how to set up InfluxDB’s high availability features.