Set up prerequisites
InfluxDB Clustered requires the following prerequisites:
Kubernetes cluster: version 1.25 or higher
Object storage: AWS S3 or S3-compatible storage used to store the InfluxDB Parquet files.
We strongly recommend that you enable object versioning in your object store.
PostgreSQL-compatible database (AWS Aurora, hosted Postgres, etc.): Used to store the InfluxDB catalog
- Supported PostgreSQL versions: 13.8–14.6
- Ensure that the PostgreSQL-compatible instance is dedicated exclusively to InfluxDB. This avoids conflicts and prevents issues caused by shared usage with other applications.
OAuth 2.0 provider:
- Must support Device Authorization Flow
- Tested and supported providers:
TLS certificate: for ingress to the cluster
Set up a Kubernetes cluster
- Deploy a Kubernetes cluster. Kubernetes v1.25 or later is required.
- Create two namespaces–
influxdb
andkubit
. - Install an ingress controller in the cluster and a mechanism to obtain a valid TLS certificate (for example: cert-manager or provide the certificate PEM manually out of band). To use the InfluxDB-specific ingress controller, install Ingress NGINX.
- Ensure your Kubernetes cluster can access the InfluxDB container registry, or, if running in an air-gapped environment, a local container registry to which you can copy the InfluxDB images.
It is strongly recommended that you run the PostgreSQL-compatible database (that stores the InfluxDB Catalog) and the Object Store (that stores InfluxDB Parquet files) in a separate namespace from InfluxDB or external to Kubernetes entirely.
Running the Catalog database and Object Store in a separate namespace or outside of Kubernetes makes management of the InfluxDB instance easier and helps to prevents accidental data loss.
While deploying everything in the same namespace is possible for testing or initial setup, it is not recommended for production environments.
Cluster sizing recommendation
For a medium-size workload, InfluxData has tested InfluxDB Clustered using the following AWS products and sizing:
- S3 for the object store (size is determined by how much data you write)
- Aurora Postgresql - serverless v2 scaling configuration (2-64 ACUs)
- EC2 instances - primarily m6i.2xlarge (8 CPU, 32GB RAM)
- 3 m6i.2xlarge instances for ingesters and routers (with minimum of 2Gi of local storage)
- 3 m6i.2xlarge instances for queriers
- 1 m6i.2xlarge instance for compactors
- 1 t3.large for the Kubernetes control plane
Your sizing may need to be different based on your environment and workload, but this is a reasonable starting size for your initial testing.
Set up local storage
The InfluxDB ingester pods need local storage to store the Write-Ahead Log (WAL).
The recommended minimum size of the local storage is 2 gibibytes (2Gi
).
Set up an OAuth2 provider
InfluxDB requires access to an OAuth2 authentication service to authenticate user access. InfluxDB Clustered requires that the OAuth2 service supports Device Authorization Flow. InfluxData has tested with Microsoft Entra ID (formerly Azure Active Directory), Keycloak, and Auth0, but any OAuth2 provider should work. To access the OAuth2 server, InfluxDB requires the following OAuth2 connection credentials:
- Client ID
- JWKS endpoint
- Device authorization endpoint
- Token endpoint.
Set up client Software
On the system used to configure the cluster (not the cluster itself), install the following:
Configure object storage permissions
Ensure the identity you use to connect to your S3-compatible object store has the correct permissions to allow InfluxDB to perform all the actions it needs to.
Was this page helpful?
Thank you for your feedback!
Support and feedback
Thank you for being part of our community! We welcome and encourage your feedback and bug reports for InfluxDB and this documentation. To find support, use the following resources:
Customers with an annual or support contract can contact InfluxData Support.